微服務架構與持續交付關係
本文主要參考《微服務架構與實踐》（王磊，博文視點，2016.1），架構師必看：微服務架構綜述 - 帳前卒 專欄 - CSDN部落格 https://blog.csdn.net/cctt_1/article/details/78344253，https://www.jianshu.com/p/be52eeb5e9a5 簡書-微服務架構，對應探討。
一、微服務架構基礎
1、概述
傳統主流的系統架構，雖然在邏輯上是分層的，但在構建和部署上並不是分層的（注：參考書是說物理上不分層），即使物理上按照分散式部署，只是解決負載均衡和水平擴充套件。這種功能集中、程式碼和資料中心化、一個釋出包、部署後執行在同一程序的應用程式，可以稱為單塊架構
微服務架構是一種架構模式，它提倡將單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。每個服務執行在其獨立的程序中，服務與服務間採用輕量級的通訊機制互相協作（通常是基於 HTTP 協議的 RESTful API）。每個服務都圍繞著具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。另外，對具體的服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建 。（摘自王磊的《微服務架構與實踐》）
簡而言之，有兩個關鍵點：一是把一個大型的單個應用程式和服務拆分為數個甚至數十個的支援微服務，它可擴充套件單個元件而不是整個的應用程式堆疊，從而滿足服務等級協議。二是採用輕量級的通訊機制互相協作，這個是其與SOA差別的重要地方。
2、 單塊架構和微服務架構比較
紅色代表優勢，黑色為劣勢，棕色為不確定。
|
單塊架構 |
微服務架構 |
|
|
|
易於部署（打好的一個軟體包釋出） 易於水平伸縮（應對使用者數暴漲，建立伺服器節點擴充套件即可） |
部署自動化要求高 （分散式系統複雜度、服務作為元件、技術多樣性） |
|
維護成本大 |
維護方便（基礎較好情況下） |
|
持續交付週期長（所有功能互相牽扯--分層多，塊頭大） |
持續交付週期短（服務作為元件，應用可以獨立部署；業務資料獨立；圍繞業務組織團隊） |
|
業務功能可擴充套件性差（垂直業務功能擴充套件困難，部分程式的功能水平擴充套件也困難）一起構建和部署--分層多，塊頭大） |
擴充套件性好，水平伸縮不如單塊式架構（服務作為元件，應用可以獨立部署；業務資料獨立；演進式開發） |
|
新人培養週期長（必須熟悉全部業務和環境--分層多，塊頭大） |
人員團隊更穩定、更持續發展（圍繞業務組織團隊、關注產品而非專案） |
|
可能會需要做好組織的架構調整和文化轉型（DevOPS） |
|
|
技術選型成本高（新技術不好進來，基本只能採用統一平臺才能通訊 |
技術多樣性好（獨立元件） |
3、SOA與微服務比較
本質上微服務架構也是SOA，但是和傳統的SOA實現比較，有很大不同（注：其實應該考慮到90年代的業務、技術、軟硬體環境和現在的差異，才能深刻體會時代的洪流）：
| 傳統的SOA實現 | 微服務實現 |
| 企業級，自頂向下開展實施 | 團隊級，自底向上開展實施 |
| 服務由多個子系統組成，粒度大 | 一個系統被拆分成多個服務，粒度細 |
| 企業服務匯流排，集中式的服務架構 | 無集中式匯流排，鬆散的服務架構 |
| 整合方式複雜（ESB/WS/SOAP） | 整合方式簡單（HTTP/REST/JSON） |
| 單塊架構系統，相互依賴，部署複雜 | 服務能獨立部署 |
二、微服務架構與持續交付的關聯
1、微服務架構產生的背景
最根本的就是，時代的發展。一，網際網路行業的快速發展，帶來的需求變化： 對時間和速度追求，快是關鍵，帶來的需求變更多，系統要求可伸縮、高可用，不斷迭代更新等。二、技術層面的發展，軟體開發模式例如敏捷、精益方法論的深入人心，硬體技術和基礎設施層面，伴隨網路基礎設施的高速發展和硬體計算能力提升，帶來的雲端計算服務、容器虛擬化技術發展。
單塊架構就面臨一系列困難，上面說的各項弱點被放大，而微服務架構的維護方便、持續交付週期短、擴充套件性好、技術多樣性好等優勢充分體現。
微服務產生關鍵背景，就是由於持續交付的需要。顯然持續交付對微服務架構成立起到支撐，必須做到：1、版本控制，否則服務依賴完全亂套；2、自動化測試，多個服務間的依賴測試，靠人工顯然困難；3、自動構建；4、整合自動部署。