前言
微服務(wù)是一整套體系，并不是僅僅代碼上業(yè)務(wù)開發(fā)，為了開發(fā)的完整性，我們究竟得配置多少治理的設(shè)施。在這一章節(jié)，我們先了解這些設(shè)施的作用是什么，為何會存在和需要這些設(shè)施，以便在我們后面章節(jié)對這些設(shè)施做詳細(xì)講解有個概要的認(rèn)識。
一個國家人多了就需要有一個政府，由這個政府組織起來各個行政部門負(fù)責(zé)起來各種行政職能，對企業(yè)人民進(jìn)行管理和服務(wù)，保證企業(yè)的正常生產(chǎn)，人民的安居樂業(yè)。
在微服務(wù)體系也是如此，一個公司的微服務(wù)系統(tǒng)龐大多了，也是需要有對應(yīng)支撐組織對業(yè)務(wù)模塊進(jìn)行服務(wù)和治理。
下面我們就一起來看下，一個中大規(guī)模的公司，想要讓微服務(wù)能夠 “Drop in 業(yè)務(wù)開發(fā)”，需要多少的治理支撐。
1. 我們需要配齊多少設(shè)施
1.1 服務(wù)注冊發(fā)現(xiàn)
當(dāng)我們開始使用微服務(wù)架構(gòu)時，我們會將一個大的單體應(yīng)用拆分成多個獨立的小服務(wù)，然后必須滿足每個小的服務(wù)之間能夠相互進(jìn)行通信，假設(shè)我們沒有服務(wù)發(fā)現(xiàn)的支撐，我們只能用硬編碼的方式將需要通信的服務(wù)的網(wǎng)絡(luò)信息寫在調(diào)用方的服務(wù)中。
但是，這樣會出現(xiàn)一系列的問題：
- 通信方式例如網(wǎng)絡(luò)地址有變化時無法及時通知消費者；
- 在生產(chǎn)環(huán)境中，每個服務(wù)一般都會部署多個實例以實現(xiàn)負(fù)載均衡，當(dāng)要對一組服務(wù)增加或減少實例，都得去相應(yīng)改動消費者的編碼。
要解決這個問題，就必須引入一個服務(wù)注冊發(fā)現(xiàn)機(jī)制，服務(wù)生產(chǎn)者將自己的信息注冊到服務(wù)注冊中心，服務(wù)消費者再從注冊中心進(jìn)行拉取。這樣，即使生產(chǎn)者的信息發(fā)生了變化，消費者也無需改動配置。
在微服務(wù)架構(gòu)中，服務(wù)發(fā)現(xiàn)組件是一個非常重要的組件，目前常用的組件有以下幾種：
- ZooKeeper；
- EureKa；
- Consule；
- Nacos。
1.2 配置中心
配置中心，顧名思義，就是用統(tǒng)一管理項目中所有的配置系統(tǒng)。
在項目中，我們可以簡單理解程序 = 代碼 + 配置。我們在程序中需要對一些參數(shù)進(jìn)行自定義的配置，但我們并不想把這些配置直接寫在代碼中，為了方便修改，并讓系統(tǒng)有更好的擴(kuò)展性，我們會將這些配置寫在工程的配置文件中。
在單體應(yīng)用中，我們可以把所有的配置項集中在某個問題或某幾個文件中，但是在微服務(wù)體系中，由于微服務(wù)眾多，服務(wù)之間又是相互調(diào)用相互依賴，為每個服務(wù)進(jìn)行配置文件就顯得非常的難以管理。
如果沒有配置中心，我們強(qiáng)行將配合文件寫在各個工程中會有以下幾個的問題：
- 配置文件過于分散，難以管理；
- 配置文件無法區(qū)分環(huán)境，可能我們的代碼工程會運行在幾套環(huán)境中，可能每個環(huán)境的參數(shù)各不相同，就得靠手動進(jìn)行維護(hù)；
- 靜態(tài)化配置，每次修改都必須通過修改文件并且重啟工程來進(jìn)行生效；
- 配置文件無法追溯，除了用代碼本身的版本管理，否則無法進(jìn)行追溯。
配置中心的思路就是把項目中各種配置，各種的參數(shù)都集中到一個地方進(jìn)行統(tǒng)一的管理，并提供標(biāo)準(zhǔn)的接口。當(dāng)服務(wù)需要獲取配置，就通過接口進(jìn)行拉取，當(dāng)配置中心的配置和參數(shù)有了變化，也能實時同步到各個服務(wù)。
也就是說，配置中心需要解決和滿足一下幾個問題：
- 配置集中管理；
- 在系統(tǒng)運行期間可以動態(tài)配置，并實時刷新到服務(wù)；
- 高可用。
我們常用的配置中心的組件有：Apollo，Nacos，Disconf，SpringCloud Config 等等。
1.3 負(fù)載均衡
在微服務(wù)架構(gòu)中，負(fù)載均衡是必須使用的技術(shù)，通過它來實現(xiàn)系統(tǒng)的高可用、集群擴(kuò)容等功能。
一般來說，在微服務(wù)中有 2 種模式的負(fù)載均衡，一種是中間件負(fù)載均衡，一種是客戶端負(fù)載均衡，這兩種都微服務(wù)開發(fā)都有充分的使用。
先說中間件負(fù)載均衡器：客戶先請求到負(fù)載均衡器，然后負(fù)載均衡器根據(jù)負(fù)載均衡算法將請求轉(zhuǎn)發(fā)到微服務(wù)，在接入層的 LB 就是一個典型的負(fù)載均衡器。
還有一種就是客戶端的負(fù)載均衡，客戶端本身維護(hù)服務(wù)提供者的列表，和自身進(jìn)行負(fù)載均衡的算法對服務(wù)提供者進(jìn)行調(diào)用。
SpringCloud Ribbon 就是基于客服端的負(fù)載均衡工具，它可以將面向服務(wù)的 REST 模板請求自動轉(zhuǎn)換成客戶端負(fù)載均衡的服務(wù)調(diào)用：
負(fù)載均衡算法有：輪訓(xùn)、隨機(jī)、加權(quán)輪訓(xùn)、加權(quán)隨機(jī)、地址哈希等等，這些將在后面章節(jié)詳細(xì)說到。
1.4 網(wǎng)絡(luò)通訊
在微服務(wù)中，使用什么協(xié)議來構(gòu)建服務(wù)體系？一般由兩種選擇：RPC 和 REST API：
- RPC：Remote Produce Call 遠(yuǎn)程過程調(diào)用，基于原生的 TCP 通訊，速度快，效率高。
- REST：是 Http 協(xié)議通訊，底層也是基于 TCP，規(guī)定了數(shù)據(jù)傳輸?shù)母袷?，目前?web 瀏覽器和服務(wù)器通訊大量使用，也可以用來進(jìn)行遠(yuǎn)程服務(wù)調(diào)用。
優(yōu)劣對比：
- 從使用的方面來看，REST 接口只需要關(guān)注提供方，客戶端只要也用 Http 方式進(jìn)行調(diào)用即可，可能不要考慮雙方使用的語言，客戶端只要通過接口發(fā)起調(diào)用即可，業(yè)務(wù)開發(fā)人員只需要關(guān)注業(yè)務(wù)方法，不需要關(guān)注網(wǎng)絡(luò)傳輸細(xì)節(jié)。
- 從性能角度來看，REST 接口使用 Http 協(xié)議進(jìn)行傳輸，導(dǎo)致在網(wǎng)絡(luò)傳輸過程中，攜帶信息過多。而 RPC 服務(wù)一般只需要關(guān)注傳輸相關(guān)業(yè)務(wù)即可，傳輸數(shù)據(jù)更小，性能更高。
1.5 序列化
序列化是用來通信，服務(wù)端把數(shù)據(jù)序列化，發(fā)送到客戶端，客戶端把接受到的數(shù)據(jù)反序列化得到對應(yīng)的數(shù)據(jù)，然后再講數(shù)據(jù)序列化后發(fā)送到服務(wù)端，服務(wù)端再反序列化得到相應(yīng)的數(shù)據(jù)。說白了，數(shù)據(jù)需要經(jīng)過序列化后變成二進(jìn)制流才能在服務(wù)端和客戶端中傳輸。
常用的有下面幾種序列化：
- Hessian2 序列化 ： hessian 是一種跨語言的高效二進(jìn)制序列化方式，它是 Dubbo RPC 協(xié)議默認(rèn)的序列化方式；
- Dubbo 序列化 ： 并不成熟，Dubbo 序列化其實不是 Dubbo RPC 默認(rèn)的序列化；
- Java 序列化 ：JDK 自帶的 Java 序列化實現(xiàn)，效果并不理想。
1.6 安全認(rèn)證
有些服務(wù)并不希望所有的人都能去調(diào)用到，涉及到一些敏感信息，比例跟錢相關(guān)的信息，那么我們需要安全和訪問的控制策略，來限制對這些服務(wù)的訪問。
我們這里說的安全訪問指的是服務(wù)間的調(diào)用，而不是外部用戶的調(diào)用，外部用戶可以走 API 網(wǎng)關(guān)。
1.7 斷路限流
斷路，限流，降級，超時，隔離是一整套容錯的組合拳。
在介紹斷路之前，我們先了解微服務(wù)的雪崩效應(yīng)。在微服務(wù)體系中由多個服務(wù)進(jìn)行組成，服務(wù)之間的數(shù)據(jù)交互通過遠(yuǎn)程調(diào)用完成，這樣帶來一個問題，假設(shè)服務(wù) A 調(diào)用服務(wù) B 和服務(wù) C，服務(wù) B 又調(diào)用了服務(wù) D 和服務(wù) E，服務(wù) C 又調(diào)用服務(wù) F，這樣就出現(xiàn)所謂的扇出，如果扇出的鏈路上某個服務(wù)調(diào)用出現(xiàn)不可用或者調(diào)用相應(yīng)時間過長，那么服務(wù) A 的調(diào)用資源會占用越來越多，因為服務(wù) A 是入口資源，進(jìn)而引起系統(tǒng)崩潰，這個就是所謂的雪崩效應(yīng)。
當(dāng)服務(wù) E 出現(xiàn)問題，會導(dǎo)致服務(wù) B 也出現(xiàn)問題，服務(wù) B 出現(xiàn)問題會導(dǎo)致服務(wù) A 出現(xiàn)問題，而的入口服務(wù) A 的崩潰，就是整個系統(tǒng)的崩潰。
從可用性和可靠性觸發(fā)，為了防止系統(tǒng)的整體崩潰，必須采用對應(yīng)該的技術(shù)手段，采用的手段都是從系統(tǒng)可用性，可靠性角度出發(fā)，盡量防止系統(tǒng)整體緩慢甚至癱瘓。
- 服務(wù)熔斷：是對雪崩效應(yīng)的一種微服務(wù)鏈路保護(hù)機(jī)制；
- 服務(wù)降級：整體資源不夠用，主動關(guān)閉部分服務(wù)，或在出現(xiàn)熔斷情況下出現(xiàn)的兜底方案；
- 服務(wù)限流：當(dāng)出現(xiàn)流量超越了整體系統(tǒng)可以承接的流量，系統(tǒng)主動做出管控，只允許部分流量進(jìn)入，拒絕或延后其他流量；
斷路降級限流，在微服務(wù)體系中是一個很大的保證性組件，在后續(xù)章節(jié)會作為一個大課題進(jìn)行講解。
1.8 鏈路跟蹤
微服務(wù)將一個龐大的系統(tǒng)切分成各個小的服務(wù)，各個服務(wù)之間相互依賴，共同協(xié)同調(diào)用構(gòu)建成整個系統(tǒng)。這個就是造成我們整個系統(tǒng)有復(fù)雜的調(diào)用鏈路，如果一個調(diào)用鏈路錯誤，如何快速定位錯誤資源，一個調(diào)用鏈路影響緩慢，如何快速定位其中延遲高的服務(wù)。
調(diào)用鏈漫長并且復(fù)雜，要了解每一個環(huán)節(jié)，我們需要全鏈路跟蹤，應(yīng)用的原理也很簡單，就是在請求的開端，生成一個唯一的 ID，并將其傳遞到整個調(diào)用鏈，這樣就可以根據(jù)整個 ID 來跟蹤整個請求并獲取各個調(diào)用環(huán)節(jié)的性能指標(biāo)。
1.9 監(jiān)控報警
監(jiān)控是微服務(wù)治理的一個重要環(huán)節(jié)，監(jiān)控系統(tǒng)的完善程度直接影響到我們微服務(wù)質(zhì)量的好壞，我們的微服務(wù)在線上運行的時候有沒有一套完善的監(jiān)控體系能去了解到它的健康情況，對整個系統(tǒng)的可靠性和穩(wěn)定性是非常重要。
微服務(wù)監(jiān)控是一整套系統(tǒng)性的監(jiān)控，一個比較完善得微服務(wù)監(jiān)控體系需要涉及到哪些層次，以下劃分為 5 個層次的監(jiān)控
- 最底層基礎(chǔ)設(shè)施監(jiān)控；
- 系統(tǒng)層監(jiān)控；
- 應(yīng)用層監(jiān)控；
- 業(yè)務(wù)監(jiān)控；
- 端用戶體驗監(jiān)控。
這個后續(xù)章節(jié)我們會對各個監(jiān)控層面進(jìn)行詳細(xì)講解。
1.10 統(tǒng)一日志
微服務(wù)將原來的單體應(yīng)用拆分成 N 個服務(wù)分布在不同的機(jī)器，原來的單個日志也被分布在 N 臺機(jī)器，日志對我們后期排查問題，定位問題非常關(guān)鍵，而分散的日志對監(jiān)控和查看勢必造成巨大的困擾。
解決這個問題，其實比較簡單，只要解決 日志采集，日志存儲，日志分析可視化日志數(shù)據(jù)，市面上 ELK 是一套比較成熟方案。
1.11 API 文檔
在單體傳統(tǒng)的 API 文檔輸出，是由一個組或一個團(tuán)隊統(tǒng)一的輸出，這個時候比較容易進(jìn)行規(guī)范。但在微服務(wù)中，每個文檔都是由各個團(tuán)隊進(jìn)行輸出，這個時候容易出現(xiàn)：
- API 接口規(guī)則返回信息不明確；
- API 接口更新還關(guān)系到通知調(diào)用者，導(dǎo)致文檔更新交流不斷；
- 缺少在線接口測試，通常需要額外的 API 測試工具，例如 postman；
- 接口文檔太多，不便于管理。
解決以上問題，可以引入比較成熟的統(tǒng)一生成 API 文檔工具。例如 Swagger , 可以在較多層面解決上述問題，也便于統(tǒng)一管理。
1.12 統(tǒng)一異常
我們希望服務(wù)治理的環(huán)節(jié)能集成統(tǒng)一的服務(wù)異常處理的能力，這樣的化異常能夠達(dá)到更加標(biāo)準(zhǔn)化，出現(xiàn)問題能更好定位好屬于什么類型的問題。如果說沒有這樣的一個環(huán)節(jié)，大家各自的玩法不一樣，拋的異常各異，出現(xiàn)問題難以定位和無法標(biāo)準(zhǔn)化友好輸出。
1.13 代碼規(guī)范
現(xiàn)在在大規(guī)模開發(fā)的情況下，比較推從一個契約驅(qū)動開發(fā)的方法，開發(fā)人員先定立契約，代碼自動生成的方式生成對應(yīng)的代碼腳手架，這個在大規(guī)模開發(fā)的時候更能確保代碼的一致和規(guī)整。
1.14 集成 DB MQ Cache
微服務(wù)治理的核心思路就是把上面講到的各個環(huán)節(jié)沉淀下來，變成平臺和框架的一部分，開發(fā)人員可以更加專注業(yè)務(wù)邏輯的實現(xiàn)，在實現(xiàn)業(yè)務(wù)邏輯的時候不需要去關(guān)注外部環(huán)節(jié)的，從而提升開發(fā)的效率，治理環(huán)節(jié)沉淀在框架之中有專門的平臺架構(gòu)團(tuán)隊去進(jìn)行管控。
2. 小結(jié)
在這一節(jié)，我們初步了解了能讓我們業(yè)務(wù)代碼 “安居樂業(yè)” 配套的各個部門，從一個大概知道每個部門存在的意義是什么，在下面的章節(jié)中，我們會逐個敲開這些部門的大門，進(jìn)入一探究竟。