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

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

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

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

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

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

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

有說法提出，這種架構(gòu)樣式事實并沒有一個的標準定義，只是存在一些“圍繞組織和業(yè)務(wù)能力、自動部署，端點智能、對語言和數(shù)據(jù)分散控制”的特征。

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

下面給出我在實踐微服務(wù)中的五點主要體會。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 收益是長期的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

要點：使用微服務(wù)并非免費的午餐。

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

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

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