微服務(wù)是一種軟件架構(gòu)風(fēng)格，它是以專(zhuān)注于單一責(zé)任與功能的小型功能區(qū)塊為基礎(chǔ)，利用模塊化的方式組合出復(fù)雜的大型應(yīng)用程序，各功能區(qū)塊使用與語(yǔ)言無(wú)關(guān)的 API 集相互通信。微服務(wù)架構(gòu)有別于更為傳統(tǒng)的單體服務(wù)，可將應(yīng)用拆分成多個(gè)核心功能。每個(gè)功能都被稱(chēng)為一項(xiàng)服務(wù)，可以單獨(dú)構(gòu)建和部署。這也體現(xiàn)了可擴(kuò)展的基本思想：將原本大一統(tǒng)的系統(tǒng)拆成多個(gè)小部分，擴(kuò)展時(shí)只修改其中一部分，通過(guò)這種方式減少改動(dòng)范圍，降低改動(dòng)風(fēng)險(xiǎn)。微服務(wù)架構(gòu)涵蓋了服務(wù)的多個(gè)方面，包括網(wǎng)關(guān)、通信協(xié)議、服務(wù)注冊(cè)/發(fā)現(xiàn)、可觀察性、如何合理的劃分等等。| 理論基礎(chǔ)
微服務(wù)的理論基礎(chǔ)主要用來(lái)指導(dǎo)微服務(wù)架構(gòu)設(shè)計(jì)、服務(wù)拆分，確定合適的服務(wù)粒度和邊界。在做微服務(wù)之前我們首先要想明白我們現(xiàn)有系統(tǒng)面臨什么樣的問(wèn)題，為什么需要微服務(wù)，隨后才是怎么做。微服務(wù)很多核心理念其實(shí)在半個(gè)世紀(jì)前的一篇文章中就被闡述過(guò)了，而且這篇文章中的很多論點(diǎn)在軟件開(kāi)發(fā)飛速發(fā)展的這半個(gè)世紀(jì)中竟然一再被驗(yàn)證，這就是康威定律（Conway’s Law）。在康威的這篇文章中，最有名的一句話就是：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
中文直譯大概的意思就是：設(shè)計(jì)系統(tǒng)的組織，其產(chǎn)生的設(shè)計(jì)等同于組織之內(nèi)、組織之間的溝通結(jié)構(gòu)。最初這篇文章只是描述作者自己的發(fā)現(xiàn)和總結(jié)，后來(lái)“人月神話”中，引用這個(gè)觀點(diǎn)，并將其“吹捧”成現(xiàn)在熟知的“高位定律”。-
組織溝通方式?jīng)Q定系統(tǒng)設(shè)計(jì)，對(duì)于復(fù)雜的系統(tǒng)，聊設(shè)計(jì)就離不開(kāi)聊人與人的溝通，解決好人與人的溝通問(wèn)題，才能有一個(gè)好的系統(tǒng)設(shè)計(jì)
-
時(shí)間再多一件事情也不可能做的完美，但總有時(shí)間做完一件事情，這與架構(gòu)設(shè)計(jì)的“簡(jiǎn)單、合適、演化”思維不謀而合
-
線型系統(tǒng)和線型組織架構(gòu)間有潛在的異質(zhì)同態(tài)特征，更直白的說(shuō)，你想要什么樣的系統(tǒng)，就搭建什么樣的團(tuán)隊(duì)，定義好系統(tǒng)的邊界和接口，團(tuán)隊(duì)內(nèi)應(yīng)該是自治的，這樣將溝通成本維持在系統(tǒng)內(nèi)部，每個(gè)子系統(tǒng)就會(huì)更加內(nèi)聚
-
大的系統(tǒng)組織總是比小系統(tǒng)更傾向于分解，面對(duì)復(fù)雜的系統(tǒng)及組織，往往可以采用分而治之
但是當(dāng)我們的業(yè)務(wù)和組織架構(gòu)復(fù)雜度比較高的時(shí)候，很多概念只從技術(shù)角度很難去抽象，這就需要我們自上而下，建立起通用語(yǔ)言，讓業(yè)務(wù)人員和研發(fā)人員說(shuō)一樣的話，把思考層次從代碼細(xì)節(jié)拉到業(yè)務(wù)層面。越高層的抽象越穩(wěn)定，越細(xì)節(jié)的東西越容易變化。通過(guò)對(duì)不同領(lǐng)域的建模，逐步確定領(lǐng)域范圍和業(yè)務(wù)邊界，這也就是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）。DDD 是一種在面向高度復(fù)雜的軟件系統(tǒng)時(shí)，關(guān)于如何去建模的方法論，它的關(guān)鍵點(diǎn)是根據(jù)系統(tǒng)的復(fù)雜程度建立合適的模型，DDD 中的界限上下文也完美匹配了微服務(wù)的高內(nèi)聚、低耦合特性，這也為我們微服務(wù)的劃分提供了強(qiáng)有力的基礎(chǔ)。-
根據(jù)需求劃分出初步的領(lǐng)域和限界上下文，以及上下文之間的關(guān)系
-
進(jìn)一步分析每個(gè)上下文內(nèi)部，識(shí)別出哪些是實(shí)體，哪些是值對(duì)象
-
對(duì)實(shí)體、值對(duì)象進(jìn)行關(guān)聯(lián)和聚合，劃分出聚合的范疇和聚合根
-
為聚合根設(shè)計(jì)倉(cāng)儲(chǔ)，并思考實(shí)體或值對(duì)象的創(chuàng)建方式
-
在工程中實(shí)踐領(lǐng)域模型，并在實(shí)踐中檢驗(yàn)?zāi)Ｐ偷暮侠硇?，倒推模型中不足的地方并重?gòu)
但是 DDD 也不是銀彈，特別是在一些新業(yè)務(wù)場(chǎng)景，本身就充滿(mǎn)了很多的不確定性，一次性把邊界劃清楚并不是一件很容易的事。大家在一個(gè)進(jìn)程里，調(diào)整起來(lái)會(huì)相對(duì)容易，然后讓不同的界限上下文各自演化，等到了一定程度之后再考慮微服務(wù)也是一個(gè)不錯(cuò)的選擇。| 網(wǎng)關(guān)
作為微服務(wù)的統(tǒng)一入口，也肩負(fù)著整個(gè)微服務(wù)的流量接入、管理、聚合、安全等，從服務(wù)分層的角度可以劃分為接入網(wǎng)關(guān)和業(yè)務(wù)網(wǎng)關(guān)。接入網(wǎng)關(guān)接入網(wǎng)關(guān)提供最基礎(chǔ)的流量接入和安全防護(hù)能力，側(cè)重于全局，與業(yè)務(wù)無(wú)關(guān)。域名&DNS：作為服務(wù)的流量入口，對(duì)外通過(guò)域名和 DNS 提供服務(wù)，國(guó)內(nèi)域名廠商一般都依托于共有云或被共有云廠商收購(gòu)，用來(lái)完善自由的云生態(tài)。像阿里的萬(wàn)網(wǎng)，騰訊的 DNSPod 等，也有國(guó)外的 AWS，GoDaddy 和 Namecheap 等，可以用作 .me 等國(guó)內(nèi)無(wú)法托管或備案域名的管理。其次也可以借助DNS（HTTPDNS、EDNS）實(shí)現(xiàn)跨地域、運(yùn)營(yíng)商網(wǎng)絡(luò)等負(fù)載均衡，實(shí)現(xiàn)異地多活、就近訪問(wèn)、容災(zāi)等。負(fù)載均衡（LB）：主要負(fù)責(zé)請(qǐng)求的轉(zhuǎn)發(fā)代理，按機(jī)器負(fù)載來(lái)分配流量等，對(duì)外提供 VIP，這里的負(fù)載可以寬泛的理解為系統(tǒng)的壓力，可以用 CPU 負(fù)載來(lái)衡量，也可以用連接數(shù)、I/O 使用率、網(wǎng)卡吞吐量等來(lái)衡量。負(fù)載均衡器按服務(wù)層級(jí)來(lái)劃分，除了前邊提到的 DNS，還有集群級(jí)別的硬件負(fù)載均衡，以及機(jī)器級(jí)別的軟件負(fù)載均衡。DNS/硬件負(fù)載均衡（F5/A10）主要用來(lái)應(yīng)對(duì)海量用戶(hù)的訪問(wèn)，中小量用戶(hù)使用無(wú)疑會(huì)增加更多的維護(hù)和采購(gòu)成本。軟件負(fù)載均衡可以選擇自研或上云，LVS、Keepalived 主要用于四層（IP+端口）的負(fù)載均衡，在四層的基礎(chǔ)之上如果要實(shí)現(xiàn)應(yīng)用層（域名/URL/用戶(hù)會(huì)話）等的 7 層負(fù)載均衡，可以使用 Nginx、Keepalived 的組合。除此之外，網(wǎng)關(guān)也負(fù)責(zé)服務(wù)整體的安全防護(hù)，SSL，IPV6 等：-
安全防護(hù)目的是保護(hù)服務(wù)數(shù)據(jù)以及可用性，例如防范常見(jiàn)的 DDOS/CC 網(wǎng)絡(luò)攻擊，反爬蟲(chóng)，自定義訪問(wèn)控制，自研成本往往比較高，可以借助云上一系列的高防、防火墻服務(wù)。
-
SSL（TLS）用來(lái)提供外部 https 訪問(wèn)，https 可以防止數(shù)據(jù)在傳輸過(guò)程中不被竊取、改變，確保數(shù)據(jù)的完整性，在支付或者用戶(hù)登錄等敏感數(shù)據(jù)場(chǎng)景，可以起到一定的保護(hù)作用，同時(shí) https 頁(yè)面對(duì)搜索引擎也比較友好。
-
IPV6，全球 43 億 IPV4 地址已經(jīng)在 2019 年年底耗盡，網(wǎng)信辦在 2018 年開(kāi)始就已經(jīng)推行各大運(yùn)營(yíng)商、CDN 廠商、互聯(lián)網(wǎng)核心產(chǎn)品支持 IPV6，我們公司之前也是試點(diǎn)之一。IPV6 的支持只需要增加一條“AAAA”DNS記錄，將域名解析到自持 IPV6 的 IP/VIP 即可。IPV4 到 IPV6 由于存在兼容性等問(wèn)題，一定是長(zhǎng)期共存的，過(guò)渡方案可以采用 IPV6 代理（IPV6 代理轉(zhuǎn)發(fā)到 IPV4 服務(wù)）或者雙棧（同時(shí)支持 IPV6 和 IPV4）。
業(yè)務(wù)網(wǎng)關(guān)：
業(yè)務(wù)網(wǎng)關(guān)作為業(yè)務(wù)的最上層出口，一般承擔(dān)起業(yè)務(wù)接入或者 BFF 的工作，例如基礎(chǔ)的路由、鑒權(quán)、限流、熔斷降級(jí)、服務(wù)聚合、插件化能力，并可以通過(guò)可視化界面管理網(wǎng)關(guān)配置。可選框架有基于 OpenResty 的 Kong、APISIX 以及其他語(yǔ)言相關(guān)的 SpringCloud Gateway、gRPC-Gateway 等等。國(guó)內(nèi)開(kāi)源的 Goku、Kratos、go-zero go 框架，有很多比較有意思的組件實(shí)現(xiàn)，我們?nèi)粘I(yè)務(wù)上也可以借鑒。鑒權(quán)：鑒權(quán)的目的是為了驗(yàn)證用戶(hù)、請(qǐng)求等的有效性，例如用戶(hù)身份鑒權(quán)（JWT/Oauth2/Cookie），請(qǐng)求鑒權(quán)（請(qǐng)求簽名、請(qǐng)求加密），鑒權(quán)邏輯也花樣繁多，大多需要基于業(yè)務(wù)定制化，通過(guò)網(wǎng)關(guān)插件能很好的集成進(jìn)來(lái)。限流：限流是為了做一定的流量控制，防止對(duì)系統(tǒng)產(chǎn)生過(guò)大壓力從而影響整個(gè)服務(wù)?？梢曰趩闻_(tái)機(jī)器或整個(gè)集群限流，常見(jiàn)的方式有限制總量和限制速率，超過(guò)的則排隊(duì)或丟棄，例如令牌桶（彈性）/漏桶（勻速）算法。熔斷降級(jí)：熔斷作為服務(wù)斷路器，當(dāng)下游的服務(wù)因?yàn)槟撤N原因突然變得不可用或響應(yīng)過(guò)慢（這里既可以指單次請(qǐng)求也可以指一段時(shí)間），上游服務(wù)為了保證自己整體服務(wù)的可用性，不再繼續(xù)調(diào)用目標(biāo)服務(wù)，直接返回，這樣也能對(duì)整體鏈路起到保護(hù)作用。如果目標(biāo)服務(wù)情況好轉(zhuǎn)則恢復(fù)調(diào)用，同時(shí)結(jié)合降級(jí)策略提升服務(wù)的魯棒性。常見(jiàn)的有Hystrix/Resilience4J（Hystrix 雖然已停止更新，但現(xiàn)有功能已經(jīng)能滿(mǎn)足大多業(yè)務(wù)場(chǎng)景）。重試：大量網(wǎng)絡(luò) IO，避免不了會(huì)出現(xiàn)因網(wǎng)絡(luò)抖動(dòng)，出現(xiàn)連接失敗或者超時(shí)，重試可以提高請(qǐng)求的最終成功率，削平服務(wù)毛刺。但重試也有可能放大故障，所以可以結(jié)合退避策略（backoff）、限制單點(diǎn)重試、限制鏈路重試這些策略進(jìn)行優(yōu)雅的重試，同時(shí)也可以采用更加激進(jìn)的“對(duì)沖請(qǐng)求”提前（tp99 時(shí)間未響應(yīng)時(shí)）發(fā)起重試請(qǐng)求，降低系統(tǒng)時(shí)延。插件化：各個(gè)網(wǎng)關(guān)集成插件的方式盡不相同，但是目的都是為了集成技術(shù)人員編寫(xiě)的一些業(yè)務(wù)相關(guān)的通用能力，例如前邊提到的身份鑒權(quán)、請(qǐng)求鑒權(quán)等等。另外作為業(yè)務(wù)網(wǎng)關(guān)插件，也可以編寫(xiě)一些基礎(chǔ)業(yè)務(wù)（API 鑒權(quán)、請(qǐng)求格式化）邏輯，直接透?jìng)髡?qǐng)求到服務(wù)層，省去很多 BFF 和上下游對(duì)接的工作。BFF：Backend For Frontend，可以按照業(yè)務(wù)邏輯，以串行、并行和分支等結(jié)構(gòu)編排多個(gè)服務(wù) API，為服務(wù)提供聚合、適配、裁剪（只返回需要的字段）功能，核心是 API 的動(dòng)態(tài)編排以滿(mǎn)足日益增長(zhǎng)的業(yè)務(wù)邏輯，降低前端與微服務(wù)之間的對(duì)接成本。BFF 并不意味著只能由后端實(shí)現(xiàn)，也可以在前端通過(guò) GraphQL 等 API 查詢(xún)語(yǔ)言實(shí)現(xiàn)。| 協(xié)議
服務(wù)間的通信方式是在采用微服務(wù)架構(gòu)時(shí)需要做出一個(gè)最基本的決策，統(tǒng)一的協(xié)議標(biāo)準(zhǔn)也能大大降低服務(wù)的聯(lián)調(diào)和維護(hù)成本。HTTP REST：REST 更確切的講是指的 API 設(shè)計(jì)風(fēng)格，而不是協(xié)議標(biāo)準(zhǔn)。通?；谑褂?HTTP，URL，和 JSON 這些現(xiàn)有的廣泛流行的協(xié)議和標(biāo)準(zhǔn)。符合 REST 設(shè)計(jì)風(fēng)格的 API 稱(chēng)作 RESTful API。在實(shí)際應(yīng)用中大多實(shí)現(xiàn)的是偽 REST API，例如用 POST 請(qǐng)求同時(shí)實(shí)現(xiàn)資源的增刪改，或者為了請(qǐng)求的擴(kuò)展性，資源的增刪改查都使用 POST JSON。RPC：RPC 協(xié)議描繪了客戶(hù)端與服務(wù)端之間的點(diǎn)對(duì)點(diǎn)調(diào)用流程，包括 stub、通信、RPC 消息協(xié)議部分。可以基于 TCP，也可以基于 http。在實(shí)際應(yīng)用中，還需要考慮服務(wù)的高可用、負(fù)載均衡等問(wèn)題，所以產(chǎn)品級(jí)的 RPC 框架除了點(diǎn)對(duì)點(diǎn)的 RPC 協(xié)議的具體實(shí)現(xiàn)外，還應(yīng)包括服務(wù)的發(fā)現(xiàn)與注冊(cè)、提供服務(wù)的多臺(tái) Server 的負(fù)載均衡、服務(wù)的高可用等更多的功能。目前的 RPC 框架大致有兩種不同的側(cè)重方向，一種偏重于服務(wù)治理（Dubbo、Motan），另一種偏重于跨語(yǔ)言調(diào)用（Thrift/GRPC）。RPC vs HTTP REST 優(yōu)點(diǎn)：-
更清晰的 API 定義，例如 gRPC 協(xié)議的定義文件 proto，自身就可以作為很好的 API 文檔，日常開(kāi)發(fā)中也可以把 proto 文件獨(dú)立版本庫(kù)管理，精簡(jiǎn)目錄結(jié)構(gòu)，方便不同的服務(wù)引用。
-
更好的傳輸效率，通過(guò)序列化和反序列化進(jìn)一步壓縮網(wǎng)絡(luò)傳輸數(shù)據(jù)，不過(guò)序列化、反序列化也會(huì)有一定的性能損耗，protobuf 可以說(shuō)很好的兼顧了這兩點(diǎn)。
-
更合適的容錯(cuò)機(jī)制，可以基于實(shí)際的業(yè)務(wù)場(chǎng)景，實(shí)現(xiàn)更合適的超時(shí)控制與異常重試機(jī)制，以應(yīng)對(duì)網(wǎng)絡(luò)抖動(dòng)等對(duì)服務(wù)造成的影響。
在一些特定場(chǎng)景，例如：OpenAPI、BFF 等，HTTP REST 可以更大程度上降低外部團(tuán)隊(duì)的接入成本。并且 RPC 也有調(diào)試不便、多語(yǔ)言互通需要對(duì)應(yīng)的 SDK 支持這些問(wèn)題，各有利弊。綜合考慮來(lái)看，除了一些特定場(chǎng)景，如果我們已經(jīng)有相對(duì)完善的基礎(chǔ)設(shè)施支撐（RPC 框架、服務(wù)治理），RPC 可以為一個(gè)更合適的選擇。| 服務(wù)注冊(cè)/發(fā)現(xiàn)
服務(wù)注冊(cè)主要是通過(guò)將微服務(wù)的后端機(jī)器 IP、端口、地域等信息注冊(cè)起來(lái)，并結(jié)合一定的發(fā)現(xiàn)機(jī)制使客戶(hù)端的請(qǐng)求能夠直連具體的后端機(jī)器。從實(shí)現(xiàn)方式上可以分為服務(wù)端模式與客戶(hù)端模式：
服務(wù)端模式：也可以說(shuō)是傳統(tǒng)模式，通過(guò)借助負(fù)載均衡器和 DNS 實(shí)現(xiàn)，負(fù)載均衡器負(fù)責(zé)健康檢查、負(fù)載均衡策略，DNS 負(fù)責(zé)實(shí)現(xiàn)訪問(wèn)域名到負(fù)載均衡器 IP/VIP 的映射。通過(guò)直接暴露域名和端口的方式提供客戶(hù)端訪問(wèn)。
客戶(hù)端模式：可以借助注冊(cè)中心實(shí)現(xiàn)，注冊(cè)中心負(fù)責(zé)服務(wù)的注冊(cè)與健康檢查，客戶(hù)端通過(guò)監(jiān)聽(tīng)配置變更的方式及時(shí)把配置中心維護(hù)的配置同步到本地，通過(guò)客戶(hù)端負(fù)載均衡策略直接向后端機(jī)器發(fā)起請(qǐng)求。
從兩種模式的實(shí)現(xiàn)方式上可以看出：①服務(wù)端模式注冊(cè)與發(fā)現(xiàn)都由服務(wù)端完成，這樣可以使客戶(hù)端專(zhuān)注在自身的業(yè)務(wù)實(shí)現(xiàn)，但是由于依賴(lài)負(fù)載均衡器，也就是集中式的 proxy，proxy 需要維護(hù)雙向連接，也很容易使自己成為系統(tǒng)瓶頸，可用性的高低直接決定了服務(wù)質(zhì)量。并且 DNS 緩存機(jī)制也會(huì)導(dǎo)致故障發(fā)生時(shí)，遷移并不能及時(shí)完成。當(dāng)然在服務(wù)量少，且負(fù)載均衡器有 VIP 的情況下，我們也可以不使用 DNS。②客戶(hù)端模式注冊(cè)與發(fā)現(xiàn)由配置中心和客戶(hù)端共同完成，通過(guò)分布式的方式，可以避免出現(xiàn) proxy 節(jié)點(diǎn)性能瓶頸問(wèn)題，但是可靠性與性能瓶頸很容器出現(xiàn)在配置中心上，并且客戶(hù)端的也需要一定的接入成本。好在開(kāi)源的已經(jīng)有很成熟的架構(gòu)方案與豐富的客戶(hù)端 SDK，例如 etcd/ZooKeeper/Consul。Consul 提供開(kāi)箱即用的功能，etcd 社區(qū)和接入易用性方面更優(yōu)一些，他們之間的一些具體區(qū)別：
|?配置中心
配置中心從使用場(chǎng)景來(lái)講，一類(lèi)是前邊講到的服務(wù)注冊(cè)、發(fā)現(xiàn)和 KV 存儲(chǔ)，例如 etcd/ZooKeeper/Consul，在 Kubernetes 場(chǎng)景下也可以通過(guò) ConfigMap/Secret 將配置寫(xiě)入本地文件、環(huán)境變量或者共享的 Volume 中。這樣沒(méi)有了中心服務(wù)的依賴(lài)和客戶(hù)端的接入，可以實(shí)現(xiàn)一些老舊服務(wù)的無(wú)侵入式改造。但是作為配置中心，除了基礎(chǔ)的配置數(shù)據(jù)，一些情況下還要開(kāi)放給非開(kāi)發(fā)人員（測(cè)試、運(yùn)維、產(chǎn)品）使用，完善的控制臺(tái)、權(quán)限管理、Dashbord 的支持，也非常重要，這類(lèi)可以參考 Nacos（阿里開(kāi)源）/Apollo（攜程開(kāi)源）。Nacos 在讀寫(xiě)性能上優(yōu)于 Apollo，但是功能特性（例如權(quán)限管理）稍遜于 Apollo。| 可觀察性
在控制論中，可觀察性是用系統(tǒng)輸出到外部的信息來(lái)推斷系統(tǒng)內(nèi)部運(yùn)運(yùn)行狀態(tài)的一種度量方式。在云原生時(shí)代，容器和服務(wù)的生命周期是緊密聯(lián)系在一起的，相較在傳統(tǒng)的單體服務(wù)運(yùn)行在物理主機(jī)或者虛擬機(jī)當(dāng)中，排查問(wèn)題的時(shí)候顯得非常不便，這種復(fù)雜性導(dǎo)致了一個(gè)定義研發(fā)運(yùn)營(yíng)效率的 MTTR（平均故障修復(fù)時(shí)間）指標(biāo)急劇增加。所以這里更強(qiáng)調(diào)的是微服務(wù)的可觀察性，需要提前想好我們要如何觀察容器內(nèi)的服務(wù)以及服務(wù)之間的拓?fù)湫畔?、各式指?biāo)的搜集等，這些監(jiān)測(cè)能力相當(dāng)重要。可觀察性三大支柱圍繞 Tracing（鏈路追蹤）、Logging（日志）和 Metrics（度量）展開(kāi)，這三個(gè)維度幾乎涵蓋了應(yīng)用程序的各種表征行為，開(kāi)發(fā)人員通過(guò)收集并查看這三個(gè)維度的數(shù)據(jù)時(shí)刻掌握應(yīng)用程序的運(yùn)行情況。很長(zhǎng)一段時(shí)間，這三者是獨(dú)立存在的，隨著時(shí)間的推移，這三者已經(jīng)相互關(guān)聯(lián)，相輔相成。
鏈路追蹤為分布式應(yīng)用的開(kāi)發(fā)者提供了完整的調(diào)用鏈路還原、調(diào)用請(qǐng)求量統(tǒng)計(jì)、鏈路拓?fù)洹?yīng)用依賴(lài)分析等工具，可以幫助開(kāi)發(fā)者快速分析和診斷分布式應(yīng)用架構(gòu)下的性能瓶頸，提高微服務(wù)時(shí)代下的開(kāi)發(fā)診斷效率以及系統(tǒng)的可觀察性。為了解決不同的分布式系統(tǒng) API 不兼容的問(wèn)題，誕生了 OpenTracing 規(guī)范，OpenTracing 中的 Trace 可以被認(rèn)為是由多個(gè) Spacn 組成的 DAG 圖。
OpenTracing 專(zhuān)注在 tracing，除此之外還有包含了 Metrics 的 OpenCensus 標(biāo)準(zhǔn)，以及由 CNCF 推出，融合 OpenTracing 和 OpenCensus 的 OpenTelemetry。OpenTelemetry 旨在實(shí)現(xiàn)云原生時(shí)代可觀察性指標(biāo)（Tracing、Logging、Metrics）的統(tǒng)一收集和處理，同時(shí)提供推動(dòng)這些標(biāo)準(zhǔn)實(shí)施的組件和工具。OpenTracing 中的佼佼者當(dāng)屬 Jaeger、Zipkin、Skywalking。他們之間的一些對(duì)比：
Zipkin 開(kāi)源時(shí)間長(zhǎng)，社區(qū)相對(duì)豐富，Jaeger 更加輕量，也是 Istio 推薦方案，SkyWalking 支持部分語(yǔ)言（Java、PHP、Python 等）的無(wú)侵入式接入。另外 APM（應(yīng)用性能）監(jiān)控的支持也會(huì)影響到我們的選型。除此之外，面對(duì)線上海量請(qǐng)求，如果采用抽樣采樣策略，那就需要支持一定的流量染色，把我們核心關(guān)注的請(qǐng)求（例如鏈路中發(fā)生了錯(cuò)誤、部分請(qǐng)求耗時(shí)過(guò)高等）都進(jìn)行采樣。可以通過(guò)結(jié)合 opentelemetry-collector 以及開(kāi)箱即用的 tailsamplingprocessor 構(gòu)建 Pipeline 插件實(shí)現(xiàn)。服務(wù)間的鏈路日志能否幫助我們判斷錯(cuò)誤發(fā)生的具體位置，這類(lèi)業(yè)務(wù)日志主要集中在訪問(wèn)日志/打點(diǎn)日志等等。隨著大數(shù)據(jù)的興起，我們對(duì)數(shù)據(jù)的分析解讀能力越來(lái)越強(qiáng)，日志作為原始數(shù)據(jù)則體現(xiàn)出了更大的價(jià)值，例如用戶(hù)的行為分析，反垃圾，輿情分析等等。業(yè)務(wù)日志：這類(lèi)日志重點(diǎn)在于通過(guò)不同級(jí)別的日志，及時(shí)發(fā)現(xiàn)分析系統(tǒng)存在的異常。RFC 5424 定義的 8 中日志級(jí)別：-
Emergency：system is unusable
-
Alert：action must be taken immediately
-
Critical：critical conditions
-
-
Warning：warning conditions
-
Notice：normal but significant condition
-
Informational：informational messages
-
Debug：debug-level messages
在實(shí)際使用過(guò)程中可能會(huì)對(duì)日志級(jí)別進(jìn)行簡(jiǎn)化和調(diào)整，一般來(lái)講 Warning 及以上的日志是需要重點(diǎn)關(guān)注的，需要做好及時(shí)的監(jiān)控告警，Warning 以下的日志也可以輔助問(wèn)題的定位。日志寫(xiě)入可以選擇寫(xiě)入消息隊(duì)列，也可以選擇落地磁盤(pán)，將關(guān)心的結(jié)構(gòu)化或非結(jié)構(gòu)化日志、業(yè)務(wù)模塊信息（如果是細(xì)粒度的微服務(wù)，可以選擇將日志放同一模塊收集），以及級(jí)別、時(shí)間（who、when、where、how、what）等要素正確的寫(xiě)入正確寫(xiě)入后再收集到日志服務(wù)。寫(xiě)入消息隊(duì)列需要考慮消息隊(duì)列的選型以及做好可用性和積壓監(jiān)控，寫(xiě)入磁盤(pán)需要考慮寫(xiě)入性能以及日志的切割清理，例如 Golang 的 zap+rotatelogs 組合。日志收集的話，由于 Logstash 資源消耗相對(duì)比較大，虛擬機(jī)環(huán)境中可以使用 Filebeat 來(lái)替代，更嚴(yán)苛的線上或容器環(huán)境，可以使用 Fluentd/Fluentd Bit。日志最終匯總到 ES 和 Kibana 做展示，通過(guò) Esalert 定制告警策略。大數(shù)據(jù)日志：大數(shù)據(jù)日志本質(zhì)上也對(duì)應(yīng)著我們一定的業(yè)務(wù)場(chǎng)景，但大多是海量日志、高吞吐量場(chǎng)景，所以對(duì)海量日志的收集和存儲(chǔ)是較大的挑戰(zhàn)。實(shí)現(xiàn)方案我們可以采用高吞吐量的流式中間件，例如 Kafka/Plusar 等，在結(jié)合流式處理（Flink）或者批處理（Spark）系統(tǒng)，將數(shù)據(jù)匯總到 Hadoop 進(jìn)行分析，這里涉及到的中間件和數(shù)據(jù)庫(kù)可參考后續(xù)章節(jié)。指標(biāo)是有關(guān)系統(tǒng)的離散的數(shù)據(jù)點(diǎn)，這些指標(biāo)通常表示為計(jì)數(shù)或度量，并且通常在一段時(shí)間內(nèi)進(jìn)行匯總或計(jì)算。一般用來(lái)做基礎(chǔ)的資源監(jiān)控和業(yè)務(wù)監(jiān)控：-
資源監(jiān)控：CPU、內(nèi)存、IO、fd、GC等
-
業(yè)務(wù)監(jiān)控：QPS、模調(diào)、耗時(shí)分布等
Zabbix 作為老牌的監(jiān)控系統(tǒng)，適合更復(fù)雜的物理機(jī)、虛擬機(jī)、數(shù)據(jù)庫(kù)等更復(fù)雜的場(chǎng)景，同時(shí)也擁有更豐富的圖形化界面。但是 Prometheus 作為云原生的代表作，與 Kubernetes、容器等能更好的結(jié)合，協(xié)同 Grafana 實(shí)現(xiàn)可定制化的界面，另外存儲(chǔ)基于 TSDB，相比于關(guān)系型數(shù)據(jù)庫(kù)也有更好的擴(kuò)展性。以 Prometheus 為例，支持的數(shù)據(jù)類(lèi)型有：-
Counter 只增不減的計(jì)數(shù)器，例如請(qǐng)求數(shù)（http_requests_total）。基于此數(shù)據(jù)模型，使用 Prometheus 提供的強(qiáng)大 PromQL 表達(dá)式能夠拓展出更加適合開(kāi)發(fā)觀察的指標(biāo)數(shù)據(jù)。分鐘增量請(qǐng)求：increase(http_requests_total[1m]) 分鐘 QPS：rate(http_requests_total[1m])
-
Gauge 可增可減的時(shí)刻量，例如 Go 語(yǔ)言協(xié)程數(shù)（go_goroutines） 波動(dòng)量：delta(go_goroutines[10m])
-
Histogram 直方圖，不同區(qū)間內(nèi)樣本的個(gè)數(shù)。例如，耗時(shí) 50ms-100ms 每分鐘請(qǐng)求量，100ms-150ms 每分鐘請(qǐng)求量。
-
Summary 概要，反應(yīng)百分位值。例如，某 RPC 接口，95% 的請(qǐng)求耗時(shí)低于 150ms，99% 的請(qǐng)求耗時(shí)低于 200ms。
Prometheus 指標(biāo)支持 pull 和 push 模式：
- Pull：服務(wù)暴露 metrics 接口，指標(biāo)內(nèi)存更新，Prometheus server 定時(shí)拉取，性能更好，但要考慮易失性
- Push：指標(biāo)推送 push-gateway，Promethus server 從 gateway 拉取，適用瞬時(shí)業(yè)務(wù)場(chǎng)景（定時(shí)任務(wù)）
| Service Mesh
我們前邊講的服務(wù)發(fā)現(xiàn)、熔斷降級(jí)、安全、流量控制、可觀察性等能力。這些通用能力在 Service Mesh 出現(xiàn)之前，由 Lib/Framework 通過(guò)一些切面的方式完成，這樣就可以在開(kāi)發(fā)層面上很容易地集成到我們的應(yīng)用服務(wù)中。
但是并沒(méi)有辦法實(shí)現(xiàn)跨語(yǔ)言編程，有什么改動(dòng)后，也需要重新編譯重新發(fā)布服務(wù)。理論上應(yīng)該有一個(gè)專(zhuān)門(mén)的層來(lái)干這事，于是出現(xiàn)了 Sidecar。
第一代 Service Mesh，像 Linkerd，后邊又出現(xiàn)了第二代 Service Mesh，Istio，職責(zé)分明，分離出處數(shù)據(jù)面和控制面。
但是 Sidecar 作為代理層，避免不了性能損耗（CPU 序列化反序列化 UDS），所以 proxyless service mesh 重新被提起，和之前的 「RPC + 服務(wù)發(fā)現(xiàn)治理」區(qū)別是啥？
感覺(jué)這個(gè)名詞營(yíng)銷(xiāo)味道略重。其實(shí)不能簡(jiǎn)單的 “Proxyless Service Mesh” 理解為 “一個(gè)簡(jiǎn)單的 RPC 框架，暴露了幾個(gè)超時(shí)參數(shù)到配置中心來(lái)控制”，它重在統(tǒng)一協(xié)議、API。
這樣就便于基于統(tǒng)一的協(xié)議實(shí)現(xiàn) proxyless mesh 和 proxy mesh 的互通，可以同時(shí)滿(mǎn)足性能敏感型和快速迭代型的業(yè)務(wù)場(chǎng)景。他們相輔相成，豐富了 service mesh 的形態(tài)：servicemesh 對(duì)于微服務(wù)基礎(chǔ)設(shè)施的一種演進(jìn)，但不代表他已經(jīng)非常成熟了，相反像遷移成本高，甚至一些可用性設(shè)計(jì)還不如業(yè)務(wù)自己做那么靈活。
這些現(xiàn)實(shí)的問(wèn)題還擺在面前，我覺(jué)得這也是屬于技術(shù)進(jìn)化的一種趨勢(shì)，當(dāng)一項(xiàng)技術(shù)足夠成熟的時(shí)候，又回衍生出新的復(fù)雜度問(wèn)題，從而又需要發(fā)展出新技術(shù)解決。
在計(jì)算機(jī)科學(xué)中，消息隊(duì)列是一種進(jìn)程間通信或同一進(jìn)程的不同線程間的通信方式，軟件的貯列用來(lái)處理一系列的輸入，通常是來(lái)自用戶(hù)。消息隊(duì)列提供了異步的通信協(xié)議，每一個(gè)貯列中的紀(jì)錄包含詳細(xì)說(shuō)明的數(shù)據(jù)，包含發(fā)生的時(shí)間，輸入設(shè)備的種類(lèi)，以及特定的輸入?yún)?shù)。也就是說(shuō)：消息的發(fā)送者和接收者不需要同時(shí)與消息隊(duì)列交互。消息會(huì)保存在隊(duì)列中，直到接收者取回它。
實(shí)際應(yīng)用場(chǎng)景中，消息隊(duì)列也經(jīng)常作為中間件，用于異步解耦、削峰填谷、數(shù)據(jù)廣播、錯(cuò)峰與流控、最終一致性等，在一些核心的大數(shù)據(jù)分析、交易支付等場(chǎng)景也經(jīng)常扮演重要角色。關(guān)于服務(wù)解耦，會(huì)有很多人質(zhì)疑，消息隊(duì)列是否能真正解耦，我的理解是：數(shù)據(jù)要發(fā)生流轉(zhuǎn)，系統(tǒng)之間要有依賴(lài)關(guān)系。例如上游服務(wù)直接讀寫(xiě)下游存儲(chǔ)、中間件進(jìn)行數(shù)據(jù)交互，解耦則更側(cè)重于將易于變化的復(fù)雜度轉(zhuǎn)移，對(duì)下游存儲(chǔ)、中間件的依賴(lài)，通過(guò)消息隊(duì)列轉(zhuǎn)化為雙方的弱接口（消息payload）依賴(lài)。但如果上游是本身是依賴(lài)的下游 API，這種方式就需要考慮有多個(gè)下游時(shí)，自身復(fù)雜度和可用性的變化。消息隊(duì)列的選型主要側(cè)重以下幾點(diǎn)：-
HA：自身的高可用性保障，避免消息隊(duì)列的引入而影響整體服務(wù)的可用性
-
高吞吐：在面對(duì)海量數(shù)據(jù)寫(xiě)入能否保持一個(gè)相對(duì)穩(wěn)定、高效的數(shù)據(jù)處理能力
-
功能豐富性：是否支持延遲消息、事務(wù)消息、死信隊(duì)列、優(yōu)先級(jí)隊(duì)列等
-
消息廣播：是否支持將消息廣播給消費(fèi)者組或者一組消費(fèi)者
-
消息堆積能力：在數(shù)據(jù)量過(guò)大時(shí)，是否允許一定消息堆積到broker
-
數(shù)據(jù)持久性：數(shù)據(jù)持久化策略的采用，也決定著數(shù)據(jù)在宕機(jī)恢復(fù)后是否會(huì)丟失數(shù)據(jù)
-
重復(fù)消費(fèi)：是否支持ack機(jī)制，在消費(fèi)者未正確處理消息時(shí)，支持重新消費(fèi)
-
消息順序性：針對(duì)順序消費(fèi)的場(chǎng)景保證數(shù)據(jù)按寫(xiě)入時(shí)間的順序性
這里著重對(duì)比一下 Redis、RabbitMQ/RocketMQ、Kafka、Plusar。| Redis
Redis 實(shí)現(xiàn)消息隊(duì)列可以通過(guò) List 類(lèi)型、Pub/Sub、Stream（Redis 5.0）類(lèi)型來(lái)實(shí)現(xiàn)，HA 使用多副本或者集群的方式。作為消息隊(duì)列使用起來(lái)非常方便，但是也有很多的弊端：-
-
數(shù)據(jù)持久性：Pub/Sub 只提供緩沖區(qū)廣播能力，不進(jìn)行持久化，List/Stream 即使基于 aof 和 rdb 持久化策略，但是并沒(méi)有事務(wù)性保障，在宕機(jī)恢復(fù)后還是存在丟失數(shù)據(jù)的可能性
-
消息堆積能力：List 隨長(zhǎng)度增大，內(nèi)存不斷增長(zhǎng)；Pub/Sub 只在緩沖區(qū)內(nèi)堆積，緩沖區(qū)滿(mǎn)消費(fèi)者強(qiáng)制下線；Stream 創(chuàng)建時(shí)可以指定隊(duì)列最大長(zhǎng)度，寫(xiě)滿(mǎn)后剔除舊消息
除此之外，List 類(lèi)型無(wú)法支持消息廣播，和 Pub/Sub 一樣也不支持重復(fù)消費(fèi)。結(jié)合整體來(lái)看 Redis 作為消息隊(duì)列大多數(shù)只應(yīng)用在數(shù)據(jù)量小，對(duì)丟失數(shù)據(jù)不敏感的業(yè)務(wù)場(chǎng)景，適用范圍較小，復(fù)雜業(yè)務(wù)并且有一定運(yùn)維支撐的情況下，可以直接考慮企業(yè)級(jí)消息中間件。| RabbitMQ vs Kafka vs RocketMQ
這幾個(gè)可以作為企業(yè)級(jí)消息中間件的代表，而 RocketMQ 在設(shè)計(jì)之初就借鑒了很多 RabbitMQ、Kafka 的設(shè)計(jì)理念，例如：Routing、多副本、順序?qū)懀↖O），也廣泛應(yīng)用在淘寶雙十一等場(chǎng)景。HA：在 HA 方面他們都是通過(guò)副本的方式，區(qū)別是 RabbitMQ 是集群級(jí)別的副本，Kafka 是多 partiton 和 ISR、選舉機(jī)制，而 RocketMQ 通過(guò)多（master/slave）副本同時(shí)保障 NameServer 和 Broker。高吞吐：Kafka 和 RocketMQ 通過(guò)直接操作文件系統(tǒng)，相比于 RabbitMQ，順序?qū)懩艽蠓忍嵘龜?shù)據(jù)的處理速度。Kafka 為了進(jìn)一步提升消息的吞吐量，可以采用客戶(hù)端緩沖隊(duì)列的方式批量發(fā)送，但也會(huì)存在宕機(jī)丟失數(shù)據(jù)的可能性，可以通過(guò)設(shè)置 batch.size 與 linger.ms 來(lái)動(dòng)態(tài)調(diào)整，相比于 RocketMQ 更加靈活。Kafka 的 partition 機(jī)制的確會(huì)帶來(lái)性能的提升，但是在 Topic 不斷增多的情況下，眾多的 partition 及副本也將順序?qū)懼鸩酵嘶癁殡S機(jī)寫(xiě)，并且擴(kuò)容時(shí)，由于 hash 值的變化，也會(huì)涉及到大量 partiton 數(shù)據(jù)的遷移。RocketMQ 采用 commitlog 的方式實(shí)現(xiàn)全局寫(xiě)，所以能支持更多的 Topic，擴(kuò)容也不涉及大量數(shù)據(jù)的遷移。功能豐富性：Kafka 只有基礎(chǔ)的消息類(lèi)型，RabbitMQ 支持優(yōu)先級(jí)隊(duì)列，通過(guò) TTL 和死信隊(duì)列可以實(shí)現(xiàn)消息的延遲和重試，但是需要提前創(chuàng)建好對(duì)應(yīng)重試頻率的隊(duì)列。例如：1s 重試隊(duì)列，10s 重試隊(duì)列，RocketMQ 則內(nèi)置了 18 個(gè)重試頻率“1s 5s 10s 30s 1m 2m……”，另外也具有獨(dú)有的 2PL 事務(wù)消息，很好的保障業(yè)務(wù)邏輯與消息發(fā)送的一致性。重復(fù)消費(fèi)：他們?nèi)叨疾捎?ACK 機(jī)制保障了單條消息重復(fù)消費(fèi)的能力，Kafka 通過(guò) offset 和 partition 特殊的 ttl 機(jī)制（segment 過(guò)期，按文件名順序清理），能支持通過(guò)重置 offset 來(lái)回溯歷史數(shù)據(jù)。消息順序性：RabbitMQ 和 RocketMQ 可以保證寫(xiě)入同一 topic 的順序性，但是在多個(gè)消費(fèi)者同時(shí)消費(fèi)的情況下還是會(huì)出現(xiàn)亂序的情況。在數(shù)據(jù)量較大的時(shí)候，我們也可以通過(guò)單個(gè)消費(fèi)者消費(fèi)，再按照一定的分發(fā)策略分配給多個(gè)消費(fèi)者執(zhí)行，只不過(guò)會(huì)提升整體復(fù)雜度，同時(shí)會(huì)帶來(lái)更多的 HA、維護(hù)成本考量。Kafka 可以保障單個(gè) partition 的順序性，并且每個(gè) partiton 只允許一個(gè)消費(fèi)者來(lái)消費(fèi)（N：1），這就從策略上避免了多消費(fèi)者的情況，在數(shù)據(jù)量較大的情況下，可以通過(guò)劃分更多的 partition 提升數(shù)據(jù)處理能力。綜合來(lái)講，RabbitMQ、RocketMQ 使用 Queue 模型，豐富的消息隊(duì)列功能，更多的應(yīng)用在業(yè)務(wù)場(chǎng)景，Kafka 基于 Streaming 模型，結(jié)合批處理、流式處理，更多的應(yīng)用在大數(shù)據(jù)分析場(chǎng)景。| Pulsar
Pulsar 作為 Apache 開(kāi)源、云原生的消息中間件，誕生之初就引發(fā)了很大的關(guān)注。設(shè)計(jì)上避免了 Kafka 遇到的功能豐富性、擴(kuò)容等方面的問(wèn)題，采用計(jì)算、存儲(chǔ)分離的架構(gòu)，broker 層只作為“API 接口層”，存儲(chǔ)交給更專(zhuān)業(yè)的 bookeeper，由于 broker 層的無(wú)狀態(tài)性，結(jié)合 Kubernetes 等非常方便的進(jìn)行擴(kuò)容。
并且 Pulsar 支持多個(gè)消費(fèi)模型提升消費(fèi)者處理能力，例如：exclusive、failover、shared、key-shared 等。可以說(shuō)綜合了 Kafka 和其他消息中間件的眾多優(yōu)點(diǎn)：-
HA、高吞吐：和 Kafka 類(lèi)似，通過(guò)多 partition 和選舉機(jī)制功，除此之外，還支持豐富的跨地域復(fù)制能力
-
功能豐富性：可以支持秒級(jí)的延遲消息，以及獨(dú)特的重試隊(duì)列和私信隊(duì)列
-
消息順序性：為了實(shí)現(xiàn) partition 消息的順序性，和 Kafka 一樣，都需要將消息寫(xiě)入到同一 broker，區(qū)別是 Kafka 會(huì)同時(shí)存儲(chǔ)消息在該 broker，broker 和 partiton 綁定在一起，而 Pulsar 可以將消息分塊（segment）后，更加均勻的分散到 bookeeper 節(jié)點(diǎn)上，broker 只需要記錄映射關(guān)系即可，這樣在資源擴(kuò)容時(shí)，可以更加快速便捷
像能量守恒定律一樣，系統(tǒng)的復(fù)雜度往往也是守恒的，實(shí)現(xiàn)即高性能又高可用的消息中間件需要的技術(shù)復(fù)雜性，不會(huì)憑空消失，只會(huì)從一個(gè)地方轉(zhuǎn)移到另一個(gè)地方。消息隊(duì)列本質(zhì)上可以理解為 feature+fs，只不過(guò)存儲(chǔ)、計(jì)算分離架構(gòu)，將各層間的職責(zé)分離，使每一層都能專(zhuān)注在自身領(lǐng)域，以應(yīng)對(duì)海量數(shù)據(jù)和更加復(fù)雜多變的環(huán)境，這也是現(xiàn)在新技術(shù)發(fā)展的一個(gè)趨勢(shì)。作為后起之秀，的確可以站在巨人的肩膀上，避免很多設(shè)計(jì)上的不足，同時(shí)引入一些新的架構(gòu)理念，但是要成功的在其中分一杯羹，同樣也要面臨用戶(hù)學(xué)習(xí)成本高、缺少殺手級(jí)應(yīng)用、如何遷移等等這些現(xiàn)實(shí)性的問(wèn)題。不過(guò)依靠良好的社區(qū)和技術(shù)先驅(qū)，隨著時(shí)間的變遷，這些短板也會(huì)逐步補(bǔ)齊，真正適應(yīng)當(dāng)前時(shí)代的技術(shù)一定會(huì)脫穎而出。
文章來(lái)源：https://c1n.cn/J3wve
轉(zhuǎn)自：幽鬼，侵刪
