1.4 微服務架構的優勢

微服務架構能夠為我們帶來許多優勢，包括技術上的優勢、業務結構上的優勢以及組織上的優勢，本節將對這些優勢展開介紹。

1.4.1 技術優勢

微服務架構的技術優勢非常明顯，我們通過一個簡單示例來說明它對軟件開發所帶來的變化。試想在一個移動醫療系統中，用戶可以通過APP進行預約掛號并形成支付訂單，另外，我們也希望實現醫生和科室的搜索功能從而為用戶提供精準查詢的用戶體驗，如圖 1-11 所示。預約掛號和搜索對于產品的業務結構而言是非常簡單和明確的功能需求，在實現上卻可能有很多種不同的方法。

在圖1-11中，我們發現預約掛號和搜索功能存在一定的依賴關系，因為用戶可以先執行搜索操作，然后根據搜索的結果進行預約掛號。這時候，比較容易想到的實現方法是把這兩個功能放在同一個模塊或子系統中，要修改就一起修改。但是，一旦這種相對較弱的依賴關系在整個系統中開始滋生蔓延時，我們會發現很快就會演變成一種腐化狀態。這種腐化狀態通常需要使用專門的架構重構才能得到緩解（我們會在第8章中討論這些架構重構方法），而微服務架構的引入能夠避免這種現象的發生。在微服務架構中，預約掛號和搜索將成為兩個獨立的微服務。如果這兩種服務之間需要交互，那么我們可以引入明確且輕量級的通信機制。微服務之間的邊界起到一種防腐劑的作用，能夠降低業務功能之間的依賴關系從而防止架構腐化。

以上的簡單案例給出了微服務架構最重要的優勢，我們還可以從以下幾個方面再進一步展開討論。

1.組件化方案

微服務架構提供的是一種高內聚、低耦合的組件化方案。組件所能帶來的獨立性與健壯性微服務都可以具備，但微服務的組件化特征更多表現在對業務的提煉和對邊界的思考。使用微服務架構迫使我們使用諸如領域驅動設計的思想去進行策略設計和技術設計，從而為更好地劃分業務功能、提取界限上下文和開展系統集成工作提供依據。而這些方法和依據的背后恰恰是我們在架構設計過程中經常會碰到的問題。

2.技術自由度

當系統架構轉變成一系列微服務之間的通信和集成時，我們就明白具體實現技術已經不是系統設計和開發的主要約束條件。因為在微服務架構中，各個微服務之間使用的是輕量級的通信機制。所謂輕量級，就是指這些通信機制跟具體實現技術無關，不受限與某一個特定協議或交互媒介。每個微服務高度獨立，可以采用適合自身開發團隊和技術體系的工具和框架來實現某個微服務，從而為我們提供了寶貴的技術自由度。

3.可擴展性

在對圖1-8分析時，我們實際上已經討論了微服務架構與生俱來的可擴展性。通過服務拆分和集成，單個服務在保持通信方式不變的前提下，對其內部功能和技術的改變不會對外部依賴它的服務產生任何影響。結合可擴展性的概念，微服務架構無疑具備這方面的優勢。

4.可伸縮性

可擴展性與可伸縮性是兩個不同的概念，但高擴展性往往能夠帶來高可伸縮性，因為可以伸縮的前提是對系統有合理的拆分。當我們明確系統中的運行瓶頸，并把引起這些瓶頸的業務功能構建成獨立的微服務，就可以應用服務集群等手段有效加強服務運行時的環境和狀態。

5.有效應對遺留系統

微服務是可用于改造遺留系統（Legacy System）的強有力武器。面對遺留系統，一方面該系統的技術體系可能存在設計上的較大缺陷，另一方面則是因為代碼量巨大且不容易修改。在代碼層次與遺留系統進行直接集成是痛苦且具有挑戰性的工作，但是遺留系統以提供接口的方式暴露某些功能入口仍然是一個相對容易實現的過程。一旦獲取這些接口，微服務架構就能與之進行通信并完成功能整合。

6.支持持續交付

持續交付通過簡單、可重復的流程來確保軟件發布過程的可靠性，通常這是通過持續集成和持續交付管道得以實現。微服務作為獨立的可部署單元，非常適合使用持續交付，因為每一個服務都可以在不依賴于其他服務的條件下完成發布和部署。基于微服務架構，持續交付管道可以運行得更快，從而加速問題反饋，這是持續交付的主要目標之一。而持續交付的另一個目標是降低系統風險，微服務小而獨立，一旦出現問題很容易進行回滾操作。

1.4.2 業務與組織優勢

康威定律（Conway’s Law）[4]指出設計系統的組織，其產生的設計和架構等價于組織間的溝通結構。從傳統的單塊架構到微服務架構實際就是這一定律的一種體現。現在很多開發團隊本質上都是分布式的，單塊架構的開發、測試、部署協調溝通成本巨大，嚴重影響效率且容易產生沖突。將單塊架構解耦成微服務架構，每個團隊開發、測試和發布自己負責的微服務，互不干擾，系統效率得到提升。可見，組織和系統架構之間有一個映射關系：一方面，如果組織結構和文化結構不支持，通常無法成功建立有效的系統架構；另一方面，如果系統設計或者架構不支持，那么你就無法成功建立一個高效的組織。

用更通俗的說法，康威定律就是指組織形式等同系統設計，更直白地說，你想要什么樣的系統，就搭建什么樣的團隊。如果一個組織分成前端團隊、Java后臺開發團隊、DBA團隊和運維團隊，那么就形成了所謂的功能團隊，各個小團隊各自為政，需要強有力的組織文化和執行力才能確保各個團隊之間有效協作；相反，如果你的系統是按照業務邊界劃分的，大家遵循同一個業務目標把大系統做成小系統、小產品，就容易形成實現微服務架構所需的自治性組織文化。

1.消除過程浪費

軟件行業大多數產品開發由時間和成本決定其投入，即一定數量的開發人員通過一定時間的開發工作完成某個具體產品。顯然，開發周期的縮短同樣意味著開發成本的降低，因此開發成本與開發周期密切相關。產品開發周期時間與成本之間的關系如圖1-12所示，可以看到開發時間和開發成本之間并不是一個簡單的線性關系，隨著開發時間的增長，開發成本增長的趨勢越來越明顯。出現這樣的情況是因為軟件開發過程中對范圍變更的控制、計劃的監控、資源的合理安排都存在風險，且風險隨時間演變其發生的概率和造成的影響就越大。圖1-12所示的就是技術管理面臨的一個重要課題，即對于范圍已經固定的產品開發任務而言，如何提高開發效率以降低開發時間和成本。

建立高效的研發過程體系可以提高開發效率，通過提高開發效率而節省下來的資源可以再投入到新產品的開發中去，從而使更多的新產品投向市場，或者減少新產品開發的總體成本。對于軟件開發這個特定行業而言，減少浪費是提高開發效率的首要切入點。浪費分成純粹的浪費和必要的浪費，其中純粹的浪費需要消除，而必要的浪費可以進行壓縮[2]。

微服務架構的技術特征決定了開發各自微服務的團隊之間只需要進行較少的協調工作，這為降低研發過程浪費提供了基礎。從組織管理的角度出發，自治性團隊較之集中式管理模式下的團隊在團隊建立和發展上能夠得到更好的可擴展性。集中式團隊普遍受限于技術上的約束和決策，諸如可用性、性能等非功能性需求都不是由某個業務功能和系統的獨立團隊所負責，而是需要集中式的、系統級別的實現和管理。微服務架構可以把大型團隊打散成小型團隊，而小型團隊比大型團隊具有更低的失敗可能性。從這點上，微服務架構還能夠降低團隊組織級別的風險。

另一方面，軟件團隊中時常會出現所謂的“扯皮現象”。這是一種明顯的過程浪費，該現象的產生原因在于不清晰的邊界。微服務架構的一大特征就是根據業務來組建團隊，某個特定業務局限于某個微服務中并由獨立團隊負責所有相關事宜。明確的邊界有助于減少團隊之間的扯皮現象，從而提升開發效率。

2.快速產品開發

在互聯網行業中，時機可能比任何其他因素更為重要。在一些行業中，市場機會窗只會開放很短的一段時間。在這種背景下，產品能不能成功在很大程度上取決于產品投放市場的時間。如果在同等產品規劃和運營策略下，也即在相同的業務創新條件下，技術創新就會成為影響產品成功的決定性因素。技術創新能夠在改善產品用戶體驗和縮短產品研發生命周期上提升產品成功的概率，如圖1-13所示，通過縮短開發時間從而快速推出新產品能帶來產品收益上的增長，而對于互聯網產品而言，很多時候錯過產品發布時機就意味著再也沒有機會。

微服務架構從技術角度給出了縮短產品開發周期的方法，主要表現在并行的開發模式上。將業務拆分成各個微服務能夠讓不同的業務功能處于一種并行開發的狀態，因為每個團隊所負責的業務需求只影響到團隊自身的微服務，所以各個團隊能夠獨立開發，整個系統也很容易分布到各個團隊中。如果涉及簡單業務需求的變更或者是發布部署的要求，獨立的微服務之間也不需要太多的統一協調工作。大規模的統一協調工作通常只發生在業務結構產生重大變更的場景，而這種場景對于軟件開發而言顯然是應該盡量避免并進行提前規劃。