第一章 為什麼使用微服務架構！
阿新 • • 發佈：2018-12-30
說到微服務架構，我們先不談微服務架構，先說一說單體應用架構。
* 單體應用架構的問題*
一個歸檔包（war包）包含的所有功能的應用程式，通常稱之為單體應用。而架構單體應用的方法論就是單體應用架構。
以一個電影售票系統為例，
相信很多專案都是從單體應用開始的，所有的業務模組耦合在一起，這樣的單體應用比較容易部署，測試，在專案初期確實可以很好的執行。然而隨著需求的增加，越來越多人加入開發團隊，程式碼庫也在飛速膨脹，慢慢的單體應用變得越來越臃腫，可維護性，靈活性逐漸降低，維護成本 越來越高。下面列舉一些單體應用的問題：
- 複雜性高：單體百萬行程式碼的專案包含的模組非常多，模組邊界模糊，依賴關係不明確，程式碼質量殘次不齊，每次改程式碼都心驚膽戰，新增一個簡單的功能都會帶來隱含的缺陷。
- 技術債務：隨著時間的推移，需求和開發人員更迭，會逐漸形成應用程式的技術債務，不壞不修很常見，已使用的系統設計難以被修改
- 部署頻率低：隨著程式碼的增多，構建和部署時間也會增加，每次功能的變更或者修復都會導致重新部署整個應用。全量部署的方式耗時長，影響範圍大，風險高，這使得單體應用部署上線頻率降低，而部署頻率的降低又會導致兩次釋出版本之間大量的功能變更和修改，出錯概率比較高。
- 可靠性差：某個模組bug，死迴圈，oom導致整個應用的崩潰。
- 拓展能力受限：單體應用只能作為一個整體進行拓展，無法根據業務模組的需要進行伸縮，列如：應用中有的是計算密集型，他需要強筋的cpu，有的是io密集型，他需要更大的記憶體。全部部署在一起的話需要綜合考慮。
微服務就解決了上述的問題：
微服務架構風格是一種將一個單一應用程式開發為一組小型服務的方法，每個服務執行在自己的程序中，服務間通訊採用輕量級通訊機制（http）。這些服務公用一個最小型的集中式的管理，服務可用不同語言開發，使用不同資料儲存技術。
微服務的優點：
- 易於開發與維護：一個微服務只關心一個特定的業務功能，所以他業務清晰，程式碼量較少。
- 單個微服務啟動快
- 區域性修改容易部署：微服務只需要部署修改的服務即可
- 技術棧不受限：每個服務可用不同的開發語言
按需伸縮：可根據不同的需求，實現細粒度的拓展。
微服務的缺點：
運維要求高：服務更多意味著運維的投入，單體應用只需保證一個應用的正常執行，而在微服務中，需要保證幾十上百的服務正常執行與協作。
- 分散式固有的複雜性：使用微服務構建的是分散式系統。
- 介面調整成本高：微服務時間通過介面進行通訊，如果修改某一個微服務的api，可能使所有使用該介面的微服務都做調整
- 重複勞動：很多服務使用相同的功能，而這個功能每個服務都寫一次，導致程式碼重複，即便可以開發為公共元件，但可能服務間語言不同導致不通。
微服務架構圖
