一文了解微服務(wù)的流程和組織

導語：微服務(wù)架構(gòu)最重要的好處是它可以實現(xiàn)大型的復雜應(yīng)用程序的持續(xù)交付和持續(xù)部署。持續(xù)交付和持續(xù)部署是DevOps的一部分，DevOps是一套快速、頻繁、可靠的軟件交付實踐。高效能的DevOps組織通常在將軟件部署到生產(chǎn)環(huán)境時面臨更少的問題和故障。

對于大型和復雜的應(yīng)用程序，微服務(wù)架構(gòu)往往是最佳的選擇。然而，除了擁有正確的架構(gòu)之外，成功的軟件開發(fā)還需要在組織、開發(fā)和交付流程方面做一些工作。

圖1展示了架構(gòu)、流程和組織之間的關(guān)系：

圖1　大型復雜應(yīng)用程序快速、頻繁和可靠地交付軟件需要具備幾項DevOps關(guān)鍵能力，其中包括持續(xù)交付和持續(xù)部署，小型自治團隊和微服務(wù)架構(gòu)

1.　進行軟件開發(fā)和交付的組織

成功往往意味著研發(fā)團隊規(guī)模的擴大。一方面，這是個好事，因為人多力量大。但是團隊大了以后，正如Fred Brooks在《人月神話》這本書中提到的，溝通成本會隨著團隊的規(guī)模呈O(N ^ 2)的速度上升。如果團隊太大，由于溝通成本過高，往往會使得團隊的效率降低。想想看，如果每天早上的站會規(guī)模達到20人會是怎樣？

解決之道是把大團隊拆分成一系列小團隊。每個團隊都足夠小，人員規(guī)模為8～12人。每個團隊都有一個明確的職責：開發(fā)并且可能也負責運維一個或者多個服務(wù)，這些服務(wù)實現(xiàn)了一個或多個業(yè)務(wù)能力。這些團隊都是跨職能的。他們可以獨立地完成開發(fā)、測試和部署等任務(wù)，而不需要頻繁地與其他團隊溝通或者協(xié)調(diào)。

逆向的康威定律

為了在使用微服務(wù)架構(gòu)時有效地交付軟件，你需要考慮康威定律，它規(guī)定了如下內(nèi)容：

設(shè)計系統(tǒng)的組織……往往被組織的架構(gòu)所限制，最終設(shè)計的結(jié)果是這些組織的溝通結(jié)構(gòu)的副本。

(梅爾文·康威)

換句話說，應(yīng)用程序的架構(gòu)往往反映了開發(fā)它的組織的結(jié)構(gòu)。因此，反向應(yīng)用康威定律并設(shè)計你的企業(yè)組織，使其結(jié)構(gòu)與微服務(wù)的架構(gòu)一一對應(yīng)。通過這樣做，可以確保你的開發(fā)團隊與服務(wù)一樣松耦合。

若干個小團隊的效率顯然要高于一個單一的大團隊。微服務(wù)架構(gòu)使得團隊可以實現(xiàn)某種程度的“自治”。每個團隊都可以開發(fā)、部署和運維擴展他們負責的服務(wù)，而不必與其他團隊協(xié)調(diào)。更進一步，當出現(xiàn)了某個服務(wù)故障或沒有滿足SLA等要求時，對應(yīng)的責任人（團隊）也非常清楚。

而且，開發(fā)組織的可擴展性更高。你可以通過添加團隊來擴展組織。如果單個團隊變得太大，則將其拆分并關(guān)聯(lián)到各自負責的服務(wù)。由于團隊松散耦合，你可以避免大型團隊的溝通開銷。因此，你可以在不影響工作效率的情況下添加人員。

2　進行軟件開發(fā)和交付的流程

采用微服務(wù)架構(gòu)以后，如果仍舊沿用瀑布式開發(fā)流程，那就跟用一匹馬來拉法拉利跑車沒什么區(qū)別—我們需要充分利用微服務(wù)帶來的各種便利。如果你希望通過微服務(wù)架構(gòu)來完成一個應(yīng)用程序的開發(fā)，那么采用類似Scrum或Kanban這類敏捷開發(fā)和部署實踐就是必不可少的。同時也需要積極實踐持續(xù)交付和持續(xù)部署，這是DevOps中的關(guān)鍵環(huán)節(jié)。

Jez Humble把持續(xù)交付定義為：

持續(xù)交付能夠以可持續(xù)的方式安全、快速地將所有類型的更改（包括新功能、配置更改、錯誤修復和實驗）交付到生產(chǎn)環(huán)境或用戶手中。

持續(xù)交付的一個關(guān)鍵特征是軟件總是隨時可以交付的。它依賴于高水平的自動化，包括自動化測試。在將代碼自動部署到生產(chǎn)環(huán)境的過程中，持續(xù)部署把持續(xù)交付提升到了一個新的水準。實施持續(xù)部署的高績效組織每天多次部署到生產(chǎn)環(huán)境中，生產(chǎn)中斷的次數(shù)要少得多，并且可以從發(fā)生的任何事情中快速恢復。微服務(wù)架構(gòu)直接支持持續(xù)交付和持續(xù)部署。

快速推進同時不把事情搞砸

持續(xù)交付和持續(xù)部署（以及更一般地說，DevOps）的目標是快速可靠地交付軟件。評估軟件開發(fā)的四個有用指標如下：

·部署頻率：軟件部署到生產(chǎn)環(huán)境中的頻率。

·交付時間：從開發(fā)人員提交變更到變更被部署的時間。

·平均恢復時間：從生產(chǎn)環(huán)境問題中恢復的時間。

·變更失敗率：導致生產(chǎn)環(huán)境問題的變更提交百分比。

在傳統(tǒng)組織中，部署頻率低，交付的時間很長。特別是開發(fā)人員和運維人員通常都會在維護窗口期間熬夜到最后一刻。相比之下，DevOps組織經(jīng)常發(fā)布軟件，通常每天多次發(fā)布，生產(chǎn)環(huán)境問題要少得多。例如，亞馬遜在2014年每隔11.6秒就將代碼更改部署到生產(chǎn)環(huán)境中，Netflix的一個軟件組件的交付時間為16分鐘。

3　采用微服務(wù)架構(gòu)時的人為因素

采用微服務(wù)架構(gòu)以后，不僅改變了技術(shù)架構(gòu)，也改變了組織結(jié)構(gòu)和開發(fā)的流程。歸根到底，這是對工作環(huán)境中的人（正如之前提到的，情緒化的生物）進行的一系列改變。如果忽略人們的情緒，那么采納微服務(wù)架構(gòu)將會是一個非常糾結(jié)和折騰的過程。FTGO的首席技術(shù)官瑪麗和其他的管理層，正面臨著如何改變FTGO軟件開發(fā)方式的挑戰(zhàn)。

暢銷書《Managing Transitions》介紹了轉(zhuǎn)型（transition）的概念，其中闡述了人們?nèi)绾螌ψ兓龀銮榫w化的反應(yīng)。它包括以下三個階段。

1.結(jié)束、失落和放棄：當人們被告知某種變化，這類變化會把他們從舒適區(qū)中拉出，這類情緒開始滋生和蔓延。人們會念叨失去之前的種種好處。例如，當被重組到一個新的跨職能團隊時，人們會想念他們之前的同事。再比如，對于負責全局數(shù)據(jù)建模的團隊來說，每個服務(wù)團隊負責自己的數(shù)據(jù)建模，這對他們是一種威脅。

2.中立區(qū)：處理新舊工作方式交替過程中，人們普遍會對新的工作方式無所適從。人們開始糾結(jié)并必須要學習處理新工作的方式。

3.新的開始：最終階段，人們開始發(fā)自內(nèi)心地熱情擁抱新的工作方式，并且開始體驗到新工作方式所帶來的種種好處。

總結(jié)

單體架構(gòu)模式將應(yīng)用程序構(gòu)建為單個可部署單元。

微服務(wù)架構(gòu)模式將系統(tǒng)分解為一組可獨立部署的服務(wù)，每個服務(wù)都有自己的數(shù)據(jù)庫。

單體架構(gòu)是簡單應(yīng)用的不錯選擇，微服務(wù)架構(gòu)通常是大型復雜應(yīng)用的更好選擇。

微服務(wù)架構(gòu)使小型自治團隊能夠并行工作，從而加快軟件開發(fā)的速度。

微服務(wù)架構(gòu)不是銀彈：它存在包括復雜性在內(nèi)的諸多弊端。

微服務(wù)架構(gòu)模式語言是一組模式，可幫助你使用微服務(wù)架構(gòu)構(gòu)建應(yīng)用程序。它可以幫助你決定是否使用微服務(wù)架構(gòu)，如果你選擇微服務(wù)架構(gòu)，模式語言可以幫助你有效地應(yīng)用它。

你需要的不僅僅是通過微服務(wù)架構(gòu)來加速軟件交付。成功的軟件開發(fā)還需要DevOps和小而自治的團隊。

不要忘記采納微服務(wù)過程中的人性層面。你需要考慮員工的情緒才能成功轉(zhuǎn)換到微服務(wù)架構(gòu)。

本文摘自《微服務(wù)架構(gòu)設(shè)計模式》，經(jīng)出版方授權(quán)發(fā)布。