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

[[278928]]

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

圖1

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

我們已經(jīng)談過了微服務(wù)架構(gòu)，現(xiàn)在來看看組織和流程。

01 進(jìn)行軟件開發(fā)和交付的組織

成功往往意味著研發(fā)團(tuán)隊(duì)規(guī)模的擴(kuò)大。一方面，這是個(gè)好事，因?yàn)槿硕嗔α看蟆５菆F(tuán)隊(duì)大了以后，正如Fred Brooks在《人月神話》這本書中提到的，溝通成本會(huì)隨著團(tuán)隊(duì)的規(guī)模呈O(N ^ 2)的速度上升。如果團(tuán)隊(duì)太大，由于溝通成本過高，往往會(huì)使得團(tuán)隊(duì)的效率降低。想想看，如果每天早上的站會(huì)規(guī)模達(dá)到20人會(huì)是怎樣?

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

• 逆向的康威定律

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

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

——梅爾文·康威

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

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

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

02 進(jìn)行軟件開發(fā)和交付的流程

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

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

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

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

• 快速推進(jìn)同時(shí)不把事情搞砸

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

• 部署頻率：軟件部署到生產(chǎn)環(huán)境中的頻率。
• 交付時(shí)間：從開發(fā)人員提交變更到變更被部署的時(shí)間。
• 平均恢復(fù)時(shí)間：從生產(chǎn)環(huán)境問題中恢復(fù)的時(shí)間。
• 變更失敗率：導(dǎo)致生產(chǎn)環(huán)境問題的變更提交百分比。

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

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

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

暢銷書《Managing Transitions》介紹了轉(zhuǎn)型(transition)的概念，其中闡述了人們?nèi)绾螌?duì)變化做出情緒化的反應(yīng)。它包括以下三個(gè)階段。

1. 結(jié)束、失落和放棄：當(dāng)人們被告知某種變化，這類變化會(huì)把他們從舒適區(qū)中拉出，這類情緒開始滋生和蔓延。人們會(huì)念叨失去之前的種種好處。例如，當(dāng)被重組到一個(gè)新的跨職能團(tuán)隊(duì)時(shí)，人們會(huì)想念他們之前的同事。再比如，對(duì)于負(fù)責(zé)全局?jǐn)?shù)據(jù)建模的團(tuán)隊(duì)來說，每個(gè)服務(wù)團(tuán)隊(duì)負(fù)責(zé)自己的數(shù)據(jù)建模，這對(duì)他們是一種威脅。
2. 中立區(qū)：處理新舊工作方式交替過程中，人們普遍會(huì)對(duì)新的工作方式無所適從。人們開始糾結(jié)并必須要學(xué)習(xí)處理新工作的方式。
3. 新的開始：最終階段，人們開始發(fā)自內(nèi)心地?zé)崆閾肀碌墓ぷ鞣绞剑⑶议_始體驗(yàn)到新工作方式所帶來的種種好處。

本書介紹了如何管理轉(zhuǎn)型過程中每個(gè)階段的問題，提高轉(zhuǎn)型的成功率。FTGO顯然正在單體地獄中煎熬，急切地需要轉(zhuǎn)型到微服務(wù)架構(gòu)。他們也需要對(duì)組織結(jié)構(gòu)和開發(fā)流程做出調(diào)整。為了成功地實(shí)現(xiàn)這一切，F(xiàn)TGO必須認(rèn)真面對(duì)這些轉(zhuǎn)型模式和所有可能的情緒化反應(yīng)。

總結(jié)

• 單體架構(gòu)模式將應(yīng)用程序構(gòu)建為單個(gè)可部署單元。
• 微服務(wù)架構(gòu)模式將系統(tǒng)分解為一組可獨(dú)立部署的服務(wù)，每個(gè)服務(wù)都有自己的數(shù)據(jù)庫。
• 單體架構(gòu)是簡(jiǎn)單應(yīng)用的不錯(cuò)選擇，微服務(wù)架構(gòu)通常是大型復(fù)雜應(yīng)用的更好選擇。
• 微服務(wù)架構(gòu)使小型自治團(tuán)隊(duì)能夠并行工作，從而加快軟件開發(fā)的速度。
• 微服務(wù)架構(gòu)不是銀彈：它存在包括復(fù)雜性在內(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和小而自治的團(tuán)隊(duì)。
• 不要忘記采納微服務(wù)過程中的人性層面。你需要考慮員工的情緒才能成功轉(zhuǎn)換到微服務(wù)架構(gòu)。