《關於微服務》

今年有人提出了2018年微服務將瘋狂至死，可見微服務的爭論從未中止過。在這我將本身對微服務的理解整理了一下，但願對你們有所幫助。

1）一組小的服務（大小沒有特別的標準，只要同一團隊的工程師理解服務的標識一致便可）

2）獨立的進程（java的tomcat，nodejs等）

3）輕量級的通訊（不是soap，是http協議）

4）基於業務能力（相似用戶服務，商品服務等等）

5）獨立部署（迭代速度快）

6）無集中式管理（無須統一技術棧，能夠根據不一樣的服務或者團隊進行靈活選擇）

ps：微服務的先行者Netflix公司，開源了一些好的微服務框架，後續會有介紹。

利：

強模塊邊界 。（模塊化的演化過程：類-->組件/類庫（sdk）-->服務(service)，方式愈來愈靈活）

可獨立部署。

技術多樣性。

弊：

分佈式複雜性。

最終一致性。（各個服務的團隊，數據也是分散式治理，會出現不一致的問題）

運維複雜性。

測試複雜性。

從生產力和系統的複雜性這兩個方面來看。公司一開始的時候，業務複雜性不高，這時候是驗證商業模式的時候，業務簡單，用單體服務反而生產力很高。隨着公司的發展，業務複雜性慢慢提升，這時候就能夠採用微服務來提高生產力了。至於這個轉化的點，須要團隊的架構師來進行各方面衡量，就我的經驗而言，團隊發展到百人以上，採用微服務就頗有必要了。

有些架構師是具備微服務架構能力，因此設計系統時就直接設計成了微服務，而不是經過單服務慢慢演化發展成微服務。在這裏我並不推薦這種作法，由於一開始對業務領域並非很瞭解，而且業務模式尚未獲得驗證，這時候上微服務風險比較高，頗有可能失敗。因此建議你們在單服務的應用成熟時，而且對業務領域比較熟悉的時候，若是發現單服務沒法適應業務發展時，再考慮微服務的設計和架構。

如上圖左邊，傳統的企業中，團隊是按職能劃分的。開發一個項目時，會從不一樣的職能團隊找人進行開發，開發完成後，再各自回到本身的職能團隊，這種模式實踐證實，效率仍是比較低的。

如上圖右邊，圍繞每一個業務線或產品，按服務劃分團隊。團隊成員從架構到運維，造成一個完整的閉環。一直圍繞在產品周圍，進行不斷的迭代。不會像傳統的團隊同樣離開。這樣開發效率會比較高。至於這種團隊的規模，建議按照亞馬遜的兩個披薩原則，大概10人左右比較好。

中臺戰略的由來：馬雲2015年去歐洲的一家公司supersell參觀，發現這個公司的創新能力很是強，團隊的規模很小，可是開發效率很高。他們就是採用中臺戰略。馬雲感觸很深，回國後就在集團內部推出了中臺戰略。

簡單的理解就是把傳統的先後臺體系中的後臺進行了細分。阿里巴巴提出了大中臺小前臺的戰略。就是強化業務和技術中臺，把前端的應用變得更小更靈活。當中臺越強大，能力就越強，越能更好的快速響應前臺的業務需求。打個比喻，就是土壤越肥沃，越適合生長不一樣的生物，打造好的生態系統。

每一個公司的服務分層都不相同，有的公司服務沒有分層，有的怎分層不少。目前業界沒有統一的標準。

下面推薦一個比較容易理解的兩層結構。

1：基礎服務： 好比一個電商網站，商品服務和訂單服務就屬於基礎服務（核心領域服務）。緩存服務，監控服務，消息隊列等也屬於基礎服務（公共服務）

2：聚合服務 ：例如網關服務就算一種聚合服務（適配服務）。

這是一種邏輯劃分，不是物理劃分，實際設計的東西不少很複雜。

下圖是一個成型的互聯網微服務的架構體系：

1：接入層 負載均衡做用，運維團隊負責

2：網關層 反向路由，安全驗證，限流等

3：業務服務層 基礎服務和領域服務

4：支撐服務層

5：平臺服務

6：基礎設施層 運維團隊負責。（或者阿里雲）

第一種：以下圖所示，傳統的服務發現（大部分公司的作法）。服務上線後，通知運維，申請域名，配置路由。調用方經過dns域名解析，通過負載均衡路由，進行服務訪問。缺點： LB的單點風險，服務穿透LB，性能也不是太好

第二種：也叫客戶端發現方式。以下圖所示。經過服務註冊的方式，服務提供者先註冊服務。消費者經過註冊中心獲取相應服務。

而且把LB的功能移動到了消費者的進程內，消費者根據自身路由去獲取相應服務。優勢是，沒有了LB單點問題，也沒有了LB的中間一跳，性能也比較好。可是這種方式有一個很是明顯的缺點就是具備很是強的耦合性。針對不一樣的語言，每一個服務的客戶端都得實現一套服務發現的功能。

第三種：也叫服務端發現方式，以下圖所示。和第二種很類似。可是LB功能獨立進程單獨部署，因此解決了客戶端多語言開發的問題。惟一的缺點就是運維成比較高，每一個節點都得部署一個LB的代理，例如nginx。

網關就比如一個公司的門衛。屏蔽內部細節，統一對外服務接口。

下圖是一個網關所處位置的示例圖。

核心就是一個servlet，經過filter機制實現的。主要分爲三類過濾器：前置過濾器，過濾器和後置過濾器。

主要特點是，這些過濾器能夠動態插拔，就是若是須要增長減小過濾器，能夠不用重啓，直接生效。原理就是：經過一個db維護過濾器（上圖藍色部分），若是增長過濾器，就將新過濾器編譯完成後push到db中，有線程會按期掃描db，發現新的過濾器後，會上傳到網關的相應文件目錄下，並通知過濾器loader進行加載相應的過濾器。

整個網關調用的流程

上圖從左變http Request開始通過三類過濾器，最終到最右邊的Http Response，這就是Zull網關的整個調用流程。

整個微服務的路由發現體系，通常由服務註冊中心和網關兩部分組成。以NetFlix爲例子，Eureka和Zull這兩個組件支撐了netFlix整個的路由發現體系。以下圖所示，首先外部請求發送到網關，網關去服務註冊中心獲取相應的服務，進行調用。其次內部服務間的調用，也經過服務註冊中心進行的

目前大部分公司都是把配置寫到配置文件中，遇到修改配置的狀況，成本很高。而且沒有修改配置的記錄，出問題很難追溯。配置中心就接解決了以上的問題。

可配置內容：數據庫鏈接，業務參數等等

配置中心就是一個web服務，配置人員經過後臺頁面修改配置，各個服務就會獲得新的配置參數。實現方式主要有兩種，一種是push，另外一種是pull。兩張方式各有優缺點。push實時性較好，可是遇到網絡抖動，會丟失消息。pull不會丟失消息可是實時性差一些。你們能夠同時兩種方式使用，實現一個比較好的效果。以下圖所示，這是一個國內知名互聯網公司的配置中心架構圖。

開源地址：http://github.com/ctripcorp/appollo

內部一些核心服務，性能要求比較高的能夠採用RPC，對外服務的通常能夠採用rest。

微服務不少的時候，就須要有治理了。一個好的微服務框架通常分爲如下14個部分。以下圖所示。這就是開篇所說的，微服務涉及的東西不少，有些初創公司和業務不成熟的產品是不太適合的，成本比較高。

目前國內比較好的微服務框架就是阿里巴巴的DUBBO了,國外的就是spring cloud,你們能夠去研究一下.

監控是微服務治理的重要環節。通常分爲如下四層。以下圖所示。

監控的內容分爲五個部分：日誌監控，Metrics監控（服務調用狀況），調用鏈監控，告警系統和健康檢查。

日誌監控，國內經常使用的就是ELK+KAFKA來實現。健康檢查和Metrics，像spring boot會自帶。Nagios也是一個很好的開源監控框架。

調用鏈監控是用來追蹤微服務以前依賴的路徑和問題定位。例如阿里的鷹眼系統。主要原理就是子節點會記錄父節點的id信息。

下圖是目前比較流行的調用鏈監控框架。

假設服務A依賴服務B和服務C，而B服務和C服務有可能繼續依賴其餘的服務，繼續下去會使得調用鏈路過長。若是在A的鏈路上某個或幾個被調用的子服務不可用或延遲較高，則會致使調用A服務的請求被堵住，堵住的請求會消耗佔用掉系統的線程、io等資源，當該類請求愈來愈多，佔用的計算機資源愈來愈多的時候，會致使系統瓶頸出現，形成其餘的請求一樣不可用，最終致使業務系統崩潰。

通常狀況對於服務依賴的保護主要有兩種方式：熔斷和限流。目前最流行的就是Hystrix的熔斷框架。

下圖是Hystrix的斷路器原理圖：

限流方式能夠採用zuul的API限流方法。http://github.com/ctripcorp/appollo

隨着微服務的流行，容器技術也相應的被你們重視起來。容器技術主要解決了如下兩個問題：

1：環境一致性問題。例如java的jar/war包部署會依賴於環境的問題（操着系統的版本，jdk版本問題）。

2：鏡像部署問題。例如java，rubby，nodejs等等的發佈系統是不同的，每一個環境都得很麻煩的部署一遍，採用docker鏡像，就屏蔽了這類問題。

下圖是Docker容器部署的一個完整過程。

更重要的是，擁有如此多服務的集羣環境遷移、複製也很是輕鬆，只需選擇好各服務對應的Docker服務鏡像、配置好相互之間訪問地址就能很快搭建出一份徹底同樣的新集羣。

目前基於容器的調度平臺有Kubernetes，mesos，omega。下圖是mesos的一個簡單架構示意圖。

下圖是一個完整的容器發佈體系