高馳濤 (Neeke Gao)，PHP/PECL開發(fā)組成員，掌握近10種開發(fā)語言，9年架構(gòu)師經(jīng)驗(yàn)，6年研發(fā)管理經(jīng)驗(yàn)。云智慧AIOps社區(qū)PMC，同時(shí)也是PECL/SeasLog、PECL/JsonNet、GoCrab等多項(xiàng)開源軟件的作者。2014年加入云智慧，致力于APM與大數(shù)據(jù)產(chǎn)品的架構(gòu)研發(fā)，崇尚敏捷、高效。

從一個(gè)問題談起

從幾年前某CTO的一個(gè)問題說起：“我們的系統(tǒng)將會(huì)擁有5000個(gè)微服務(wù)組件，我們應(yīng)該怎么做？”

我們都知道一個(gè)接口是無法稱之為微服務(wù)的，接口數(shù)量達(dá)到十幾個(gè)或許才夠稱之為微服務(wù)。那么，對于包含5000個(gè)微服務(wù)的系統(tǒng)而言，該如何實(shí)現(xiàn)和管理呢？

在這樣龐大的系統(tǒng)背后，可預(yù)見的一定存在很大的問題。

微服務(wù)的前世今生

微服務(wù)是如何誕生的，必須了解以下四個(gè)領(lǐng)域：

TOGAF：全稱“開放組體系結(jié)構(gòu)框架”，TOGAF在上世紀(jì)七、八十年代的時(shí)候就已經(jīng)由專門組織負(fù)責(zé)開發(fā)了，直到1995年美國國防部參與之后，TOGAF才最終成型。

如今，大家手機(jī)里正在使用的產(chǎn)品和應(yīng)用中，很多都會(huì)用到SAP、IBM或者惠普的軟件，而這些軟件公司所遵循的就是TOGAF。可以說目前全球超過50%的企業(yè)正在使用TOGAF實(shí)踐軟件架構(gòu)設(shè)計(jì)和開發(fā)。

TOGAF是一個(gè)架構(gòu)體系，但并沒有提供具體的架構(gòu)方法。TOGAF包含了業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)、技術(shù)架構(gòu)等。

TOGAF有三個(gè)最為主要的支柱：

1. 企業(yè)架構(gòu)域，主要是企業(yè)信息與業(yè)務(wù)流等；
2. ADM一系列的架構(gòu)方法論；
3. 企業(yè)連續(xù)性，指的是在企業(yè)業(yè)務(wù)高速增長并且不斷變更的過程中，保證架構(gòu)體系的連續(xù)性。

DDD：全稱為“領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)”，其包含了諸多的概念，三句話進(jìn)行概括：

1. DDD是精簡的業(yè)務(wù)，DDD首先關(guān)注的就是業(yè)務(wù)，把各種繁瑣的業(yè)務(wù)流程精簡成更細(xì)的鏈條；
2. DDD需要回答業(yè)務(wù)是干什么的，能夠滿足什么需求，達(dá)成什么目的；
3. 不斷迭代，DDD的不斷迭代與TOGAF的企業(yè)連續(xù)性類似。

SOA：全稱為“面向服務(wù)架構(gòu)”，理論同樣較多，總結(jié)為以下三點(diǎn)：

1. SOA解決了信息孤島的問題；
2. 業(yè)務(wù)重用，從業(yè)務(wù)角度將各個(gè)服務(wù)組合成一個(gè)個(gè)中間件或者服務(wù)，將其提供給用戶或者其他系統(tǒng)；
3. SOA使得系統(tǒng)成為互聯(lián)互通的信息群。

GRASP原則：全稱為“通用職責(zé)分配原則”，包含很多耳熟能詳?shù)母拍钊纾骸暗婉詈稀?、“高?nèi)聚”，均來自GRASP原則。它與設(shè)計(jì)模式不同，設(shè)計(jì)模式指導(dǎo)如何實(shí)現(xiàn)系統(tǒng)，而GRASP旨在指導(dǎo)如何劃分。

GRASP原則旨在指導(dǎo)定義業(yè)務(wù)架構(gòu)以及API等相關(guān)內(nèi)容和劃分服務(wù)，其理論內(nèi)容也非常多，只需要記住三個(gè)關(guān)鍵：

1. 自己干自己的事；
2. 自己只干自己能干的事；
3. 自己只干自己的事，強(qiáng)調(diào)了資源劃分。

在軟件工程的教科書上給出了微服務(wù)架構(gòu)的定義：微服務(wù)架構(gòu)是一種架構(gòu)模式，它是將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為?戶提供最終價(jià)值。每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)間采用輕量級(jí)的通信機(jī)制互相溝通(通常是基于HTTP協(xié)議的RESTFul API)。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)?構(gòu)建，并且能夠被獨(dú)?的部署到?產(chǎn)環(huán)境、類?產(chǎn)環(huán)境等。另外，應(yīng)當(dāng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對具體的一個(gè)服務(wù)?言，應(yīng)根據(jù)業(yè)務(wù)上下?，選擇合適的語言、工具對其進(jìn)行構(gòu)建。

而這些教科書上的內(nèi)容或許在當(dāng)下來看已經(jīng)過時(shí)了。

微服務(wù)帶來的優(yōu)勢

我們使用微服務(wù)架構(gòu)的時(shí)候，到底得到了什么東西呢？這里總結(jié)了四點(diǎn)最為明顯的優(yōu)點(diǎn)：

1. 使得開發(fā)和迭代變得更加敏捷，使用微服務(wù)架構(gòu)使得敏捷開發(fā)成為可能；
2. 易于擴(kuò)展和收縮，一些公司基于Kubernetes、Docker等技術(shù)可以在幾秒內(nèi)拉起上萬個(gè)微服務(wù)，當(dāng)大型流量沖擊到達(dá)的時(shí)候，可以實(shí)現(xiàn)無損地承擔(dān)全部流量，同時(shí)實(shí)現(xiàn)用戶無感知，而當(dāng)數(shù)據(jù)訪問量降低之后，又可以實(shí)現(xiàn)快速縮容；
3. 多技術(shù)棧可能，目前云智慧的技術(shù)棧非常全面，雖然開發(fā)人員只有60多人，但是開發(fā)語言卻多達(dá)10多門，而使用微服務(wù)可以有效地組織各類開發(fā)人員；
4. 高可修改性，比如實(shí)現(xiàn)數(shù)據(jù)庫的快速遷移，通道的快速切換等。

微服務(wù)帶來的兩點(diǎn)疑問

微服務(wù)能夠帶來諸多優(yōu)點(diǎn)，但是也存在兩點(diǎn)疑問：

第一個(gè)就是“微服務(wù)架構(gòu)，你的系統(tǒng)變得更健壯了嗎？”；

第二個(gè)則是“使用微服務(wù)讓系統(tǒng)變得更快了嗎？”

對于這兩點(diǎn)而言，可能說是見仁見智的。有人說因?yàn)榻M件變得越來越多，可監(jiān)控性就會(huì)變難，因此系統(tǒng)健壯性就會(huì)變得越來越差；也有人說因?yàn)閷⑾到y(tǒng)拆分得越來越細(xì)，因此健壯性就會(huì)越來越強(qiáng)。如果單體架構(gòu)是串行的，那么使用微服務(wù)可以將其變成并行的和分布式的，而多個(gè)組件之間進(jìn)行通信，也會(huì)使得通信成為性能瓶頸，那么使用微服務(wù)到底是變快了還是變慢了呢？這兩個(gè)問題都很難以回答。作為一個(gè)架構(gòu)師或者開發(fā)者需要不斷進(jìn)行深入的思考。

微服務(wù)架構(gòu)面臨的挑戰(zhàn)和思考

這里總結(jié)了在使用微服務(wù)架構(gòu)的時(shí)候所需要面臨的8條挑戰(zhàn)和相關(guān)的思考：

1. 小即是多

當(dāng)業(yè)務(wù)從大變小的時(shí)候，也意味著業(yè)務(wù)變多了。由大變小，可以使系統(tǒng)變得更加容易維護(hù)和修改，但是由少變多，又會(huì)使得問題更加復(fù)雜，因此也會(huì)出現(xiàn)很多的挑戰(zhàn)。

第一個(gè)問題就是多節(jié)點(diǎn)、多服務(wù)和多狀態(tài)。系統(tǒng)中的節(jié)點(diǎn)、組件服務(wù)變得更多了，那么節(jié)點(diǎn)和服務(wù)之間的狀態(tài)也會(huì)變得更難維護(hù)，更加復(fù)雜?；谇懊嫣岬降乃姆N知識(shí)，可以將從大變小和從少變多這兩個(gè)轉(zhuǎn)變進(jìn)行折中，使得其變得更加可控。而解決這個(gè)問題的關(guān)鍵在于對于服務(wù)的合理拆分，主要有三點(diǎn)可以考慮，即數(shù)據(jù)資源、業(yè)務(wù)功能以及服務(wù)對象。

2. 債務(wù)管理

Bug、代碼缺陷、未完成的功能或者版本不兼容等問題都是債務(wù)。當(dāng)服務(wù)變得越來越多的時(shí)候，債務(wù)往往就會(huì)變得更多。

為了解決這些問題，其實(shí)有這樣的幾種策略：

• 單元測試，如果單元測試做的足夠好，那么代碼缺陷的可能性就會(huì)變得更低一些，可以將服務(wù)由少變多所造成的債務(wù)變多情況進(jìn)行收斂；
• 集成回歸，這部分提供了很多工具去做這件事情，不用開發(fā)者自己去做；
• 版本管理，這里指的是靜態(tài)庫的版本管理，動(dòng)態(tài)庫指的是正在變更中的庫，而靜態(tài)庫指的是不再變更的庫和配置項(xiàng)，這一點(diǎn)控制不好，就容易使得系統(tǒng)管理混亂；
• 迭代沖刺，是一種組織方式，當(dāng)有很多技術(shù)債務(wù)需要進(jìn)行管理時(shí)，如何將這些債務(wù)一點(diǎn)點(diǎn)處理掉或者把發(fā)散的趨勢收斂住，迭代沖刺就是一種做法；
• Bug Crash，這是智慧云團(tuán)隊(duì)自己發(fā)明的一個(gè)名詞，相當(dāng)于是對于Bug的大掃除，無論采用傳統(tǒng)的還是敏捷的開發(fā)模式，都有一些Bug存在，因此定期會(huì)組織全體開發(fā)和測試以及產(chǎn)品將自己的產(chǎn)品用一遍，進(jìn)行Bug大掃除；
• 回歸總結(jié)，無論采用什么開發(fā)模式，在一個(gè)迭代周期完成之后，回歸總結(jié)是少不了的，也需要通過一些方法解決新發(fā)生的問題，或者將其封閉住不使債務(wù)繼續(xù)蔓延。

3. 復(fù)雜的服務(wù)依賴

如果只有一個(gè)或者幾個(gè)組件，那么其實(shí)不存在服務(wù)依賴問題，而如果有幾千個(gè)組件，那么服務(wù)依賴將會(huì)成為巨大的問題。舉例而言，如果用戶服務(wù)需要調(diào)用訂單服務(wù)，那么在啟動(dòng)的時(shí)候需要進(jìn)行一些初始化任務(wù)，那么一個(gè)服務(wù)的版本發(fā)布可能導(dǎo)致系統(tǒng)全面癱瘓，這就是復(fù)雜服務(wù)依賴問題。

為了解決這個(gè)問題首先就需要服務(wù)發(fā)現(xiàn)機(jī)制，比如使用etcd或者Zookeeper等，首先服務(wù)發(fā)現(xiàn)中心也需要是分布式高可靠的，那么服務(wù)起來之后需要把自己的名字和調(diào)用方式告訴服務(wù)發(fā)現(xiàn)中心，注冊上去；對于服務(wù)調(diào)用者而言只需要從服務(wù)發(fā)現(xiàn)中心那里通過約定好的名字獲取服務(wù)調(diào)用地址即可。

依賴喚醒是有一個(gè)相對比較新的東西，比如大流量突然打進(jìn)來的時(shí)候，A服務(wù)需要從原來的10個(gè)啟動(dòng)到100個(gè)，而B從原來的3個(gè)肯定也是不夠用的，因此需要通過喚醒的機(jī)制將服務(wù)拉起來，而不是被動(dòng)的被通知。

還有一種情況也需要使用到依賴喚醒機(jī)制，比如緩存穿透問題，正常情況下，緩存是生效的，不會(huì)存在穿透的情況，但是可能因?yàn)槟撤N異常使得緩存不生效了，會(huì)將大量的流量打到DB里面去，使得服務(wù)變得不可用了，整個(gè)服務(wù)雪崩掉，針對這些問題一般會(huì)開發(fā)一些擋板服務(wù)，可能會(huì)給出一些固定的數(shù)據(jù)，而這些擋板服務(wù)也有可能會(huì)面臨這種突發(fā)的流量也需要通過依賴喚醒的機(jī)制實(shí)現(xiàn)喚醒。

此外，還有灰度發(fā)布和AB測試，這兩點(diǎn)是相關(guān)聯(lián)的。還有多版本共存問題，對于服務(wù)的多版本也是一個(gè)技術(shù)債務(wù)問題，需要考慮如何將其舊版本拿下來。

4. 消息通訊

如果系統(tǒng)中包含多個(gè)語言棧，多種實(shí)現(xiàn)方式。那統(tǒng)一標(biāo)準(zhǔn)是必須的，統(tǒng)一一種RPC或者就使用RestFul API等。消息中心也是一種處理做法，這一點(diǎn)在Java中應(yīng)用很多，消息中心并不是消息隊(duì)列，而是一個(gè)事件驅(qū)動(dòng)的消息中心。此外，還有通訊網(wǎng)關(guān)，這在使用微服務(wù)的時(shí)候也是一個(gè)必要點(diǎn)，其主要解決了監(jiān)控問題，而且可以通過網(wǎng)關(guān)起到中控的作用，比如安全、性能以及用戶校驗(yàn)等任務(wù)。

5. 分布式事務(wù)

在實(shí)現(xiàn)分布式事務(wù)的時(shí)候可以采用2PC或者3PC原則來實(shí)現(xiàn)，2PC原則是通過全部節(jié)點(diǎn)投票和執(zhí)行兩個(gè)步驟完成的，并且是阻塞的；而3PC則不同，雖然在一個(gè)具體的事務(wù)里面可以是阻塞的，也可以是非阻塞的。3PC協(xié)議則是通過“Can-Pre-Do”三個(gè)步驟來實(shí)現(xiàn)的，其實(shí)PDU就是3PC協(xié)議在單體中的實(shí)現(xiàn)方式。而在分布式系統(tǒng)中，3PC有三種實(shí)現(xiàn)方式，使用分布式的事件驅(qū)動(dòng)、最大通知以及兩階段補(bǔ)償TCC。

6. 花式故障

很多時(shí)候，當(dāng)系統(tǒng)出現(xiàn)問題可能需要花費(fèi)數(shù)周和很多人力才能找到根源所在，可能因?yàn)橄到y(tǒng)太多，使得系統(tǒng)架構(gòu)師也無法理清系統(tǒng)與系統(tǒng)之間的關(guān)系。面對諸多的花式故障，也有多種策略可以應(yīng)對，比如全鏈路追蹤，比如使用Open Tracking；主動(dòng)撥測，很多用戶端的APP里面內(nèi)置探針，使其可以接收Server端的指令來定期探測接口和服務(wù)是否正常。

7. 中心與去中心

中心與去中心可以算是一個(gè)永恒的話題，上圖中展示的配置、發(fā)號(hào)、日志、調(diào)度、狀態(tài)以及預(yù)警，其實(shí)對于比較成熟的大型系統(tǒng)而言，這六點(diǎn)都是需要中心的。

8. 組織危機(jī)

最后一個(gè)問題，也是最大的問題。其實(shí)要實(shí)現(xiàn)向微服務(wù)架構(gòu)的變更的時(shí)候，最大的問題就是組織危機(jī)。這一點(diǎn)與開發(fā)者關(guān)系不大，但是對于Team Leader以及組織的管理人員而言，關(guān)系非常大。架構(gòu)的轉(zhuǎn)變需要考慮到信任危機(jī)、過期維護(hù)、多語言棧、溝通協(xié)作、安全網(wǎng)關(guān)以及輪崗結(jié)對等問題。

總結(jié)

總結(jié)而言，最重要的觀點(diǎn)有兩個(gè)：微服務(wù)不是銀彈，不要讓重復(fù)的事情做兩次。

寫在最后

近年來，在AIOps領(lǐng)域極速發(fā)展的背景下，IT工具、平臺(tái)能力、解決方案、AI場景及可用數(shù)據(jù)集的迫切需求在各行業(yè)迸發(fā)?；诖耍浦腔墼?021年8月發(fā)布了AIOps社區(qū)， 旨在樹起一面開源旗幟，為各行業(yè)客戶、用戶、研究者和開發(fā)者們構(gòu)建活躍的用戶及開發(fā)者社區(qū)，共同貢獻(xiàn)及解決行業(yè)難題、促進(jìn)該領(lǐng)域技術(shù)發(fā)展。

社區(qū)先后開源了數(shù)據(jù)可視化編排平臺(tái)-FlyFish、運(yùn)維管理平臺(tái)OMP、云服務(wù)管理平臺(tái)-摩爾平臺(tái)、Hours算法等產(chǎn)品。