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