目錄
一、爲什麼會出現微服務
（一）單體架構的缺點
1. 項目過於臃腫
所有的功能模塊都集中在同一個項目的時候，整個項目就會變得特別臃腫，開發者維護起來就會特別困難，增加維護成本。
2. 資源無法隔離
整個單體系統的各個模塊都依賴於同樣的數據庫和內存等資源，一旦某個功能模塊對資源使用不當，整個系統都會被拖垮。可能因爲某個模塊的一個小問題導致整個系統都不能用了，改完也需要將整個項目重新部署
3. 無法靈活擴展
當系統的訪問量越來越大的時候，單體系統固然可以進行水平擴展，即部署在多態機器上組成集羣，但是這種擴展並非靈活的擴展。可能我們現在的性能瓶頸只是某個模塊（例如下圖支付模塊），所以我們只希望對該模塊進行水平擴展，但是單體系統無法做到這一點。
（二）微服務的優勢
1. 獨立部署，靈活擴展
在傳統的單體系統中我們部署的單位是整個系統，而微服務則是以每一個獨立的服務單元（獨立組件）爲單位進行部署。這是我們就可以根據不同服務的吞吐量的不同來部署不同數量的服務器。
2. 資源的有效隔離
微服務的設計原則之一就是每一個服務擁有獨立的數據源，假如微服務A想要讀寫微服務B的數據庫，只能調用微服務B對外暴露的接口來完成。這樣有效避免了服務之間爭用數據庫和緩存資源所帶來的問題。如果每個微服務實例在docker容易上運行的話，還可以實現服務器資源（內存、CPU資源等）的有效隔離。
3. 團隊組織架構的調整
微服務設計的思想也改變了原有企業研發團隊組織架構。傳統的研發組織架構是水平架構，前端有前端的團隊，後端有後端的團隊，DBA有DNA的團隊，測試有測試的團隊。而微服務的設計思想對團隊的劃分有着一定的影響，使得團隊組織架構的劃分更傾向於垂直架構，比如用戶業務是 一個團隊來負責，支付業務是一個團隊來負責。（這種垂直劃分只是一個理想的架構，並不是每個公司和企業都符合這樣的條件把團隊組織架構拆分的這麼絕對）。
二、什麼是微服務
微服務的理念是由國際種著名的OO專家，敏捷開發方法的創始人之一，現爲ThoughtWorks公司的首席科學家Martin Fowler提出的。
Martin Fowler論文網址
就目前而言，對於微服務業界並沒有一個統一的標準的定義。通常而言，微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程序劃分成一組小的服務，但每個服務運行在其獨立的自己的進程中，服務之間互相協調、互相配合，爲用戶提供最終價值。服務之間採用輕量級的通信機制互相溝通（通常是基於HTTP的RESTful API）。每個服務都圍繞具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。另外，應儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數據存儲技術。
三、微服務的優缺點
（一）優點
- 每個服務足夠內聚，足夠小，代碼容易理解這樣能聚焦一個指定的業務功能或業務需求 開發簡單、開發效率高，一個服務可能就是專一的只幹一件事
- 微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成
- 微服務是松耦合的，是有功能有意義的服務，無論是在開發階段還是部署階段都是獨立的 微服務能使用不同的語言開發
- 易於和第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續集成工具，如Jenkins、Hudson、bamboo
- 微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更加關注自己的工作成果，無需通過合作才能體現價值 微服務允許你利用融合最新技術
- 微服務只是業務邏輯的代碼，不會和HTML、CSS或其他界面組件混合
- 每個微服務都有自己的存儲能力，可以有自己的數據庫，也可以有統一的數據庫
（二）缺點
- 開發人員要處理分佈式系統的複雜性
- 多服務運維難度，隨着服務的增加，運維的壓力也在增大
- 系統部署依賴
- 服務間通信成本
- 數據一致性
- 系統集成測試
- 性能監控
四、微服務的技術棧
| 微服務條目 | 落地技術 |
|---|---|
| 服務開發 | Springboot、Spring、SpringMVC |
| 服務配置與管理 | Netflix公司的Archaius、阿里的Diamond等 |
| 服務註冊與發現 | Eureka、Consul、Zookeeper等 |
| 服務調用 | Rest、RPC、gRPC |
| 服務熔斷器 | Hystrix、Envoy等 |
| 負載均衡 | Ribbon、Nginx等 |
| 服務接口調用(客戶端調用服務的簡化工具) | Feign等 |
| 消息隊列 | Kafka、RabbitMQ、ActiveMQ等 |
| 服務配置中心管理 | SpringCloudConfig、Chef等 |
| 服務路由（API網關） | Zuul等 |
| 服務監控 | Zabbix、Nagios、Metrics、Spectator等 |
| 全鏈路追蹤 | Zipkin，Brave、Dapper等 |
| 服務部署 | Docker、OpenStack、Kubernetes等 |
| 數據流操作開發包 | SpringCloud Stream（封裝與Redis,Rabbit、Kafka等發送接收消息） |
| 事件消息總線 | Spring Cloud Bus |
| … | … |
五、微服務和SOA
（一）SOA
面向服務的架構（SOA）是一個組件模型，它將應用程序的不同功能 單元（稱爲服務）進行拆分，並通過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的，它已經獨立於實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。SOA架構是一種粗粒度、松耦合的服務架構，更多的強調異構系統之間的服務通信和解耦合。
（二）微服務
微服務是系統按業務邊界做細粒度的拆分和部署。我們需要清楚地是微服務並非指他的體積足夠小而是它的職責足夠單一。很多人誤以爲“微”服務拆分的足夠小就是微服務，然而並不是這樣。“微”還有微不足道的意思，也就是說某個服務出現故障，它不會影響整個系統。微服務是面向服務架構發展的下一步。基本上這種架構類型是開發軟件，web或移動應用程序作爲獨立服務套件的一種特殊方式。創建這些服務僅用於一個特定的業務功能。他們之間完全相互獨立，這意味着他們可以用不同的編程語言並使用不同的數據庫，集中式服務管理幾乎不存在，微服務使用輕量級HTTP，REST或Thrift API互相進行通信。
（三）對比
微服務不再強調傳統SOA架構裏面比較中的ESB總線，同時SOA的思想進入到單個業務系統內部實現真正的組件化，微服務是SOA的一種輕量級的解決方案，其本質還是SOA，只是更容易落地實現而已。微服務架構強調的第一個重點就是業務系統需要徹底的組件化和服務化，原有的單個業務系統會拆分爲多個可以獨立開發，設計，運行和運維的小應用。這些小應用之間通過服務完成交互和集成。每個小應用從前端webui，到控制層，邏輯層，數據庫訪問，數據庫都完全是獨立的一套。
| 功能 | SOA | 微服務 |
|---|---|---|
| 組件大小 | 大塊業務邏輯 | 單獨任務或小塊業務邏輯 |
| 耦合 | 通常松耦合 | 總是松耦合 |
| 公司架構 | 任何類型 | 小型、專注於功能交叉的團隊 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目標 | 確保應用能夠相互交互 | 執行新功能，快速拓展開發團隊 |
六、微服務的適用場景
-
需要對系統細粒度監控
-
經典架構模式太重
-
提升系統可用性，如果一個系統掛了，不會對整個業務產生致命影響
-
應用變得越來越大
-
修改一個bug需要平滑升級
-
項目存在多種開發語言
七、微服務框架的對比
參考文獻：
什麼是微服務
SOA與微服務是什麼？之間有什麼聯繫？