“ 微服務(MicroServices)架構是當前網際網路業界的一個技術熱點，大家是否明白一個微服務架構有哪些技術關注點(technical concerns)？需要哪些基礎框架或元件來支援微服務架構？這些框架或元件該如何選型呢？”

在公眾號中專門有微服務選單欄，裡面講解了Spring boot和Spring Cloud的一些入門案例。但是並沒有對微服務技術有一個深入的介紹，今天我們就來看一下微服務的技術架構。

一：服務註冊和發現，負載均衡和健康檢查

微服務架構和單塊架構（將整個應用作為一個整體，部署在同一個Web 容器，如Tomcat 或者Jetty 中）不同，是因為微服務架構是由一系列職責單一的細粒度服務構成的分散式網狀結構，服務之間通過輕量機制進行通訊。但是你是否想過服務之間通過輕量機制進行通訊必然引入服務註冊和發現的問題，服務提供方要註冊通告服務地址，服務的呼叫方要能發現目標服務。

服務的呼叫方要能發現目標服務，同時服務提供方一般以叢集方式提供服務，也就引入了負載均衡和健康檢查問題。根據負載均衡LB所在位置的不同，目前主要的服務註冊、發現和負載均衡方案有三種：

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

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

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

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

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

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

該方案也是一種分散式方案，沒有單點問題，一個LB程序掛了隻影響該主機上的服務呼叫方，效能好，同時，該方案還簡化了服務呼叫方，不需要為不同語言開發客戶庫，LB的升級不需要服務呼叫方改程式碼。該方案的不足是部署較複雜，環節多，出錯除錯排查問題不方便。

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

二：服務前端路由

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

1.服務反向路由，閘道器要負責將外部請求反向路由到內部具體的微服務，這樣雖然企業內部是複雜的分散式微服務結構，但是外部系統從閘道器上看到的就像是一個統一的完整服務，閘道器遮蔽了後臺服務的複雜性，同時也遮蔽了後臺服務的升級和變化。

2.安全認證和防爬蟲，所有外部請求必須經過閘道器，閘道器可以集中對訪問進行安全控制，比如使用者認證和授權，同時還可以分析訪問模式實現防爬蟲功能，閘道器是連線企業內外系統的安全之門。

3.限流和容錯，在流量高峰期，閘道器可以限制流量，保護後臺系統不被大流量沖垮，在內部系統出現故障時，閘道器可以集中做容錯，保持外部良好的使用者體驗。

4.監控，閘道器可以集中監控訪問量，呼叫延遲，錯誤計數和訪問模式，為後端的效能優化或者擴容提供資料支援。

5.日誌，閘道器可以收集所有的訪問日誌，進入後臺系統做進一步分析。

除以上基本能力外，閘道器還可以實現線上引流，線上壓測，線上除錯(Surgical debugging)，金絲雀測試(Canary Testing)，資料中心雙活(Active-Active HA)等高階功能。

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

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

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

三：服務容錯

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

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

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

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微服務平臺穩定性和彈性的基石，正逐漸被社群接受為標準容錯元件

四：Netflix的微服務框架

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

1.Eureka:　服務註冊發現框架

2.Zuul:　服務閘道器

3.Karyon:　服務端框架

4.Ribbon:　客戶端框架

5.Hystrix: 服務容錯元件

6.Archaius: 服務配置元件

7.Servo: Metrics元件

8.Blitz4j: 日誌元件

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

今天小程式更新題庫為：

1.什麼是自旋鎖

2.說一說Synchronized

3.什麼是偏向鎖？

4.什麼是輕量級鎖？

5.lock和synchronize對比

更多文章請關注公眾號：每天學Java。想獲得更多最新面試提醒請進入小程式：每天學Java

 公眾號二維碼：                                                                                          小程式二維碼：