基於SpringBoot和SpringCloud實現微服務架構

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服務。

SpringCloud 的子項目

目前來說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，可以讓你以命令行方式快速建立雲組件。

什麼是微服務？

微服務簡介
微服務的流行，Martin功不可沒，這老頭也是個奇人，特別擅長抽象歸納和製造概念，我覺的這就是最牛逼的markting啊，感覺這也是目前國人欠缺的能力。

先來看看傳統的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軸將服務按數據分區（分表）

怎麼具體實現微服務

聽上去好像都不錯，具體怎麼落地啊？這需要回答下面幾個問題：

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、降級（本地緩存）

這些方法基本上都很明確通用，就不詳細說明了。

服務的應用

這裏有一個圖非常好的總結微服務架構需要考慮的問題，包括

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供應商考慮這裏的商機。微服務比較適合未來有一定的擴展複雜度，且有 很大用戶增量預期的應用，說人話就是新興的互聯網公司。創業初期，不可能買大量的機器或者很貴的機器，但是又必須考慮應對成功後的巨量的用戶，微服務架構 成了最好的選擇。

思考

看到上面的圖，不是不覺得特別的熟悉？其實我們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是工具，是手段。下次在抽時間再學習整理下。