微服務(MicroServices)架構是當前互聯網業界的一個技術熱點，圈里有不少同行朋友當前有計劃在各自公司開展微服務化體系建設，他們都有相同的疑問：一個微服務架構有哪些技術關注點(technical concerns)？需要哪些基礎框架或組件來支持微服務架構？這些框架或組件該如何選型？筆者之前在兩家大型互聯網公司參與和主導過大型服務化體系和框架建設，同時在這塊也投入了很多時間去學習和研究，有一些經驗和學習心得，可以和大家一起分享。

服務注冊、發現、負載均衡和健康檢查

和單塊(Monolithic)架構不同，微服務架構是由一系列職責單一的細粒度服務構成的分布式網狀結構，服務之間通過輕量機制進行通信，這時候必然引入一個服務注冊發現問題，也就是說服務提供方要注冊通告服務地址，服務的調用方要能發現目標服務，同時服務提供方一般以集群方式提供服務，也就引入了負載均衡和健康檢查問題。根據負載均衡LB所在位置的不同，目前主要的服務注冊、發現和負載均衡方案有三種：

第一種是集中式LB方案，如下圖Fig 1，在服務消費者和服務提供者之間有一個獨立的LB，LB通常是專門的硬件設備如F5，或者基于軟件如LVS，HAproxy等實現。LB上有所有服務的地址映射表，通常由運維配置注冊，當服務消費方調用某個目標服務時，它向LB發起請求，由LB以某種策略（比如Round-Robin）做負載均衡后將請求轉發到目標服務。LB一般具備健康檢查能力，能自動摘除不健康的服務實例。服務消費方如何發現LB呢？通常的做法是通過DNS，運維人員為服務配置一個DNS域名，這個域名指向LB。

Fig 1, 集中式LB方案

集中式LB方案實現簡單，在LB上也容易做集中式的訪問控制，這一方案目前還是業界主流。集中式LB的主要問題是單點問題，所有服務調用流量都經過LB，當服務數量和調用量大的時候，LB容易成為瓶頸，且一旦LB發生故障對整個系統的影響是災難性的。另外，LB在服務消費方和服務提供方之間增加了一跳(hop)，有一定性能開銷。

第二種是進程內LB方案，針對集中式LB的不足，進程內LB方案將LB的功能以庫的形式集成到服務消費方進程里頭，該方案也被稱為軟負載(Soft Load Balancing)或者客戶端負載方案，下圖Fig 2展示了這種方案的工作原理。這一方案需要一個服務注冊表(Service Registry)配合支持服務自注冊和自發現，服務提供方啟動時，首先將服務地址注冊到服務注冊表（同時定期報心跳到服務注冊表以表明服務的存活狀態，相當于健康檢查），服務消費方要訪問某個服務時，它通過內置的LB組件向服務注冊表查詢（同時緩存并定期刷新）目標服務地址列表，然后以某種負載均衡策略選擇一個目標服務地址，最后向目標服務發起請求。這一方案對服務注冊表的可用性(Availability)要求很高，一般采用能滿足高可用分布式一致的組件（例如Zookeeper, Consul, Etcd等）來實現。

Fig 2, 進程內LB方案

進程內LB方案是一種分布式方案，LB和服務發現能力被分散到每一個服務消費者的進程內部，同時服務消費方和服務提供方之間是直接調用，沒有額外開銷，性能比較好。但是，該方案以客戶庫(Client Library)的方式集成到服務調用方進程里頭，如果企業內有多種不同的語言棧，就要配合開發多種不同的客戶端，有一定的研發和維護成本。另外，一旦客戶端跟隨服務調用方發布到生產環境中，后續如果要對客戶庫進行升級，勢必要求服務調用方修改代碼并重新發布，所以該方案的升級推廣有不小的阻力。

進程內LB的案例是Netflix的開源服務框架，對應的組件分別是：Eureka服務注冊表，Karyon服務端框架支持服務自注冊和健康檢查，Ribbon客戶端框架支持服務自發現和軟路由。另外，阿里開源的服務框架Dubbo也是采用類似機制。

第三種是主機獨立LB進程方案，該方案是針對第二種方案的不足而提出的一種折中方案，原理和第二種方案基本類似，不同之處是，他將LB和服務發現功能從進程內移出來，變成主機上的一個獨立進程，主機上的一個或者多個服務要訪問目標服務時，他們都通過同一主機上的獨立LB進程做服務發現和負載均衡，見下圖Fig 3。

Fig 3 主機獨立LB進程方案

該方案也是一種分布式方案，沒有單點問題，一個LB進程掛了只影響該主機上的服務調用方，服務調用方和LB之間是進程內調用，性能好，同時，該方案還簡化了服務調用方，不需要為不同語言開發客戶庫，LB的升級不需要服務調用方改代碼。該方案的不足是部署較復雜，環節多，出錯調試排查問題不方便。

該方案的典型案例是Airbnb的SmartStack服務發現框架，對應組件分別是：Zookeeper作為服務注冊表，Nerve獨立進程負責服務注冊和健康檢查，Synapse/HAproxy獨立進程負責服務發現和負載均衡。Google最新推出的基于容器的PaaS平臺Kubernetes，其內部服務發現采用類似的機制。

服務前端路由

微服務除了內部相互之間調用和通信之外，最終要以某種方式暴露出去，才能讓外界系統（例如客戶的瀏覽器、移動設備等等）訪問到，這就涉及服務的前端路由，對應的組件是服務網關(Service Gateway)，見圖Fig 4，網關是連接企業內部和外部系統的一道門，有如下關鍵作用：

1. 服務反向路由，網關要負責將外部請求反向路由到內部具體的微服務，這樣雖然企業內部是復雜的分布式微服務結構，但是外部系統從網關上看到的就像是一個統一的完整服務，網關屏蔽了后臺服務的復雜性，同時也屏蔽了后臺服務的升級和變化。
2. 安全認證和防爬蟲，所有外部請求必須經過網關，網關可以集中對訪問進行安全控制，比如用戶認證和授權，同時還可以分析訪問模式實現防爬蟲功能，網關是連接企業內外系統的安全之門。
3. 限流和容錯，在流量高峰期，網關可以限制流量，保護后臺系統不被大流量沖垮，在內部系統出現故障時，網關可以集中做容錯，保持外部良好的用戶體驗。
4. 監控，網關可以集中監控訪問量，調用延遲，錯誤計數和訪問模式，為后端的性能優化或者擴容提供數據支持。
5. 日志，網關可以收集所有的訪問日志，進入后臺系統做進一步分析。

Fig 4, 服務網關

除以上基本能力外，網關還可以實現線上引流，線上壓測，線上調試(Surgical debugging)，金絲雀測試(Canary Testing)，數據中心雙活(Active-Active HA)等高級功能。

網關通常工作在7層，有一定的計算邏輯，一般以集群方式部署，前置LB進行負載均衡。

開源的網關組件有Netflix的Zuul，特點是動態可熱部署的過濾器(filter)機制，其它如HAproxy，Nginx等都可以擴展作為網關使用。

在介紹過服務注冊表和網關等組件之后，我們可以通過一個簡化的微服務架構圖(Fig 5)來更加直觀地展示整個微服務體系內的服務注冊發現和路由機制，該圖假定采用進程內LB服務發現和負載均衡機制。在下圖Fig 5的微服務架構中，服務簡化為兩層，后端通用服務（也稱中間層服務Middle Tier Service）和前端服務（也稱邊緣服務Edge Service，前端服務的作用是對后端服務做必要的聚合和裁剪后暴露給外部不同的設備，如PC，Pad或者Phone）。后端服務啟動時會將地址信息注冊到服務注冊表，前端服務通過查詢服務注冊表就可以發現然后調用后端服務；前端服務啟動時也會將地址信息注冊到服務注冊表，這樣網關通過查詢服務注冊表就可以將請求路由到目標前端服務，這樣整個微服務體系的服務自注冊自發現和軟路由就通過服務注冊表和網關串聯起來了。如果以面向對象設計模式的視角來看，網關類似Proxy代理或者Façade門面模式，而服務注冊表和服務自注冊自發現類似IoC依賴注入模式，微服務可以理解為基于網關代理和注冊表IoC構建的分布式系統。

Fig 5, 簡化的微服務架構圖

服務容錯

當企業微服務化以后，服務之間會有錯綜復雜的依賴關系，例如，一個前端請求一般會依賴于多個后端服務，技術上稱為1 -> N扇出(見圖Fig 6)。在實際生產環境中，服務往往不是百分百可靠，服務可能會出錯或者產生延遲，如果一個應用不能對其依賴的故障進行容錯和隔離，那么該應用本身就處在被拖垮的風險中。在一個高流量的網站中，某個單一后端一旦發生延遲，可能在數秒內導致所有應用資源(線程，隊列等)被耗盡，造成所謂的雪崩效應(Cascading Failure，見圖Fig 7)，嚴重時可致整個網站癱瘓。

Fig 6, 服務依賴

Fig 7, 高峰期單個服務延遲致雪崩效應

經過多年的探索和實踐，業界在分布式服務容錯一塊探索出了一套有效的容錯模式和最佳實踐，主要包括：

1. 電路熔斷器模式(Circuit Breaker Patten), 該模式的原理類似于家里的電路熔斷器，如果家里的電路發生短路，熔斷器能夠主動熔斷電路，以避免災難性損失。在分布式系統中應用電路熔斷器模式后，當目標服務慢或者大量超時，調用方能夠主動熔斷，以防止服務被進一步拖垮；如果情況又好轉了，電路又能自動恢復，這就是所謂的彈性容錯，系統有自恢復能力。下圖Fig 8是一個典型的具備彈性恢復能力的電路保護器狀態圖，正常狀態下，電路處于關閉狀態(Closed)，如果調用持續出錯或者超時，電路被打開進入熔斷狀態(Open)，后續一段時間內的所有調用都會被拒絕(Fail Fast)，一段時間以后，保護器會嘗試進入半熔斷狀態(Half-Open)，允許少量請求進來嘗試，如果調用仍然失敗，則回到熔斷狀態，如果調用成功，則回到電路閉合狀態。



Fig 8, 彈性電路保護狀態圖

2. 艙壁隔離模式(Bulkhead Isolation Pattern)，顧名思義，該模式像艙壁一樣對資源或失敗單元進行隔離，如果一個船艙破了進水，只損失一個船艙，其它船艙可以不受影響 。線程隔離(Thread Isolation)就是艙壁隔離模式的一個例子，假定一個應用程序A調用了Svc1/Svc2/Svc3三個服務，且部署A的容器一共有120個工作線程，采用線程隔離機制，可以給對Svc1/Svc2/Svc3的調用各分配40個線程，當Svc2慢了，給Svc2分配的40個線程因慢而阻塞并最終耗盡，線程隔離可以保證給Svc1/Svc3分配的80個線程可以不受影響，如果沒有這種隔離機制，當Svc2慢的時候，120個工作線程會很快全部被對Svc2的調用吃光，整個應用程序會全部慢下來。
3. 限流(Rate Limiting/Load Shedder)，服務總有容量限制，沒有限流機制的服務很容易在突發流量(秒殺，雙十一)時被沖垮。限流通常指對服務限定并發訪問量，比如單位時間只允許100個并發調用，對超過這個限制的請求要拒絕并回退。
4. 回退(fallback)，在熔斷或者限流發生的時候，應用程序的后續處理邏輯是什么？回退是系統的彈性恢復能力，常見的處理策略有，直接拋出異常，也稱快速失敗(Fail Fast)，也可以返回空值或缺省值，還可以返回備份數據，如果主服務熔斷了，可以從備份服務獲取數據。

Netflix將上述容錯模式和最佳實踐集成到一個稱為Hystrix的開源組件中，凡是需要容錯的依賴點(服務，緩存，數據庫訪問等)，開發人員只需要將調用封裝在Hystrix Command里頭，則相關調用就自動置于Hystrix的彈性容錯保護之下。Hystrix組件已經在Netflix經過多年運維驗證，是Netflix微服務平臺穩定性和彈性的基石，正逐漸被社區接受為標準容錯組件。

服務框架

微服務化以后，為了讓業務開發人員專注于業務邏輯實現，避免冗余和重復勞動，規范研發提升效率，必然要將一些公共關注點推到框架層面。服務框架(Fig 9)主要封裝公共關注點邏輯，包括：

Fig 9, 服務框架

1. 服務注冊、發現、負載均衡和健康檢查，假定采用進程內LB方案，那么服務自注冊一般統一做在服務器端框架中，健康檢查邏輯由具體業務服務定制，框架層提供調用健康檢查邏輯的機制，服務發現和負載均衡則集成在服務客戶端框架中。
2. 監控日志，框架一方面要記錄重要的框架層日志、metrics和調用鏈數據，還要將日志、metrics等接口暴露出來，讓業務層能根據需要記錄業務日志數據。在運行環境中，所有日志數據一般集中落地到企業后臺日志系統，做進一步分析和處理。
3. REST/RPC和序列化，框架層要支持將業務邏輯以HTTP/REST或者RPC方式暴露出來，HTTP/REST是當前主流API暴露方式，在性能要求高的場合則可采用Binary/RPC方式。針對當前多樣化的設備類型(瀏覽器、普通PC、無線設備等)，框架層要支持可定制的序列化機制，例如，對瀏覽器，框架支持輸出Ajax友好的JSON消息格式，而對無線設備上的Native App，框架支持輸出性能高的Binary消息格式。
4. 配置，除了支持普通配置文件方式的配置，框架層還可集成動態運行時配置，能夠在運行時針對不同環境動態調整服務的參數和配置。
5. 限流和容錯，框架集成限流容錯組件，能夠在運行時自動限流和容錯，保護服務，如果進一步和動態配置相結合，還可以實現動態限流和熔斷。
6. 管理接口，框架集成管理接口，一方面可以在線查看框架和服務內部狀態，同時還可以動態調整內部狀態，對調試、監控和管理能提供快速反饋。Spring Boot微框架的Actuator模塊就是一個強大的管理接口。
7. 統一錯誤處理，對于框架層和服務的內部異常，如果框架層能夠統一處理并記錄日志，對服務監控和快速問題定位有很大幫助。
8. 安全，安全和訪問控制邏輯可以在框架層統一進行封裝，可做成插件形式，具體業務服務根據需要加載相關安全插件。
9. 文檔自動生成，文檔的書寫和同步一直是一個痛點，框架層如果能支持文檔的自動生成和同步，會給使用API的開發和測試人員帶來極大便利。Swagger是一種流行Restful API的文檔方案。

當前業界比較成熟的微服務框架有Netflix的Karyon/Ribbon，Spring的Spring Boot/Cloud，阿里的Dubbo等。

運行期配置管理

服務一般有很多依賴配置，例如訪問數據庫有連接字符串配置，連接池大小和連接超時配置，這些配置在不同環境(開發/測試/生產)一般不同，比如生產環境需要配連接池，而開發測試環境可能不配，另外有些參數配置在運行期可能還要動態調整，例如，運行時根據流量狀況動態調整限流和熔斷閥值。目前比較常見的做法是搭建一個運行時配置中心支持微服務的動態配置，簡化架構如下圖(Fig 10):

Fig 10, 服務配置中心

動態配置存放在集中的配置服務器上，用戶通過管理界面配置和調整服務配置，具體服務通過定期拉(Scheduled Pull)的方式或者服務器推(Server-side Push)的方式更新動態配置，拉方式比較可靠，但會有延遲同時有無效網絡開銷(假設配置不常更新)，服務器推方式能及時更新配置，但是實現較復雜，一般在服務和配置服務器之間要建立長連接。配置中心還要解決配置的版本控制和審計問題，對于大規模服務化環境，配置中心還要考慮分布式和高可用問題。

配置中心比較成熟的開源方案有百度的Disconf，360的QConf，Spring的Cloud Config和阿里的Diamond等。

Netflix的微服務框架

Netflix是一家成功實踐微服務架構的互聯網公司，幾年前，Netflix就把它的幾乎整個微服務框架棧開源貢獻給了社區，這些框架和組件包括：

1. Eureka:　服務注冊發現框架
2. Zuul:　服務網關
3. Karyon:　服務端框架
4. Ribbon:　客戶端框架
5. Hystrix: 服務容錯組件
6. Archaius: 服務配置組件
7. Servo: Metrics組件
8. Blitz4j: 日志組件

下圖Fig 11展示了基于這些組件構建的一個微服務框架體系，來自recipes-rss。

Fig 11, 基于Netflix開源組件的微服務框架

Netflix的開源框架組件已經在Netflix的大規模分布式微服務環境中經過多年的生產實戰驗證，正逐步被社區接受為構造微服務框架的標準組件。Pivotal去年推出的Spring Cloud開源產品，主要是基于對Netflix開源組件的進一步封裝，方便Spring開發人員構建微服務基礎框架。對于一些打算構建微服務框架體系的公司來說，充分利用或參考借鑒Netflix的開源微服務組件(或Spring Cloud)，在此基礎上進行必要的企業定制，無疑是通向微服務架構的捷徑。