javascript
基于 Spring Boot + Cloud 构建微云架构
點擊上方“Java基基”，選擇“設為星標”
做積極的人，而不是積極廢人！
源碼精品專欄
?原創 | Java 2019 超神之路，很肝~
中文詳細注釋的開源項目
RPC 框架 Dubbo 源碼解析
網絡應用框架 Netty 源碼解析
消息中間件 RocketMQ 源碼解析
數據庫中間件 Sharding-JDBC 和 MyCAT 源碼解析
作業調度中間件 Elastic-Job 源碼解析
分布式事務中間件 TCC-Transaction 源碼解析
Eureka 和 Hystrix 源碼解析
Java 并發源碼
來源：?my.oschina.net/u/3636867/blog/1802517
前言
Spring 頂級框架
WHAT - 什么是微服務
HOW - 怎么具體實踐微服務
So What - 思考
前言
首先，最想說的是，當你要學習一套最新的技術時，官網的英文文檔是學習的最佳渠道。因為網上流傳的多數資料是官網翻譯而來，很多描述的重點也都偏向于作者自身碰到的問題，這樣就很容易讓你理解和操作出現偏差，最開始我就進入了這樣誤區。官網的技術導讀真的描述的很詳細，雖然對于我們看英文很費勁，但如果英文不是很差，請選擇沉下心去讀，你一定能收獲好多。
我的學習是先從Spring boot開始的，然后接觸到微服務架構，當然，這一切最大的啟迪還是感謝我的一個老師，是他給我指明了新的道路，讓我眼前一亮，再次感謝。
Spring 頂級框架
談及微服務，作為當前主流的企業框架Spring，它提供了一整套相關的頂級項目，能讓開發者快速的上手實現自己的應用，今天就介紹下Spring旗下各個頂級項目：
Spring IO platform :用于系統部署，是可集成的，構建現代化應用的版本平臺，具體來說當你使用maven dependency引入spring jar包時它就在工作了。
Spring Boot :旨在簡化創建產品級的 Spring 應用和服務，簡化了配置文件，使用嵌入式web服務器，含有諸多開箱即用微服務功能，可以和spring cloud聯合部署。
Spring Framework :即通常所說的spring 框架，是一個開源的Java/Java EE全功能棧應用程序框架，其它spring項目如spring boot也依賴于此框架。
Spring Cloud ：微服務工具包，為開發者提供了在分布式系統的配置管理、服務發現、斷路器、智能路由、微代理、控制總線等開發工具包。
Spring XD ：是一種運行時環境（服務器軟件，非開發框架），組合spring技術，如spring batch、spring boot、spring data，采集大數據并處理。
Spring Data ：是一個數據訪問及操作的工具包，封裝了很多種數據及數據庫的訪問相關技術，包括：jdbc、Redis、MongoDB、Neo4j等。
Spring Batch ：批處理框架，或說是批量任務執行管理器，功能包括任務調度、日志記錄/跟蹤等。
Spring Security ：是一個能夠為基于Spring的企業應用系統提供聲明式的安全訪問控制解決方案的安全框架。
Spring Integration ：面向企業應用集成（EAI/ESB）的編程框架，支持的通信方式包括HTTP、FTP、TCP/UDP、JMS、RabbitMQ、Email等。
Spring Social ：一組工具包，一組連接社交服務API，如Twitter、Facebook、LinkedIn、GitHub等，有幾十個。
Spring AMQP ：消息隊列操作的工具包，主要是封裝了RabbitMQ的操作。
Spring HATEOAS ：是一個用于支持實現超文本驅動的 REST Web 服務的開發庫。
Spring Mobile ：是Spring MVC的擴展，用來簡化手機上的Web應用開發。
Spring for Android ：是Spring框架的一個擴展，其主要目的在乎簡化Android本地應用的開發，提供RestTemplate來訪問Rest服務。
Spring Web Flow ：目標是成為管理Web應用頁面流程的最佳方案，將頁面跳轉流程單獨管理，并可配置。
Spring LDAP ：是一個用于操作LDAP的Java工具包，基于Spring的JdbcTemplate模式，簡化LDAP訪問。
Spring Session ：session管理的開發工具包，讓你可以把session保存到redis等，進行集群化session管理。
Spring Web Services ：是基于Spring的Web服務框架，提供SOAP服務開發，允許通過多種方式創建Web服務。
Spring Shell ：提供交互式的Shell可讓你使用簡單的基于Spring的編程模型來開發命令，比如Spring Roo命令。
Spring Roo ：是一種Spring開發的輔助工具，使用命令行操作來生成自動化項目，操作非常類似于Rails。
Spring Scala ：為Scala語言編程提供的spring框架的封裝（新的編程語言，Java平臺的Scala于2003年底/2004年初發布）。
Spring BlazeDS Integration ：一個開發RIA工具包，可以集成Adobe Flex、BlazeDS、Spring以及Java技術創建RIA。
Spring Loaded ：用于實現java程序和web應用的熱部署的開源工具。
Spring REST Shell ：可以調用Rest服務的命令行工具，敲命令行操作Rest服務。
Spring cloud子項目
目前來說spring主要集中于spring boot（用于開發微服務）和spring cloud相關框架的開發，我們從幾張圖著手理解，然后再具體介紹：
spring cloud子項目包括：
Spring Cloud Config ：配置管理開發工具包，可以讓你把配置放到遠程服務器，目前支持本地存儲、Git以及Subversion。
Spring Cloud Bus ：事件、消息總線，用于在集群（例如，配置變化事件）中傳播狀態變化，可與Spring Cloud Config聯合實現熱部署。
Spring Cloud Netflix ：針對多種Netflix組件提供的開發工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。
Netflix Eureka ：云端負載均衡，一個基于 REST 的服務，用于定位服務，以實現云端的負載均衡和中間層服務器的故障轉移。
Netflix Hystrix ：容錯管理工具，旨在通過控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。
Netflix Zuul ：邊緣服務工具，是提供動態路由，監控，彈性，安全等的邊緣服務。
Netflix Archaius ：配置管理API，包含一系列配置管理API，提供動態類型化屬性、線程安全配置操作、輪詢框架、回調機制等功能。
Spring Cloud for Cloud Foundry ：通過Oauth2協議綁定服務到CloudFoundry，CloudFoundry是VMware推出的開源PaaS云平臺。
Spring Cloud Sleuth ：日志收集工具包，封裝了Dapper,Zipkin和HTrace操作。
Spring Cloud Data Flow ：大數據操作工具，通過命令行方式操作數據流。
Spring Cloud Security ：安全工具包，為你的應用程序添加安全控制，主要是指OAuth2。
Spring Cloud Consul ：封裝了Consul操作，consul是一個服務發現與配置工具，與Docker容器可以無縫集成。
Spring Cloud Zookeeper ：操作Zookeeper的工具包，用于使用zookeeper方式的服務注冊和發現。
Spring Cloud Stream ：數據流操作開發包，封裝了與Redis,Rabbit、Kafka等發送接收消息。
Spring Cloud CLI ：基于 Spring Boot CLI，可以讓你以命令行方式快速建立云組件。
WHAT - 什么是微服務
微服務簡介
微服務的流行，Martin功不可沒，這老頭也是個奇人，特別擅長抽象歸納和制造概念，我覺的這就是最牛逼的markting啊，感覺這也是目前國人欠缺的能力。
Martin Fowler是國際著名的OO專家，敏捷開發方法的創始人之一，現為ThoughtWorks公司的首席科學家.福勒（Martin Fowler），在面向對象分析設計、UML、模式、軟件開發方法學、XP、重構等方面，都是世界頂級的專家，現為Thought Works公司的首席科學家。Thought Works是一家從事企業應用開發和集成的公司。早在20世紀80年代，Fowler就是使用對象技術構建多層企業應用的倡導者，他著有幾本經典書籍：《企業應用架構模式》、《UML精粹》和《重構》等。—— 百度百科
先來看看傳統的web開發方式，通過對比比較容易理解什么是Microservice Architecture。和Microservice相對應的，這種方式一般被稱為Monolithic（比較難傳神的翻譯）。所有的功能打包在一個 WAR包里，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有邏輯。
Monolithic比較適合小項目，優點是：
1、開發簡單直接，集中式管理
2、基本不會重復開發
3、功能都在本地，沒有分布式的管理開銷和調用開銷
它的缺點也非常明顯，特別對于互聯網公司來說（不一一列舉了）：
1、開發效率低：所有的開發在一個項目改代碼，遞交代碼相互等待，代碼沖突不斷
2、代碼維護難：代碼功能耦合在一起，新人不知道何從下手
3、部署不靈活：構建時間長，任何小修改必須重新構建整個項目，這個過程往往很長
4、穩定性不高：一個微不足道的小問題，可以導致整個應用掛掉
5、擴展性不夠：無法滿足高并發情況下的業務需求
所以，現在主流的設計一般會采用Microservice Architecture，就是基于微服務的架構。簡單來說，微服務的目的是有效的拆分應用，實現敏捷開發和部署。
用《The art of scalability》一書里提到的scale cube比較容易理解如何拆分。你看，我們叫分庫分表，別人總結成了scale cube，這就是抽象的能力啊，把復雜的東西用最簡單的概念解釋和總結。X軸代表運行多個負載均衡器之后運行的實例，Y軸代表將應用進一步分解為微服務 （分庫），數據量大時，還可以用Z軸將服務按數據分區（分表）
微服務的具體特征
先看看最官方的定義吧
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services , which may be written in different programming languages and use different data storage technologies.
-- James Lewis and Martin Fowler
把Martin老頭的定義大概的翻譯一下就是下面幾條，這個定義還是太抽象是不是，那就對了，就是要務虛，都說明白了誰還找他付費咨詢啊，這么貴。
一些列的獨立的服務共同組成系統
單獨部署，跑在自己的進程里
每個服務為獨立的業務開發
分布式的管理
Martin自己也說了，每個人對微服務都可以有自己的理解，不過大概的標準還是有一些的。
1、分布式服務組成的系統
2、按照業務而不是技術來劃分組織
3、做有生命的產品而不是項目
4、Smart endpoints and dumb pipes（我的理解是強服務個體和弱通信）
5、自動化運維（DevOps）
6、容錯
7、快速演化
SOA vs Microservice
除了Smart endpoints and dumb pipes都很容易理解對嗎？相信很多人都會問一個問題，這是不是就是SOA換了個概念，掛羊頭賣狗肉啊，有說法把Microservice叫成 Lightway SOA。也有很多傳統磚家跳出來說Microservice就是SOA。其實Martin也沒否認SOA和Microservice的關系。
我個人理解，Microservice是SOA的傳承，但一個最本質的區別就在于Smart endpoints and dumb pipes，或者說是真正的分布式的、去中心化的。Smart endpoints and dumb pipes本質就是去ESB，把所有的“思考”邏輯包括路由、消息解析等放在服務內部（Smart endpoints），去掉一個大一統的ESB，服務間輕（dumb pipes）通信，是比SOA更徹底的拆分。
HOW - 怎么具體實踐微服務
聽上去好像都不錯，具體怎么落地啊？這需要回答下面幾個問題：
1、客戶端如何訪問這些服務？
2、服務之間如何通信？
3、這么多服務，怎么找?
4、服務掛了怎么辦？
5、客戶端如何訪問這些服務？
原來的Monolithic方式開發，所有的服務都是本地的，UI可以直接調用，現在按功能拆分成獨立的服務，跑在獨立的一般都在獨立的虛擬機上的 Java進程了。客戶端UI如何訪問他的？后臺有N個服務，前臺就需要記住管理N個服務，一個服務下線/更新/升級，前臺就要重新部署，這明顯不服務我們 拆分的理念，特別當前臺是移動應用的時候，通常業務變化的節奏更快。另外，N個小服務的調用也是一個不小的網絡開銷。還有一般微服務在系統內部，通常是無 狀態的，用戶登錄信息和權限管理最好有一個統一的地方維護管理（OAuth）。
所以，一般在后臺N個服務和UI之間一般會一個代理或者叫API Gateway，他的作用包括
1、提供統一服務入口，讓微服務對前臺透明
2、聚合后臺的服務，節省流量，提升性能
3、提供安全，過濾，流控等API管理功能
我的理解其實這個API Gateway可以有很多廣義的實現辦法，可以是一個軟硬一體的盒子，也可以是一個簡單的MVC框架，甚至是一個Node.js的服務端。他們最重要的作 用是為前臺（通常是移動應用）提供后臺服務的聚合，提供一個統一的服務出口，解除他們之間的耦合，不過API Gateway也有可能成為單點故障點或者性能的瓶頸。
一般用過Taobao Open Platform的就能很容易的體會，TAO就是這個API Gateway。
服務之間如何通信？
因為所有的微服務都是獨立的Java進程跑在獨立的虛擬機上，所以服務間的通行就是IPC（inter process communication），已經有很多成熟的方案。現在基本最通用的有兩種方式。這幾種方式，展開來講都可以寫本書，而且大家一般都比較熟悉細節了， 就不展開講了。
1、同步調用
2、REST（JAX-RS，Spring Boot）
3、RPC（Thrift, Dubbo）
4、異步消息調用(Kafka, Notify, MetaQ)
一般同步調用比較簡單，一致性強，但是容易出調用問題，性能體驗上也會差些，特別是調用層次多的時候。RESTful和RPC的比較也是一個很有意 思的話題。
一般REST基于HTTP，更容易實現，更容易被接受，服務端實現技術也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要 求，只要封裝了HTTP的SDK就能調用，所以相對使用的廣一些。RPC也有自己的優點，傳輸協議更高效，安全更可控，特別在一個公司內部，如果有統一個 的開發規范和統一的服務框架時，他的開發效率優勢更明顯些。就看各自的技術積累實際條件，自己的選擇了。
而異步消息的方式在分布式系統中有特別廣泛的應用，他既能減低調用服務之間的耦合，又能成為調用之間的緩沖，確保消息積壓不會沖垮被調用方，同時能 保證調用方的服務體驗，繼續干自己該干的活，不至于被后臺性能拖慢。
不過需要付出的代價是一致性的減弱，需要接受數據最終一致性；還有就是后臺服務一般要 實現冪等性，因為消息發送出于性能的考慮一般會有重復（保證消息的被收到且僅收到一次對性能是很大的考驗）；最后就是必須引入一個獨立的broker，如 果公司內部沒有技術積累，對broker分布式管理也是一個很大的挑戰。
這么多服務，怎么找?
在微服務架構中，一般每一個服務都是有多個拷貝，來做負載均衡。一個服務隨時可能下線，也可能應對臨時訪問壓力增加新的服務節點。服務之間如何相互 感知？服務如何管理？這就是服務發現的問題了。
一般有兩類做法，也各有優缺點。基本都是通過zookeeper等類似技術做服務注冊信息的分布式管理。當 服務上線時，服務提供者將自己的服務信息注冊到ZK（或類似框架），并通過心跳維持長鏈接，實時更新鏈接信息。服務調用者通過ZK尋址，根據可定制算法， 找到一個服務，還可以將服務信息緩存在本地以提高性能。當服務下線時，ZK會發通知給服務客戶端。
1、客戶端做：優點是架構簡單，擴展靈活，只對服務注冊器依賴。缺點是客戶端要維護所有調用服務的地址，有技術難度，一般大公司都有成熟的內部框架支持，比如Dubbo。
2、服務端做：優點是簡單，所有服務對于前臺調用方透明，一般在小公司在云服務上部署的應用采用的比較多。
這么多服務，服務掛了怎么辦？
前面提到，Monolithic方式開發一個很大的風險是，把所有雞蛋放在一個籃子里，一榮俱榮，一損俱損。而分布式最大的特性就是網絡是不可靠 的。通過微服務拆分能降低這個風險，不過如果沒有特別的保障，結局肯定是噩夢。
我們剛遇到一個線上故障就是一個很不起眼的SQL計數功能，在訪問量上升 時，導致數據庫load彪高，影響了所在應用的性能，從而影響所有調用這個應用服務的前臺應用。所以當我們的系統是由一系列的服務調用鏈組成的時候，我們 必須確保任一環節出問題都不至于影響整體鏈路。相應的手段有很多：
1、重試機制
2、限流
3、熔斷機制
4、負載均衡
5、降級（本地緩存）
這些方法基本上都很明確通用，就不詳細說明了。
WHY - 微服務的應用
這里有一個圖非常好的總結微服務架構需要考慮的問題，包括
1、API Gateway
2、服務間調用
3、服務發現
4、服務容錯
5、服務部署
6、數據調用
微服務的優點和缺點（或者說挑戰）一樣明顯。
1、優點
2、開發簡單
3、技術棧靈活
4、服務獨立無依賴
5、獨立按需擴展
6、可用性高
7、缺點（挑戰）
8、多服務運維難度
9、系統部署依賴
10、服務間通信成本
11、數據一致性
12、系統集成測試
13、重復工作
14、性能監控
沒有最好的，只有適合自己的。
1、對于大的互聯網公司，微服務架構是血液，是習慣，每家公司都有自己的套路和架構，細節有不同，但是核心理念是通的。
2、對于一般的公司而言，實踐微服務有非常大的技術挑戰，于是乎才有了這么多IT供應商考慮這里的商機。微服務比較適合未來有一定的擴展復雜度，且有 很大用戶增量預期的應用，說人話就是新興的互聯網公司。創業初期，不可能買大量的機器或者很貴的機器，但是又必須考慮應對成功后的巨量的用戶，微服務架構 成了最好的選擇。
So What - 思考**
看到上面的圖，不是不覺得特別的熟悉？其實我們N年前就用的滾瓜爛熟了好不好？褲子都拖了。
其實本來所謂的微服務就是對互聯網在應用技術的一個總結歸納，IT廠商鼓吹所有概念無非是為了生意（business），SOA是，Cloud是，Microservice也是。下面玩笑很有意思的概括了這個情況（我加了第一條線，原圖點擊閱讀原文查看）
所以微服對我們的思考我覺得更多的是思維上的，對已微服務架構，技術上不是問題，意識比工具重要。
1、按照業務 或者客戶需求組織資源（這是最難的）
2、做有生命的產品，而不是項目
3、頭狼戰隊，全棧化
4、后臺服務貫徹Single Responsibility Principle
5、VM->Docker （to PE）
6、DevOps (to PE)
同時，對于開發同學，有這么多的中間件和強大的PE支持固然是好事，我們也需要深入去了解這些中間件背后的原理，知其然知其所以然，設想下，如果我們是一個小公司的CTO，離開的阿里的大環境，在有限的技術資源如何通過開源技術實施微服務？
最后，一般提到微服務都離不開DevOps和Docker，理解微服務架構是核心，devops和docker是工具，是手段。下次在抽時間再學習整理下。
歡迎加入我的知識星球，一起探討架構，交流源碼。加入方式，長按下方二維碼噢：
已在知識星球更新源碼解析如下：
最近更新《芋道 SpringBoot 2.X 入門》系列，已經 20 余篇，覆蓋了?MyBatis、Redis、MongoDB、ES、分庫分表、讀寫分離、SpringMVC、Webflux、權限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能測試等等內容。
提供近 3W 行代碼的 SpringBoot 示例，以及超 4W 行代碼的電商微服務項目。
獲取方式：點“在看”，關注公眾號并回復?666?領取，更多內容陸續奉上。
如果你喜歡這篇文章，喜歡，轉發。
生活很美好，明天見(｡･ω･｡)ﾉ?
總結
以上是生活随笔為你收集整理的基于 Spring Boot + Cloud 构建微云架构的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【开启SSH】小米AIoT路由器 AC2
- 下一篇： java.lang.NoSuchMeth