GitHub：https://github.com/JDawnF
一般的服務調用流程如圖：
首先服務提供者（就是提供服務的一方）按照一定格式的服務描述，向註冊中心註冊服務，聲明自己能夠提供哪些服務以及服務的地址是什麼，完成服務發佈。
接下來服務消費者（就是調用服務的一方）請求註冊中心，查詢所需要調用服務的地址，然後以約定的通信協議向服務提供者發起請求，得到請求結果後再按照約定的協議解析結果。而且在服務的調用過程中，服務的請求耗時、調用量以及成功率等指標都會被記錄下來用作監控，調用經過的鏈路信息會被記錄下來，用於故障定位和問題追蹤。在這期間，如果調用失敗，可以通過重試等服務治理手段來保證成功率。
一般在微服務架構中包含這些組件：服務描述 、註冊中心 、服務框架 、服務監控、 服務追蹤 、服務治理。
服務描述
服務調用首先要解決的問題就是服務如何對外描述。你需要說明這個服務的名字，他是幹嘛的，提供了什麼功能，需要怎麼才能被調用，返回的結果是什麼樣的等等信息。
常用的服務描述方式包括 RESTful API、XML 配置以及 IDL 文件三種。
- RESTful API 方式通常用於 HTTP 協議的服務描述，並且常用 Wiki 或者Swagger來進行管理。
-
XML 配置方式多用作 RPC 協議的服務描述，通過 *.xml 配置文件來定義接口名、參數以及返回值類型等。
-
IDL 文件方式通常用作 Thrift 和 gRPC 這類跨語言服務調用框架中，比如 gRPC 就是通過 Protobuf 文件來定義服務的接口名、參數以及返回值的數據結構。
註冊中心
註冊中心主要負責服務的發佈和訂閱，相當於是一個記錄服務描述中相關信息的列表，服務提供者將自己提供的服務以及地址登記到註冊中心，服務消費者則從註冊中心查詢所需要調用的服務的地址，然後發起請求。
一般來講，註冊中心的工作流程是：
-
服務提供者在啓動時，根據服務發佈文件中配置的發佈信息向註冊中心註冊自己的服務。
-
服務消費者在啓動時，根據消費者配置文件中配置的服務信息向註冊中心訂閱自己所需要的服務。
-
註冊中心返回服務提供者地址列表給服務消費者。
-
當服務提供者發生變化，比如有節點新增或者銷燬，註冊中心將變更通知給服務消費者。
服務框架
通過註冊中心，服務消費者就可以獲取到服務提供者的地址，有了地址後就可以發起調用。但在發起調用服務需要解決這幾個問題：
-
服務通信採用什麼協議？就是說服務提供者和服務消費者之間以什麼樣的協議進行網絡通信，是採用四層 TCP、UDP 協議，還是採用七層 HTTP 協議，還是採用其他協議？
-
數據傳輸採用什麼方式？就是說服務提供者和服務消費者之間的數據傳輸採用哪種方式，是同步還是異步，是在單連接上傳輸，還是多路複用。
-
數據壓縮採用什麼格式？通常數據傳輸都會對數據進行壓縮，來減少網絡傳輸的數據量，從而減少帶寬消耗和網絡傳輸時間，比如常見的 JSON 序列化、Java 對象序列化以及 Protobuf 序列化等。
服務監控
一旦服務消費者與服務提供者之間能夠正常發起服務調用，需要對調用情況進行監控，以瞭解服務是否正常。通常來講，服務監控主要包括三個流程：
-
指標收集。就是要把每一次服務調用的請求耗時以及成功與否收集起來，並上傳到集中的數據處理中心。
-
數據處理。有了每次調用的請求耗時以及成功與否等信息，就可以計算每秒服務請求量、平均耗時以及成功率等指標。
-
數據展示。數據收集起來，經過處理之後，還需要以友好的方式對外展示，才能發揮價值。通常都是將數據展示在 Dashboard 面板上，並且每隔 10s 等間隔自動刷新，用作業務監控和報警等。
服務追蹤
除了需要對服務調用情況進行監控之外，還需要記錄服務調用經過的每一層鏈路，以便進行問題追蹤和故障定位。服務追蹤的工作原理大概如下：
-
服務消費者發起調用前，會在本地按照一定的規則生成一個 requestid，發起調用時，將 requestid 當作請求參數的一部分，傳遞給服務提供者。
-
服務提供者接收到請求後，記錄下這次請求的 requestid，然後處理請求。如果服務提供者繼續請求其他服務，會在本地再生成一個自己的 requestid，然後把這兩個 requestid 都當作請求參數繼續往下傳遞。
以此類推，通過這種層層往下傳遞的方式，一次請求，無論最後依賴多少次服務調用、經過多少服務節點，都可以通過最開始生成的 requestid 串聯所有節點，從而達到服務追蹤的目的。
服務治理
通過上面服務監控發現的問題，還有服務追蹤定位到的問題所在，而解決問題就得靠服務治理了。服務治理就是通過一系列的手段來保證在各種意外情況下，服務調用仍然能夠正常進行。一般常見以下情況和解決方案：
-
單機故障。通常遇到單機故障，都是靠運維發現並重啓服務或者從線上摘除故障節點。然而集羣的規模越大，越是容易遇到單機故障，在機器規模超過一百臺以上時，靠傳統的人肉運維顯然難以應對。而服務治理可以通過一定的策略，自動摘除故障節點，不需要人爲干預，就能保證單機故障不會影響業務。
-
單 IDC 故障。你應該經常聽說某某 App，因爲施工挖斷光纜導致大批量用戶無法使用的嚴重故障。而服務治理可以通過自動切換故障 IDC 的流量到其他正常 IDC，可以避免因爲單 IDC 故障引起的大批量業務受影響。
-
依賴服務不可用。比如你的服務依賴依賴了另一個服務，當另一個服務出現問題時，會拖慢甚至拖垮你的服務。而服務治理可以通過熔斷，在依賴服務異常的情況下，一段時期內停止發起調用而直接返回。這樣一方面保證了服務消費者能夠不被拖垮，另一方面也給服務提供者減少壓力，使其能夠儘快恢復。
參照：從0開始學微服務