來自極客時間
我想你一定很好奇微服務架構到底是什麼樣子的，接下來我們一起走進微服務架構，來看看它的各個組成部分。
下面這張圖是我根據自己的經驗，繪製的微服務架構的模組圖，在具體介紹之前先來看下一次正常的服務呼叫的流程。
首先服務提供者（就是提供服務的一方）按照一定格式的服務描述，向註冊中心註冊服務，宣告自己能夠提供哪些服務以及服務的位址是什麼，完成服務發布。
接下來服務消費者（就是呼叫服務的一方）請求註冊中心，查詢所需要呼叫服務的位址，然後以約定的通訊協議向服務提供者發起請求，得到請求結果後再按照約定的協議解析結果。
而且在服務的呼叫過程中，服務的請求耗時、呼叫量以及成功率等指標都會被記錄下來用作監控，呼叫經過的鏈路資訊會被記錄下來，用於故障定位和問題追蹤。在這期間，如果呼叫失敗，可以通過重試等服務治理手段來保證成功率。
總結一下，微服務架構下，服務呼叫主要依賴下面幾個基本元件：
接下來，我來為你一一介紹這些元件。
服務呼叫首先要解決的問題就是服務如何對外描述。比如，你對外提供了乙個服務，那麼這個服務的服務名叫什麼？呼叫這個服務需要提供哪些資訊？呼叫這個服務返回的結果是什麼格式的？該如何解析？這些就是服務描述要解決的問題。
常用的服務描述方式包括restful api、xml配置以及idl檔案三種。
其中，restful api方式通常用於http協議的服務描述，並且常用wiki或者swagger來進行管理。下面是乙個restful api方式的服務描述的例子。
xml配置方式多用作rpc協議的服務描述，通過*.xml配置檔案來定義介面名、引數以及返回值型別等。下面是乙個xml配置方式的服務描述的例子。
idl檔案方式通常用作thrift和grpc這類跨語言服務呼叫框架中，比如grpc就是通過protobuf檔案來定義服務的介面名、引數以及返回值的資料結構，示例如下：
有了服務的介面描述，下一步要解決的問題就是服務的發布和訂閱，就是說你提供了乙個服務，如何讓外部想呼叫你的服務的人知道。這個時候就需要乙個類似註冊中心的角色，服務提供者將自己提供的服務以及位址登記到註冊中心，服務消費者則從註冊中心查詢所需要呼叫的服務的位址，然後發起請求。
一般來講，註冊中心的工作流程是：
通過註冊中心，服務消費者就可以獲取到服務提供者的位址，有了位址後就可以發起呼叫。但在發起呼叫之前你還需要解決以下幾個問題。
一旦服務消費者與服務提供者之間能夠正常發起服務呼叫，你就需要對呼叫情況進行監控，以了解服務是否正常。通常來講，服務監控主要包括三個流程。
除了需要對服務呼叫情況進行監控之外，你還需要記錄服務呼叫經過的每一層鏈路，以便進行問題追蹤和故障定位。
服務追蹤的工作原理大致如下：
以此類推，通過這種層層往下傳遞的方式，一次請求，無論最後依賴多少次服務呼叫、經過多少服務節點，都可以通過最開始生成的requestid串聯所有節點，從而達到服務追蹤的目的。
服務監控能夠發現問題，服務追蹤能夠定位問題所在，而解決問題就得靠服務治理了。服務治理就是通過一系列的手段來保證在各種意外情況下，服務呼叫仍然能夠正常進行。
在生產環境中，你應該經常會遇到下面幾種狀況。
上面是三種最常見的需要引入服務治理的場景，當然還有一些其他服務治理的手段比如自動擴縮容，可以用來解決服務的容量問題。
通過前面的講解，相信你已經對微服務架構有了基本的認識，對微服務架構的基本元件也有了初步了解。
這幾個基本元件共同組成了微服務架構，在生產環境下缺一不可，所以在引入微服務架構之前，你的團隊必須掌握這些基本元件的原理並具備相應的開發能力。實現方式上，可以引入開源方案；如果有充足的資深技術人員，也可以選擇自行研發微服務架構的每個元件。但對於大部分中小團隊來說，我認為採用開源實現方案是乙個更明智的選擇，一方面你可以節省相關技術人員的投入從而更專注於業務，另一方面也可以少走彎路少踩坑。不管你是採用開源方案還是自行研發，都必須吃透每個元件的工作原理並能在此基礎上進行二次開發。
03 初探微服務架構
上一期我給你講了什麼時候應該進行服務化，以及服務化拆分的兩種方式即橫向拆分和縱向拆分，最後還提到了引入微服務架構需要解決的問題。我想你一定很好奇微服務架構到底是什麼樣子的，接下來我們一起走進微服務架構，來看看它的各個組成部分。下面這張圖是我根據自己的經驗，繪製的微服務架構的模組圖，在具體介紹之前先來...
微服務與微服務架構
微服務 微服務強調的是服務的大小，它關注的是某乙個點，是具體解決某乙個問題 提供落地對應服務的乙個服務應用,狹意的看,可以看作eclipse裡面的乙個個微服務工程 或者module。例如 訂單服務 支付服務 微服務架構 馬丁.福勒 martin fowler 微服務架構介紹 微服務架構是 種架構模式...
微服務架構
一 先了解一下什麼是單體應用 就是乙個應用程式包含了所有模組功能，各模組同時部署。當然這種應用模式比較容易部署 測試，但隨著專案的加大，單體模式就會變得越來越臃腫，維護的成本逐漸變高。當乙個模組出錯，整個應用都會出現問題，擴充套件能力也會受到限制。二 什麼是微服務 是將整個應用程式分解為多個模組，各...