【服務(wù)治理】服務(wù)治理漫談

0. 前言

本文是服務(wù)治理領(lǐng)域?qū)ｎ}的第一篇，并不希望也無法大包大攬將所有的點(diǎn)都覆蓋到，更意在從一些更貼近我們實(shí)際工作的角度來進(jìn)行更抽象層次的剖析，更多分享的是我認(rèn)為重要或者有意思的一些方法論和邏輯推演過程。這能給我們后續(xù)無論是業(yè)務(wù)應(yīng)用還是基礎(chǔ)技術(shù)領(lǐng)域的服務(wù)治理提供一些參考。

1. 什么是服務(wù)治理

在一切的最開始，我們先來問自己一個(gè)問題，什么叫做服務(wù)治理？網(wǎng)上有很多關(guān)于服務(wù)治理的定義，維基百科也有著對(duì)應(yīng)的定義。林林總總，有宏觀的也有細(xì)節(jié)的。而在本文中，我嘗試為其進(jìn)行另一個(gè)維度上的簡單定義：

服務(wù)治理，即以組織、業(yè)務(wù)和系統(tǒng)三者為核心要素建立連接，在此基礎(chǔ)上實(shí)現(xiàn)服務(wù)系統(tǒng)的正向打通和逆向反饋。

1.1 三要素

• 組織
  組織即人。服務(wù)不可能獨(dú)自存在，我們在進(jìn)行治理的過程中，往往過度重視面向業(yè)務(wù)的用戶體驗(yàn)，而會(huì)忽視掉在這個(gè)技術(shù)生態(tài)上另外一個(gè)非常重要的服務(wù)對(duì)象—技術(shù)人員。大家往往更專注于如何設(shè)計(jì)出一個(gè)高性能高可擴(kuò)展的系統(tǒng)，而冷落了技術(shù)人員在這之中的訴求。一個(gè)良好的服務(wù)治理的判斷標(biāo)準(zhǔn)，即要在服務(wù)好普通用戶的同時(shí)，也需要讓在這生態(tài)之上的技術(shù)同學(xué)得到歸屬感。
• 業(yè)務(wù)
  業(yè)務(wù)即產(chǎn)品。毋庸置疑，技術(shù)是為業(yè)務(wù)服務(wù)的?？照劶夹g(shù)本身沒有意義。所以我們需要保持對(duì)業(yè)務(wù)敏銳的洞察力和前瞻意識(shí)，這樣才能設(shè)計(jì)出一個(gè)演化式的合理服務(wù)架構(gòu)。比如業(yè)務(wù)流量很低且還處于快速試錯(cuò)階段，而你卻上了一整套的高并發(fā)的解決方案，這就本末倒置了。大部分技術(shù)同學(xué)天然會(huì)有“秀技術(shù)肌肉”的沖動(dòng)，這是正常的，但作為架構(gòu)師，需要合理控制組織的欲望，結(jié)合業(yè)務(wù)實(shí)際進(jìn)行處理，才能達(dá)到一個(gè)良好的服務(wù)治理的狀態(tài)。
• 系統(tǒng)
  系統(tǒng)層面上，也即我們最常談及服務(wù)治理時(shí)候會(huì)關(guān)注的點(diǎn)。如何做一個(gè)可靠、高性能、自動(dòng)化、可擴(kuò)展且能夠快速迭代的系統(tǒng)出來響應(yīng)業(yè)務(wù)的需求呢？良好的服務(wù)治理要求我們能夠結(jié)合組織和業(yè)務(wù)實(shí)際，進(jìn)行系統(tǒng)層面的控制。這樣也是下列章節(jié)中會(huì)重點(diǎn)提及的內(nèi)容。

如上圖所示，三要素之間會(huì)相互影響，良好的服務(wù)治理能夠讓三者相互促進(jìn)優(yōu)化迭代，不合理的服務(wù)治理將導(dǎo)致三者相互拉扯、沖突，乃至降低士氣和效率并影響最后的公司產(chǎn)出。所以服務(wù)治理，從來就不單純只是系統(tǒng)、技術(shù)的問題，也涵蓋著人和事情的要素。

1.2 系統(tǒng)層面的正向打通和逆向反饋

在系統(tǒng)層面的服務(wù)治理的范疇，相關(guān)的介紹有很多，比如業(yè)內(nèi)享有盛譽(yù)的阿里開源框架 Dubbo（目前已入 Apache）中的相關(guān)圖表的呈現(xiàn)：

可以看出在一個(gè)復(fù)雜的網(wǎng)絡(luò)拓?fù)鋱鼍爸?#xff0c;我們需要對(duì)這個(gè)服務(wù)網(wǎng)進(jìn)行各種各樣的治理，來確保這個(gè)網(wǎng)在技術(shù)層面能夠盡可能地維持健康和有效。但如何去歸納我們到底需要什么樣的服務(wù)治理呢？如下圖所示：

在系統(tǒng)層面，我們認(rèn)為：

服務(wù)治理其實(shí)是由流量的正向打通和逆向反饋所構(gòu)成的一個(gè)環(huán)

正向打通，即如何將流量打通，這也是對(duì)于一個(gè)服務(wù)本身最基本的要求。我們于是需要思考：

如何做跨服務(wù)通訊，Rest 還是 Rpc ？序列化用 json 還是 pb ？能支持什么協(xié)議？是否支持多協(xié)議轉(zhuǎn)換？

如何做服務(wù)注冊/發(fā)現(xiàn)，用 Eureka、Zookeeper、etcd、Consul、Nacos？

如何做負(fù)載均衡，用軟負(fù)載，還是硬負(fù)載？負(fù)載算法用 RR、Random、一致性哈希？

如何做路由篩選，撈一百個(gè)，還是 IDC 優(yōu)先，還是類似 Envoy 這樣的防恐慌機(jī)制或者干脆來個(gè)類似 Dubbo 的腳本花活？

如何做授權(quán)鑒權(quán)，是否需要 TLS，是否需要黑白名單，是否要驗(yàn)簽，用什么加密算法，機(jī)器如何互信？
……

逆向反饋，則是代表我們?nèi)绾位诟鞣N基于流量進(jìn)來后觀察到的數(shù)據(jù)，來進(jìn)行系統(tǒng)性地決策（一般是負(fù)反饋）我們的服務(wù)網(wǎng)需要做哪些事情才能讓整張網(wǎng)持續(xù)處于健康狀態(tài)。于是，我們思考，

如何扛住流量洪峰，削峰、限流？怎么限流？信號(hào)量、令牌桶、漏桶、固定窗口計(jì)數(shù)、滑動(dòng)窗口計(jì)數(shù)、線程隔離？

如何正確處理異常，及時(shí)熔斷？一鍵降級(jí)？級(jí)聯(lián)決策關(guān)閉入口？

如何讓系統(tǒng)可觀察，監(jiān)控、報(bào)警、分布式鏈路追蹤？選擇 Cat、Zabbix、Falcon、Prometheus、Zipkin、Skywalking？

如何提升資源效率，采用容器，Kvm？Docker？Swarm？K8s？Mesos？Openstack？

如何定義一個(gè)服務(wù)的健康度，SLA？RTO？RPO？健康度量模型？
……

2. 服務(wù)治理的發(fā)展史

我們都知道，服務(wù)的發(fā)展是由單塊應(yīng)用，服務(wù)水平分層，服務(wù)縱向切割，乃至后續(xù)微服務(wù)思想的興起，**“兩個(gè)星期”重構(gòu)法則和“兩張披薩”**團(tuán)隊(duì)等眼花繚亂的服務(wù)拆分方法論充塞你的耳目。這都是些常見的論調(diào)，但不是本章節(jié)闡述的重點(diǎn)。本章節(jié)更關(guān)注的是服務(wù)治理發(fā)展拆分過程中，所必然要面對(duì)的一個(gè)核心問題—“服務(wù)拆分后，之間如何產(chǎn)生聯(lián)系？”也即：

如何形成復(fù)雜服務(wù)節(jié)點(diǎn)的網(wǎng)絡(luò)？

限于篇幅，我們來簡單回顧下針對(duì)該問題的幾個(gè)重要思潮。

2.1 Server Proxy

我姑且稱之為集中式代理階段。該階段也是最樸素的解決方案，多采用集中式的單點(diǎn)服務(wù)集群來承擔(dān)較多服務(wù)治理的功能。比如集中式部署 Lvs、Nginx、Haproxy、Tengine、Mycat、Atlas、Codis等等，就是最常見的方式。這種方式的優(yōu)勢在于便于功能的集中維護(hù)，且語言無關(guān)，上手成本低，所以其實(shí)在大中小公司特別是創(chuàng)業(yè)公司里面擁有大量受眾。但其帶來的問題也很明顯，以最風(fēng)靡的域名+Http Rest調(diào)用 + Nginx組合套裝為例，調(diào)用鏈路需要經(jīng)過 DNS（DNS cache）、KeepAlived、(Lvs)、Nginx 幾層。超長的調(diào)用鏈路路和多個(gè)單點(diǎn)系統(tǒng)，將會(huì)在服務(wù)規(guī)模上升時(shí)引發(fā)穩(wěn)定性和性能問題。在丁丁租房和美團(tuán)就多次發(fā)生類似的單點(diǎn)故障。丁丁租房曾經(jīng)因?yàn)?Nginx、DNS以及 Codis-Proxy故障而導(dǎo)致過大面積的業(yè)務(wù)影響。美團(tuán)的 DNS、MGW 等都遭遇過類似問題，其進(jìn)一步因此而推出去內(nèi)網(wǎng)Http調(diào)用轉(zhuǎn)為Thrift直連的技術(shù)項(xiàng)目?？傮w來看，其必然有用武之地，其更適合初創(chuàng)公司，或者特別強(qiáng)調(diào)跨語言的應(yīng)用場景，Server Proxy 都可作為一個(gè)快速上手的解決方案以供使用。但在使用時(shí)候，需要對(duì)其缺陷有著清晰認(rèn)識(shí)以便于在后續(xù)演化中做出正確決策。

2.2 Smart Client

樸素直接的 Server Proxy 帶給我們便利的同時(shí)，也帶給我們大量的問題，而這個(gè)時(shí)候，為了應(yīng)對(duì)這類問題，Smart Client 快速崛起并綻放出其強(qiáng)大的生命力。我們姑且稱之為框架化階段，該階段為了解決 Server Proxy 所存在的單點(diǎn)長鏈路的問題，替代以直連的方式來構(gòu)建兩個(gè)節(jié)點(diǎn)之間的聯(lián)系。這一步到位地解決了單點(diǎn)長鏈路的問題，且能夠在直連的基礎(chǔ)上，進(jìn)行更大的性能優(yōu)化和穩(wěn)定性的抬升。代表開源產(chǎn)品（服務(wù)框架 or Rpc 框架）有比如 Uber 的 Ring-pop、阿里的 Dubbo、螞蟻的 Sofa-Rpc、當(dāng)當(dāng)?shù)?Dubbox、微博的 Motan、點(diǎn)評(píng)的 Pigeon/Zebra、百度的brpc/Stargate、Grpc、Thrift等。大的思路即兩個(gè)：

硬的不行，那就轉(zhuǎn)為軟的。硬件式的服務(wù)治理行不通，那么就轉(zhuǎn)到軟件式的服務(wù)治理。

遠(yuǎn)的不行，那就轉(zhuǎn)為近的。遠(yuǎn)端集中式部署的方式行不通，那么就拉到和我應(yīng)用進(jìn)程里面部署。

如此一來，Server Proxy思潮中的諸多弊病就被一一化解了。

鼓吹了很久 Smart Client 的優(yōu)點(diǎn)，那他不存在問題嗎？必然還是存在的，而且問題也十分明顯和突出。

第一方面，我們知道，微服務(wù)領(lǐng)域的氣質(zhì)是趨向自治的。Smart Client 也被成為富客戶端，而采取這種方式將很嚴(yán)重地限制我們在技術(shù)棧上的選擇，換一個(gè)語言就需要重新實(shí)現(xiàn)一遍基本所有的治理能力，及其之后帶來的多套語言下成本增長的維護(hù)升級(jí)成本，這個(gè)對(duì)于絕大部分公司來說都是難以承受的負(fù)擔(dān)。Uber 不得不針對(duì) Ring-pop 推出 node 和 go 版，微博的 Motan 也推出了多個(gè)語言版本，Grpc、Thrift也沒能逃出這個(gè)命運(yùn)。而現(xiàn)在大部分的公司都會(huì)混合兩種以上的語言進(jìn)行實(shí)際的開發(fā)。所以這個(gè)問題也必須要進(jìn)行正視。

第二方面，Smart Client 采用重 SDK 的方式嵌入應(yīng)用進(jìn)程進(jìn)行共存，這將使得服務(wù)治理的運(yùn)維工作和業(yè)務(wù)應(yīng)用的維護(hù)完全攪到一起。這在現(xiàn)實(shí)的工作場景中，給服務(wù)治理的運(yùn)維難度抬升了幾個(gè)量級(jí)，服務(wù)治理團(tuán)隊(duì)不得不被迫面對(duì)多個(gè)版本并存的架構(gòu)代碼，以及推行一個(gè)版本可能需要半年以上的噩夢。

當(dāng)然，盡管有以上問題，但是由于目前沒有特別成熟的替代方案，Smart Client 目前仍然在高并發(fā)大流量的業(yè)務(wù)場景中占據(jù)著主流地位。如果語言能夠盡可能收斂的場景也可以使用，比如可以采用 Java 版的 Smart Client，并對(duì)于不高的Nodejs流量采用Http Rest 加上域名的方式來做折中的服務(wù)治理。

2.3 Local Proxy

Server Proxy 和 Smart Client 都有著無法回避的問題，那么還有其他的解決方案嗎？為了回應(yīng)這一個(gè)問題，Local Proxy 應(yīng)運(yùn)而生，既然集中式部署有單點(diǎn)問題，富客戶端又有耦合的問題，那么為什么不取一個(gè)折中呢？這時(shí)候的思路就變?yōu)?#xff1a;

就近進(jìn)行進(jìn)程級(jí)別治理。即采用本地進(jìn)程級(jí)別代理的方式，既可以規(guī)避集中式單點(diǎn)部署的問題，又可以回避語言相關(guān)和應(yīng)用耦合的問題。

這個(gè)思路開始逐步風(fēng)靡，非常多的治理方案也在這個(gè)思想下如雨后春筍冒出。
airbnb 的 SmartStack 采用了四件套完成了整個(gè)核心的服務(wù)串聯(lián)治理過程，是一個(gè)樸素解決方案。

而攜程 OSP 也采用類似方式來進(jìn)行處理，和 airbnb 的差別主要在于將 Synapse 和 Haproxy 的功能整合為了一個(gè) Proxy 來替代。

在云領(lǐng)域里面，由于跨語言和運(yùn)維效率被放在了更為重要的角度來審視，這種思想更是占據(jù)了主導(dǎo)的地位，Mesos+Marathon的云架構(gòu)中，也有類似方案，采用Haproxy進(jìn)行路由，中控節(jié)點(diǎn)會(huì)刷新對(duì)應(yīng)的路由信息。

Google 親兒子 K8s 也是如此，考慮到了 Proxy 的性能問題，進(jìn)行了折中處理，采用 Iptables 規(guī)則注入的方式進(jìn)行轉(zhuǎn)發(fā)（當(dāng)然，這種方式也有不可回避的問題）

這些方式都有其對(duì)應(yīng)的問題，但是最大的一個(gè)問題即：

如何解決其帶來的性能下滑。無論 iptables 或者采用 agent 來進(jìn)行治理、轉(zhuǎn)發(fā)、通訊，都會(huì)面臨著一個(gè)繞不過去的問題，在高流量高并發(fā)的場景下，其對(duì)性能的損耗有多少？相比于眾多已經(jīng)裝備有富客戶端直連的應(yīng)用來說，性能的差距有多大？目前已知的部分產(chǎn)品，在高流量下QPS和RT都有著不小的損耗，有的解決方案甚至能夠達(dá)到20%的性能損耗，這明顯在很多場景下是無法接受的。

這時(shí)候，Local Proxy 的最后一個(gè)殺器 — Servicemesh正式被推上風(fēng)口浪尖，2018年也被稱為 Servicemesh 元年。我認(rèn)為，其理念如下：

1. 犧牲一定的性能和資源，換取服務(wù)治理理整體的?高度?自治和可運(yùn)營
2. 執(zhí)?行行和控制分離，數(shù)據(jù)平?面和控制平?面切割
3. 虛擬化、標(biāo)準(zhǔn)化、產(chǎn)品化，定義規(guī)范。

Servicemesh 從雜亂無章，百家齊放的 Local Proxy 思潮中解放出來，提出了更系統(tǒng)地思考。本文無意對(duì) Servicemesh 做更多概念性的描述，網(wǎng)上已經(jīng)有相當(dāng)多類似的文章，此處限于篇幅不展開。于是，有多家巨頭合作的 Istio（其本來目的是為了幫助應(yīng)用更好地上云）的珠玉在前，其他公司也紛紛基于/參考Isito做出自己的解決方案：

阿里基于 golang 重寫了 Envoy 并在這基礎(chǔ)上構(gòu)建了 Sofa-Mosn/Pilot，

下沉了 Istio 中頗受詬病的 Mixer 的限流能力，

騰訊基于 Envoy 進(jìn)行改造整合內(nèi)部的 TSF 服務(wù)框架，

美團(tuán)基于 Envoy 改造整合內(nèi)部的 Octo 服務(wù)框架，

微博基于 Motan-Go 研制出 Motan-Mesh，整合了自己的服務(wù)治理體系，

華為的 ServiceComb 也是類似的做法， Mixer完全下沉，

Twitter推出 Conduit，基于Rust，也將Mixer完成下沉，

貓眼參考了 Envoy/Sofa-Mosn 的架構(gòu)，自研了Maoyan-Mesh。
……

但是，Servicemesh 仍然有幾個(gè)問題沒解決，除了仍然繞不開的性能問題外，目前也有越來越多的人在進(jìn)行mesh反思一個(gè)問題：

控制面板和數(shù)據(jù)面板切割的標(biāo)準(zhǔn)是什么？是不是過于理想化了？

這個(gè)問題目前見仁見智，此處不展開。雖然 Servicemesh 目前還在起步階段，很多問題也還在摸索中，但是從微服務(wù)領(lǐng)域發(fā)展的趨勢來看，上文所述的 Servicemesh 的三個(gè)理念與其不謀而合，必然是未來的大勢所趨。

2.4 總結(jié)

這一章回顧了服務(wù)治理的發(fā)展歷程，經(jīng)歷了三個(gè)大階段的思潮，我們回歸初心，可以看到每個(gè)階段的方案其實(shí)都有其適用和不適用的場景，沒有最好的方案，只有最合適的方案。我們也可以沿著這三個(gè)階段的思考邏輯發(fā)現(xiàn)，其實(shí)對(duì)于服務(wù)的治理，也是處于一個(gè)反復(fù)摸索、糾結(jié)，螺旋上升的過程。

3. 我們需要什么樣的服務(wù)治理

我們了解了什么是服務(wù)治理、服務(wù)治理是怎么演變發(fā)展的，這時(shí)候，我們不禁會(huì)想，我也要做服務(wù)治理！但是，請先停一下，請先問一下自己，我們需要什么樣的服務(wù)治理？

這個(gè)問題很好回答，同時(shí)也很難回答。簡單來說，這取決于三要素的發(fā)展現(xiàn)狀。取決于你的組織、業(yè)務(wù)和系統(tǒng)的健康度、匹配度和成熟度。但這個(gè)形而上的“道”，如何轉(zhuǎn)換成形而下的“器”，確是需要結(jié)合實(shí)際場景case by case去思考的，沒有標(biāo)準(zhǔn)答案。

你可以說 All In One 的巨無霸工程在創(chuàng)業(yè)初期短平快的組織結(jié)構(gòu)和業(yè)務(wù)試錯(cuò)情況下能夠快速發(fā)揮作用，
也可以說雖然洋蔥架構(gòu)如此多的層次讓你剝開之后只想哭但是能夠在特定的組織結(jié)構(gòu)下起到微妙的平衡，
你也可以說你暫時(shí)并不需要彈性不需要高性能因?yàn)闄?quán)衡起來性價(jià)比不高，
你甚至可以說不需要微服務(wù)因?yàn)檫\(yùn)維成熟度完全跟不上。
……

發(fā)現(xiàn)沒有，所以，這才是對(duì)架構(gòu)師而言有趣而有挑戰(zhàn)的地方，服務(wù)治理從廣義上來說，并不是一個(gè)技術(shù)問題，而是一個(gè)有趣的哲學(xué)問題。架構(gòu)師需要利用其前瞻和洞察的能力，引領(lǐng)團(tuán)隊(duì)走向正確的方向，而不是一味糾結(jié)于是不是沒有響應(yīng)好所有的訴求，是不是沒有遵循所謂的最佳實(shí)踐。這么考慮一下，如果世界上只有一種顏色，只有一種解法，那未免也太無聊了吧，這個(gè)世界的有趣不正在與你養(yǎng)出的那只充滿了“迫不得已”而又“正該如此”的薛定諤的貓嗎？

4. 應(yīng)用領(lǐng)域的指導(dǎo)原則

4.1 四個(gè)問題

網(wǎng)上有很多關(guān)于應(yīng)該怎么拆分服務(wù)的文章，更多偏向技術(shù)層面。此處不加以贅述，我們討論四個(gè)問題，也是經(jīng)常困擾我們的四個(gè)重要問題：

應(yīng)該在什么階段進(jìn)行拆分？
如前面提及的，考慮下你的業(yè)務(wù)迭代速度是否會(huì)引起系統(tǒng)所有權(quán)和使用權(quán)的競爭，進(jìn)一步反向制約迭代的效率；考慮下是不是大應(yīng)用導(dǎo)致你技術(shù)升級(jí)優(yōu)化和資源的使用上困難重重；考慮下公司的運(yùn)維水平和團(tuán)隊(duì)成員的素質(zhì)是不是能夠支撐起更細(xì)粒度的微服務(wù)體系結(jié)構(gòu)。你考慮清楚了這三點(diǎn)，你就知道你是否應(yīng)該進(jìn)行拆分了。

應(yīng)該按照什么維度來拆？
大原則上來說，按照業(yè)務(wù)領(lǐng)域進(jìn)行拆分即可。在領(lǐng)域之內(nèi)，進(jìn)行分層拆解，將接入層、邏輯層和數(shù)據(jù)層復(fù)雜到一定程度的時(shí)候進(jìn)行橫向拆解。《微服務(wù)設(shè)計(jì)》一書中，提到了“限界上下文”的概念來讓系統(tǒng)和業(yè)務(wù)邊界進(jìn)行對(duì)齊也是類似的道理。

服務(wù)拆分到多小算小？
有一個(gè)說法是“確保兩個(gè)星期之內(nèi)能夠重構(gòu)”。這和敏捷開發(fā)理論中的“重構(gòu)式迭代”不謀而合，不過我覺得這種理論有待商榷，在大量的實(shí)際場景中不是很適用。我比較認(rèn)同的是另一個(gè)說法—“足夠小就行”。沒有唯一的衡量標(biāo)準(zhǔn)，這個(gè)取決于你的業(yè)務(wù)發(fā)展速度，業(yè)務(wù)復(fù)雜度，技術(shù)棧異構(gòu)程度。很多人的傾向是，更愿意對(duì)一些功能在不明確后續(xù)發(fā)展的時(shí)候，盡量能不拆就不拆。這同樣也是我的建議。另外建議，確保一個(gè)服務(wù)只有一個(gè)團(tuán)隊(duì)在維護(hù)，這能避免大量的問題。當(dāng)你發(fā)現(xiàn)有多個(gè)團(tuán)隊(duì)在維護(hù)的時(shí)候，說明你可能需要拆分了。

微服務(wù)團(tuán)隊(duì)需要多大？
亞馬遜創(chuàng)始人貝佐斯的“兩個(gè)披薩”原則基本適用，該原則為“每個(gè)內(nèi)部團(tuán)隊(duì)都應(yīng)該足夠小，兩個(gè)比薩餅就能解決伙食問題”。這樣團(tuán)隊(duì)更容易具備戰(zhàn)斗力和凝聚力，也能擁有更好的效率和對(duì)未來的應(yīng)變能力。

4.2 組織邊界的兩個(gè)原則

服務(wù)治理三大要素中，我認(rèn)為組織（即人）是最為重要的一個(gè)因素，也能夠?qū)ζ渌麅蓚€(gè)因素起更顯著影響作用的因素。如下兩個(gè)定律在業(yè)內(nèi)鼎鼎大名：

1. 康威第一定律：組織溝通方式會(huì)通過系統(tǒng)設(shè)計(jì)表達(dá)出來。
2. 咨詢第二定律：不管一開始看起來什么樣，它永遠(yuǎn)是人的問題。

人是復(fù)雜的動(dòng)物，你必然會(huì)發(fā)現(xiàn)，脫離組織結(jié)構(gòu)來談最佳的系統(tǒng)設(shè)計(jì)是不切實(shí)際的。無論我們的初心多么的純粹，希望兩個(gè)組織結(jié)構(gòu)一起協(xié)同做一件類似的事情，最后你基本都會(huì)發(fā)現(xiàn)，會(huì)做成兩件事情，或者你將擁有一個(gè)跨多團(tuán)隊(duì)的n層洋蔥圈架構(gòu)。你可以動(dòng)用行政的方式讓多團(tuán)隊(duì)按照你的設(shè)想精密地共同完成一件你畫好藍(lán)圖的大系統(tǒng)，但是往往最后的代價(jià)就是跌入谷底的效率和員工幸福感。

所以首當(dāng)其沖，我們應(yīng)該倡導(dǎo)組織邊界和系統(tǒng)邊界/業(yè)務(wù)邊界對(duì)齊。比如當(dāng)你不得不面對(duì)分布式異地辦公的服務(wù)治理場景時(shí)，考慮盡可能地讓每個(gè)辦公區(qū)的團(tuán)隊(duì)承擔(dān)獨(dú)立業(yè)務(wù)的服務(wù)系統(tǒng)。這也是 Amazon 和 Netflix 等公司所踐行的原則。

5. 技術(shù)領(lǐng)域的指導(dǎo)原則

面向技術(shù)領(lǐng)域，這個(gè)問題比處理上面的問題要更直接而明確，我們挑選其中四個(gè)方向來鋪開分析：

可運(yùn)營

高可用

高性能

自動(dòng)化與標(biāo)準(zhǔn)化

5.1 可運(yùn)營

我們認(rèn)為可運(yùn)營的核心在于可觀察，以及在觀察之后的可控制。

5.1.1 可觀察 — 監(jiān)控報(bào)警

可運(yùn)營的前提和核心即可觀察，這即進(jìn)一步要求我們需要有足夠立體的監(jiān)控報(bào)警能力來支撐。這也很大程度決定了我們服務(wù)生態(tài)體系的想象力。

一般劃分的維度，我們可以自底向上劃分為：基礎(chǔ)設(shè)施級(jí)監(jiān)控、系統(tǒng)級(jí)監(jiān)控、業(yè)務(wù)級(jí)監(jiān)控、產(chǎn)品級(jí)監(jiān)控。每個(gè)層級(jí)的監(jiān)控都有自己的關(guān)注核心和邏輯，基礎(chǔ)設(shè)施級(jí)的監(jiān)控比如運(yùn)維層面會(huì)更關(guān)注機(jī)器 CPU、MEM、磁盤 IO、網(wǎng)卡 IO 、CDN 速度、多IDC延時(shí)等。系統(tǒng)級(jí)監(jiān)控更關(guān)注單應(yīng)用內(nèi)，如JVM使用、堆棧、線程情況，拋異常 case、彈性指標(biāo)、TPS、RT 等，以及跨應(yīng)用的調(diào)用鏈路健康情況。業(yè)務(wù)級(jí)監(jiān)控更偏業(yè)務(wù)導(dǎo)向，如下單人數(shù)、庫存余量、支付數(shù)、退款數(shù)、UGC 增量等等和業(yè)務(wù)直接關(guān)聯(lián)的指標(biāo)；而產(chǎn)品級(jí)監(jiān)控則會(huì)從產(chǎn)品整體去進(jìn)行核心產(chǎn)品指標(biāo)的定義，比如產(chǎn)品留存率、頁面轉(zhuǎn)化率、營銷支付轉(zhuǎn)化率、認(rèn)證人數(shù)、認(rèn)購單數(shù)等等。比較常見的監(jiān)控報(bào)警產(chǎn)品有 Falcon、Zabbix、Nagios、Cat、Prometheus 等。

日志也是監(jiān)控的一環(huán)，業(yè)界有開源的解決方案 ELK，但 ELK 本身存在很大的優(yōu)化空間，所以很多公司都會(huì)基于 ELK 或者基于他的采集模型做定制化開發(fā)。

需要特別提到的是，需要正視四個(gè)層級(jí)的立體式監(jiān)控情況下可能引發(fā)的報(bào)警風(fēng)暴問題，這就需要能夠有決策中樞進(jìn)行報(bào)警的分析、關(guān)聯(lián)和聚合，并且可以提供對(duì)應(yīng)的ACK機(jī)制，這則是一個(gè)長期的建設(shè)過程。

5.1.2 可控制 — 指令下發(fā)

除了可觀察外，可運(yùn)營的另一關(guān)鍵就是能夠動(dòng)態(tài)下發(fā)指令或配置，這樣才能真正意義上實(shí)現(xiàn)可控制的目標(biāo)。一般來說：

基礎(chǔ)架構(gòu)/運(yùn)維層面偏向于使用 puppet、ansible 之類的批量下發(fā)工具來進(jìn)行指令、配置、安裝包之類的動(dòng)態(tài)下發(fā)。但 ansible 由于權(quán)限過大的問題，使用時(shí)候要慎重。

而在中間件層面，更多采用配置中心、注冊中心來進(jìn)行下發(fā)。下發(fā)的方式，可以是推、拉或者推拉結(jié)合的方式來進(jìn)行。二者的底層存儲(chǔ)選型其實(shí)比較類似的，所以也有一些共性問題需要注意。比如你考慮一下，你做好迎接 Zookeeper 給你帶來的 watch 事件丟失以及重度 SDK 引入潛在風(fēng)險(xiǎn)的挑戰(zhàn)了嗎？你做好 etcd 很難擴(kuò)展且無法做多中心的心里準(zhǔn)備了嗎？你做好接受 Consul 雖然天然支持多中心但是事件監(jiān)聽弱得讓人無力吐槽的心里準(zhǔn)備了嗎？你做好 Eureka 過分強(qiáng)調(diào) AP 而可能帶來的極端情況下各種異常 case 嗎？你甚至，是不是有種想要自己簡單實(shí)現(xiàn)配置中心和注冊中心的沖動(dòng)？那么你想好對(duì) CAP 的權(quán)衡，想好幾大核心操作如何實(shí)現(xiàn)，想好如何設(shè)計(jì)推拉模型了嗎？

5.2 高可用

高可用即如何讓你的服務(wù)保持彈性，或者也有文章稱之“反脆弱”。在我看來，高可用出現(xiàn)的目的即為應(yīng)對(duì)故障，沿著故障的生命周期，我們也同樣將高可用的領(lǐng)域劃分為事前治理和事后治理兩大階段。

5.2.1 事前治理

在故障發(fā)生之前，我們能做哪些事情，即稱之為事前治理。我們認(rèn)為，在這個(gè)階段主要的技術(shù)上的措施有兩個(gè)：

基于經(jīng)驗(yàn)的環(huán)境重塑-壓測演練。成熟的分布式服務(wù)環(huán)境，大部分的嚴(yán)重問題都會(huì)出在高流量的場景下。所以我們最好的方式就是構(gòu)造這樣的環(huán)境，在業(yè)務(wù)高峰來之前，先進(jìn)行對(duì)應(yīng)的壓測演練，以進(jìn)行問題的試探。健全的壓測體系強(qiáng)依賴于分布式鏈路系統(tǒng)在全鏈路中傳遞壓測標(biāo)，這樣業(yè)務(wù)、中間件和基礎(chǔ)設(shè)施才能識(shí)別流量類型，并進(jìn)行對(duì)應(yīng)的處理，比如 Kafka 可以對(duì)壓測標(biāo)隔離出單獨(dú)的 Topic，數(shù)據(jù)庫中間件可以對(duì)壓測標(biāo)隔離出壓測影子表。

避免失敗的方式就是經(jīng)常失敗-故障演練。我們知道壓測只是一種基于經(jīng)驗(yàn)的環(huán)境重塑，希望通過不斷試探系統(tǒng)在高壓下的反應(yīng)來檢測出潛在的風(fēng)險(xiǎn)。而根據(jù)“墨菲定律”我們知道，如果有事情變壞的可能，那它總會(huì)發(fā)生。特別是在大量節(jié)點(diǎn)并存的網(wǎng)狀服務(wù)拓?fù)渲?#xff0c;這種概率就會(huì)不斷被抬升。避免失敗的方式就是經(jīng)常失敗，所以我們需要主動(dòng)模擬各種故障來檢驗(yàn)我們系統(tǒng)的彈性。Netflix 的“猴子大軍”可以隨機(jī)模擬進(jìn)程故障、機(jī)房故障，阿里也基于強(qiáng)弱依賴的理論進(jìn)行了故障演練的豐富實(shí)踐。如果想做一套故障演練系統(tǒng)，那么阿里開源的 Sandbox 就非常適合對(duì)Java進(jìn)程來做這件事情。

5.2.2 事后治理

在故障發(fā)生之后，我們能做些什么呢？歸納來看，最核心的無非就是限流、熔斷、隔離、降級(jí)。限流熔斷可以基于線程數(shù)控制、信號(hào)量控制、固定窗口計(jì)數(shù)、滑動(dòng)窗口計(jì)數(shù)、令牌桶計(jì)數(shù)、漏桶計(jì)數(shù)等等的方式來進(jìn)行流量的限制，單機(jī)限流熔斷相對(duì)簡單，Google 的 Guava Ratelimiter 就是一種很好的實(shí)踐，整合了令牌桶和漏桶的方式，對(duì)于需要預(yù)熱和不需要預(yù)熱的場景都做了充分支持，Hystrix 也提供了數(shù)種限流、熔斷和隔離的方式。當(dāng)然限制之后，如何恢復(fù)也是一大問題。是要階梯式恢復(fù)，還是時(shí)間窗口恢復(fù)，還是需要驗(yàn)證碼恢復(fù)，都存在著很多的使用場景，不復(fù)贅述。

但是，如果放在分布式的環(huán)境下，這個(gè)問題將會(huì)變得復(fù)雜得多，比如是否要做富 SDK？比如是否要在 SDK 中引入其他中間件比如 Redis？比如采集數(shù)據(jù)的延時(shí)問題可能引發(fā)的誤判如何解決？分布式環(huán)境下我們能信任什么數(shù)據(jù)？

目前比較主流的分布式環(huán)境下的限流熔斷仍然采用的富客戶端的方式來實(shí)現(xiàn)。貓眼基于自身現(xiàn)狀和訴求，采取的則是輕 SDK + 重 Server 的方式來進(jìn)行。基本所有的決策都在 Server 端進(jìn)行。通過這種方式，實(shí)現(xiàn)了與業(yè)務(wù)較大程度上的解耦，并且為以后的聯(lián)合決策提供先決條件。

5.3 高性能

如何才能讓我們的服務(wù)保持高性能狀態(tài)？加緩存、做靜態(tài)化、預(yù)熱、做異步、搞并行、業(yè)務(wù)優(yōu)化、服務(wù)分級(jí)分流、硬件加速之類的就不贅述了。晚上很多類似的文章，而我這邊比較感興趣的，也主要想和大家討論的是，服務(wù)治理框架的一大核心—底層通訊層面上，如何才能做到高性能？這就離不開幾個(gè)法寶：

5.3.1 直連

連接方式上，直連帶來的性能優(yōu)勢毋庸置疑。大部分的分布式服務(wù)框架都會(huì)采用直連的方式進(jìn)行服務(wù)間的通訊。

5.3.2 高性能序列化

在高并發(fā)情況下，序列化有可能會(huì)成為你的性能熱點(diǎn)。適當(dāng)時(shí)候考慮下 pb、json、gson 或者自定義的序列化協(xié)議。自定義的序列化協(xié)議需要考慮如何壓縮空間，并能夠便于框架的提取解析，比如螞蟻金服的 Bolt 協(xié)議里約定的魔數(shù)、固定頭、變長頭、包體等的方法論就是一個(gè)很好的例子。

5.3.3 Zero-Copy

Zero-Copy 是一個(gè)大殺器，在 Nginx、Netty（不是傳統(tǒng)意義上的 Zero-Copy）、Kafka、RocketMQ 等項(xiàng)目中被使用，在合適的地方利用這個(gè)特性，比如磁盤順序讀 + Mmap + sendfile，你的系統(tǒng)性能將瞬間提升幾個(gè)數(shù)量級(jí)。

5.3.4 Epoll 多路復(fù)用

Epoll相比于自己用宏定義把自己坑死的 select，以及后繼者 poll 來說，在使用限制上以及性能上有著明顯的飛躍。也是目前最主流的 IO 模型。現(xiàn)在各種業(yè)內(nèi)風(fēng)靡的高性能服務(wù)器設(shè)計(jì)，Epoll 基本都是必然采用的 IO 模型。當(dāng)然 Netty 也采用過真正意義上的異步 IO - AIO，但是由于 Linux 的AIO目前尚不成熟等原因，最后的效果不好所以并沒有真正推開。

5.3.5 Reactor線程模型

基本高性能服務(wù)的底層都采用了Reactor模式來實(shí)現(xiàn)線程模型。當(dāng)然，配合線程池/協(xié)程池，以及 Reactor 的層次，可以有多種的實(shí)現(xiàn)路徑。有類似 Nginx 這樣的一主多子進(jìn)程 + 單 Reactor 單線程（高版本提供了線程池機(jī)制）的模型，evio 和 Envoy 利用“單 Reactor 協(xié)程池（線程池）”， Netty 采用多級(jí) Reactor + 多級(jí)線程池。

5.3.6 字節(jié)重用

我們習(xí)慣于對(duì)每個(gè)請求去新創(chuàng)建一個(gè)他所需要的空間來存放一些信息。但是當(dāng)并發(fā)量上來后，這樣的空間分配將會(huì)導(dǎo)致較大的性能開銷和回收壓力。所以基于伙伴算法或者Slab算法或其他的方式，進(jìn)行一個(gè)字節(jié)內(nèi)存使用的分配管理，將會(huì)讓你收益良多。比如 Netty 由于申請了堆外內(nèi)存而采用了伙伴算法，Nginx 則采用了 Slab 機(jī)制，Mosn 在 Golang 分配機(jī)制的基礎(chǔ)上引入多級(jí)容量加 sync.Pool 機(jī)制的緩存來進(jìn)行優(yōu)化。

5.3.7 本地通訊優(yōu)化

如果你的服務(wù)通訊是采用的 Servicemesh 之類的 Local Proxy 來進(jìn)行轉(zhuǎn)發(fā)，那么應(yīng)用服務(wù)和 Proxy 之間的通訊鏈路可以基于本地進(jìn)程通訊的特性進(jìn)行優(yōu)化。比如利用 mmap 進(jìn)行進(jìn)程間的通信，可以減少內(nèi)核切換次數(shù)，這能讓你獲得意想不到的收益。traffic-shm 是一個(gè)異步無鎖的IPC框架，能夠輕松支撐百萬 TPS，其就采用了 mmap 來進(jìn)行通訊。

5.3.8 內(nèi)存對(duì)齊

操作系統(tǒng)按照頁進(jìn)行內(nèi)存管理。如果你直接操作內(nèi)存地址進(jìn)行數(shù)據(jù)傳輸（比如用 mmap）的話，那么如果沒有內(nèi)存對(duì)齊，將會(huì)導(dǎo)致你拉取到并不需要的內(nèi)存空間，且會(huì)有內(nèi)存移動(dòng)拼接的額外開銷，這將會(huì)直接導(dǎo)致你性能的下滑。高性能內(nèi)存隊(duì)列 Disruptor 也是采用了內(nèi)存對(duì)齊的方式進(jìn)行優(yōu)化。

5.3.9 無鎖化

通訊的第一反應(yīng)即需要處理并發(fā)安全的問題，很多時(shí)候你可能不得不通過鎖的方式來保障安全。這個(gè)時(shí)候，考慮下通過利用硬件層面的CAS操作來替代常規(guī)的鎖操作，也可以采取類似 Redis 這樣單線程處理的方式，或者 Envoy 這樣雖然采用了線程池，但是連接會(huì)進(jìn)行單個(gè)線程的綁定操作來規(guī)避并發(fā)問題。

5.3.10 池化

線程資源是很寶貴的，加上線程本身不可能申請幾千上萬個(gè)出來，所以線程池是默認(rèn)的標(biāo)配。這邊要談的是，比如你用了協(xié)程技術(shù)，雖然協(xié)程被神化為輕量級(jí)線程，性能非常高且可以輕松開出幾萬個(gè)而面不改色。但是你需要知道，這也會(huì)很嚴(yán)重地影響你實(shí)際的處理性能，并且由于 golang 本身的協(xié)程分配原理，協(xié)程的一些元數(shù)據(jù)并不會(huì)在使用后被回收，這是由于 golang 開發(fā)者的理念是“一旦到達(dá)過這樣的流量，就說明系統(tǒng)有可能再次面臨這樣的洪峰，那么就提前做好準(zhǔn)備”。所以我們對(duì)于協(xié)程，仍然需要考慮池化的問題。Motan-Go 和 Thrift 的 golang 版本中目前并沒有這方面的考慮，而 Sofa-Mosn 已經(jīng)做了對(duì)應(yīng)的池化處理。

5.4 標(biāo)準(zhǔn)化與自動(dòng)化

如在前面章節(jié)中提到的：

犧牲一定的性能和資源，換取服務(wù)治理理整體的高度自治和可運(yùn)營

我認(rèn)為在未來的成熟服務(wù)治理中，比起絕對(duì)的性能表現(xiàn)，我們更關(guān)注應(yīng)用服務(wù)拓?fù)涫欠衲軌蛘嬲墒斓娇梢浴白詣?dòng)化”甚至“自治”的程度。盡可能地解放人力操作，將其進(jìn)化為機(jī)器語言。比如我們提倡自動(dòng)化部署、自動(dòng)化壓測、自動(dòng)化故障演練，自動(dòng)化系統(tǒng)測試，自動(dòng)化限流熔斷，自動(dòng)伸縮等等，都是在各個(gè)領(lǐng)域應(yīng)用自動(dòng)化解放人的雙手的很好示例。
但，服務(wù)治理上，如何才能實(shí)現(xiàn)更高效的自動(dòng)化呢？我認(rèn)為：

自動(dòng)化是治理的高級(jí)形態(tài)，而標(biāo)準(zhǔn)化是規(guī)?；卫淼那疤帷?/strong>

只有標(biāo)準(zhǔn)化，才能簡化復(fù)雜服務(wù)世界的問題，將各種異構(gòu)場景盡量同構(gòu)建模，如此才有可能用可控成本完成規(guī)?；姆?wù)治理，進(jìn)一步完成大規(guī)模的自動(dòng)化。 標(biāo)準(zhǔn)化，意味著你要考慮的差異性越少，你治理的成本越低，你能自動(dòng)化的程度就越高。
你可以認(rèn)為：

Docker 其實(shí)就是部署級(jí)別的標(biāo)準(zhǔn)化，通過它可以很好地標(biāo)準(zhǔn)化環(huán)境，也可以提供標(biāo)準(zhǔn)化部署運(yùn)維的手段，甚至我們可以通過容器來標(biāo)準(zhǔn)化服務(wù)治理的核心設(shè)施，通過容器對(duì)我們應(yīng)用的改造和適配，我們就可以輕松完成大規(guī)模的自動(dòng)化部署和彈性伸縮。

Servicemesh 領(lǐng)軍項(xiàng)目 Istio 的控制平面，也很好詮釋了什么叫標(biāo)準(zhǔn)化，Pilot 標(biāo)準(zhǔn)化了異構(gòu)的配置下發(fā)能力和注冊中心，Mixer 標(biāo)準(zhǔn)化了遙測和限流的能力（當(dāng)然，這在業(yè)內(nèi)有一定的爭議）。

阿里的 Sandbox 標(biāo)準(zhǔn)化了 AOP 切面的編織過程和完整的生命周期，讓使用者相比于傳統(tǒng)的方式節(jié)省了非常多的成本。

你甚至可以認(rèn)為，大多數(shù)的框架，本身就是一個(gè)標(biāo)準(zhǔn)化的過程。

這時(shí)候的你，是不是認(rèn)為，標(biāo)準(zhǔn)化其實(shí)無處不在？是的，沒錯(cuò)。介紹一個(gè)有意思的“奶牛和寵物理論”，大致意思是：

你不應(yīng)該老是想?yún)^(qū)分哪些服務(wù)是奶牛，哪些服務(wù)是寵物。生了病就殺掉它而不要去想?yún)^(qū)分出哪些是寵物并治好它。

是的，區(qū)分得越少，你的系統(tǒng)將越可靠，你的煩惱就越少。回到初心，其實(shí)都是一樣的。
記得關(guān)注自己構(gòu)建的系統(tǒng)生態(tài)之上的研發(fā)同學(xué)，如果他們終日忙碌，那么請抽時(shí)間和他們一起停下腳步審視下系統(tǒng)標(biāo)準(zhǔn)化和自動(dòng)化的進(jìn)展，或許你會(huì)有意想不到的收獲。

6. 結(jié)語與展望

我們來回顧一下，在第一章，我們講述了什么是服務(wù)治理，認(rèn)為服務(wù)治理即治理三要素和服務(wù)環(huán)，第二章，介紹了服務(wù)治理的發(fā)展演變，簡單介紹了三個(gè)階段的思潮和演變的邏輯，讓我們對(duì)于目前服務(wù)治理大發(fā)展方向和未來的發(fā)展趨勢可以有一個(gè)初步的預(yù)測。在步入實(shí)際一些實(shí)踐雜談之前，我們需要先問清楚自己一個(gè)問題，我們需要什么樣的服務(wù)治理，第三章我闡述了我個(gè)人的理解，這其實(shí)是一個(gè)哲學(xué)問題。之后的兩張，則從業(yè)務(wù)應(yīng)用層面，以及從底層基礎(chǔ)技術(shù)領(lǐng)域，挑出了幾個(gè)我認(rèn)為比較有意思而重要的思考和實(shí)踐來與大家進(jìn)行討論。當(dāng)然，限于篇幅，我無法展開的論證每一個(gè)點(diǎn)，也由于自身能力和實(shí)踐的限制，多少會(huì)有一些謬誤的地方，也歡迎大家隨時(shí)指出。

如標(biāo)題所示，這只是服務(wù)治理整體的漫談，偏重于從整體視角來理解服務(wù)治理的內(nèi)核，并對(duì)一些很重要但很少被系統(tǒng)性談及的部分進(jìn)行進(jìn)一步的解讀。后續(xù)我會(huì)進(jìn)行服務(wù)治理每一重要層次和環(huán)節(jié)的剖析，我們不僅希望結(jié)合實(shí)際生產(chǎn)實(shí)踐來分析具體的系統(tǒng)架構(gòu)，也希望通過對(duì)架構(gòu)的剖析能進(jìn)一步地去洞察設(shè)計(jì)者的意圖和思考邏輯，知其然而知其所以然，這是我認(rèn)為架構(gòu)師領(lǐng)域非常重要的一個(gè)技能，也歡迎大家持續(xù)關(guān)注。

總結(jié)

以上是生活随笔為你收集整理的【服务治理】服务治理漫谈的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。