康威定律

微服務簡單說

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. 不敢作新的技術的嘗試
   因爲咱們的項目是單體的架構，項目成員必須使用同一種技術棧進行項目的開發。切換新的技術和語言要對整個項目進行重頭開發。這使得嘗試新的語言變得比較困難。

   微服務架構好處

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

8. 因爲拆分爲多個小服務每一個服務比較容易理解
9. 每一個微服務有啓動調試速度快，無需過多的等待編譯時間
10. 咱們能夠針對每一個服務方便進行橫向和縱向的擴張
11. 根據服務特色 針對性的進行服務器硬件升級
12. 單個服務的升級不要其餘服務的協調
13. 服務拆分和團隊組織更匹配

14. 嘗試新的技術變得更容易

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到微服務