## **逃離單體地獄** ## 泥球模式 * 把這種軟件比喻成“隨意架構的，龐大的，草率的”布滿了膠帶和線路，如同意大利面條一般的代碼叢林。軟件交付的步伐已經放緩，更糟糕的是，應用程序是使用一些已經過時的框架編寫的。 ## 典型的分層模塊化企業級java應用 * 他由業務邏輯組成，業務邏輯外面是實現用戶界面的適配器和與外部系統的接口。 * 業務邏輯有包含了服務和領域對象的模塊組成，一些典型的模塊若干適配器來完成與外部系統的對接工作，包括RESTAPI和web頁面適配器。 *單體軟件架構風格： 一個系統應用被作為單一的單元打包和部署->部署運行在Tomcat上 ## 單體架構的好處 * 應用的開發很簡單，IDE和其他開發工具只需構建這一個單獨的應用程序。 * 易于對應用程序進行大規模的更改（比如更改數據庫模式） * 測試相對簡單直觀，（只需要對RESTAPI進行單元測試） * 部署簡單明了，（以war的形式部署在Tomcat上） * 橫向擴展不費吹灰之力，（一般使用ngixn進行橫向水平擴展） ## 為什么逃離單體煉獄 * 顯示更多功能是時，會導致代碼庫膨脹 * 敏捷開發和部署已經不可能 * 更改的代碼提交到單個源代碼庫，從代碼提交到生產環境，漫長而艱巨，并且涉及到手工測試，應用程序龐大，復雜，不可靠，難以維護 * 過渡的復雜度會嚇退開發者（難以理解它的全部，修復比實現新功能更困難且耗時，而且會形成惡性循環） * 開發速度緩慢，（構建應用程序需要很長時間，從編輯到構建運行再到測試周期時間長） * 從代碼提交到實際部署的周期很長，而且容易出錯。 * 難以擴展（橫向擴展）服務器需要較大的內存 * 交付可靠的單體應用是一項挑戰（錯誤的代碼進入生產環境程序缺少故障隔離，所有的代碼都在一個行程運行） * 需要長期依賴某一個可能已經過時的技術棧 ## **拯救之道 微服務架構** * 軟件架構對功能行需求影響不大，架構的重要行在于它影響了應用的非功能性需求，也稱為質量屬性或者其他的能力。 * 擴展了立方體和服務 * Y軸擴展又稱為功能行分解，用過分解不同功能的方式來實現擴展 * X擴展 又稱為水平復制通過克隆實例的方式擴展(負債均衡) * Z擴展，又稱為數據分區，通過類似客戶ID的方式吧相似的數據分區進行擴展 ## 微服務的定義 * 把應用程序功能性分解為一組服務的架構風格（模塊化） * 微服務架構作為模塊化的一種形式 * 模塊化是開發大型復雜的應用程序的基礎，大型應用需要拆分為模塊 * 微服務架構使用服務作為模塊化的單元，服務的API為自身構筑了一個可逾越的邊界 * 服務可以獨立部署和擴展 * 每個服務都擁有自己的數據庫 * 微服務架構特性是每一個服務之間都是松耦合的，僅通過調用API的方式進行通信，在運行時服務實現類相互之間的獨立，服務不會因為其他服務鎖了數據庫而進入堵塞的狀態 ## 微服務架構的好處 * 使大型的復雜應用程序可以持續交付和持續部署 * 每個服務器都相對較小并容易維護 * 服務可以獨立部署 * 微服務架構可以實現團隊的自活 * 服務可以獨立擴展 * 更容易試驗和采納新的技術 * 更好的容錯性 ## 微服務的弊端 * 服務的拆分和定義是一個有難度的事情（重點） 1. * 服務的拆分沒有一個衡量標準，沒有算法可以完成服務拆分工作，一個不小心就構建出一個分布式的單體應用，一個包含了一大堆互相緊耦合的服務，這樣會把單體架構的和微服務架構兩者合一，弊端基于一身。 2. * 分布式系統帶來的各種復雜性，使開發，測試和部署變得困難 * 多個服務的功能需要協調更多開發人員 * 開發者需要思考應該在應用的什么階段使用微服務架構