作者：finley 出處：https://www.cnblogs.com/Finley/p/16812713.html

版權(quán)：本作品采用「署名-非商業(yè)性使用-相同方式共享 4.0 國際」許可協(xié)議進行許可。

「從小白到架構(gòu)師」系列努力以淺顯易懂、圖文并茂的方式向各位讀者朋友介紹 WEB 服務(wù)端從單體架構(gòu)到今天的大型分布式系統(tǒng)、微服務(wù)架構(gòu)的演進歷程。

在「從小白到架構(gòu)師」系列的第一篇《應(yīng)對高并發(fā)》中，我們介紹了通過緩存、橫向擴容、消息隊列、分布式數(shù)據(jù)庫等基礎(chǔ)設(shè)施來提高系統(tǒng)并發(fā)量的方法。

在實際開發(fā)中業(yè)務(wù)邏輯比基礎(chǔ)設(shè)施更加靈活多變且更容易出故障，架構(gòu)設(shè)計不僅需要考慮基礎(chǔ)設(shè)施的建設(shè)，同樣需要關(guān)注業(yè)務(wù)開發(fā)的便利以及應(yīng)對業(yè)務(wù)系統(tǒng)的故障。

還是從博客開始

還是從我們熟悉的博客網(wǎng)站開始，小明是個喜歡寫博客的程序員，他覺得市面上的博客網(wǎng)站都太丑了，就想自己搞一個。

說干就干，小明抄起LAMP（Linux-Apache-MySQL-PHP）一把梭三下五除二就把網(wǎng)站搞了起來，網(wǎng)站的名字就暫定為「淘金網(wǎng)」??

由于淘金網(wǎng)界面美觀方便好用, 越來越多的網(wǎng)友開始入駐淘金網(wǎng)來耕耘自己的一小片天地。

漸漸地用戶們覺得只能寫博客功能太單一了，有些用戶想要把系列文章編輯成電子書、有些用戶想要做直播分享，有些用戶想要在這里發(fā)狀態(tài)，小明也想要賣點會員補貼一下服務(wù)器的支出…… 

沒關(guān)系都可以有，繼續(xù)一把梭加邏輯就是了：

日子也就這么一天一天的過下去，淘金網(wǎng)逐漸從個人小站發(fā)展成了一家小有規(guī)模的創(chuàng)業(yè)公司。

1. 博客、電子書、微博每個模塊都向用戶、訂單這些表里塞了一堆字段，一動線上就出 BUG, 誰都不敢動。
2. 即使上線一個小功能也要發(fā)布整個網(wǎng)站，有時候會不小心帶上了一些未經(jīng)測試的代碼，有時候會在意想不到的地方出了錯誤。
3. 一個業(yè)務(wù)容量不足需要加機器， 就相當于給所有模塊做了擴容，白白支出了其它模塊的固定開銷（無負載的服務(wù)所消耗的資源，比如 Spring 容器消耗的大量內(nèi)存，后臺線程消耗的 CPU）。

這些都還可以忍，直到那個陽光明媚的早晨小明美滋滋打開后臺想要看一眼今天的入賬時，卻發(fā)現(xiàn)網(wǎng)站打不開了。。。

檢查日志發(fā)現(xiàn)，在編寫創(chuàng)作者中心的邏輯時不小心寫了一個不停向數(shù)組中插入元素的死循環(huán)，過不了多久服務(wù)器就會 OOM 崩潰掉，只有 supervisord 還在徒勞的嘗試重啟服務(wù)器。。。

明總是個未雨綢繆的人， 他覺得BUG 是無法杜絕的，這樣的故障早晚會再次發(fā)生。小明靈機一動決定把博客、電子書、會員、直播這些業(yè)務(wù)拆分成獨立的服務(wù)端程序。

一個模塊拉起一個進程，這樣任你 OOM 還是 panic 都不會影響其它業(yè)務(wù)，萬一出了什么故障損失也就小得多了。

小明發(fā)現(xiàn)把服務(wù)拆開后一些老問題也解決了：未測試代碼被誤上線的情況幾乎沒有了；各個模塊可以按照需求各自規(guī)劃服務(wù)器資源了；

而且還有個意外之喜，每個模塊可以用不同的技術(shù)棧， 前端可以用 node.js 做 BFF, 數(shù)據(jù)分析可以用 Hadoop, 推薦系統(tǒng)可以用 Python...

還有個問題沒有解決，不同模塊依舊依賴同一個數(shù)據(jù)庫，表結(jié)構(gòu)牽一發(fā)而動全身，每次修改都小心翼翼如履薄冰。

小明決定一鼓作氣，將數(shù)據(jù)庫也按照業(yè)務(wù)板塊進行拆分，每個模塊只允許讀寫自己的數(shù)據(jù)庫，需要其它模塊數(shù)據(jù)時一律調(diào)接口，禁止直接訪問數(shù)據(jù)庫。

ok, 現(xiàn)在一切都是那么的完美，歲月如此靜好。。。

服務(wù)治理的難題

話說自從服務(wù)拆分之后再也沒有出現(xiàn)過全站崩潰的事故，小明美滋滋的準備開個年會，大家拿了年終獎回家過年。就在年會上，小明聽到程序員們在抱怨：

• “支付系統(tǒng)一到有活動就擴容，活動結(jié)束就把臨時加的機器下掉，其它人也得跟著改配置文件才能找到服務(wù)地址”
• “一個請求經(jīng)過了好幾個模塊，出了 BUG 找半天都查不清是哪個模塊的故障”
• “一上促銷商城那邊的調(diào)用就特別多，差點把我們的支付壓垮，直播的人就來抱怨說沒法刷禮物”
• “會員那邊不靠譜，付款失敗還照樣發(fā)會員，損失好多錢”

小明把這些問題一一記錄下來，開始尋找答案。

服務(wù)發(fā)現(xiàn)

支付系統(tǒng)一到有活動就擴容，活動結(jié)束就把臨時加的機器下掉，其它人也得跟著改配置文件才能找到服務(wù)地址

我們服務(wù)部署在不同的服務(wù)器上，而且會隨著負載情況不時的增刪機器，調(diào)用方如何及時準確的獲得服務(wù)的地址？實例之間如何均衡負載？我們將這個問題稱為服務(wù)發(fā)現(xiàn)。

DNS 系統(tǒng)也可以算是一種服務(wù)發(fā)現(xiàn)，服務(wù)提供方的節(jié)點在啟動后向 DNS 注冊自己的地址，節(jié)點下線前將自己從 DNS 的節(jié)點列表中刪除。

服務(wù)調(diào)用方通過域名向DNS查詢服務(wù)提供方的實際地址，DNS 會在節(jié)點列表中按預(yù)定策略挑選一個節(jié)點的 ip 地址返回給調(diào)用方。

在實際使用中更多的還是采用 Zookeeper、Consul、Etcd 等高一致性的 KV 組件做服務(wù)發(fā)現(xiàn)：

服務(wù)發(fā)現(xiàn)系統(tǒng)會通過心跳包等機制檢查節(jié)點健康狀態(tài)，并屏蔽不健康的節(jié)點。

這樣即使節(jié)點在崩潰前沒有向配置中心報告故障，服務(wù)發(fā)現(xiàn)也能避免請求繼續(xù)到達異常節(jié)點：

因為服務(wù)發(fā)現(xiàn)可以方便的控制調(diào)用方訪問的節(jié)點，所以也常常用來實現(xiàn)灰度發(fā)布，A/B測試等功能：

限流、熔斷、降級

一上促銷商城那邊的調(diào)用就特別多，差點把我們的支付壓垮，直播的人就來抱怨說沒法刷禮物

雖然服務(wù)拆分之后單個進程崩潰不會波及其它進程，但是若下層的服務(wù)的實際負載超出了最大吞吐量出現(xiàn)響應(yīng)過慢或超時的情況仍然可能波及其它上層服務(wù)。

因此，有必要在服務(wù)之間設(shè)置保護機制，防止小故障的影響不斷擴大，最終造成大面積的雪崩。常用的保護機制有三種：

熔斷：當某個服務(wù)或節(jié)點的調(diào)用失敗數(shù)或調(diào)用耗時超過閾值時，調(diào)用方應(yīng)停止繼續(xù)調(diào)用此節(jié)點并快速返回失敗。

防止自身請求大量堆積，整條鏈路浪費大量資源等待下游響應(yīng)。

降級：當下游服務(wù)停止工作后，如果該服務(wù)并非核心業(yè)務(wù)，則上游服務(wù)應(yīng)該降級，以保證核心業(yè)務(wù)不中斷。

限流：當服務(wù)提供方的負載接近最大處理能力時可以丟棄請求并立即返回失敗，防止大量堆積的請求將自身壓垮。或者當某個上層服務(wù)的調(diào)用量過大時丟棄它的（部分）請求，避免自身崩潰影響其他上層服務(wù)。

鏈路追蹤

一個請求經(jīng)過了好幾個模塊，出了 BUG 找半天都查不清是哪個模塊的故障

要想查清故障原因就需要記錄一個請求在系統(tǒng)中經(jīng)過了哪些模塊以及模塊之間的調(diào)用關(guān)系，進而找到故障模塊的相關(guān)日志，這種在服務(wù)系統(tǒng)中追蹤調(diào)用關(guān)系的技術(shù)稱為鏈路追蹤。

鏈路追蹤的原理是在請求進入系統(tǒng)時為它分配一個唯一的 traceID (通常使用雪花算法生成), 這個請求調(diào)用過程中產(chǎn)生的所有日志數(shù)據(jù)都要帶上這個 traceID 并上報到統(tǒng)一的日志數(shù)據(jù)庫。

事后分析時只要使用 traceID 進行查詢就可以找到相關(guān)日志了。

比較出名的鏈路系統(tǒng)是 Google 的 Dapper，有興趣的朋友可以點鏈接看一下詳細的資料，這里就不展開討論了。

分布式事務(wù)

會員那邊不靠譜，付款失敗還照樣發(fā)會員，損失好多錢

付款和變更訂單狀態(tài)兩個操作應(yīng)該是原子的，要么都執(zhí)行要么都不執(zhí)行，不應(yīng)該出現(xiàn)一個執(zhí)行另一個不執(zhí)行的情況。

這是典型的數(shù)據(jù)庫事務(wù)問題，在我們將數(shù)據(jù)庫拆分之前這個問題可以交給數(shù)據(jù)庫的事務(wù)機制解決，但是數(shù)據(jù)庫拆分之后一個事務(wù)涉及到多個數(shù)據(jù)庫實例甚至是異構(gòu)的數(shù)據(jù)庫，這就需要一些分布式事務(wù)協(xié)調(diào)組件來處理了。

常見的分布式事務(wù)實現(xiàn)方案有 TCC(try-confirm-catch)事務(wù)、MQ 事務(wù)消息、Saga 事務(wù)等。

分布式事務(wù)主要有兩種實現(xiàn)思路，第一種的典型代表是 TCC 事務(wù)，TCC 事務(wù)分為三個階段：

1. Try 階段：事務(wù)協(xié)調(diào)器要求參與方預(yù)留并鎖定事務(wù)所需資源；
2. Confirm 階段：若所有參與方都表示資源充足可以提交，事務(wù)協(xié)調(diào)器會向所有參與方發(fā)出 Confirm 指令，要求實際執(zhí)行事務(wù)。
3. Cancel 階段：若 Try 或 Confirm 階段任一參與者表示無法繼續(xù)事務(wù)協(xié)調(diào)器會向所有參與方發(fā)出 Cancel 指令解鎖預(yù)留資源并回滾事務(wù)。

第二種實現(xiàn)思路的典型代表是 Saga 事務(wù)，Saga 事務(wù)將一個大事務(wù)拆分成多個有序的子事務(wù)并且每個子事務(wù)都準備了撤銷操作，事務(wù)協(xié)調(diào)器會順序的執(zhí)行子事務(wù)，如果某個步驟失敗，則根據(jù)相反順序一次執(zhí)行一次撤銷操作。

上面我們只簡單介紹了分布式事務(wù)保證原子性的機制，在實際實現(xiàn)中還要考慮分布式事務(wù)的一致性(強一致還是最終一致)、隔離性(Saga 事務(wù)會暴露事務(wù)執(zhí)行到一半時的狀態(tài))、對業(yè)務(wù)的侵入性、并發(fā)量等各種問題，簡言之分布式事務(wù)是一種非常復(fù)雜、成本很高的技術(shù)。

由于分布式事務(wù)的高成本，在在實際開發(fā)中經(jīng)常使用「對賬」的方式來保證多模塊事務(wù)的最終一致性，即用離線任務(wù)定時掃描數(shù)據(jù)庫找出未正確處理的事務(wù)，然后按照預(yù)定策略進行補償(比如撤銷未成功付款用戶的會員身份)或者要求人工介入修復(fù)。

微服務(wù)時代的基礎(chǔ)設(shè)施

容器化和 Kubernetes

淘金網(wǎng)從最開始便是直接部署在云服務(wù)器上的，到了后來做了服務(wù)拆分也依舊沒有改變。每次擴容都要等待新的云服務(wù)器慢慢啟動、跑腳本裝環(huán)境最后拉起服務(wù)進程，一等就是半天。

需要升級 JRE 的時候還要寫腳本一臺一臺連上去進行升級，有時候還會升級失敗需要人工介入進行處理。

還有些時候為了充分利用資源會在一臺云服務(wù)器上部署好幾個服務(wù)，這些混部的機器管理起來也是各種麻煩。

這一切都讓程序員們苦不堪言，于是小明又開始了調(diào)研，這時一種叫「容器化」的新技術(shù)吸引他的視線。

我們都知道計算機可以分為三層：硬件、操作系統(tǒng)和應(yīng)用程序。所謂的云服務(wù)器本質(zhì)上是虛擬機，虛擬機可以模擬硬件的接口，這樣做最大的好處是可以在虛擬機上運行與宿主機不同的操作系統(tǒng)程序，比如我們可以 Windows 系統(tǒng)上運行 Linux 虛擬機。

但是，操作系統(tǒng)內(nèi)核的計算量十分龐大，在軟件模擬出的硬件上運行其性能可想而知。

對于云服務(wù)器而言并不需要再運行一個操作系統(tǒng)內(nèi)核，云服務(wù)器只是需要獨立的目錄樹、進程空間、協(xié)議棧就可以了，就是說即使云服務(wù)器 A 和 B 運行在同一臺的宿主機上 A 的根目錄和 B 根目錄是獨立的。

容器化技術(shù)的實質(zhì)是模擬操作系統(tǒng)內(nèi)核，實際上運行的只有宿主機一個操作系統(tǒng)內(nèi)核，但是宿主機上的每個容器都認為自己擁有一個獨立的操作系統(tǒng)內(nèi)核。

Docker 是目前容器技術(shù)的事實標準，它使用使用 Linux Namespaces 技術(shù)隔離目錄樹、進程空間、協(xié)議棧等，使容器之間互不影響；使用 cgroups 機制分隔宿主機的 CPU、內(nèi)存等資源。

Docker 的另一個重要貢獻是定義了容器鏡像的標準。Docker 鏡像使用分層文件系統(tǒng) AUFS。

每層數(shù)據(jù)一旦提交便不可改變，只能添加一個新層將其覆蓋。Docker 鏡像的不可變性保證了運行環(huán)境的一致，免除了登錄云服務(wù)器裝環(huán)境的痛苦，一致的運行環(huán)境也減少了「測試環(huán)境是好的，怎么一上正式環(huán)境就出問題了」的發(fā)生。

分層文件系統(tǒng)使得每次打包 Docker 鏡像只需要更新業(yè)務(wù)二進制，比虛擬機鏡像小很多。Docker 允許將任何現(xiàn)有容器作為基礎(chǔ)鏡像來使用，極大的方便了重用。

Docker 只提供了單機上的容器化支持，而我們的生產(chǎn)環(huán)境是由很多服務(wù)器組成的，有些模塊負載不足需要橫向擴容多加幾個容器，有些宿主機會宕機需要將上面運行的容器換臺宿主機重啟。

解決這個問題的是大名鼎鼎的 Kubernetes, Kubernetes 不僅可以完成服務(wù)編排的工作，而且提供了描述集群架構(gòu)的規(guī)范。我們通過編寫 yml 定義集群的最終狀態(tài)，Kubernetes 可以將系統(tǒng)自動達到并維持在這個狀態(tài)。這種能力將人力從繁重的運維工作中解脫出來，實現(xiàn)了方便可靠的部署和擴縮容。

Service Mesh

由于微服務(wù)需要提供服務(wù)發(fā)現(xiàn)、熔斷限流等服務(wù)自治能力，所以微服務(wù)框架所要提供的功能比傳統(tǒng)的 Web 框架多很多。

看到現(xiàn)在仍不少見的 Centos7、Java 5、Struts2 等各種老舊的基礎(chǔ)設(shè)施就可以想象升級基礎(chǔ)框架是一件多么痛苦的事情。

為了解決基礎(chǔ)架構(gòu)組和業(yè)務(wù)組之間為了升級框架帶來的瘋狂扯皮，小明找到了一個新的思路。

這種方式稱為 Service Mesh，它將服務(wù)發(fā)現(xiàn)、認證授權(quán)、調(diào)用追蹤等服務(wù)治理所需的能力放到一個被稱為 SideCar 的代理組件中，所有出站入站的流量都通過 SideCar 進行處理和轉(zhuǎn)發(fā), 業(yè)務(wù)方只需要和 SideCar 進行通信即可。

Service Mesh 中還有個被稱為控制面(Control Panel) 的組件來統(tǒng)一管理所有 Sidecar 的配置，SideCar 和業(yè)務(wù)組成的部分稱為數(shù)據(jù)面(Data Panel), 控制面和數(shù)據(jù)面共同組成了 Service Mesh 架構(gòu)。

因為 Side Car 和業(yè)務(wù)只通過 RPC 進行通信，兩者可以獨立升級，免去了升級基礎(chǔ)框架時需要改動業(yè)務(wù)代碼的種種麻煩。

由于 RPC 調(diào)用天生可以跨語言，所以只需要開發(fā)一次 SideCar 就可以對接多種語言開發(fā)的業(yè)務(wù)系統(tǒng)。

圖片來源：Pattern: Service Mesh

ServiceMesh 直譯是服務(wù)網(wǎng)格，大概是因為架構(gòu)圖比較像網(wǎng)格才起了這個名字吧~

總結(jié)

何謂微服務(wù)

又是一年年終季，小明看著自己搞的這么多東西打算整個 PPT 去行業(yè)交流會上吹吹牛。他左翻右找，終于找到了一篇論文：Microservices: a-definition-of-this-new-architectural-term, 原來自己做的這套結(jié)構(gòu)有一個好聽的名字：「微服務(wù)」：

微服務(wù)是一種通過多個小型服務(wù)組合來構(gòu)建單個應(yīng)用的架構(gòu)風(fēng)格，這些服務(wù)圍繞業(yè)務(wù)能力而非特定的技術(shù)標準來構(gòu)建。

各個服務(wù)可以采用不同的編程語言，不同的數(shù)據(jù)存儲技術(shù)，運行在不同的進程之中。服務(wù)采取輕量級的通信機制和自動化的部署機制實現(xiàn)通信與運維。

「什么是微服務(wù)」這個問題是典型的一千個人眼里有一千個哈姆雷特，不過回顧「淘金網(wǎng)」的歷程我們發(fā)現(xiàn)有一些理念已經(jīng)是業(yè)界的共識：

1. 按照業(yè)務(wù)板塊將單體大服務(wù)拆分為多個獨立的小服務(wù)，通過分割解耦的方式控制代碼的復(fù)雜度。小服務(wù)的獨立性賦予了它更高的靈活性，比如采用異構(gòu)技術(shù)和異構(gòu)架構(gòu)的自由。分散部署也有效的阻止了局部錯誤造成大范圍的故障。
2. 數(shù)據(jù)去中心化：各個服務(wù)獨立維護數(shù)據(jù)庫，降低模塊之間的耦合程度。
3. 重視服務(wù)治理，但鼓勵各模塊自治。微服務(wù)不僅僅是將服務(wù)拆分，而且重視處理拆分后出現(xiàn)的一系列問題，比如控制流量路由的服務(wù)發(fā)現(xiàn)系統(tǒng)；避免連鎖故障的限流、熔斷、降級技術(shù)；用于調(diào)試和排查的鏈路追蹤系統(tǒng)；以及維護事務(wù)安全性的分布式事務(wù)機制。服務(wù)治理能力不是由中心或者基礎(chǔ)架構(gòu)強加給各模塊的，而是各模塊根據(jù)自己的需要靈活選擇治理能力和實現(xiàn)方式。
4. 重視彈性：服務(wù)的部署容量不是固定的，而是根據(jù)業(yè)務(wù)需求量隨時增加或減少節(jié)點數(shù)，并且因此促進了 Kubernetes 等彈性平臺的廣泛使用。
5. 重視彈性：服務(wù)系統(tǒng)應(yīng)該可以按照業(yè)務(wù)需要靈活的進行擴縮容。

下集預(yù)告：揭開分布式系統(tǒng)的面紗

很多同學(xué)一提到分布式系統(tǒng)便想到 CAP 理論、Paxos 算法、Hadoop 等嚇人的名詞，甚至失去了繼續(xù)學(xué)習(xí)的勇氣。「從小白到架構(gòu)師」 系列的前兩篇幾乎每句都與分布式系統(tǒng)密切相關(guān)，

第三篇文章「揭開分布式系統(tǒng)的面紗」我們將一起探索分布式系統(tǒng)的各種技術(shù)和問題：如何編寫在分布式環(huán)境中運行的業(yè)務(wù)代碼？什么是分布式共識問題，又有哪些解決方案？CAP 定理是什么，又有哪些例證？那些經(jīng)典的分布式數(shù)據(jù)庫又是如何工作的？

我開通了項目股東服務(wù)，已經(jīng)有不少消息推送平臺項目股東拿了阿里/vivo等大廠offer了。我是沒找到網(wǎng)上有跟我提供相同的服務(wù)，價格還比我低的。

??一對一周到的服務(wù)：有很多人的自學(xué)能力和基礎(chǔ)確實不太行，不知道怎么開始學(xué)習(xí)，從哪開始看起，學(xué)習(xí)項目的過程中會走很多彎路，很容易就迷茫了。付費最跟自學(xué)最主要的區(qū)別就是我的服務(wù)會更周到。我會告訴你怎么開始學(xué)這個開源項目，哪些是重點需要掌握的，如何利用最短的時間把握整個系統(tǒng)架構(gòu)和編碼的設(shè)計，把時間節(jié)省下來去做其他事情。學(xué)習(xí)經(jīng)驗/路線/簡歷編寫/面試經(jīng)驗知無不言

??本地直連遠程服務(wù)：生產(chǎn)環(huán)境的應(yīng)用系統(tǒng)肯定會依賴各種中間件，我專門買了兩臺服務(wù)器已經(jīng)搭建好必要的環(huán)境??，在本地就可以直接啟動運行體驗和學(xué)習(xí)，無須花額外的時間自行搭建調(diào)試。

??細致的文檔&視頻：巨細致的語雀文檔11W+ 字，共106個文檔，項目視頻還在持續(xù)制作更新中（20個），不怕你學(xué)不會。

??付費社群：優(yōu)質(zhì)的社群里需篩選過濾，學(xué)習(xí)氛圍是很重要的，多跟同輩或前輩聊聊，會少走很多彎路??

??清爽干練commit：專屬股東倉庫，一步一步從零復(fù)現(xiàn)austin，每個commit都帶著文檔&視頻學(xué)習(xí)。

如果想獲取上面的權(quán)益，可以看看??Java項目訓(xùn)練營