淺談微服務

微服務已經火了很久了，很多人對這個東西感覺很高大上，實際上，有點規模的互聯網公已經把微服務用的很順手了，說實話，這門技術的使用，完全是“被迫”接受的，

一、該不該去學微服務

大多數開發者都希望能接觸到微服務開發，然而并不是每家公司都愿意花這么大的成本去搞這個東西，環境所逼，很多人為了自己的前途，拼命想去大廠，大公司有什么好處呢，我隨便列舉幾點：

• 1.工資福利待遇較好
• 2.技術堆疊先進，成熟的、規范化的開發流程
• 3 . 較為成熟的晉升渠道

很多人會說，學了不能用的技術學了也沒用啊，在作業中學習能用到的技術才是最有效的，我以前也是這么聽別人講的，現在想起來，純粹放屁，互聯網這個行業，人員流動性是很高的，大家都想一步步晉級去大廠，很多知識，是大廠需求的，但是在一般的小公司，毫無用武之地，別人跟你說，你別學這個了，我們公司用不到的，你學了也是白學，現在用不到就不學了？搞怪吧，我現在學的東西難道不是為未來的我做準備的，而是單純為這家公司做準備的？我用一個打工者的角度來思考這個問題（一些領導或者資本家的角度大多是有自我利益性的，都是基于自己利益不被損害的前提下來做事），畢竟大多數人都是打工者，學以致用當然是好，但是大多數人并不是有這樣的機會，沒有這個機會怎么辦，自己去創造啊，我想搞微服務，現在這家不搞，那你以后就去找一家有搞的啊，學習干嘛還要找這么多的借口，對于后端開發來說，我覺得要有追求，還是要對微服務有點了解，我相信努力的你，未來一定會用到它，

二、微服務是什么

定義：微服務是由單一應用程式構成的小服務，擁有自己的行程與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其他服務使用 HTTP API 通訊，同時，服務會使用最小規模的集中管理 （例如 Docker）技術，服務可以用不同的編程語言與資料庫等

博主也去過一些公司，接觸到的技術團隊也不算少了，有十幾人的，也有幾十人，幾百人的，我發現，微服務這個東西，只有對技術有追求的公司，規模稍微大些的才會弄，這些公司受不住大單體專案的摧殘，他們是沒辦法的，規模到那個程度了，不搞微服務得不償失，當專案復雜性達到一定的量級，開發人員也到達了一定的人數，微服務拆分便是必然的趨勢，

微服務是趨向后端的概念，微服務的核心在于這個“微”字，以前的時候，我們經常把一個專案寫在一個倉庫中，所有跟這個專案有關的內容全部放在一起，大家開發共用一個倉庫，如果沒有人強制設立規范的話，代碼質量和目錄規范什么的都無法達到保證，隨著專案的擴大以及開發人員的增加，風險也會隨之增大，有可能一人為了開發A功能，導致其他功能都掛了，或者說有人改動了一小段共用代碼，導致其他子系統奔潰，當然，這都是有可能的，

慢慢的大家覺得，有些東西可以單獨抽離處理作為一個獨立的模塊（服務），在開發，測驗，部署的程序中都可以單獨對其操作，模塊之間的上線發布互不影響，代碼倉庫相互隔離，例如，評論模塊和點贊模塊拆分成兩個微服務，點贊服務掛了，評論模塊還是正常不受影響的，對用戶來說，只是區域性功能失效，用戶體驗也不會太差，

三、微服務和單體應用的優劣勢

技術一直是雙刃劍，有優勢必然也會有劣勢，畢竟軟體設計沒有銀彈，

微服務優勢：

• 服務獨立部署維護
• 服務性能提升
• 業務拆分更細，各司其職
• 代碼維護更簡單，單個服務業務復雜性低

微服務劣勢：

• 運維成本高
• 對開發者的要求更高
• 前期投入成本大

單體架構優勢：

• 開發快速
• 部署簡單，對開發者要求較低
• 運維成本低

單體架構劣勢：

• 容易發生級聯事故
• 系統高可用查
• 線上發布慢
• 團隊協作開發成本高（人員規模大時）

單體架構適合專案剛開始需要快速迭代上線，技術人員人員較少的場景，但是隨著系統的復雜性逐漸增加，單體所帶來的的劣勢遠比優勢更加突出，此時，在公司實力的允許下，單體必將被微服務所重構，

四、微服務架構包括哪些內容

開始干貨內容

1. 微服務拆分

1.1 縱向拆分（業務拆分）

按業務維度進行拆分，標準是按照業務的關聯程度來決定，關聯比較密切的業務拆分為一個微服務， 而功能相對比較獨立的業務適合單獨拆分為一個微服務

1.2 橫向拆分（功能拆分）

按公共且獨立功能維度拆分，標準是按照是否有公共的被多個其他服務呼叫，且依賴的資源獨立不與其他業務耦合

一般來說，有以上兩種方式的拆分維度，具體的拆分選擇需要按照公司業務以及人員規模進行決定

2. 微服務發布和參考

常常有以下三種服務實作方式

• resfulApi
• xml配置
• IDL檔案（grpc/thrift)

3.服務注冊（注冊中心）

基于RPC實作的微服務，常用存在三種角色，分別是

• 服務提供者
• 服務消費者
• 服務注冊中心
  
  其中注冊中心充當著服務提供者和服務消費者之間的中介介紹所角色
  服務呼叫者，想要知道服務提供者的呼叫資訊，則需要向中介介紹所獲取資訊，這就好比是商家，平臺，用戶三者的關系，商家在平臺上注冊自己的資訊，用戶通過平臺獲取商家的資訊，再和商家進行聯系

注冊中心是整個微服務中較為復雜的部分，一個注冊中心往往需要提供一系列 API 供服務呼叫者和服務提供者使用，一般至少需要以下的介面：

• 服務注冊介面（用于服務的注冊）
• 服務反注冊介面（用于服務的注銷）
• 心跳匯報介面（檢測服務是否可用）
• 服務訂閱介面（訂閱服務，服務有變動時會有訊息推送）
• 服務查詢介面（查詢服務資訊）
• 服務變更查詢介面（查看服務的變更資訊）
• 服務修改介面（修改服務注冊資訊）

為了避免中介所掛壁，導致兩端無法正常通信，往往注冊中心會采用集群的部署方式，這就意味著對于節點之間的資料同步有著很大的挑戰，

4. 微服務呼叫

微服務的呼叫可分為三步曲：

4.1 建立連接

建立連接一般有兩種方式，一種是基于應用層的HTTP通信，一種是底層的socket通信，

4.2 資料傳輸

資料傳輸方式有基于HTTP和grpc的實作，通過為了高性能以及減少網路帶寬，我們會使用pb物件的方式進行傳輸，而不是使用可視化較好的 json 格式進行傳輸，比較 pb 是二進制的傳輸方式，性能相對較好，

4.3 服務端處理請求

服務端處理一般有三種處理機制，分別為

• 同步阻塞方式（BIO)
  客戶端每發一次請求，服務端就生成一個執行緒去處理，當客戶端同時發起的請求很多時，服務端需要創建很多的執行緒去處理每一個請求，如果達到了系統最大的執行緒數瓶頸，新來的請求就沒法處理了
• 同步非阻塞方式（NIO)
  客戶端每發一次請求，服務端并不是每次都創建一個新執行緒來處理，而是通過 I/O 多路復用技術進行處理，就是把多個 I/O 的阻塞復用到同一個 select 的阻塞上，從而使系統在單執行緒的情況下可以同時處理多個客戶端請求，這種方式的優勢是開銷小，不用為每個請求創建一個執行緒，可以節省系統開銷，
• 異步非阻塞方式（AIO)
  客戶端只需要發起一個 I/O 操作然后立即回傳，等 I/O 操作真正完成以后，客戶端會得到 I/O 操作完成的通知，此時客戶端只需要對資料進行處理就好了，不需要進行實際的 I/O 讀寫操作，因為真正的 I/O 讀取或者寫入操作已經由內核完成了，這種方式的優勢是客戶端無需等待，不存在阻塞等待問題，

幾種處理方式各有好處和劣勢，因此一般根據 業務進行決定，但是市面上常用的RPC框架已經幫我們把這個搞好了，不需要我們對其關心，

5. 微服務監控

5.1 監控物件：

• 用戶端的監控： 通常是指業務直接對用戶提供的功能的監控
• 介面監控：通常是指業務提供的功能所依賴的具體 RPC 介面的監控
• 資源監控：通常是指某個介面依賴的資源的監控
• 基礎監控：通常是指對服務器本身的健康狀況的監控

5.2 監控指標

• 請求量：實時請求量（QPS) 和統計請求量（PV)
• 回應時間：服務在不同時間段的回應時間
• 錯誤率：錯誤率的監控通常用一段時間內呼叫失敗的次數占呼叫總次數的比率來衡量

5.3 監控維度

• 全域維度
• 分機房維度
• 單機維度
• 時間維度
• 核心維度

不同的監控維度往往是業務需要，導致監控的側重點不同，

6. 微服務追蹤

6.1 作用

基于RPC的呼叫方式，和本地服務器呼叫有著很大的不同，涉及不同服務器，不同網路，不同物理區域，因此為了能準確定位呼叫鏈路中的問題，需要微服務的追蹤，當然作用不當當只有問題定位，還有很多，例如：

• 優化系統瓶頸： 通過記錄呼叫經過的每一條鏈路的耗時
• 優化鏈路呼叫：分析呼叫經過的路徑，優化呼叫
• 生成網路拓撲：生成一張系統的網路呼叫拓撲圖，它可以反映系統都依賴了哪些服務，以及服務之間的呼叫關系是什么樣的
• 透明傳輸資料：逐層傳遞同一資料

6.2 原理

一般有三種實作方式：

• traceId：用于標識某一次具體的請求 ID，當用戶的請求進入系統后，會在 RPC 呼叫網路的第一層生成一個全域唯一的 traceId，并且會隨著每一層的 RPC 呼叫，不斷往后傳遞，這樣的話通過 traceId 就可以把一次用戶請求在系統中呼叫的路徑串聯起來

• spanId：用于標識一次 RPC 呼叫在分布式請求中的位置，當用戶的請求進入系統后，處在 RPC 呼叫網路的第一層 A 時 spanId 初始值是 0，進入下一層 RPC 呼叫 B 的時候 spanId 是 0.1，繼續進入下一層 RPC 呼叫 C 時 spanId 是 0.1.1，而與 B 處在同一層的 RPC 呼叫 E 的 spanId 是 0.2，這樣的話通過 spanId 就可以定位某一次 RPC 請求在系統呼叫中所處的位置，以及它的上下游依賴分別是誰

• annotation： 用于業務自定義埋點資料，可以是業務感興趣的想上傳到后端的資料，比如一次請求的用戶 UID

6.3 實作邏輯

• 資料采集
  – CS階段（client send）：客戶端發起請求，并生成呼叫的背景關系
  – SR階段（server receive）：服務端接受請求，并生成背景關系
  – SS階段（server send）：服務端回傳請求，這個階段會將服務端背景關系資料上報
  – CR階段（client receive）：客戶端接識訓傳結果，這個階段會將客戶端背景關系資料上報

• 資料處理
  資料處理一般有兩種范式，一種是實時資料處理，一種是離線資料處理，通過是兩種方式相結合實作，

• 資料展示
  一般以呼叫鏈路圖和呼叫拓撲圖進行呈現

7. 微服務治理

• 節點管理
  包括注冊中心主動摘除機制和服務消費者主動拆除機制

• 負載均衡
  – 隨機演算法
  – 輪訓演算法
  – 最少活躍呼叫法
  – 一致性hash演算法

• 服務路由
  可分為靜態配置和動態配置，大家可以類比靜態路由和靜態路由

• 服務容錯
  包含四種容錯機制
  – FailOver：失敗自動切換
  – FailBack：失敗通知
  – FailCache：失敗快取
  – FailFast：快速失敗

以上為微服務所涉及到基本知識點，因為篇幅有限，需要繼續學習的同學可以自行去研究學習，另外附上博主學習微服務時做的思維導圖示記供大家參考：

需要高清大圖的可以在資源里進行下載，