本文將介紹微服務架構和相關的組件，介紹他們是什麼以及為什麼要使用微服務架構和這些組件。本文側重於簡明地表達微服務架構的全局圖景，因此不會涉及具體如何使用組件等細節。
要理解微服務，首先要先理解不是微服務的那些。通常跟微服務相對的是單體應用，即將所有功能都打包成在一個獨立單元的應用程序。從單體應用到微服務並不是一蹴而就的，這是一個逐漸演變的過程。本文將以一個網上超市應用為例來說明這一過程。
一：最初的需求
當時互聯網還不發達，網上超市還是藍海。只要功能實現了就能隨便賺錢。所以他們的需求很簡單，只需要一個網站掛在公網，用戶能夠在這個網站上瀏覽商品、購買商品；另外還需一個管理後臺，可以管理商品、用戶、以及訂單數據。
我們整理一下功能清單：
§ 網站
§ 用戶註冊、登錄功能
§ 商品展示
§ 下單
§ 管理後臺
§ 用戶管理
§ 商品管理
§ 訂單管理
由於需求簡單，管理後臺出於安全考慮，不和網站做在一起，總體架構圖如下：
§ 開展促銷活動。比如元旦全場打折，春節買二送一，情人節狗糧優惠券等等。
§ 拓展渠道，新增移動端營銷。除了網站外，還需要開發移動端APP，微信小程序等。
§ 精準營銷。利用歷史數據對用戶進行分析，提供個性化服務。
§ ……
這些活動都需要程序開發的支持。
這一階段存在很多不合理的地方：
§ 網站和移動端應用有很多相同業務邏輯的重複代碼。
§ 數據有時候通過數據庫共享，有時候通過接口調用傳輸。接口調用關係雜亂。
§ 單個應用為了給其他應用提供接口，漸漸地越改越大，包含了很多本來就不屬於它的邏輯。應用邊界模糊，功能歸屬混亂。
§ 管理後臺在一開始的設計中保障級別較低。加入數據分析和促銷管理相關功能後出現性能瓶頸，影響了其他應用。
§ 數據庫表結構被多個應用依賴，無法重構和優化。
§ 所有應用都在一個數據庫上操作，數據庫出現性能瓶頸。特別是數據分析跑起來的時候，數據庫性能急劇下降。
§ 開發、測試、部署、維護愈發困難。即使只改動一個小功能，也需要整個應用一起發佈。有時候發佈會不小心帶上了一些未經測試的代碼，或者修改了一個功能後，另一個意想不到的地方出錯了。為了減輕發佈可能產生的問題的影響和線上業務停頓的影響，所有應用都要在凌晨三四點執行發佈。發佈後為了驗證應用正常運行，還得盯到第二天白天的用戶高峰期……
§ 團隊出現推諉扯皮現象。關於一些公用的功能應該建設在哪個應用上的問題常常要爭論很久，最後要麼乾脆各做各的，或者隨便放個地方但是都不維護。
儘管有著諸多問題，但也不能否認這一階段的成果：快速地根據業務變化建設了系統。不過緊迫且繁重的任務容易使人陷入局部、短淺的思維方式，從而做出妥協式的決策。在這種架構中，每個人都只關注在自己的一畝三分地，缺乏全局的、長遠的設計。長此以往，系統建設將會越來越困難，甚至陷入不斷推翻、重建的循環。
三：是時候做出改變了
要做改造，首先你需要有足夠的精力和資源。如果你的需求方（業務人員、項目經理、上司等）很強勢地一心追求需求進度，以致於你無法挪出額外的精力和資源的話，那麼你可能無法做任何事……
在編程的世界中，最重要的便是抽象能力。微服務改造的過程實際上也是個抽象的過程。
用戶服務
§ 商品服務
§ 促銷服務
§ 訂單服務
§ 數據分析服務
各個應用後臺只需從這些服務獲取所需的數據，從而刪去了大量冗餘的代碼，就剩個輕薄的控制層和前端。這一階段的架構如下：
這個階段只是將服務分開了，數據庫依然是共用的，所以一些煙囪式系統的缺點仍然存在：
1. 數據庫成為性能瓶頸，並且有單點故障的風險。
2. 數據管理趨向混亂。即使一開始有良好的模塊化設計，隨著時間推移，總會有一個服務直接從數據庫取另一個服務的數據的現象。
3. 數據庫表結構可能被多個服務依賴，牽一髮而動全身，很難調整。
如果一直保持共用數據庫的模式，則整個架構會越來越僵化，失去了微服務架構的意義。所有持久化層相互隔離，由各個服務自己負責。另外，為了提高系統的實時性，加入了消息隊列機制。架構如下：
完全拆分後各個服務可以採用異構的技術。比如數據分析服務可以使用數據倉庫作為持久化層，以便於高效地做一些統計計算；商品服務和促銷服務訪問頻率比較大，因此加入了緩存機制等。
還有一種抽象出公共邏輯的方法是把這些公共邏輯做成公共的框架庫。這種方法可以減少服務調用的性能損耗。但是這種方法的管理成本非常高昂，很難保證所有應用版本的一致性。
數據庫拆分也有一些問題和挑戰：比如說跨庫級聯的需求，通過服務查詢數據顆粒度的粗細問題等。但是這些問題可以通過合理的設計來解決。總體來說，數據庫拆分是一個利大於弊的。
微服務架構還有一個技術外的好處，它使整個系統的分工更加明確，責任更加清晰，每個人專心負責為其他人提供更好的服務。在單體應用的時代，公共的業務功能經常沒有明確的歸屬。最後要麼各做各的，每個人都重新實現了一遍；要麼是隨機一個人（一般是能力比較強或者比較熱心的人）做到他負責的應用裡面。在後者的情況下，這個人在負責自己應用之外，還要額外負責給別人提供這些公共的功能——而這個功能本來是無人負責的，僅僅因為他能力較強/比較熱心，就莫名地背鍋（這種情況還被美其名曰能者多勞）。結果最後大家都不願意提供公共的功能。長此以往，團隊裡的人漸漸變得各自為政，不再關心全局的架構設計。
從這個角度上看，使用微服務架構同時也需要組織結構做相應的調整。所以說做微服務改造需要管理者的支持。
四：沒有銀彈
§ 微服務架構整個應用分散成多個服務，定位故障點非常困難。
§ 穩定性下降。服務數量變多導致其中一個服務出現故障的概率增大，並且一個服務故障可能導致整個系統掛掉。事實上，在大訪問量的生產場景下，故障總是會出現的。
§ 服務數量非常多，部署、管理的工作量很大。
§ 開發方面：如何保證各個服務在持續開發的情況下仍然保持協同合作。
§ 測試方面：服務拆分後，幾乎所有功能都會涉及多個服務。原本單個程序的測試變為服務間調用的測試。測試變得更加複雜。
五：監控 - 發現故障的徵兆
在高併發分佈式的場景下，故障經常是突然間就雪崩式爆發。所以必須建立完善的監控體系，儘可能發現故障的徵兆。
微服務架構中組件繁多，各個組件所需要監控的指標不同。比如Redis緩存一般監控佔用內存值、網絡流量，數據庫監控連接數、磁盤空間，業務服務監控併發數、響應延遲、錯誤率等。因此如果做一個大而全的監控系統來監控各個組件是不大現實的，而且擴展性會很差。一般的做法是讓各個組件提供報告自己當前狀態的接口（metrics接口），這個接口輸出的數據格式應該是一致的。然後部署一個指標採集器組件，定時從這些接口獲取並保持組件狀態，同時提供查詢服務。最後還需要一個UI，從指標採集器查詢各項指標，繪製監控界面或者根據閾值發出告警。
大部分組件都不需要自己動手開發，網絡上有開源組件。
六：定位問題 - 鏈路跟蹤
在微服務架構下，一個用戶的請求往往涉及多個內部服務調用。為了方便定位問題，需要能夠記錄每個用戶請求時，微服務內部產生了多少服務調用，及其調用關係。這個叫做鏈路跟蹤。
我們用一個Istio文檔裡的鏈路跟蹤例子來看看效果：
圖片來自：https://istio.io/zh/docs/tasks/telemetry/distributed-tracing/zipkin/
從圖中可以看到，這是一個用戶訪問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是Elasticsearch、Logstash和Kibana三個組件的縮寫。
§ Elasticsearch：搜索引擎，同時也是日誌的存儲。
§ Logstash：日誌採集器，它接收日誌輸入，對日誌進行一些預處理，然後輸出到Elasticsearch。
§ Kibana：UI組件，通過Elasticsearch的API查找數據並展示給用戶。
最後還有一個小問題是如何將日誌發送到Logstash。一種方案是在日誌輸出的時候直接調用Logstash接口將日誌發送過去。這樣一來又（咦，為啥要用“又”）要修改代碼……於是小明選用了另一種方案：日誌仍然輸出到文件，每個服務裡再部署個Agent掃描日誌文件然後輸出給Logstash。
八：網關 - 權限控制，服務治理
拆分成微服務後，出現大量的服務，大量的接口，使得整個調用關係亂糟糟的。經常在開發過程中，寫著寫著，忽然想不起某個數據應該調用哪個服務。或者寫歪了，調用了不該調用的服務，本來一個只讀的功能結果修改了數據……
為了應對這些情況，微服務的調用需要一個把關的東西，也就是網關。在調用者和被調用者中間加一層網關，每次調用時進行權限校驗。另外，網關也可以作為一個提供服務接口文檔的平臺。
使用網關有一個問題就是要決定在多大粒度上使用：最粗粒度的方案是整個微服務一個網關，微服務外部通過網關訪問微服務，微服務內部則直接調用；最細粒度則是所有調用，不管是微服務內部調用或者來自外部的調用，都必須通過網關。折中的方案是按照業務領域將微服務分成幾個區，區內直接調用，區間通過網關調用。
九：服務註冊與發現 - 動態擴容
前面的組件，都是旨在降低故障發生的可能性。然而故障總是會發生的，所以另一個需要研究的是如何降低故障產生的影響。
最粗暴的（也是最常用的）故障處理策略就是冗餘。一般來說，一個服務都會部署多個實例，這樣一來能夠分擔壓力提高性能，二來即使一個實例掛了其他實例還能響應。
冗餘的一個問題是使用幾個冗餘？這個問題在時間軸上並沒有一個切確的答案。根據服務功能、時間段的不同，需要不同數量的實例。比如在平日裡，可能4個實例已經夠用；而在促銷活動時，流量大增，可能需要40個實例。因此冗餘數量並不是一個固定的值，而是根據需要實時調整的。
一般來說新增實例的操作為：
1. 部署新實例
2. 將新實例註冊到負載均衡或DNS上
操作只有兩步，但如果註冊到負載均衡或DNS的操作為人工操作的話，那事情就不簡單了。想想新增40個實例後，要手工輸入40個IP的感覺……
解決這個問題的方案是服務自動註冊與發現。首先，需要部署一個服務發現服務，它提供所有已註冊服務的地址信息的服務。DNS也算是一種服務發現服務。然後各個應用服務在啟動時自動將自己註冊到服務發現服務上。並且應用服務啟動後會實時（定期）從服務發現服務同步各個應用服務的地址列表到本地。服務發現服務也會定期檢查應用服務的健康狀態，去掉不健康的實例地址。這樣新增實例時只需要部署新實例，實例下線時直接關停服務即可，服務發現會自動檢查服務實例的增減。
服務發現還會跟客戶端負載均衡配合使用。由於應用服務已經同步服務地址列表在本地了，所以訪問微服務時，可以自己決定負載策略。甚至可以在服務註冊時加入一些元數據（服務版本等信息），客戶端負載則根據這些元數據進行流量控制，實現A/B測試、藍綠髮布等功能。
服務發現有很多組件可以選擇，比如說ZooKeeper 、Eureka、Consul、etcd等。
微服務不是架構演變的終點。往細走還有Serverless、FaaS等方向。另一方面也有人在唱合久必分分久必合，重新發現單體架構……
閱讀更多 newer大俠 的文章
