image.png

該書作者以FTGO應(yīng)用程序從單體應(yīng)用逐步演進為微服務(wù)架構(gòu)為例子，解釋了微服務(wù)架構(gòu)的設(shè)計模式和主要概念。

單體地獄

FTGO的應(yīng)用程序是一個單體的，它由一個單一的JAVA WAR文件構(gòu)成。隨著時間的推移，應(yīng)用程序變得異常復(fù)雜，且難以維護和擴展。這是一個典型泥球模式（the Big Ball of Mud Pattern， 隨意架構(gòu)的、龐大的、草率的、布滿了膠帶和線路，如同個意大利面條一般的代碼叢林）。

但單體應(yīng)用并非一無是處，在項目早起單體應(yīng)用體相對較?。?/p>

• 開發(fā)簡單
• 易于大規(guī)模更改：船小好調(diào)頭
• 測試簡單
• 部署簡單
• 橫向擴展簡單：部署多個實例，一個負載均衡器進行調(diào)度

可怕的是隨著時間的推移，單體應(yīng)用逐漸發(fā)展為單體地獄。

• 過度的復(fù)雜性會嚇退開發(fā)者
  系統(tǒng)本身過于龐大和復(fù)雜，開發(fā)者需要對整個系統(tǒng)都有清楚的了解。對于項目中的老鳥，這沒有問題。但對于新成員來說，就是噩夢。一個惡性循環(huán)隨之產(chǎn)生，代碼庫難以理解，開發(fā)容易出錯，hotfix的補丁又使代碼庫更為復(fù)雜和難懂。

• 開發(fā)速度緩慢
  項目太大，每次編輯、構(gòu)建、運行、測試都變得異常艱難，嚴重影響團隊開發(fā)效率。

• 從代碼提交到實際部署周期過長，容易出問題
  多個團隊使用一個repo進行開發(fā)，使用主干開發(fā)，團隊成員會互相影戲；使用feature開發(fā)，又會面臨代碼的合并。即使合并成功，之后的測試也需要耗費極大時間和精力，一個issue的出現(xiàn)需要多個團隊，協(xié)同排查。

• 難以擴展
  系統(tǒng)中各個模塊對于服務(wù)器性能要求各不相同，單體應(yīng)用的系統(tǒng)就需要滿足所有模塊的需求，這對服務(wù)器的性能也提出了挑戰(zhàn)。

• 交付可靠的單體應(yīng)用是一個挑戰(zhàn)
  單體應(yīng)用由于過于龐大，難以充分測試，issue將會被帶到線上環(huán)境。另外，單體應(yīng)用對于故障也缺乏隔離，應(yīng)用中的一個模塊出現(xiàn)故障，如內(nèi)存泄漏，將會導(dǎo)致整個應(yīng)用無法使用。

• 長期依賴過時技術(shù)棧
  必須使用同一套技術(shù)棧，任何的升級和改造，都可能引起致命的錯誤。

微服務(wù)架構(gòu)

今天，針對大型復(fù)雜應(yīng)用的開發(fā)，越來越多的共識趨向于考慮使用微服務(wù)架構(gòu)。

有人把，微服務(wù)架構(gòu)，定義為：面向服務(wù)的架構(gòu)，它們由松耦合和具有邊界上下文的元素組成。而作者受到擴展立方體的啟發(fā)，則將微服務(wù)定義為：把應(yīng)用程序功能性分解為一組服務(wù)的架構(gòu)風格。

《The Art of Scalability》中提到了一個三位可擴展模型，擴展立方體。

image

X軸擴展：主要是面向單體應(yīng)用程序的擴展，多個實例通過負載均衡器去分配請求，主要用于提升系統(tǒng)吞吐量和可用性。常見的方式：集群。

Z軸擴展：也需要實現(xiàn)單體應(yīng)用的多個實例，但不同的是實例之間并不是相同的，每個實例只負責數(shù)據(jù)集的一個子集，路由網(wǎng)關(guān)通過請求的屬性將請求路由到特定的實例，主要用于提升系統(tǒng)的吞吐量，常見方式：分庫分表。例如以userId為標志，不同的用戶分配到不同的實例上。

Y軸擴展：X軸擴展和Z軸擴展都可以提升系統(tǒng)的吞吐量，但并沒有解決日益增長的開發(fā)問題和應(yīng)用復(fù)雜性的問題，Y軸擴展通過拆分功能解決此類問題，主要用于降低系統(tǒng)耦合性，常見方式：微服務(wù)。

微服務(wù)架構(gòu)的優(yōu)勢

1. 使得大型應(yīng)用可以做到持續(xù)交付和持續(xù)部署。
   能夠做到持續(xù)交付和持續(xù)部署，這主要是由于微服務(wù)架構(gòu)的特性所致：
   • 可測試性：服務(wù)相對較小，方便測試
   • 可部署性：每個服務(wù)都可以獨立部署，
   • 團隊自主性和松散耦合：服務(wù)之間的隔離性使得每個團隊可以獨立于其他團隊，開發(fā)、部署、擴展他們的服務(wù)。

持續(xù)交付和持續(xù)部署，也帶來了一些業(yè)務(wù)價值：

• 所短新功能上市時間，快速獲得用戶反饋
• 整個系統(tǒng)可靠性提升
• 團隊滿意度提高

2. 每個服務(wù)相對較小且易于維護
3. 服務(wù)可以獨立擴展，無論在X軸上還是Z軸上，都可以方便擴展。
4. 更好的容錯性，故障隔離。
5. 易于使用新技術(shù)

微服務(wù)架構(gòu)的劣勢

1. 服務(wù)拆分和定義是一項挑戰(zhàn)
2. 分布式系統(tǒng)更為復(fù)雜，使得開發(fā)、測試、部署都更困難
3. 開發(fā)跨多個服務(wù)的功能時，需要多個團隊協(xié)同開發(fā)。需要制定開發(fā)計劃，按照服務(wù)依賴關(guān)系，依次開發(fā)和部署。
4. 微服務(wù)架構(gòu)不適用于軟件開發(fā)的所有階段。初創(chuàng)的系統(tǒng)，應(yīng)該先使用單體應(yīng)用，快速迭代和試錯。一開始就是用微服務(wù)架構(gòu)，反而會拖慢開發(fā)效率。在完成MVP后，就要逐步轉(zhuǎn)向微服務(wù)架構(gòu)。

微服務(wù)架構(gòu)的模式語言

什么是模式和模式語言？

模式：針對特定上下文中發(fā)生的問題的可重用解決方案。
模式語言：解決特定領(lǐng)域內(nèi)問題的相關(guān)模式的集合。
--建筑理論家，Christopher Alexander

《Design Patterns: Elements of Reusable Object-Oriented Software》的作者受到Christopher Alexander的啟發(fā)寫了這本書。書中，描述了面向?qū)ο笤O(shè)計模式的合計。Christopher Alexander理解：軟件模式就是通過定義一組互相協(xié)作的軟件元素來解決軟件架構(gòu)或設(shè)計問題。

常用的模式結(jié)構(gòu)包含三個方面：

• 需求（Forces）：必須解決的問題。需求描述必須解決的問題和圍繞這個問題的特定上下文環(huán)境。
• 結(jié)果上下文（Resulting context）：采用模式后可能帶來的后果
  • 好處：這個模式的優(yōu)勢和解決了什么問題
  • 弊端：這個模式的劣勢和它沒有解決哪些需求
  • 問題：新引入的問題
• 相關(guān)模式（Related patterns），描述了這個模式和其他模式之間的關(guān)系。
  • 前導(dǎo)：催生這個模式的需求的模式。
  • 后續(xù)：用來解決當前模式引入的新問題的模式。例如引入微服務(wù)，那就需要一系列后續(xù)模式（服務(wù)發(fā)現(xiàn)，斷路器），解決微服務(wù)帶來的問題。
  • 代替：可以互相替換的另外的解決方案。單體架構(gòu)和微服務(wù)架構(gòu)師互為代替的模式。
  • 泛化：針對一個問題的一般性解決方案
  • 特化：針對一個問題的具體解決方案

把解決類似問題的模式組成，一組模式。通過這些關(guān)系相關(guān)的模式集合形成所謂的模式語言。模式語言中的模式共同解決特定領(lǐng)域中的問題。

微服務(wù)架構(gòu)的語言模式

image.png

微服務(wù)之上：流程和組織

除了擁有正確的架構(gòu)之外，成功的軟件開發(fā)還需要在組織、開發(fā)和交付流程方面做一些工作。

人多并不一定力量大，團隊規(guī)模增加，也會伴隨著其他問題的出現(xiàn)?！度嗽律裨挕愤@本書中提到的，溝通成本會隨著團隊的規(guī)模呈O(N2)的速度上升。

解決之道是把大團隊拆分成一系列小團隊。每個團隊都足夠小，人員規(guī)模為8～12人。

• 每個團隊都有一個明確的職責：開發(fā)并且可能也負責運維一個或者多個服務(wù)，這些服務(wù)實現(xiàn)了一個或多個業(yè)務(wù)能力。
• 這些團隊都是跨職能的。
• 他們可以獨立地完成開發(fā)、測試和部署等任務(wù)，而不需要頻繁地與其他團隊溝通或者協(xié)調(diào)。

落地微服務(wù)架構(gòu)，需要考慮到康威定律(Conway's law)。

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

翻譯成中文就是：設(shè)計系統(tǒng)的組織....往往被組織的架構(gòu)所限制，最終設(shè)計的結(jié)果是這些組織的溝通結(jié)構(gòu)的副本。換句話說，應(yīng)用程序的架構(gòu)往往反映了開發(fā)它的組織的結(jié)構(gòu)。所以除了軟件結(jié)構(gòu)的改變，同時

• 需要對軟件開發(fā)和交付流程進行改造。Scrum或Kanban這類敏捷開發(fā)和不數(shù)時間，持續(xù)交付（之需交付能夠以刻之需的方式安全、快速的將所有類型的變更，包括新功能、配置更改、錯誤修復(fù)和試驗，交付到生產(chǎn)環(huán)境或用戶手中）和持續(xù)部署。
• 需要改變組織結(jié)構(gòu)和開發(fā)的流程。