實(shí)踐微服務(wù)六年，我獲得了這些心得體會(huì)

作為微服務(wù)架構(gòu)的忠心擁躉，雖然有時(shí)也會(huì)對(duì)其感到不爽。使用微服務(wù)時(shí)，我時(shí)常能感受到“小中見(jiàn)大”、“穩(wěn)中有快”等理念，另一方面也會(huì)警惕“廚子太多燒壞了湯”。

回顧 2014 年，公司正在通過(guò)采用微服務(wù)架構(gòu)實(shí)施數(shù)字化轉(zhuǎn)型。那時(shí)數(shù)字化、轉(zhuǎn)型和微服務(wù)這些詞對(duì)我就是天籟之音。

作為一名解決方案架構(gòu)師，我非常希望能了解這種新模式。為了跟上技術(shù)前沿趨勢(shì)，我閱讀了大量微服務(wù)架構(gòu)相關(guān)的文章，與我的網(wǎng)絡(luò)技術(shù)負(fù)責(zé)人交流，并研究了一些適用的用例。

那時(shí)我發(fā)自內(nèi)心地相信微服務(wù)架構(gòu)，確信單體應(yīng)用將會(huì)消亡。

此后，我服務(wù)過(guò)的每家公司都已采用或正在采用微服務(wù)架構(gòu)。雖然其中一些公司的領(lǐng)導(dǎo)團(tuán)隊(duì)并沒(méi)能說(shuō)服組織為什么要選擇微服務(wù)，一個(gè)普遍的回答是：“其他公司都在這樣做，在每次會(huì)議上大家都說(shuō)微服務(wù)是一種改變游戲規(guī)則的方式，所以我們也這樣做吧?！?/span>

通過(guò)為各個(gè)業(yè)務(wù)領(lǐng)域中的多家公司提供體系結(jié)構(gòu)和設(shè)計(jì)支持，我發(fā)現(xiàn)將現(xiàn)有的單體應(yīng)用重新架構(gòu)為微服務(wù)架構(gòu)需要付出大量的耐心、時(shí)間和經(jīng)驗(yàn)。

在給出我在采用微服務(wù)中的五點(diǎn)切身體會(huì)之前，首先重新審視一下什么是微服務(wù)？

有說(shuō)法提出，這種架構(gòu)樣式事實(shí)并沒(méi)有一個(gè)的標(biāo)準(zhǔn)定義，只是存在一些“圍繞組織和業(yè)務(wù)能力、自動(dòng)部署，端點(diǎn)智能、對(duì)語(yǔ)言和數(shù)據(jù)分散控制”的特征。

在我看來(lái)，如果一個(gè)組織必須具備上述所有特征才能去使用微服務(wù)，那么我們就不僅是在談?wù)摷夹g(shù)變革，而是在推動(dòng)組織內(nèi)的重大文化變革。

下面給出我在實(shí)踐微服務(wù)中的五點(diǎn)主要體會(huì)。

1 跳出項(xiàng)目，擁抱產(chǎn)品

傳統(tǒng)的軟件開(kāi)發(fā)方式中，開(kāi)發(fā)團(tuán)隊(duì)一起構(gòu)建一個(gè)單體應(yīng)用軟件，進(jìn)而由生產(chǎn)支持團(tuán)隊(duì)管理該軟件。在這種方式中，生產(chǎn)支持團(tuán)隊(duì)作為軟件的新所有者，通常并不完全了解組件的構(gòu)建過(guò)程，例如代碼的邏輯，所使用的技術(shù)等。

他們的核心工作是確保滿足業(yè)務(wù)需求的生產(chǎn)系統(tǒng)能正常地運(yùn)行，團(tuán)隊(duì)之間通常也沒(méi)有定義有效的溝通途徑。生產(chǎn)系統(tǒng)中出現(xiàn)的問(wèn)題將導(dǎo)致開(kāi)發(fā)回滾到某個(gè)還原點(diǎn)，或是給出快速的短期修補(bǔ)。有時(shí)，生產(chǎn)代碼中的一個(gè)微小問(wèn)題將觸發(fā)整個(gè)過(guò)程全部重新開(kāi)始。而問(wèn)題通常必須由原始開(kāi)發(fā)團(tuán)隊(duì)解決，這導(dǎo)致整體延遲。

如果以瀑布式開(kāi)發(fā)方式（即前期設(shè)計(jì)、集中式的版本發(fā)布流程、構(gòu)建和部署）處理微服務(wù)，則存在巨大的風(fēng)險(xiǎn)。最終得到的可能是一個(gè)更復(fù)雜的系統(tǒng)，無(wú)法享受微服務(wù)所承諾的任何好處。

在微服務(wù)中，經(jīng)常提及的是“產(chǎn)品”，而非“項(xiàng)目”。使用微服務(wù)方法，利益相關(guān)者（包括用戶、程序、產(chǎn)品和技術(shù)人員）致力于產(chǎn)品這一共同目標(biāo)。在投資、軟件交付到維護(hù)的整個(gè)過(guò)程上，產(chǎn)品模式都不同于項(xiàng)目模式。

產(chǎn)品直接影響所提供的業(yè)務(wù)功能。不同于傳統(tǒng)方法中構(gòu)建單體應(yīng)用需要多個(gè)團(tuán)隊(duì)參與，微服務(wù)模式支持單個(gè)團(tuán)隊(duì)完全負(fù)責(zé)構(gòu)建和管理某一小部分軟件。團(tuán)隊(duì)在產(chǎn)品模式下是穩(wěn)定的、跨職能的，并以結(jié)果為導(dǎo)向的，獨(dú)立完成“設(shè)計(jì) - 構(gòu)建 - 運(yùn)行”全過(guò)程。

每個(gè)團(tuán)隊(duì)都是遵循統(tǒng)一報(bào)告層級(jí)的獨(dú)立部門(mén)，根據(jù)路線圖去分塊構(gòu)建獨(dú)立的軟件單元。某一層上的團(tuán)隊(duì)可將另一層上的團(tuán)隊(duì)視為他們的（內(nèi)部）客戶，相互協(xié)作去解決業(yè)務(wù)問(wèn)題，而不是以權(quán)責(zé)交付的方式工作。

由于工程團(tuán)隊(duì)以產(chǎn)品模式工作，他們了解軟件在生產(chǎn)中的行為，因此可以立即解決所有問(wèn)題，避免產(chǎn)生延誤。

CapitalOne 秉持 YBYO（You Build You Own，自己構(gòu)建）理念，團(tuán)隊(duì)全權(quán)負(fù)責(zé)設(shè)計(jì)、構(gòu)建、測(cè)試和部署生產(chǎn)環(huán)境中的軟件。工程團(tuán)隊(duì)直接參與產(chǎn)品，并與用戶互動(dòng)。用戶不斷提供反饋，幫助團(tuán)隊(duì)構(gòu)建高質(zhì)量的產(chǎn)品。

要點(diǎn)：控制范圍使團(tuán)隊(duì)可以更好地構(gòu)建和管理微服務(wù)。產(chǎn)品模式支持與終端用戶建立更緊密的合作、管理和構(gòu)建關(guān)系。

2 思考宏觀服務(wù)“微”構(gòu)建

我在加入 CapitalOne 之前曾任職另一家公司的團(tuán)隊(duì)，為公司的電子商務(wù)網(wǎng)站建立產(chǎn)品目錄服務(wù)。該公司采用了微服務(wù)方法，產(chǎn)品目錄服務(wù)以請(qǐng)求為準(zhǔn)則，向最終用戶提供產(chǎn)品列表。

由于我的團(tuán)隊(duì)控制著數(shù)據(jù)和目錄數(shù)據(jù)庫(kù)，因此選擇 Java 和 SpringBoot 構(gòu)建服務(wù)。這些編程語(yǔ)言支持豐富的軟件庫(kù)，我們對(duì)此非常滿意。服務(wù)最終公開(kāi)提供在面向最終用戶的 API 網(wǎng)關(guān)上。

公司中同樣還有其他幾個(gè)團(tuán)隊(duì)，使用各自的技術(shù)來(lái)構(gòu)建自己的服務(wù)。從產(chǎn)品的角度來(lái)看，每個(gè)功能都受到構(gòu)建在異構(gòu)平臺(tái)上的各個(gè)服務(wù)的支持。這樣的模型解決了一個(gè)重要的問(wèn)題，那就是在招募和培訓(xùn)團(tuán)隊(duì)中，不必使用相同的技術(shù)堆棧構(gòu)建單體應(yīng)用。在微服務(wù)模型中，每個(gè)團(tuán)隊(duì)都可以選擇適合自身業(yè)務(wù)需求的工具，據(jù)此招聘新的團(tuán)隊(duì)成員。

微服務(wù)是一種通過(guò)服務(wù)構(gòu)建其中業(yè)務(wù)應(yīng)用組件的體系架構(gòu)。每個(gè)服務(wù)都是業(yè)務(wù)流程中的一個(gè)獨(dú)立于其他服務(wù)的邏輯軟件單元。這種不依賴于其他服務(wù)和技術(shù)選擇的自由度，打開(kāi)了探索新技術(shù)、構(gòu)建本地軟件組件以及基于服務(wù)定義范圍進(jìn)行設(shè)計(jì)的大門(mén)。

在 CapitalOne，軟件產(chǎn)品與業(yè)務(wù)功能是保持一致的。各個(gè)業(yè)務(wù)線（lines of businesses，LOB）構(gòu)建和管理自己的產(chǎn)品?？缏毮艿臉I(yè)務(wù)線主要是用于構(gòu)建和管理企業(yè)產(chǎn)品的，例如滿足所有 LOB 需求的數(shù)據(jù)湖和平臺(tái)。

要點(diǎn)：松耦合和緊關(guān)聯(lián)的原則，支持團(tuán)隊(duì)構(gòu)建各種解決更大業(yè)務(wù)問(wèn)題的產(chǎn)品。

3 關(guān)鍵在于實(shí)現(xiàn)：RESTful一勞永逸

微服務(wù)架構(gòu)實(shí)際上是一種微組件架構(gòu)。“微”指組件的粒度細(xì)，而不是指所暴露接口的粒度。微服務(wù)是以 API 為接口的組件，但并非所有的微服務(wù)組件都暴露 API。在從單體應(yīng)用向微服務(wù)架構(gòu)過(guò)渡中，我們可以保持暴露的 API 數(shù)量不變。

在這一過(guò)渡過(guò)程中，確定初始計(jì)劃將需要幾天甚至幾個(gè)月的時(shí)間，反過(guò)來(lái)增加了初始階段的前期成本。大型應(yīng)用分解為微服務(wù)，可能需要更多團(tuán)隊(duì)的協(xié)作。其中持續(xù)存在著過(guò)度工程的風(fēng)險(xiǎn)，導(dǎo)致創(chuàng)建了比需求更多的微服務(wù)，增加了體系結(jié)構(gòu)的復(fù)雜性。

我在加入 CapitalOne 之前曾任職的一個(gè)公司，確定了一些可遷移到微服務(wù)架構(gòu)的單體業(yè)務(wù)應(yīng)用。產(chǎn)品的愿景并沒(méi)有發(fā)生改變，因?yàn)檎w的業(yè)務(wù)功能沒(méi)有改變。

公司招聘了更多的團(tuán)隊(duì)，期望這些團(tuán)隊(duì)擔(dān)當(dāng)起服務(wù)的所有者。公司根據(jù)發(fā)布時(shí)間表部署服務(wù)，但基礎(chǔ)架構(gòu)團(tuán)隊(duì)并未受到計(jì)劃的影響，仍然掌控著生產(chǎn)系統(tǒng)。計(jì)劃在啟動(dòng)兩年后的進(jìn)展不大，花光了預(yù)算。

如上的許多實(shí)例表明，公司內(nèi)部團(tuán)隊(duì)?wèi)?yīng)對(duì)微服務(wù)的實(shí)現(xiàn)做更好的溝通。實(shí)現(xiàn)數(shù)字化轉(zhuǎn)型的不僅僅是應(yīng)用的開(kāi)發(fā)和新的技術(shù)，還需要在產(chǎn)品分析、預(yù)算估算、架構(gòu)、部署程序的重新設(shè)計(jì)、基礎(chǔ)架構(gòu)擴(kuò)展等過(guò)程上做大量的工作。過(guò)渡到微服務(wù)，需要時(shí)間、金錢(qián)，以及對(duì)業(yè)務(wù)問(wèn)題看法上的重大轉(zhuǎn)變。

要點(diǎn)：微服務(wù)并非只是一種架構(gòu)方式，而是一種會(huì)影響到組織中每個(gè)團(tuán)隊(duì)的文化變遷。

4 收益是長(zhǎng)期的

采用微服務(wù)需要建立多個(gè)產(chǎn)品、服務(wù)和團(tuán)隊(duì)。在采用這種復(fù)雜的體系結(jié)構(gòu)之前，組織必須確立一個(gè)扎實(shí)的路線圖。

企業(yè)需要采用強(qiáng)大的企業(yè)級(jí)產(chǎn)品，支持各個(gè)團(tuán)隊(duì)以微服務(wù)方式工作，凝聚在一起。其中包括支持 API 文檔的工具，以及源代碼管理、問(wèn)題追蹤器和實(shí)現(xiàn)自動(dòng)部署的工具等協(xié)作工具。

服務(wù)由工程團(tuán)隊(duì)構(gòu)建，以 API 方式暴露在 API 網(wǎng)關(guān)上。API 網(wǎng)關(guān)類(lèi)似于一個(gè) REST API 的市場(chǎng)，是組織日常業(yè)務(wù)運(yùn)營(yíng)的骨干。一旦組織步入微服務(wù)方法的正軌，持續(xù)的服務(wù)流就能得以創(chuàng)建、升級(jí)、替換等。工程師可能并不知道每個(gè)服務(wù)的確切位置，由服務(wù)發(fā)現(xiàn)系統(tǒng)支持服務(wù)的自動(dòng)檢測(cè)，使得服務(wù)之間可以互相發(fā)現(xiàn)。

為了獲得更好的性能和故障隔離，微服務(wù)組件需要一個(gè)專(zhuān)門(mén)的基礎(chǔ)架構(gòu)。每個(gè)微服務(wù)應(yīng)具有自己的發(fā)布時(shí)間表，無(wú)需依賴于其他服務(wù)而隨時(shí)部署到生產(chǎn)環(huán)境。因此，選擇有效工具持續(xù)并實(shí)時(shí)監(jiān)視和分析微服務(wù)的是至關(guān)重要的。

API 是微服務(wù)世界的接口，因此 API 的日志記錄、性能監(jiān)視和安全性也是組織中 IT 服務(wù)過(guò)程的關(guān)鍵。

構(gòu)建有彈性的微服務(wù)，可遵循多種設(shè)計(jì)模式，例如，“重試模式”（Retry Pattern）通過(guò)透明地重試失敗操作嘗試連接到服務(wù)或網(wǎng)絡(luò)資源，支持應(yīng)用處理瞬態(tài)故障；“斷路器模式”（Circuit Breaker pattern）支持應(yīng)用在連接遠(yuǎn)程服務(wù)或資源時(shí)發(fā)生錯(cuò)誤時(shí)能很好地處理故障。

這樣避免了微服務(wù)生態(tài)系統(tǒng)中出現(xiàn)級(jí)聯(lián)故障，進(jìn)而提高應(yīng)用的穩(wěn)定性和彈性。在微服務(wù)中，每個(gè)服務(wù)都是獨(dú)立的組件，每個(gè)功能和服務(wù)都可以擴(kuò)展，而不必?cái)U(kuò)展整個(gè)應(yīng)用。關(guān)鍵服務(wù)可部署多個(gè)實(shí)例，實(shí)現(xiàn)高可用性和更好的性能，而不會(huì)影響其他服務(wù)的性能。

要點(diǎn)：盡管過(guò)渡到微服務(wù)需在前期需投入大量的資源和工作，但隨著時(shí)間和工作上的付出，以及自動(dòng)化工具的使用，業(yè)務(wù)將從中受益，可快速向市場(chǎng)交付有質(zhì)量產(chǎn)品。

5 微服務(wù)并不普適

并非所有的業(yè)務(wù)和用例都適用微服務(wù)。例如，團(tuán)隊(duì)必須構(gòu)建具有很少功能的簡(jiǎn)單應(yīng)用，或是大型單體應(yīng)用無(wú)法拆分成較小的模塊，或是不了解微服務(wù)體架構(gòu)所帶來(lái)的權(quán)衡。

此外，某些企業(yè)可能尚未具備快速開(kāi)發(fā)和部署應(yīng)用的能力，或是不需要持續(xù)監(jiān)視應(yīng)用或業(yè)務(wù)，因?yàn)榘l(fā)生故障的恢復(fù)時(shí)間較長(zhǎng)對(duì)業(yè)務(wù)影響不大。

和所有其他工具一樣，微服務(wù)只是一種工具，并非普適于所有業(yè)務(wù)問(wèn)題的解決方案。業(yè)務(wù)優(yōu)先于一切，底層系統(tǒng)則可以適應(yīng)任何體系架構(gòu)模式，無(wú)論是單體應(yīng)用還是微服務(wù)。

在決定使用微服務(wù)之前，每家企業(yè)必須首先了解自身的業(yè)務(wù)需求，權(quán)衡利弊后再?zèng)Q定是否轉(zhuǎn)向微服務(wù)。

CapitalOne 在完全采用云和微服務(wù)架構(gòu)之前，投入了大量時(shí)間和精力研究微服務(wù)應(yīng)用。有能力的領(lǐng)導(dǎo)、富有遠(yuǎn)見(jiàn)的產(chǎn)品團(tuán)隊(duì)和技術(shù)精湛的工程團(tuán)隊(duì)通力合作，使得 CapitalOne 實(shí)現(xiàn)了銀行技術(shù)領(lǐng)導(dǎo)者這一目標(biāo)。

要點(diǎn)：使用微服務(wù)并非免費(fèi)的午餐。

使用微服務(wù)架構(gòu)將導(dǎo)致基礎(chǔ)架構(gòu)的需求、成本和復(fù)雜性激增，那么企業(yè)為什么要采用微服務(wù)？具有大客戶群的大公司，將通過(guò)在短時(shí)間內(nèi)向客戶提供優(yōu)質(zhì)的產(chǎn)品而蓬勃發(fā)展。他們的系統(tǒng)需要始終保持運(yùn)行的狀態(tài)，為分布在各個(gè)地區(qū)的客戶提供服務(wù)。

微服務(wù)是一種有助于實(shí)現(xiàn)此目標(biāo)的解決方案。在當(dāng)今的世界中，隨著云原生基礎(chǔ)架構(gòu)的出現(xiàn)、DevOps 交付管道的自動(dòng)化以及容器的采用，公司應(yīng)該研究一下微服務(wù)的優(yōu)勢(shì)。

需要指出的是，企業(yè)決定選用某種技術(shù)，并非完全因?yàn)閯e人用著很酷。相反，在采用微服務(wù)之前，我們需要花費(fèi)時(shí)間和精力去了解這種架構(gòu)模式，該架構(gòu)與企業(yè)自身的相關(guān)性。希望我的切身體會(huì)能有助于讀者深入了解微服務(wù)。