微服務簡單說

1 微服務架構定義

微服務一詞源自 馬丁·福勒（Martin Fowler) 在2014 年的一篇博客：Microservices 該文章中對微服務定義如下：

the microservice architectural style [1] is an approach to developing
a single application as a suite of small services, each running in its
own process and communicating with lightweight mechanisms, often an
HTTP resource API. These services are built around business
capabilities and independently deployable by fully automated
deployment machinery. There is a bare minimum of centralized
management of these services, which may be written in different
programming languages and use different data storage technologies.

微服務架構風格是將單體應用程序 拆分為多個小型的服務 並且每個服務在獨立的進程中。服務間的通信采用輕量級通信的機制 通常是HTTP方式提供API 來實現。這些服務通過自動化部署的方式進行獨立部署。每個服務可以根據自身的特點采用不同的語言開發同時也可以使用不同的數據存儲技術。

服務的拆分是基於業務和公司的組織架構進行拆分，也稱之為康威定律。

另外 Adrian Cockcroft 更是將微服務比喻成 細粒度的 SOA（面向服務的架構）

2 單體架構定義

雖然我對微服務的定義進行解釋，但是如果想更深層次的了解微服務 我們不得不先從單體架構說起。

單體架構就是 將 web項目應用實例 的所有功能模塊打包到一起並放在一個web容器中運行的系統。 例如 我們的一個電商網站 其中包含 商品模塊 訂單模塊 等我們可以通過maven多模塊 或者 放入到不同的包中來區分。 但是最終還是將其打包成一個war 部署在我們的tomcate中。

單體架構好處

1. IDE友好支持：
   NetBeans、Eclipse、IntelliJ 這樣工具專門為單體應用設計。 你只需要使用其中一種 就可以在你本地機器上進行 開發 調試 部署。
2. 方便測試：
   測試人員只需要測試單個應用即可。新開發的功能部署完成就可以測試所有的功能。
3. 容易部署：
   打包成war包放入我們的服務器 或者打包成一個課執行的jar 執行jar包即可。

單體架構缺點

隨着業務規模的發展我們的單體架構會出現如下問題

1. 項目越來越復雜（隨着業務發展模塊會越來越多）
2. 項目整體編譯耗時長
   我們開發人員在進行開發和調試過程中需要化大量的時間在無用的重新編譯上。
3. 合並代碼容易產生沖突
   在進行多個需求並行開發時每個分支會涉及到很多相同的代碼以至於極易產生沖突。
4. 新功能上線周期長
   每次進行新功能的開發和bug修改很難預估對項目整體的影響，那就需要進行全部功能的測試。然而這個測試是比較耗時的 導致我們上線時間的延長。
5. 項目穩定性差
   項目中不重要的功能模塊出現bug會導致整個服務癱瘓。
6. 只能做橫向擴展
   由於整個功能模塊都在一個實例中，我們對整個服務實例進行擴展，無法針對具體的功能進行垂直的拆分。也無法對某個功能進行單獨的硬件升級。
7. 不敢做新的技術的嘗試
   由於我們的項目是單體的架構，項目成員必須使用同一種技術棧進行項目的開發。切換新的技術和語言要對整個項目進行重頭開發。這使得嘗試新的語言變得比較困難。

微服務架構好處

簡單點說微服務的好處正式用來彌補單體架構的不足的。具體的好處如下：

1. 由於拆分為多個小服務每個服務比較容易理解
2. 每個微服務有啟動調試速度快，無需過多的等待編譯時間
3. 我們可以針對每個服務方便進行橫向和縱向的擴張
4. 根據服務特點 針對性的進行服務器硬件升級
5. 單個服務的升級不要其他服務的協調
6. 服務拆分和團隊組織更匹配
7. 嘗試新的技術變得更容易

4 微服務架構與SOA的區別

1. SOA是面向服務架構。而微服務也是面向服務架構。
2. 微服務架構可以理解成更細力度的 SOA。
3. 微服務架構強調要采用輕量級的通信。
4. 微服務架構強調的是基於業務做細粒度的拆分和部署。
5. 微服務構架強調每個服務有獨立的數據庫。

我的個人理解就是微服務是在SOA 上進一步的延伸而產生的新名詞。

5 微服務面臨的困難

微服務不是銀彈，使用微服務業務也有困難需要解決。當我們將服務拆分多個服務 可能是幾十個服務 也有可能是上百甚至上千個服務。這個多服務如何區治理就是我們要面臨的困難，具體細分的話包含如下內容：

1. 單體系統架構如何拆分
2. 多個服務之間的通信
3. 服務API文檔
4. 服務注冊發現
5. 服務負載均衡
6. 服務網關
7. 分布式追蹤
8. 日志聚合
9. 集中配置
10. 容錯限流
11. 服務自動化部署
12. 監控告警

如果你的項目代碼模塊 代碼邏輯 比較混亂是不能夠通過微服務來解決的。引入微服務需要對整個項目的功能進行梳理划分后才能在考慮切換為微服務。

參考文獻

和堅 簡書博主當我們在說微服務治理的時候究竟在說什么：
Rick Osowski：微服務介紹
承諾一時的華麗 簡書博主：Go - Micro微服務框架實踐 - 相關概念（六）
每日一拾 簡書博主：架構設計漫步：從單體架構、SOA到微服務