作者：古霜卡比
前言
本文将介紹微服務架構和相關的元件，介紹他們是什麼以及為什麼要使用微服務架構和這些元件。本文側重于簡明地表達微服務架構的全局圖景，是以不會涉及具體如何使用元件等細節。
要了解微服務，首先要先了解不是微服務的那些。通常跟微服務相對的是單體應用，即将所有功能都打包成在一個獨立單元的應用程式。從單體應用到微服務并不是一蹴而就的，這是一個逐漸演變的過程。本文将以一個網上超市應用為例來說明這一過程。
最初的需求
幾年前，小明和小皮一起創業做網上超市。小明負責程式開發，小皮負責其他事宜。當時網際網路還不發達，網上超市還是藍海。隻要功能實作了就能随便賺錢。是以他們的需求很簡單，隻需要一個網站挂在公網，使用者能夠在這個網站上浏覽商品、購買商品；另外還需一個管理背景，可以管理商品、使用者、以及訂單資料。
功能清單：
網站
使用者注冊、登入功能
商品展示
下單
管理背景
使用者管理
商品管理
訂單管理
由于需求簡單，小明左手右手一個慢動作，網站就做好了。管理背景出于安全考慮，不和網站做在一起，小明右手左手慢動作重播，管理網站也做好了。總體架構圖如下：
小明揮一揮手，找了家雲服務部署上去，網站就上線了。上線後好評如潮，深受各類肥宅喜愛。小明小皮美滋滋地開始躺着收錢。
随着業務發展……
好景不長，沒過幾天，各類網上超市緊跟着拔地而起，對小明小皮造成了強烈的沖擊。
在競争的壓力下，小明小皮決定開展一些營銷手段：
開展促銷活動。比如元旦全場打折，春節買二送一，情人節狗糧優惠券等等。
拓展管道，新增移動端營銷。除了網站外，還需要開發移動端APP，微信小程式等。
精準營銷。利用曆史資料對使用者進行分析，提供個性化服務。
……
這些活動都需要程式開發的支援。小明拉了同學小紅加入團隊。小紅負責資料分析以及移動端相關開發。小明負責促銷活動相關功能的開發。
因為開發任務比較緊迫，小明小紅沒有好好規劃整個系統的架構，随便拍了拍腦袋，決定把促銷管理和資料分析放在管理背景裡，微信和移動端APP另外搭建。通宵了幾天後，新功能和新應用基本完工。這時架構圖如下：
這一階段存在很多不合理的地方：
網站和移動端應用有很多相同業務邏輯的重複代碼。
資料有時候通過資料庫共享，有時候通過接口調用傳輸。接口調用關系雜亂。
單個應用為了給其他應用提供接口，漸漸地越改越大，包含了很多本來就不屬于它的邏輯。應用邊界模糊，功能歸屬混亂。
管理背景在一開始的設計中保障級别較低。加入資料分析和促銷管理相關功能後出現性能瓶頸，影響了其他應用。
資料庫表結構被多個應用依賴，無法重構和優化。
所有應用都在一個資料庫上操作，資料庫出現性能瓶頸。特别是資料分析跑起來的時候，資料庫性能急劇下降。
開發、測試、部署、維護愈發困難。即使隻改動一個小功能，也需要整個應用一起釋出。有時候釋出會不小心帶上了一些未經測試的代碼，或者修改了一個功能後，另一個意想不到的地方出錯了。為了減輕釋出可能産生的問題的影響和線上業務停頓的影響，所有應用都要在淩晨三四點執行釋出。釋出後為了驗證應用正常運作，還得盯到第二天白天的使用者高峰期……
團隊出現推诿扯皮現象。關于一些公用的功能應該建設在哪個應用上的問題常常要争論很久，最後要麼幹脆各做各的，或者随便放個地方但是都不維護。
盡管有着諸多問題，但也不能否認這一階段的成果：快速地根據業務變化建設了系統。不過緊迫且繁重的任務容易使人陷入局部、短淺的思維方式，進而做出妥協式的決策。在這種架構中，每個人都隻關注在自己的一畝三分地，缺乏全局的、長遠的設計。長此以往，系統建設将會越來越困難，甚至陷入不斷推翻、重建的循環。
是時候做出改變了
幸好小明和小紅是有追求有理想的好青年。意識到問題後，小明和小紅從瑣碎的業務需求中騰出了一部分精力，開始梳理整體架構，針對問題準備着手改造。
要做改造，首先你需要有足夠的精力和資源。如果你的需求方（業務人員、項目經理、上司等）很強勢地一心追求需求進度，以緻于你無法挪出額外的精力和資源的話，那麼你可能無法做任何事……
在程式設計的世界中，最重要的便是抽象能力。微服務改造的過程實際上也是個抽象的過程。小明和小紅整理了網上超市的業務邏輯，抽象出公用的業務能力，做成幾個公共服務：
使用者服務
商品服務
促銷服務
訂單服務
資料分析服務
各個應用背景隻需從這些服務擷取所需的資料，進而删去了大量備援的代碼，就剩個輕薄的控制層和前端。這一階段的架構如下：
這個階段隻是将服務分開了，資料庫依然是共用的，是以一些煙囪式系統的缺點仍然存在：
資料庫成為性能瓶頸，并且有單點故障的風險。
資料管理趨向混亂。即使一開始有良好的子產品化設計，随着時間推移，總會有一個服務直接從資料庫取另一個服務的資料的現象。
資料庫表結構可能被多個服務依賴，牽一發而動全身，很難調整。
如果一直保持共用資料庫的模式，則整個架構會越來越僵化，失去了微服務架構的意義。是以小明和小紅一鼓作氣，把資料庫也拆分了。所有持久化層互相隔離，由各個服務自己負責。另外，為了提高系統的實時性，加入了消息隊列機制。架構如下：
完全拆分後各個服務可以采用異構的技術。比如資料分析服務可以使用資料倉庫作為持久化層，以便于高效地做一些統計計算；商品服務和促銷服務通路頻率比較大，是以加入了緩存機制等。
還有一種抽象出公共邏輯的方法是把這些公共邏輯做成公共的架構庫。這種方法可以減少服務調用的性能損耗。但是這種方法的管理成本非常高昂，很難保證所有應用版本的一緻性。
資料庫拆分也有一些問題和挑戰：比如說跨庫級聯的需求，通過服務查詢資料顆粒度的粗細問題等。但是這些問題可以通過合理的設計來解決。總體來說，資料庫拆分是一個利大于弊的。
微服務架構還有一個技術外的好處，它使整個系統的分工更加明确，責任更加清晰，每個人專心負責為其他人提供更好的服務。在單體應用的時代，公共的業務功能經常沒有明确的歸屬。最後要麼各做各的，每個人都重新實作了一遍；要麼是随機一個人（一般是能力比較強或者比較熱心的人）做到他負責的應用裡面。在後者的情況下，這個人在負責自己應用之外，還要額外負責給别人提供這些公共的功能——而這個功能本來是無人負責的，僅僅因為他能力較強/比較熱心，就莫名地背鍋（這種情況還被美其名曰能者多勞）。結果最後大家都不願意提供公共的功能。長此以往，團隊裡的人漸漸變得各自為政，不再關心全局的架構設計。
從這個角度上看，使用微服務架構同時也需要組織結構做相應的調整。是以說做微服務改造需要管理者的支援。
改造完成後，小明和小紅厘清楚各自的鍋。兩人十分滿意，一切就像是麥克斯韋方程組一樣漂亮完美。
然而……
沒有銀彈
春天來了，萬物複蘇，又到了一年一度的購物狂歡節。眼看着日訂單數量蹭蹭地上漲，小皮小明小紅喜笑顔開。可惜好景不長，樂極生悲，突然嘣的一下，系統挂了。
以往單體應用，排查問題通常是看一下日志，研究錯誤資訊和調用堆棧。而微服務架構整個應用分散成多個服務，定位故障點非常困難。小明一個台機器一台機器地檢視日志，一個服務一個服務地手工調用。經過十幾分鐘的查找，小明終于定位到故障點：促銷服務由于接收的請求量太大而停止響應了。其他服務都直接或間接地會調用促銷服務，于是也跟着當機了。
在微服務架構中，一個服務故障可能會産生雪崩效用，導緻整個系統故障。其實在節前，小明和小紅是有做過請求量評估的。按照預計，伺服器資源是足以支援節日的請求量的，是以肯定是哪裡出了問題。不過形勢緊急，随着每一分每一秒流逝的都是白花花的銀子，是以小明也沒時間排查問題，當機立斷在雲上建立了幾台虛拟機，然後一台一台地部署新的促銷服務節點。幾分鐘的操作後，系統總算是勉強恢複正常了。整個故障時間内估計損失了幾十萬的銷售額，三人的心在滴血……
事後，小明簡單寫了個日志分析工具（量太大了，文本編輯器幾乎打不開，打開了肉眼也看不過來），統計了促銷服務的通路日志，發現在故障期間，商品服務由于代碼問題，在某些場景下會對促銷服務發起大量請求。這個問題并不複雜，小明手指抖一抖，修複了這個價值幾十萬的Bug。
問題是解決了，但誰也無法保證不會再發生類似的其他問題。微服務架構雖然邏輯設計上看是完美的，但就像積木搭建的華麗宮殿一樣，經不起風吹草動。微服務架構雖然解決了舊問題，也引入了新的問題：
微服務架構整個應用分散成多個服務，定位故障點非常困難。
穩定性下降。服務數量變多導緻其中一個服務出現故障的機率增大，并且一個服務故障可能導緻整個系統挂掉。事實上，在大通路量的生産場景下，故障總是會出現的。
服務數量非常多，部署、管理的工作量很大。
開發方面：如何保證各個服務在持續開發的情況下仍然保持協同合作。
測試方面：服務拆分後，幾乎所有功能都會涉及多個服務。原本單個程式的測試變為服務間調用的測試。測試變得更加複雜。
小明小紅痛定思痛，決心好好解決這些問題。對故障的處理一般從兩方面入手，一方面盡量減少故障發生的機率，另一方面降低故障造成的影響。
監控 - 發現故障的征兆
在高并發分布式的場景下，故障經常是突然間就雪崩式爆發。是以必須建立完善的監控體系，盡可能發現故障的征兆。
微服務架構中元件繁多，各個元件所需要監控的名額不同。比如Redis緩存一般監控占用記憶體值、網絡流量，資料庫監控連接配接數、磁盤空間，業務服務監控并發數、響應延遲、錯誤率等。是以如果做一個大而全的監控系統來監控各個元件是不大現實的，而且擴充性會很差。一般的做法是讓各個元件提供報告自己目前狀态的接口（metrics接口），這個接口輸出的資料格式應該是一緻的。然後部署一個名額采集器元件，定時從這些接口擷取并保持元件狀态，同時提供查詢服務。最後還需要一個UI，從名額采集器查詢各項名額，繪制監控界面或者根據門檻值發出告警。
大部分元件都不需要自己動手開發，網絡上有開源元件。小明下載下傳了RedisExporter和MySQLExporter，這兩個元件分别提供了Redis緩存和MySQL資料庫的名額接口。微服務則根據各個服務的業務邏輯實作自定義的名額接口。然後小明采用Prometheus作為名額采集器，Grafana配置監控界面和郵件告警。這樣一套微服務監控系統就搭建起來了：
定位問題 - 鍊路跟蹤
在微服務架構下，一個使用者的請求往往涉及多個内部服務調用。為了友善定位問題，需要能夠記錄每個使用者請求時，微服務内部産生了多少服務調用，及其調用關系。這個叫做鍊路跟蹤。
我們用一個Istio文檔裡的鍊路跟蹤例子來看看效果：
從圖中可以看到，這是一個使用者通路productpage頁面的請求。在請求過程中，productpage服務順序調用了details和reviews服務的接口。而reviews服務在響應過程中又調用了ratings的接口。整個鍊路跟蹤的記錄是一棵樹：
要實作鍊路跟蹤，每次服務調用會在HTTP的HEADERS中記錄至少記錄四項資料：
traceId：traceId辨別一個使用者請求的調用鍊路。具有相同traceId的調用屬于同一條鍊路。
spanId：辨別一次服務調用的ID，即鍊路跟蹤的節點ID。
parentId：父節點的spanId。
requestTime & responseTime：請求時間和響應時間。
另外，還需要調用日志收集與存儲的元件，以及展示鍊路調用的UI元件。
以上隻是一個極簡的說明，關于鍊路跟蹤的理論依據可詳見Google的Dapper
了解了理論基礎後，小明選用了Dapper的一個開源實作Zipkin。然後手指一抖，寫了個HTTP請求的攔截器，在每次HTTP請求時生成這些資料注入到HEADERS，同時異步發送調用日志到Zipkin的日志收集器中。這裡額外提一下，HTTP請求的攔截器，可以在微服務的代碼中實作，也可以使用一個網絡代理元件來實作（不過這樣子每個微服務都需要加一層代理）。
鍊路跟蹤隻能定位到哪個服務出現問題，不能提供具體的錯誤資訊。查找具體的錯誤資訊的能力則需要由日志分析元件來提供。
分析問題 - 日志分析
日志分析元件應該在微服務興起之前就被廣泛使用了。即使單體應用架構，當通路數變大、或伺服器規模增多時，日志檔案的大小會膨脹到難以用文本編輯器進行通路，更糟的是它們分散在多台伺服器上面。排查一個問題，需要登入到各台伺服器去擷取日志檔案，一個一個地查找（而且打開、查找都很慢）想要的日志資訊。
是以，在應用規模變大時，我們需要一個日志的“搜尋引擎”。以便于能準确的找到想要的日志。另外，資料源一側還需要收集日志的元件和展示結果的UI元件：
小明調查了一下，使用了大名鼎鼎地ELK日志分析元件。ELK是Elasticsearch、Logstash和Kibana三個元件的縮寫。
Elasticsearch：搜尋引擎，同時也是日志的存儲。
Logstash：日志采集器，它接收日志輸入，對日志進行一些預處理，然後輸出到Elasticsearch。
Kibana：UI元件，通過Elasticsearch的API查找資料并展示給使用者。
最後還有一個小問題是如何将日志發送到Logstash。一種方案是在日志輸出的時候直接調用Logstash接口将日志發送過去。這樣一來又（咦，為啥要用“又”）要修改代碼……于是小明選用了另一種方案：日志仍然輸出到檔案，每個服務裡再部署個Agent掃描日志檔案然後輸出給Logstash。
網關 - 權限控制，服務治理
拆分成微服務後，出現大量的服務，大量的接口，使得整個調用關系亂糟糟的。經常在開發過程中，寫着寫着，忽然想不起某個資料應該調用哪個服務。或者寫歪了，調用了不該調用的服務，本來一個隻讀的功能結果修改了資料……
為了應對這些情況，微服務的調用需要一個把關的東西，也就是網關。在調用者和被調用者中間加一層網關，每次調用時進行權限校驗。另外，網關也可以作為一個提供服務接口文檔的平台。
使用網關有一個問題就是要決定在多大粒度上使用：最粗粒度的方案是整個微服務一個網關，微服務外部通過網關通路微服務，微服務内部則直接調用；最細粒度則是所有調用，不管是微服務内部調用或者來自外部的調用，都必須通過網關。折中的方案是按照業務領域将微服務分成幾個區，區内直接調用，區間通過網關調用。
由于整個網上超市的服務數量還不算特别多，小明采用的最粗粒度的方案：
服務注冊于發現 - 動态擴容
前面的元件，都是旨在降低故障發生的可能性。然而故障總是會發生的，是以另一個需要研究的是如何降低故障産生的影響。
最粗暴的（也是最常用的）故障處理政策就是備援。一般來說，一個服務都會部署多個執行個體，這樣一來能夠分擔壓力提高性能，二來即使一個執行個體挂了其他執行個體還能響應。
備援的一個問題是使用幾個備援？這個問題在時間軸上并沒有一個切确的答案。根據服務功能、時間段的不同，需要不同數量的執行個體。比如在平日裡，可能4個執行個體已經夠用；而在促銷活動時，流量大增，可能需要40個執行個體。是以備援數量并不是一個固定的值，而是根據需要實時調整的。
一般來說新增執行個體的操作為：
部署新執行個體
将新執行個體注冊到負載均衡或DNS上
操作隻有兩步，但如果注冊到負載均衡或DNS的操作為人工操作的話，那事情就不簡單了。想想新增40個執行個體後，要手工輸入40個IP的感覺……
解決這個問題的方案是服務自動注冊與發現。首先，需要部署一個服務發現服務，它提供所有已注冊服務的位址資訊的服務。DNS也算是一種服務發現服務。然後各個應用服務在啟動時自動将自己注冊到服務發現服務上。
并且應用服務啟動後會實時（定期）從服務發現服務同步各個應用服務的位址清單到本地。服務發現服務也會定期檢查應用服務的健康狀态，去掉不健康的執行個體位址。這樣新增執行個體時隻需要部署新執行個體，執行個體下線時直接關停服務即可，服務發現會自動檢查服務執行個體的增減。
服務發現還會跟用戶端負載均衡配合使用。由于應用服務已經同步服務位址清單在本地了，是以通路微服務時，可以自己決定負載政策。甚至可以在服務注冊時加入一些中繼資料（服務版本等資訊），用戶端負載則根據這些中繼資料進行流量控制，實作A/B測試、藍綠釋出等功能。
服務發現有很多元件可以選擇，比如說Zookeeper 、Eureka、Consul、Etcd等。不過小明覺得自己水準不錯，想炫技，于是基于Redis自己寫了一個……
熔斷、服務降級、限流
熔斷
當一個服務因為各種原因停止響應時，調用方通常會等待一段時間，然後逾時或者收到錯誤傳回。如果調用鍊路比較長，可能會導緻請求堆積，整條鍊路占用大量資源一直在等待下遊響應。是以當多次通路一個服務失敗時，應熔斷，标記該服務已停止工作，直接傳回錯誤。直至該服務恢複正常後再重建立立連接配接。
服務降級
當下遊服務停止工作後，如果該服務并非核心業務，則上遊服務應該降級，以保證核心業務不中斷。比如網上超市下單界面有一個推薦商品湊單的功能，當推薦子產品挂了後，下單功能不能一起挂掉，隻需要暫時關閉推薦功能即可。
限流
一個服務挂掉後，上遊服務或者使用者一般會習慣性地重試通路。這導緻一旦服務恢複正常，很可能因為瞬間網絡流量過大又立刻挂掉，在棺材裡重複着仰卧起坐。是以服務需要能夠自我保護——限流。限流政策有很多，最簡單的比如當機關時間内請求數過多時，丢棄多餘的請求。另外，也可以考慮分區限流。僅拒絕來自産生大量請求的服務的請求。例如商品服務和訂單服務都需要通路促銷服務，商品服務由于代碼問題發起了大量請求，促銷服務則隻限制來自商品服務的請求，來自訂單服務的請求則正常響應。
測試
微服務架構下，測試分為三個層次：
端到端測試：覆寫整個系統，一般在使用者界面機型測試。
服務測試：針對服務接口進行測試。
單元測試：針對代碼單元進行測試。
三種測試從上到下實施的容易程度遞增，但是測試效果遞減。端到端測試最費時費力，但是通過測試後我們對系統最有信心。單元測試最容易實施，效率也最高，但是測試後不能保證整個系統沒有問題。
由于端到端測試實施難度較大，一般隻對核心功能做端到端測試。一旦端到端測試失敗，則需要将其分解到單元測試：則分析失敗原因，然後編寫單元測試來重制這個問題，這樣未來我們便可以更快地捕獲同樣的錯誤。
服務測試的難度在于服務會經常依賴一些其他服務。這個問題可以通過Mock Server解決：
單元測試大家都很熟悉了。我們一般會編寫大量的單元測試（包括回歸測試）盡量覆寫所有代碼。
微服務架構
名額接口、鍊路跟蹤注入、日志引流、服務注冊發現、路由規則等元件以及熔斷、限流等功能都需要在應用服務上添加一些對接代碼。如果讓每個應用服務自己實作是非常耗時耗力的。基于DRY的原則，小明開發了一套微服務架構，将與各個元件對接的代碼和另外一些公共代碼抽離到架構中，所有的應用服務都統一使用這套架構進行開發。
使用微服務架構可以實作很多自定義的功能。甚至可以将程式調用堆棧資訊注入到鍊路跟蹤，實作代碼級别的鍊路跟蹤。或者輸出線程池、連接配接池的狀态資訊，實時監控服務底層狀态。
使用統一的微服務架構有一個比較嚴重的問題：架構更新成本很高。每次架構更新，都需要所有應用服務配合更新。當然，一般會使用相容方案，留出一段并行時間等待所有應用服務更新。但是如果應用服務非常多時，更新時間可能會非常漫長。并且有一些很穩定幾乎不更新的應用服務，其負責人可能會拒絕更新……是以，使用統一微服務架構需要完善的版本管理方法和開發管理規範。
另一條路 - Service Mesh
另一種抽象公共代碼的方法是直接将這些代碼抽象到一個反向代理元件。每個服務都額外部署這個代理元件，所有出站入站的流量都通過該元件進行處理和轉發。這個元件被稱為Sidecar。
Sidecar不會産生額外網絡成本。Sidecar會和微服務節點部署在同一台主機上并且共用相同的虛拟網卡。是以sidecar和微服務節點的通信實際上都隻是通過記憶體拷貝實作的。
Sidecar隻負責網絡通信。還需要有個元件來統一管理所有sidecar的配置。在Service Mesh中，負責網絡通信的部分叫資料平面（data plane），負責配置管理的部分叫控制平面（control plane）。資料平面和控制平面構成了Service Mesh的基本架構。
Sevice Mesh相比于微服務架構的優點在于它不侵入代碼，更新和維護更友善。它經常被诟病的則是性能問題。即使回環網絡不會産生實際的網絡請求，但仍然有記憶體拷貝的額外成本。另外有一些集中式的流量處理也會影響性能。
結束、也是開始
微服務不是架構演變的終點。往細走還有Serverless、FaaS等方向。另一方面也有人在唱合久必分分久必合，重新發現單體架構……
最後
歡迎大家一起交流，喜歡文章記得點個贊喲，感謝支援！