聽說你想了解微服務架構

前言： 熱辣滾燙的微服務一直在撥撩着程序員的心，然而很多人對微服務架構不甚明瞭，單純的爲了用而用。只是把現有的單體拆點東西出來，例如商品服務，然後彼此間用上RPC就算微服務了。恕我直言，其實這還相差甚遠！

閱讀本文你將收穫：

1. 瞭解什麼是微服務架構。
2. 瞭解微服務架構有哪些內容。
3. 瞭解微服務架構中遇到的問題。
4. 這些問題的解決方案

大綱：

1. 什麼是微服務？
2. 微服務架構是什麼？
3. 微服務架構的各個組成怎麼解決問題的？

一、什麼是微服務?

1.1 在談論什麼是微服務的時候，我們先說說爲什麼需要微服務？

單體之痛：

• 團隊開發協作巨麻煩
  多人協同開發的時候，會因爲同時修改了代碼導致編譯不通過，各種重來。

• 系統可用性差
  因爲某個同學代碼質量問題，成爲整個系統的瓶頸所在，影響整個系統的可用性。

• 部署效率低下
  代碼越來越多，所涉及的相關資源也越來越多，打包編譯一次的時間都能撩個妹了。

• 難以擴展
  當系統需要伸縮的時候，必須對應用程序進行擴容，不能做到對某個功能點單獨擴容。

• 我要用微服務
  當你想用微服務的時候，單體的問題你能找出千千萬。但是，如果你一定要用，請先通讀此文後，做到心中有B-tree了在用！

1.2 微服務解決了什麼問題？

當然，微服務能解決上述單體應用出現的問題，不然我寫這麼多幹啥呢~o(￣︶￣)o（手動狗頭）

1.3 微服務帶來了哪些問題？

任何事情都有兩面性，微服務有其優點，必然有其缺點。只有充分了解了其優缺點，結合自身業務和開發能力的實際情況，再來做出權衡取捨，用不用微服務！

微服務的缺點：

• 需要點亮devops技能
  硬實力！

• 分佈式系統帶來的複雜度幾何級上升
  硬實力！

• 對開發人員素質要求變高了
  不再是CRUD就能安安穩穩過日子了

1.4 什麼是微服務

維基百科對微服務的定義:

微服務(Microservices) 是一種軟件架構風格，它是以專注於單一責任與功能的小型功能區塊 (Small Building Blocks) 爲基礎，利用模組化的方式組合出複雜的大型應用程序，各功能區塊使用與語言無關 (Language-Independent/Language agnostic) 的 API 集相互通訊。

是的，你沒看錯，這就完了~

二、微服務架構是什麼？

看圖說話：

微服務架構的六大組成部分：

1. 服務描述
   解決了如下問題：

   • 對外提供一個服務，那麼這個服務的服務名叫什麼？
   • 調用這個服務需要哪些信息？
   • 調用這個服務返回的是什麼格式？
   • 該如何解析？

2. 註冊中心
   有了服務接口的描述，下一步要解決的問題就是服務發佈和訂閱。

   • 服務發佈：服務提供者將自己提供的服務以及地址登記到註冊中心。
   • 服務訂閱：服務消費者則從註冊中心查詢所需要調用的服務地址，然後發起請求

3. 服務框架
   解決了如下問題：

   • 服務通信採用什麼協議？
   • 數據傳輸採用什麼方式？
   • 數據壓縮採用什麼格式？

4. 服務監控
   一旦服務提供者和服務消費者能夠正常發起服務調用，需要對調用情況進行監控，以瞭解服務是否正常。

5. 服務追蹤
   除了對服務調用情況進行監控之外，需要記錄服務調用經過的每一層鏈路，以便問題追蹤和故障定位。

6. 服務治理
   服務監控能夠發現問題，服務追蹤能夠定位問題，解決問題就靠服務治理！

三、微服務架構的各個組成怎麼解決問題的？

1. 服務描述

常用的服務描述方式：
- RESTful API： 常用於HTTP協議的服務描述
- XML配置：多用作RPC服務的協議描述
- IDL文件：通常用作Thirft和gRPC這類跨語言服務框架中。

2. 註冊中心

註冊中心的工作流程：
- 服務提供者在啓動時，根據服務發佈文件中配置的發佈信息向註冊中心註冊自己的服務。
- 服務消費者在啓動時，根據消費者配置文件中的配置信息向註冊中心訂閱自己所需要的服務。
- 註冊中心返回服務提供者地址列表給服務消費者。
- 當服務提供者發生變化，比如節點新增或銷燬，註冊中心將變更通知給服務消費者。

3. 服務框架

服務通信協議：

• 四層TCP/UDP協議
• 七層HTTP協議

數據傳輸方式：

• 同步
• 異步
• 單連接上傳輸
• 多路複用

數據壓縮格式：

• JSON序列化
• JAVA對象序列化
• Protobuf序列化

4. 服務監控

要了解服務監控首先要明白有哪些監控對象？具體監控哪些指標？從哪些維度監控？

這個話題有點大，在我做的思維導圖裏面有詳細的概述，希望讀者朋友能夠結合思維導圖一起看！

5. 服務追蹤

• 服務消費者發起調用前，會在本地按照一定的規則生成一個requestid，發起調用時，將requestid當做請求參數的一部分，傳遞給服務提供者。
• 服務提供者收到請求後，記錄下本次的requestid，然後處理請求。
• 如果服務提供者繼續請求其他服務，會在本地生成一個requestid，然後把這兩個requestid當做參數繼續往下傳遞。

6. 服務治理

服務治理就是通過一系列手段保證在各種意外的情況下，服務調用能夠正常進行。可分爲：

• 單機故障
• 單IDC故障
• 依賴服務不可用

終極殺器

思維導圖：

總結：

本文大部分成果總結於極客時間-《從0開始學微服務》胡忠想老師的專欄。一文只是簡述阿忠伯的課程，其精華難以概括，有興趣的同學可以上極客時間訂閱該課程！

https://github.com/FristResponder/MindMapping.git

上面是本人學習總結的所有思維導圖，喜歡的麻煩給個star​