使用微服務架構將導致基礎架構的需求、成本和複雜性激增，但會提高企業服務的連續性和彈性，進而影響企業整體運行文化。在採用微服務之前，企業需要花費時間和精力去了解微服務架構，以及架構與企業自身的相關性。作爲一名軟件工程師，本文作者給出了對採用微服務架構的切身體會。
本文最初發佈於 Medium，經原作者授權由 InfoQ 中文站翻譯並分享。
我是一名微服務架構的忠心擁躉，雖然有時也會對其感到不爽。使用微服務時，我時常能感受到“小中見大”、“穩中有快”等理念，另一方面也會警惕“廚子太多燒壞了湯”。
回顧 2014 年，當時我任一家公司的軟件工程主管，該公司正在通過採用微服務架構實施數字化轉型。那時數字化、轉型和微服務這些詞對我就是天籟之音。作爲一名工程主管（雖然我目前是一位解決方案架構師），我非常希望能瞭解這種新模式。爲了跟上技術前沿趨勢，我閱讀了大量微服務架構相關的文章，與我的網絡技術負責人交流，並研究了一些適用的用例。那時我發自內心地相信微服務架構，確信單體應用將會消亡。此後，我服務過的每家公司都已採用或正在採用微服務架構。雖然其中一些公司的領導團隊並沒能說服組織爲什麼要選擇微服務，一個普遍的回答是：“其他公司都在這樣做，在每次會議上大家都說微服務是一種改變遊戲規則的方式，所以我們也這樣做吧。”通過爲各個業務領域中的多家公司提供體系結構和設計支持，我發現將現有的單體應用重新架構爲微服務架構需要付出大量的耐心、時間和經驗。
在給出我在採用微服務中的五點切身體會之前，首先重新審視一下什麼是微服務？有說法提出，這種架構樣式事實並沒有一個的標準定義，只是存在一些“圍繞組織和業務能力、自動部署，端點智能、對語言和數據分散控制”的特徵。在我看來，如果一個組織必須具備上述所有特徵才能去使用微服務，那麼我們就不僅是在談論技術變革，而是在推動組織內的重大文化變革。
下面給出我在實踐微服務中的五點主要體會。
跳出項目，擁抱產品
傳統的軟件開發方式中，開發團隊一起構建一個單體應用軟件，進而由生產支持團隊管理該軟件。在這種方式中，生產支持團隊作爲軟件的新所有者，通常並不完全瞭解組件的構建過程，例如代碼的邏輯，所使用的技術等。他們的核心工作是確保滿足業務需求的生產系統能正常地運行，團隊之間通常也沒有定義有效的溝通途徑。生產系統中出現的問題將導致開發回滾到某個還原點，或是給出快速的短期修補。有時，生產代碼中的一個微小問題將觸發整個過程全部重新開始。而問題通常必須由原始開發團隊解決，這導致整體延遲。
如果以瀑布式開發方式（即前期設計、集中式的版本發佈流程、構建和部署）處理微服務，則存在巨大的風險。最終得到的可能是一個更復雜的系統，無法享受微服務所承諾的任何好處。
在微服務中，經常提及的是“產品”，而非“項目”。使用微服務方法，利益相關者（包括用戶、程序、產品和技術人員）致力於產品這一共同目標。在投資、軟件交付到維護的整個過程上，產品模式都不同於項目模式。產品直接影響所提供的業務功能。不同於傳統方法中構建單體應用需要多個團隊參與，微服務模式支持單個團隊完全負責構建和管理某一小部分軟件。團隊在產品模式下是穩定的、跨職能的，並以結果爲導向的，獨立完成“設計 - 構建 - 運行”全過程。每個團隊都是遵循統一報告層級的獨立部門，根據路線圖去分塊構建獨立的軟件單元。某一層上的團隊可將另一層上的團隊視爲他們的（內部）客戶，相互協作去解決業務問題，而不是以權責交付的方式工作。由於工程團隊以產品模式工作，他們瞭解軟件在生產中的行爲，因此可以立即解決所有問題，避免產生延誤。
CapitalOne 秉持 YBYO（You Build You Own，自己構建）理念，團隊全權負責設計、構建、測試和部署生產環境中的軟件。工程團隊直接參與產品，並與用戶互動。用戶不斷提供反饋，幫助團隊構建高質量的產品。
要點：控制範圍使團隊可以更好地構建和管理微服務。產品模式支持與終端用戶建立更緊密的合作、管理和構建關係。
更具責任感和自由度：思考宏觀，服務“微”構建
我在加入 CapitalOne 之前曾任職另一家公司的團隊，爲公司的電子商務網站建立產品目錄服務。該公司採用了微服務方法，產品目錄服務以請求爲準則，向最終用戶提供產品列表。由於我的團隊控制着數據和目錄數據庫，因此選擇 Java 和 SpringBoot 構建服務。這些編程語言支持豐富的軟件庫，我們對此非常滿意。服務最終公開提供在面向最終用戶的 API 網關上。
公司中同樣還有其他幾個團隊，使用各自的技術來構建自己的服務。從產品的角度來看，每個功能都受到構建在異構平臺上的各個服務的支持。這樣的模型解決了一個重要的問題，那就是在招募和培訓團隊中，不必使用相同的技術堆棧構建單體應用。在微服務模型中，每個團隊都可以選擇適合自身業務需求的工具，據此招聘新的團隊成員。
微服務是一種通過服務構建其中業務應用組件的體系架構。每個服務都是業務流程中的一個獨立於其他服務的邏輯軟件單元。這種不依賴於其他服務和技術選擇的自由度，打開了探索新技術、構建本地軟件組件以及基於服務定義範圍進行設計的大門。
在 CapitalOne，軟件產品與業務功能是保持一致的。各個業務線（lines of businesses，LOB）構建和管理自己的產品。跨職能的業務線主要是用於構建和管理企業產品的，例如滿足所有 LOB 需求的數據湖和平臺。
要點：松耦合和緊關聯的原則，支持團隊構建各種解決更大業務問題的產品。
關鍵在於實現：RESTful 一勞永逸
微服務架構實際上是一種微組件架構。“微”指組件的粒度細，而不是指所暴露接口的粒度。微服務是以 API 爲接口的組件，但並非所有的微服務組件都暴露 API。在從單體應用向微服務架構過渡中，我們可以保持暴露的 API 數量不變。在這一過渡過程中，確定初始計劃將需要幾天甚至幾個月的時間，反過來增加了初始階段的前期成本。大型應用分解爲微服務，可能需要更多團隊的協作。其中持續存在着過度工程的風險，導致創建了比需求更多的微服務，增加了體系結構的複雜性。
我在加入 CapitalOne 之前曾任職的一個公司，確定了一些可遷移到微服務架構的單體業務應用。產品的願景並沒有發生改變，因爲整體的業務功能沒有改變。公司招聘了更多的團隊，期望這些團隊擔當起服務的所有者。公司根據發佈時間表部署服務，但基礎架構團隊並未受到計劃的影響，仍然掌控着生產系統。計劃在啓動兩年後的進展不大，花光了預算。
如上的許多實例表明，公司內部團隊應對微服務的實現做更好的溝通。實現數字化轉型的不僅僅是應用的開發和新的技術，還需要在產品分析、預算估算、架構、部署程序的重新設計、基礎架構擴展等過程上做大量的工作。過渡到微服務，需要時間、金錢，以及對業務問題看法上的重大轉變。
要點：微服務並非只是一種架構方式，而是一種會影響到組織中每個團隊的文化變遷。
收益是長期的：雖然複雜代價大，但是彈性可擴展
採用微服務需要建立多個產品、服務和團隊。在採用這種複雜的體系結構之前，組織必須確立一個紮實的路線圖。企業需要採用強大的企業級產品，支持各個團隊以微服務方式工作，凝聚在一起。其中包括支持 API 文檔的工具，以及源代碼管理、問題追蹤器和實現自動部署的工具等協作工具。
服務由工程團隊構建，以 API 方式暴露在 API 網關上。API 網關類似於一個 REST API 的市場，是組織日常業務運營的骨幹。一旦組織步入微服務方法的正軌，持續的服務流就能得以創建、升級、替換等。工程師可能並不知道每個服務的確切位置，由服務發現系統支持服務的自動檢測，使得服務之間可以互相發現。
爲了獲得更好的性能和故障隔離，微服務組件需要一個專門的基礎架構。每個微服務應具有自己的發佈時間表，無需依賴於其他服務而隨時部署到生產環境。因此，選擇有效工具持續並實時監視和分析微服務的是至關重要的。API 是微服務世界的接口，因此 API 的日誌記錄、性能監視和安全性也是組織中 IT 服務過程的關鍵。
構建有彈性的微服務，可遵循多種設計模式，例如，“重試模式”（Retry Pattern）通過透明地重試失敗操作嘗試連接到服務或網絡資源，支持應用處理瞬態故障；“斷路器模式”（Circuit Breaker pattern）支持應用在連接遠程服務或資源時發生錯誤時能很好地處理故障。這樣避免了微服務生態系統中出現級聯故障，進而提高應用的穩定性和彈性。在微服務中，每個服務都是獨立的組件，每個功能和服務都可以擴展，而不必擴展整個應用。關鍵服務可部署多個實例，實現高可用性和更好的性能，而不會影響其他服務的性能。
要點：儘管過渡到微服務需在前期需投入大量的資源和工作，但隨着時間和工作上的付出，以及自動化工具的使用，業務將從中受益，可快速向市場交付有質量產品。
微服務並不普適
並非所有的業務和用例都適用微服務。例如，團隊必須構建具有很少功能的簡單應用，或是大型單體應用無法拆分成較小的模塊，或是不瞭解微服務體架構所帶來的權衡。此外，某些企業可能尚未具備快速開發和部署應用的能力，或是不需要持續監視應用或業務，因爲發生故障的恢復時間較長對業務影響不大。
和所有其他工具一樣，微服務只是一種工具，並非普適於所有業務問題的解決方案。業務優先於一切，底層系統則可以適應任何體系架構模式，無論是單體應用還是微服務。在決定使用微服務之前，每家企業必須首先了解自身的業務需求，權衡利弊後再決定是否轉向微服務。
CapitalOne 在完全採用雲和微服務架構之前，投入了大量時間和精力研究微服務應用。有能力的領導、富有遠見的產品團隊和技術精湛的工程團隊通力合作，使得 CapitalOne 實現了銀行技術領導者這一目標。
要點：使用微服務並非免費的午餐。
使用微服務架構將導致基礎架構的需求、成本和複雜性激增，那麼企業爲什麼要採用微服務？具有大客戶羣的大公司，將通過在短時間內向客戶提供優質的產品而蓬勃發展。他們的系統需要始終保持運行的狀態，爲分佈在各個地區的客戶提供服務。微服務是一種有助於實現此目標的解決方案。在當今的世界中，隨着雲原生基礎架構的出現、DevOps 交付管道的自動化以及容器的採用，公司應該研究一下微服務的優勢。
需要指出的是，企業決定選用某種技術，並非完全因爲別人用着很酷。相反，在採用微服務之前，我們需要花費時間和精力去了解這種架構模式，該架構與企業自身的相關性。希望我的切身體會能有助於讀者深入瞭解微服務。
原文鏈接