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