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