一文了解微服務的流程和組織

導語：微服務架構最重要的好處是它可以實現大型的複雜應用程式的持續交付和持續部署。持續交付和持續部署是DevOps的一部分，DevOps是一套快速、頻繁、可靠的軟體交付實踐。高效能的DevOps組織通常在將軟體部署到生產環境時面臨更少的問題和故障。

對於大型和複雜的應用程式，微服務架構往往是最佳的選擇。然而，除了擁有正確的架構之外，成功的軟體開發還需要在組織、開發和交付流程方面做一些工作。

圖1展示了架構、流程和組織之間的關係：

圖1　大型複雜應用程式快速、頻繁和可靠地交付軟體需要具備幾項DevOps關鍵能力，其中包括持續交付和持續部署，小型自治團隊和微服務架構

1.　進行軟體開發和交付的組織

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

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

逆向的康威定律

為了在使用微服務架構時有效地交付軟體，你需要考慮康威定律，它規定了如下內容：

設計系統的組織……往往被組織的架構所限制，最終設計的結果是這些組織的溝通結構的副本。

(梅爾文·康威)

換句話說，應用程式的架構往往反映了開發它的組織的結構。因此，反向應用康威定律並設計你的企業組織，使其結構與微服務的架構一一對應。透過這樣做，可以確保你的開發團隊與服務一樣松耦合。

若干個小團隊的效率顯然要高於一個單一的大團隊。微服務架構使得團隊可以實現某種程度的“自治”。每個團隊都可以開發、部署和運維擴充套件他們負責的服務，而不必與其他團隊協調。更進一步，當出現了某個服務故障或沒有滿足SLA等要求時，對應的責任人（團隊）也非常清楚。

而且，開發組織的可擴充套件性更高。你可以透過新增團隊來擴充套件組織。如果單個團隊變得太大，則將其拆分並關聯到各自負責的服務。由於團隊鬆散耦合，你可以避免大型團隊的溝通開銷。因此，你可以在不影響工作效率的情況下新增人員。

2　進行軟體開發和交付的流程

採用微服務架構以後，如果仍舊沿用瀑布式開發流程，那就跟用一匹馬來拉法拉利跑車沒什麼區別—我們需要充分利用微服務帶來的各種便利。如果你希望透過微服務架構來完成一個應用程式的開發，那麼採用類似Scrum或Kanban這類敏捷開發和部署實踐就是必不可少的。同時也需要積極實踐持續交付和持續部署，這是DevOps中的關鍵環節。

Jez Humble把持續交付定義為：

持續交付能夠以可持續的方式安全、快速地將所有型別的更改（包括新功能、配置更改、錯誤修復和實驗）交付到生產環境或使用者手中。

持續交付的一個關鍵特徵是軟體總是隨時可以交付的。它依賴於高水平的自動化，包括自動化測試。在將程式碼自動部署到生產環境的過程中，持續部署把持續交付提升到了一個新的水準。實施持續部署的高績效組織每天多次部署到生產環境中，生產中斷的次數要少得多，並且可以從發生的任何事情中快速恢復。微服務架構直接支援持續交付和持續部署。

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

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

·部署頻率：軟體部署到生產環境中的頻率。

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

·平均恢復時間：從生產環境問題中恢復的時間。

·變更失敗率：導致生產環境問題的變更提交百分比。

在傳統組織中，部署頻率低，交付的時間很長。特別是開發人員和運維人員通常都會在維護視窗期間熬夜到最後一刻。相比之下，DevOps組織經常釋出軟體，通常每天多次釋出，生產環境問題要少得多。例如，亞馬遜在2014年每隔11.6秒就將程式碼更改部署到生產環境中，Netflix的一個軟體元件的交付時間為16分鐘。

3　採用微服務架構時的人為因素

採用微服務架構以後，不僅改變了技術架構，也改變了組織結構和開發的流程。歸根到底，這是對工作環境中的人（正如之前提到的，情緒化的生物）進行的一系列改變。如果忽略人們的情緒，那麼採納微服務架構將會是一個非常糾結和折騰的過程。FTGO的技術長瑪麗和其他的管理層，正面臨著如何改變FTGO軟體開發方式的挑戰。

暢銷書《Managing Transitions》介紹了轉型（transition）的概念，其中闡述了人們如何對變化做出情緒化的反應。它包括以下三個階段。

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

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

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

總結

單體架構模式將應用程式構建為單個可部署單元。

微服務架構模式將系統分解為一組可獨立部署的服務，每個服務都有自己的資料庫。

單體架構是簡單應用的不錯選擇，微服務架構通常是大型複雜應用的更好選擇。

微服務架構使小型自治團隊能夠並行工作，從而加快軟體開發的速度。

微服務架構不是銀彈：它存在包括複雜性在內的諸多弊端。

微服務架構模式語言是一組模式，可幫助你使用微服務架構構建應用程式。它可以幫助你決定是否使用微服務架構，如果你選擇微服務架構，模式語言可以幫助你有效地應用它。

你需要的不僅僅是透過微服務架構來加速軟體交付。成功的軟體開發還需要DevOps和小而自治的團隊。

不要忘記採納微服務過程中的人性層面。你需要考慮員工的情緒才能成功轉換到微服務架構。

本文摘自《微服務架構設計模式》，經出版方授權釋出。