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

成都創(chuàng)新互聯(lián)公司服務(wù)項目包括石首網(wǎng)站建設(shè)、石首網(wǎng)站制作、石首網(wǎng)頁制作以及石首網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，石首網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到石首省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

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

圖1

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

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

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

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

解決之道是把大團隊拆分成一系列小團隊。每個團隊都足夠小，人員規(guī)模為8～12人。每個團隊都有一個明確的職責(zé)：開發(fā)并且可能也負(fù)責(zé)運維一個或者多個服務(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ā)、部署和運維擴展他們負(fù)責(zé)的服務(wù)，而不必與其他團隊協(xié)調(diào)。更進(jìn)一步，當(dāng)出現(xiàn)了某個服務(wù)故障或沒有滿足SLA等要求時，對應(yīng)的責(zé)任人(團隊)也非常清楚。

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

02 進(jìn)行軟件開發(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ù)的方式安全、快速地將所有類型的更改(包括新功能、配置更改、錯誤修復(fù)和實驗)交付到生產(chǎn)環(huán)境或用戶手中。

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

網(wǎng)站標(biāo)題：一文了解微服務(wù)的流程和組織
標(biāo)題網(wǎng)址：http://uogjgqi.cn/article/cdcgdhg.html