第一章 逃離單體地域
- 邁向單體地獄的漫長旅途
- 拯救之道：微服務架構
- 1. 擴展立方體和服務
- 2. 微服務架構作為模塊化的一種形式
- 3. 每個服務都擁有自己的資料庫
- 4. FTGO的微服務架構
- 微服務架構的好處和弊端
- 1. 微服務架構的好處
- 2. 微服務架構的弊端
- 微服務架構的模式語言
- 微服務之上：流程和組織
- 1. 進行軟體開發和交付的組織
- 2. 進行軟體開發和交付的流程
邁向單體地獄的漫長旅途
單體架構存在著巨大的局限性，渴求成功的應用程式，往往都不斷地在單體架構的基礎之上擴展，每一次開發沖刺(Sprint)，開發團隊就會實作更多的功能，顯然這會導致代碼庫膨脹，而且，隨著公司的成功，研發團隊的規模不斷壯大，代碼庫規模變大的同時，團隊的管理成本也不斷提高，
那個曾經小巧的、簡單的、由一個小團隊開發維護的應用程式，已經演變成一個由大團隊開發的巨無霸單體應用程式，開發變得緩慢和痛苦，敏捷開發和部署已經不可能，
- 過度的復雜性會嚇退開發者
- 開發速度緩慢
- 從代碼提交到實際部署的周期很長，而且容易出問題
- 難以擴展
- 交付可靠的單體應用是一項挑戰
- 需要長期的依賴某個可能已經過時的技術堆疊
拯救之道：微服務架構
今天，針對大型復雜應用的開發，越來越多的共識趨向于考慮使用微服務架構，但微服務到底是什么？不幸的是，微服務這個叫法本身暗示和強調了尺寸，
1. 擴展立方體和服務
這個模型描述了擴展一個應用程式的三種維度:X、Y和Z，
- X軸擴展:在多個實體之間實作請求的負載均衡
- Z軸擴展:根據請求的屬性路由請求
- Y軸擴展:根據功能把應用拆分為服務
服務本質上是一個麻雀雖小但五臟俱全的應用程式，它實作了一組相關的功能，例如訂單管理、客戶管理等，服務可以在需要的時候借助X軸或Z軸方式進行擴展，例如,訂單服務可以被部署為一組負載均衡的服務實體，
我對微服務架構的概括性定義是：把應用程式功能性分解為一組服務的架構風格，請注意這個定義中并沒有包含任何與規模有關的內容，重要的是,每一個服務都是由一組專注的、內聚的功能職責組成，
2. 微服務架構作為模塊化的一種形式
模塊化是開發大型、復雜應用程式的基礎，應用程式規模太大很難作為一個整體開發，也很難讓一個人完全理解，為了讓不同的人開發和理解，大型應用需要拆分為模塊，
微服務架構使用服務作為模塊化的單元，服務的API為它自身構筑了一個不可逾越的邊界,你無法越過API去訪問服務內部的類，這與采用Java包的單體應用完全不同，因此模塊化的服務更容易隨著時間推移而不斷演化，微服務架構也帶來其他的好處,例如服務可以獨立進行部署和擴展，
3. 每個服務都擁有自己的資料庫
微服務架構的一個關鍵特性是每一個服務之間都是松耦合的，它們僅通過API進行通信，實作這種松耦合的方式之一，是每個服務都擁有自己的私有資料庫，在開發階段，開發者可以修改自己服務的資料庫模式，而不必同其他服務的開發者協調，在運行時,服務實作了相互之間的獨立，服務不會因為其他的服務鎖住了資料庫而進入堵塞的狀態，
4. FTGO的微服務架構
前端服務包括 API Gateway和餐館的Web用戶界面(Restaurant Web UI)， API Gateway扮演了一個對外的角色，它提供了供消費者和快遞員的移動應用程式使用的 REST API，餐館的網頁界面實作了餐館用來管理選單和訂單流程的Web用戶界面，
FTGO應用程式的業務邏輯由眾多后端服務組成，每個后端服務都有一個 REST API和它自己的私有資料庫，后端服務包括以下內容:
- Order Service:管理訂單，
- Delivery Service:管理從餐館到客戶之間的訂單派送(送餐)，
- Restaurant service:維護餐館有關的資訊，
- Kitchen service:管理訂單的準備程序，
- Accounting service:處理賬單和付款，
每個服務及其API都有非常清晰的定義，每個都可以獨立開發、測驗、部署和擴展，此外,該架構在保持模塊化方面做得很好，開發人員無法繞過服務的API并訪問其內部組件，
微服務架構的好處和弊端
1. 微服務架構的好處
- 使大型的復雜應用程式可以持續交付和持續部署，
- 每個服務都相對較小并容易維護，
- 服務可以獨立部署，
- 服務可以獨立擴展，
- 微服務架構可以實作團隊的自治，
- 更容易實驗和采納新的技術，
- 更好的容錯性，
2. 微服務架構的弊端
- 服務的拆分和定義是一項挑戰，
- 分布式系統帶來的各種復雜性，使開發、測驗和部署變得更困難，
- 當部署跨越多個服務的功能時需要謹慎地協調更多開發團隊，
- 開發者需要思考到底應該在應用的什么階段使用微服務架構，
微服務架構的模式語言
- 服務拆分的相關模式
- 通信的相關模式
- 實作事務管理的資料一致性相關模式
- 在微服務架構中查詢資料的相關模式
- 服務部署的相關模式
- 可觀測性的相關模式
- 實作服務自動化測驗的相關模式
- 解決基礎設施和邊界問題的相關模式
- 安全相關的模式
微服務之上：流程和組織
對于大型和復雜的應用程式，微服務架構往往是最佳的選擇，然而，除了擁有正確的架構之外，成功的軟體開發還需要在組織、開發和交付流程方面做一些作業，
1. 進行軟體開發和交付的組織
成功往往意味著研發團隊規模的擴大，一方面，這是個好事，因為人多力量大，但是團隊大了以后，正如 Fred Brooks在《人月神話》這本書中提到的，溝通成本會隨著團隊的規模呈O(N2)的速度上升，如果團隊太大,由于溝通成本過高,往往會使得團隊的效率降低，
想想看，如果每天早上的站會規模達到20人會是怎樣？
解決之道是把大團隊拆分成一系列小團隊，每個團隊都足夠小，人員規模為8~12人，每個團隊都有一個明確的職責:開發并且可能也負責運維一個或者多個服務,這些服務實作了一個或多個業務能力，這些團隊都是跨職能的，他們可以獨立地完成開發、測驗和部署等任務,而不需要頻繁地與其他團隊溝通或者協調，
2. 進行軟體開發和交付的流程
采用微服務架構以后,如果仍舊沿用瀑布式開發流程,那就跟用一匹馬來拉法拉利跑車沒什么區別——我們需要充分利用微服務帶來的各種便利，如果你希望通過微服務架構來完成一個應用程式的開發,那么采用類似 Scrum或 Kanban這類敏捷開發和部署實踐就是必不可少的，同時也需要積極實踐持續交付和持續部署,這是 DevOps中的關鍵環節，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/258402.html
標籤：其他
上一篇：maven常用依賴大全