微服務架構系統靈活性，健壯性，擴充套件性好，特別適合需求變化迅速的場景。但系統複雜度高，部署，管理難度大。微服務除了開發期框架之外，還有需要一系列的執行期中介軟體支撐，如API閘道器，服務註冊中心，統一配置中心等。 目前國內比較成熟的吧，東軟有一支團隊在做，他們網站是 https://platform.neusoft.com/

從傳統單體架構轉向微服務，是隨著業務應用系統愈來愈複雜與技術不斷交織演進的結果。

微服務架構簡介微服務是架構層的一個概念，透過分解（業務單元），將專案拆解出 n 個單元，互相沒有強依賴關係（解耦），自我準備需要的依賴條件，進而達到可以獨立執行，不再受環境與地點上的限制。微服務的由來微服務最早由 Martin Fowler 與 James Lewis 於 2014 年共同提出，微服務架構風格是一種使用一套小服務來開發單個應用的一種方式，每個服務執行在自己的程序中，並使用輕量級機制通訊，通常是 HTTP API，這些服務基於業務能力構建，並能夠透過自動化部署機制來獨立部署，這些服務使用不同的程式語言實現，以及不同資料儲存技術，並保持最低限度的集中式管理。傳統的單體應用模式我們在以往的傳統應用模式下，大致是所有的功能都整合在同一個應用中，這種模式一般被稱為單體式開發，即所有的功能打包在一個 war 包內，然後部署在 jee 中，這裡麵包含了所有的業務邏輯，觸發器，大部分的還包含了 ui，如下圖：這樣的模式下暴露出了他所致命的缺點：程式碼管理比較難，因為大家都在同一個工程下，會經常的發生衝突新人不太容易上手，因為耦合性太高，調查一個問題時往往會牽扯更多的功能打包危險度大，往往只是提交很小一部分的修改卻需要全量打包運維危險度大，可能只是某一個功能崩潰了就會導致整個系統癱瘓不容易擴充套件，如果只是一個功能的請求量突增，不容易擴充套件部署要求較高，這樣的應用往往需要高配置的主機來承載微服務的應用模式我們在做架構設計的時候，常常需要遵守三個標準（敏捷性、使用者體驗、成本），基於微服務的架構設計目的就是有效的拆分應用，每個應用單獨管理，進而實現敏捷開發和部署，如下圖： ąpøDB İȚ DB由一些獨立的應用組合成一個軟體系統，每個服務獨立執行，跑在自己的微環

境中，每個服務獨立開發可以按照業務單元進行拆分，實現了跨組織誇地域協同的問題，多個服務採用分散式進行管理，且具有強隔離性。

微服務架構在微服務架構中，除了每個業務單元的服務外，就是那些服務治理元件了，比如：服務中心、服務消費、負載均衡、斷路器、智慧路由、配置管理等，這些個元件互相配合再加上業務的各個微服務，共同組建了一個微服務系統，一個簡單的微服務系統如下：

使用者透過客戶端發起請求，nginx 負載到某個 zuul 上然後轉發到相應的微服務上，微服務間透過 rpc 或者 mq 進行通訊，透過配置服務獲取配置資料，最終將整合後的結果返回給使用者。

微服務的優缺點微服務架構之所以流行起來，與他的這些優點密不可分，比如：他將巨大的單體式應用分解出多個服務，解決了複雜性的問題，在總功能不變的情況下，系統被分解成多個可管理的服務，每個服務都用 rpc/mq 來驅動和定義清晰的 api 邊界，為很難實現的功能提供了模組化的解決方案，並且更容易開發和維護。在這樣的架構模式下，可以實現每個服務可由不同的團隊來開發，從而放寬了技術選型，只需提供標準的 restapi 即可，在這種自由模式的開發背景下， 開發者可以選擇較新的技術，由於每個服務的功能很小，所以開發的難度也很低，即使出現了程式碼重寫的問題難度也不是很大。由於微服務採用的是獨立部署，開發者在部署的時候不用考慮其他的服務對自己的影響，這種改變加快了部署速度並減少了部署風險，微服務架構使ci/cd 成為可能。但是微服務也存在一些不足，比如：微服務採用的分散式系統，故而會產生固有的複雜性，開發者需要在 rpc 等訊息傳遞之間完成程序間的通訊，更或者需要用程式碼來解決訊息傳遞過慢或異常的情況。來源於資料庫事務的分佈，以至於我們不能達到強一致性，只能的選擇最終一致性當我們對某個服務的某個 api 進行測試的時候，需要保證這個服務所依賴的其他服務都是正常開啟的狀態，這給測試帶來了複雜性的問題。

Fred Brooks 曾寫過 there are no silver bullets，像其他科技一樣，微服務也有很多不足，所以在做系統架構之前首先要確定最終的目的，是否有效的拆分應用，是否需要實現敏捷開發、敏捷部署。

思想上的轉變微服務對於我們來說，技術上不是問題，更多的是思維邏輯，對於微服務架構我們應該主動的在思維上進行轉變。主要有一下幾點：應用的單元是業務邏輯，按照業務進行服務的拆分做有生命的產品，而不是專案培養團隊內部核心人員，微服務架構師，全棧專家單一職責的原則，每個服務只幹一件事情部署方式向 docker 轉型開發模式向 devops 轉型同時，對於開發同學，有這麼多的中介軟體和強大的 PE 支援固然是好事，我們也需要深入去了解這些中介軟體背後的原理，知其然知其所以然。最後，一般提到微服務都離不開 DevOps 和 Docker，理解微服務架構是核心， devops 和 docker 則是工具，是手段。