微服務的隱性收益
引言：微服務并不適用于每個公司，而且實現微服務化的過程也并不容易。但是，實現微服務除了明顯優勢之外，還有一些隱性的收益值得關注。本文編譯自 Tom Killalea的一篇舊文 https://queue.acm.org/detail.cfm?id=2956643，融入了一點兒個人的理解。
微服務是一種構建分布式系統的方法，在微服務系統中，服務只能通過API來公開，這是一個API的世界(可以參考沒有被了解的API?一個老碼農眼中的API世界)。在微服務的世界里，服務本身在特定且有良好界限的場景下或職責區域具有高度的內聚性，而且服務之間是松耦合的。這樣的微服務通常很簡單，但是它們可以組合成非常豐富且復雜的應用。采用微服務的構建方法所需的工作量相當大，特別是從單體架構遷移的時候。然而，微服務的好處眾多，眾所周知的優勢包括敏捷性的增強、彈性、可伸縮性和開發人員的生產力。本文指出了微服務的一些隱性收益，我們或許應該有意識地努力收獲這些收益。
微服務帶來的最基本好處是明確地分離服務，將每個服務的關注點集中在整個應用中的某個明確定義的位置。這些服務可以通過服務之間的松耦合以新穎的方式組合，并可以獨立部署。清晰的關注點分離，跨領域的最小耦合，以及更高變化率的潛力導致業務靈活性和工程速度的提高。許多人都被微服務架構能夠更頻繁地做出改變且減少負面影響的誘惑所吸引。
通過持續交付和基礎設施的可編程化，這些實踐在實現微型服務的過程中對彈性、敏捷性和生產力產生了積極的影響。微服務的另一個關鍵好處是，它們可以使整個體系結構的不同部分的所有者在持久性機制選擇、一致性和并發性方面對構建大規模分布式系統做出非常不同的決策。這給了服務所有者更大的自主權，可以導致更快地采用新技術，并且可以允許他們追求定制的方法，這些方法可能只對少數服務，甚至只對一個服務是最佳的。
雖然微服務有實現上的難度，但是可以為那些麻煩的組織帶來好處，盡管其中一些收益并不是顯而易見的。下面是一些不那么明顯的好處，這些因素可能是采用微服務的額外收益。
隱性收益 # 1: 無許可創新
關于創新，可以參考《隄上創新誰述記——老碼農的“創新”漫談》和《斯須改變如蒼狗——一張圖的隨想》，那么，什么是無許可創新呢?無許可創新是指“其他人在我們創造的通信結構之上創造新事物的能力”。
一旦啟用了微服務，它可以引導業務方創新一系列的接口，應用這些接口可能使得設計者都會感到驚訝。為了確定無許可創新是否已經到了可能的程度，一個簡單的測試是觀察團隊間會議的流行程度。跨團隊會議表明了協調、耦合以及服務接口的粒度或功能問題。一個熱愛無許可創新的組織應該有較高的實驗率和較低的跨團隊會議率。
隱性收益 # 2: 可預料的故障
在IT領域，我們仍然不知道如何構建一個工作可靠的復雜系統，這一點不足為奇，系統的不可靠性隨著規模和復雜程度的增加而增加。雖然對于微服務是否能夠降低整體復雜性的看法不一，但是微型服務通常會增加故障的數量是肯定的。此外，跨服務邊界的故障更難以排除，因為外部調用堆棧本身比內部調用堆棧更脆弱，而且調試任務受到更糟糕的工具和更具挑戰性的特定功能分析的限制。有人說：“我們用微型服務替換了原來的單體結構，于是每一次斷電都可能更像是一場謀殺之謎。”
為不可避免性失敗的常態而設計，可以引發關于狀態持久性、彈性、依賴管理、共同命運和優雅降級的常態討論。這樣的討論通常利用緩存、監控、分流與限流、負載減少等技術來減少任何給定故障的爆炸半徑。在一個成熟的微服務體系結構中，應該預料到單個服務的故障，而所有服務的級聯故障應該是不可能的。
隱性收益 # 3: 突破信任
在小公司或小型代碼庫中，一些工程師可能對部署的內容有強烈的信任感，因為他們會review每一個提交內容。隨著團隊規模的增加，“鄧巴數”開始發揮作用，導致這種信任變得越來越緊張。關于鄧巴數，可以參考《有意義的不只是鄧巴數》。
向微服務的轉型可以迫使這種信任浮出水面并面對現實。一個服務和另一個服務之間的邊界是一組API。我們放棄了對這些API背后的設計、如何開發實現以及數據如何持久化的影響，以換取一組服務質量等級(SLA)來管理API的穩定性及其運行時的特性(關于SLA可以參考淺析面向云架構的SLA 以及性能，10點系統性思考)。信任可以用自治和責任的結合來取代。
微服務可以為不斷發展的組織提供一個有效的模式，它的規模遠遠超出了“鄧巴數”的限制。
隱性收益 # 4: 構建并擁有
微服務鼓勵“構建并擁有它”的模式。亞馬遜 CTO Werner Vogels 在2006年與 Jim Gray 的一次對話中描述了這個模型: “每個服務都有一個與之相關的團隊，這個團隊完全負責這個服務——從確定功能的范圍，到構建它，再到運行它。也就是說，開發者建造并運行它。這使得開發人員能夠接觸到這些軟件的日常操作，也使他們與客戶進行日常接觸。客戶反饋回路對于提高服務質量至關重要。”
在之后的十年里，隨著越來越多的軟件工程師遵循這種模式，并承擔起運營和開發微服務的責任，已經推動了一系列實踐的廣泛應用，這些實踐能夠實現更大程度的自動化，并降低運營成本。其中包括持續部署、虛擬化或容器化、自動彈性和各種自我修復技術。
隱性收益 # 5: 加速廢棄
在一個巨型單體架構體系中，很難安全地反對任何東西。使用微型服務，則很容易獲得服務調用量的清晰視圖，支持服務的不同版本和潛在的競爭版本，或者建立一個除了向后兼容那些用戶最關心的接口之外與舊服務不共享任何東西的新服務。
在一個無許可創新的世界里，服務可以而且應該經常變來變去。需要投入一些努力，使那些沒有真正流行起來的服務變得更加容易使用。解決這個問題的一個方法是對資源進行高度的競爭，任何資源有限的團隊，只要負責一項不景氣的服務，就會把大部分時間花在對客戶更重要的其他服務上。當這種情況發生時，服務的不成功責任應該轉移到最關心它的用戶身上。這個團隊可能理所當然地認為自己是被留下來“頂鍋扛雷” ，其他團隊則不希望保留對他們的依賴關系，這樣就有了遷移或終止依賴服務的額外動機。這聽起來可能很殘酷，但這是“快速失敗”的一個重要部分。
隱性收益 # 6: 終止數據庫瓶頸
在亞馬遜的早期，少量的關系數據庫被用于公司所有關鍵的事務數據。為了保證數據的完整性和性能，任何提議的模式更改都必須經過 DBA團隊的審查和批準。
使用微服務后，服務使用者不應該關心數據在一組API背后是如何持久化的，而且實際上，在不需要通知的情況下，將一種持久化機制替換為另一種持久化機制應該是可能的。
隱性收益 # 7: 集中面對痛苦
向微型服務的轉型應該使組織能夠采取非常不同的方法來滿足其對不同服務的治理期望。這將從一個一致數據分類模型和不同業務流程完整性的關鍵度劃分開始。這通常會導致為處理最重要數據和流程的服務建立安全模型，并實施必要的控制以滿足公司的安全和合規需求。
隨著微服務的激增，可以確保最重要的合規負擔集中在極少數服務上，從而使剩余的服務有更高的創新率，相對沒有這些問題的負擔。
隱性收益 # 8: 不同的測試
工程團隊經常把遷移到微服務視為一個機會，可以從不同的角度考慮測試。通常，在開始構建服務之前，會開始考慮如何在設計的早期階段進行測試。更明確地界定所有權和范圍可以鼓勵實現更大測試的覆蓋面。正如 Yelp 在闡述其服務原則時所說的，“接口是測試中最重要的組件。接口測試將告訴客戶端實際看到了什么，而其余的測試將告訴如何確保客戶端看到這些結果。”
采用持續集成、持續部署、冒煙測試和灰度部署等實踐，可以導致在生產中發現問題時進行高保真和低修復時間的測試。一組測試的有效性不能用發現問題的速度來衡量，而更多的是用它們所帶來的變化速度來衡量。
微服務轉型中的危險指標
如果我們遇到了如下的情景，說明我們的微服務轉型是不完整的，甚至是危險的。這些指標至少包括包括:
- 不同的服務進行協調部署。
- 需要提供客戶端庫。
- 一個服務的改變會產生意想不到的后果，或甚至需要修改其他服務。
- 服務共享同一個持久性存儲。
- 在沒人幫助的情況下，你不能改變自己服務的持久化層。
- 工程師需要對其他團隊服務的設計和模式有深入的了解。
- 有一個統一適用于所有服務的合規控制。
- 基礎設施不可編程。
- 不能進行一鍵式的部署和一鍵式回滾。
結束語
微服務并不適用于每個公司，這個微服務的實現過程也并不容易。因此，關于采用微服務的討論往往非常熱烈，主要集中在自主性、敏捷性、彈性和開發人員的生產力上。然而，好處并不僅限于此，為了讓微服務之旅更有價值，有意識地獲得額外收益也很有意義。
【本文來自51CTO專欄作者“老曹”的原創文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】
