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

[[278928]]

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

圖1

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

我們已經談過了微服務架構，現在來看看組織和流程。

01 進行軟件開發和交付的組織

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

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

• 逆向的康威定律

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

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

——梅爾文·康威

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

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

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

02 進行軟件開發和交付的流程

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

Jez Humble把持續交付定義為：

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

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

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

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

• 部署頻率：軟件部署到生產環境中的頻率。
• 交付時間：從開發人員提交變更到變更被部署的時間。
• 平均恢復時間：從生產環境問題中恢復的時間。
• 變更失敗率：導致生產環境問題的變更提交百分比。

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

03 采用微服務架構時的人為因素

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

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

1. 結束、失落和放棄：當人們被告知某種變化，這類變化會把他們從舒適區中拉出，這類情緒開始滋生和蔓延。人們會念叨失去之前的種種好處。例如，當被重組到一個新的跨職能團隊時，人們會想念他們之前的同事。再比如，對于負責全局數據建模的團隊來說，每個服務團隊負責自己的數據建模，這對他們是一種威脅。
2. 中立區：處理新舊工作方式交替過程中，人們普遍會對新的工作方式無所適從。人們開始糾結并必須要學習處理新工作的方式。
3. 新的開始：最終階段，人們開始發自內心地熱情擁抱新的工作方式，并且開始體驗到新工作方式所帶來的種種好處。

本書介紹了如何管理轉型過程中每個階段的問題，提高轉型的成功率。FTGO顯然正在單體地獄中煎熬，急切地需要轉型到微服務架構。他們也需要對組織結構和開發流程做出調整。為了成功地實現這一切，FTGO必須認真面對這些轉型模式和所有可能的情緒化反應。

總結

• 單體架構模式將應用程序構建為單個可部署單元。
• 微服務架構模式將系統分解為一組可獨立部署的服務，每個服務都有自己的數據庫。
• 單體架構是簡單應用的不錯選擇，微服務架構通常是大型復雜應用的更好選擇。
• 微服務架構使小型自治團隊能夠并行工作，從而加快軟件開發的速度。
• 微服務架構不是銀彈：它存在包括復雜性在內的諸多弊端。
• 微服務架構模式語言是一組模式，可幫助你使用微服務架構構建應用程序。它可以幫助你決定是否使用微服務架構，如果你選擇微服務架構，模式語言可以幫助你有效地應用它。
• 你需要的不僅僅是通過微服務架構來加速軟件交付。成功的軟件開發還需要DevOps和小而自治的團隊。
• 不要忘記采納微服務過程中的人性層面。你需要考慮員工的情緒才能成功轉換到微服務架構。