微服務初步理解

本文參考書籍

https://github.com/oopsguy/microservices-from-design-to-deployment-chinese

 

微服務簡介

單體應用

在項目開發啓動階段，好比開發一個電商系統，該系統包括了訂單模塊、商品搜索模塊、用戶模塊和後臺等系統，啓動階段雖然按照業務邏輯分模塊開發，可是最終成功上線運行的是一個單體應用，在項目開發的初期，單應用的架構有助於快速更改業務流程，快速迭代，當項目發展到必定時期後，一個龐大、複雜的單體，對於新的功能的開發可能就是陷入了很大的困境，不管是修復線上小的問題仍是新需求的開發都設計到整個項目的從新部署和測試，而且下降了開發的效率。

當項目發展到必定階段後，不一樣模塊存在資源需求的衝突，單體應用可能難以擴展；當單體應用在線上實際運行過程當中，任何一個模塊出現一個bug，均可能會致使整個單體應用不可用。當須要對項目中開發的某個模塊進行灰度發佈的時候，單體應用每每也不能知足很好的擴展性。那麼如何進行改進呢？

微服務

經過將應用程序分解成一套比較小的互聯服務，即微服務架構模式。一個服務一般實現了一組不一樣的特性或功能，例如用戶模塊等。每個微服務都是一個迷你應用，都包括了本身實現的業務邏輯，暴露了對外服務的接口，服務可單獨部署與開發。

應用程序的每一個功能區域都由相應的微服務實現，每一個後端服務暴露相關接口，服務之間可使用異步或基於消息的通訊，一些API也暴露給移動端應用，可是應用不能直接訪問後端服務，它們之間的通訊都由一個API網關的中介負責，API網關負責負載均衡、緩存、訪問控制、API計量和監控。微服務架構模式影響到了應用程序與數據局之間的關係，與其餘共享單個數據庫模式服務有所不一樣，其每個服務都由本身的數據庫模式，這樣就能夠實現鬆耦合的結構，而且服務可根據自身的需求選擇不一樣的數據庫，以達到最佳的適用場景。每一個服務也能夠選用不一樣的技術棧來實現不一樣場景的業務。

微服務優缺點

優勢

1.解決了複雜的問題，將龐大的單體應用分解成一套服務，雖然功能數量不變，可是應用程序已經被分解成可管理的服務，每一個服務都有一個明肯定義的API，如RPC或消息驅動，每一個服務能更快地開發並更容易理解與維護。

2.每一個服務均可以選用不一樣的技術棧，由不一樣的團隊開發維護。

3.每一個服務均可以獨立部署。

4.微服務使得每一個服務都可以獨立擴展。

缺點

1.因爲微服務是一個分佈式系統，其使得總體項目變得複雜，開發者須要選擇和實現基於消息或者rpc的進程間通訊機制，此外，因爲目標請求可能延遲或不可用，還須要額外的處理機制保證通訊。

2.微服務面臨着分區數據庫問題，在基於微服務的應用程序中，須要更新不一樣服務的數據庫，通常不會選擇分佈式事務，不只由於CAP定理，也是由於若是使用了NoSql數據庫和消息代理，就沒有很好的支持，最後使用最終一致性方法，這對開發人員來講更具挑戰性。

3.微服務的測試工做相對複雜，一個微服務的測試須要啓動該服務所依賴的全部服務，增大了測試的難度。

4.微服務的部署工做也相對複雜，一個單體應用能夠很容易地部署到基於傳統負載均衡器的一組服務器上，相比之下，微服務應用程序一般由大量的服務此次，每一個服務均可以有多個運行時實例，這對服務的發現機制，服務的部署監控和擴展都提出了更高的要求。

總結

構建微服務本質上須要考慮的方向不少，須要根據當前項目的業務緊密相關聯，單體應用適用於簡單、輕量級的應用程序，若是應用發展到必定規模，微服務架構雖然複雜、維護大，可是保證了業務的靈活性和擴展性。如何選擇須要實際業務進行選擇。