如何發佈和引用服務
服務提供者如何發佈一個服務，服務消費者如何引用這個服務。具體來說，就是這個服務的接口名是什麼？調用這個服務需要傳遞哪些參數？接口的返回值是什麼類型？以及一些其他接口描述信息
最常見的服務發佈和引用的方式有三種：
RESTful API (一般對外)
XML配置 （對內）
IDL文件（跨語言，Thrift, gRPC）
如何註冊和發現服務
在微服務架構下，主要有三種角色：服務提供者（RPC Server）、服務消費者（RPC Client）和服務註冊中心（Registry）。
RPC Server提供服務，在啟動時，根據服務發佈文件server.xml中的配置的信息，向Registry註冊自身服務，並向Registry定期發送心跳彙報存活狀態。
RPC Client調用服務，在啟動時，根據服務引用文件client.xml中配置的信息，向Registry訂閱服務，把Registry返回的服務節點列表緩存在本地內存中，並與RPC Sever建立連接。
當RPC Server節點發生變更時，Registry會同步變更，RPC Client感知後會刷新本地內存中緩存的服務節點列表。
RPC Client從本地緩存的服務節點列表中，基於負載均衡算法選擇一臺RPC Sever發起調用。
註冊中心實現方式
註冊中心的實現主要涉及幾個問題：註冊中心需要提供哪些接口，該如何部署；如何存儲服務信息；如何監控服務提供者節點的存活；如果服務提供者節點有變化如何通知服務消費者，以及如何控制註冊中心的訪問權限。
註冊中心必須提供以下最基本的API
- 服務註冊接口：服務提供者通過調用服務註冊接口來完成服務註冊。服務反註冊接口：服務提供者通過調用服務反註冊接口來完成服務註銷。心跳彙報接口：服務提供者通過調用心跳彙報接口完成節點存活狀態上報。服務訂閱接口：服務消費者通過調用服務訂閱接口完成服務訂閱，獲取可用的服務提供者節點列表。服務變更查詢接口：服務消費者通過調用服務變更查詢接口，獲取最新的可用服務節點列表。
除此之外，為了便於管理，註冊中心還必須提供一些後臺管理的API，例如：
- 服務查詢接口：查詢註冊中心當前註冊了哪些服務信息。服務修改接口：修改註冊中心中某一服務的信息。
如何實現RPC遠程服務調用
在進行服務化拆分之後，服務提供者和服務消費者運行在兩臺不同物理機上的不同進程內，它們之間的調用相比於本地方法調用，可稱之為遠程方法調用，簡稱RPC。
想要完成遠程調用，你需要解決四個問題：
- 客戶端和服務端如何建立網絡連接？服務端如何處理請求？數據傳輸採用什麼協議？數據該如何序列化和反序列化？
客戶端和服務端如何建立網絡連接
客戶端和服務端之間基於TCP協議建立網絡連接最常用的途徑有兩種
- HTTP通信Socket通信
服務端如何處理請求
- 同步阻塞方式 (適用於連接數比較小的業務場景)同步非阻塞方式 (用於連接數比較多並且請求消耗比較輕的業務場景，比如聊天服務器)異步非阻塞方式 (用於連接數比較多而且請求消耗比較重的業務場景)
數據傳輸採用什麼協議
最常用的有HTTP協議，它是一種開放的協議，各大網站的服務器和瀏覽器之間的數據傳輸大都採用了這種協議。還有一些定製的私有協議，比如阿里巴巴開源的Dubbo協議等。
數據該如何序列化和反序列化
常用的序列化方式分為兩類：
- 文本類如XML/JSON等二進制類如PB/Thrift等
如何監控微服務調用
監控對象
- 用戶端監控。提供給用戶的功能監控接口監控。依賴的具體RPC接口的監控資源監控。依賴的redis,mysql等基礎監控。服務器本身的健康狀況的監控
監控指標
- 請求量，請求量一般有二個維度，一個是實時請求量即QPS,還一個是統計請求量即PV。響應時間，可以用一段時間內所有調用的平均耗時來反映請求的響應時間錯誤率，通常用一段時間內調用失敗的次數佔調用總次數的比率來衡量
監控維度
- 全局維度分機房維度單機維度時間維度核心維度
監控系統的步驟
1.數據採集
通常有兩種數據收集方式：
- 服務主動上報，這種處理方式通過在業務代碼或者服務框架里加入數據收集代碼邏輯，在每一次服務調用完成後，主動上報服務的調用信息。代理收集，這種處理方式通過服務調用後把調用的詳細信息記錄到本地日誌文件中，然後再通過代理去解析本地日誌文件，然後再上報服務的調用信息。
2. 數據傳輸
數據傳輸最常用的方式有兩種：
- UDP傳輸，這種處理方式是數據處理單元提供服務器的請求地址，數據採集後通過UDP協議與服務器建立連接，然後把數據發送過去。Kafka傳輸，這種處理方式是數據採集後發送到指定的Topic，然後數據處理單元再訂閱對應的Topic，就可以從Kafka消息隊列中讀取到對應的數據。
3. 數據處理
數據處理是對收集來的原始數據進行聚合並存儲。數據聚合通常有兩個維度：
- 接口維度聚合，這個維度是把實時收到的數據按照接口名維度實時聚合在一起，這樣就可以得到每個接口的實時請求量、平均耗時等信息。機器維度聚合，這個維度是把實時收到的數據按照調用的節點維度聚合在一起，這樣就可以從單機維度去查看每個接口的實時請求量、平均耗時等信息。
4. 數據展示
數據展示是把處理後的數據以Dashboard的方式展示給用戶。數據展示有多種方式，比如曲線圖、餅狀圖、格子圖展示等。
如何追蹤微服務調用
在微服務架構下，由於進行了服務拆分，一次請求涉及到多個服務調用，如果請求失敗，就很難定位是在哪個環節出錯，所以我們需要服務調用鏈的追蹤。
服務追蹤的作用
- 優化系統瓶頸優化鏈路調用生成網絡拓撲透明傳輸數據
服務追蹤系統原理
它的核心理念就是調用鏈：通過一個全局唯一的ID將分佈在各個服務節點上的同一次請求串聯起來，從而還原原有的調用關係，可以追蹤系統問題、分析調用數據並統計各種系統指標。
服務追蹤系統可以分為三層
- 數據採集層，負責各個節點數據埋點並上報數據處理層。數據處理層，負責數據的存儲與計算。數據展示層，負責數據的圖形化展示。
微服務治理的手段有哪些
一次服務調用，服務提供者、註冊中心、網絡這三者都可能會有問題，此時服務消費者應該如何處理才能確保調用成功呢？這就是服務治理要解決的問題。
常用的服務治理手段
節點管理
服務調用失敗一般是由兩類原因引起的，一類是服務提供者自身出現問題，如服務器宕機、進程意外退出等；一類是網絡問題，如服務提供者、註冊中心、服務消費者這三者任意兩者之間的網絡出現問題。
無論是服務提供者自身出現問題還是網絡發生問題，都有兩種節點管理手段。
- 註冊中心主動摘除機制
這種機制要求服務提供者定時的主動向註冊中心彙報心跳，註冊中心根據服務提供者節點最近一次彙報心跳的時間與上一次彙報心跳時間做比較，如果超出一定時間，就認為服務提供者出現問題，繼而把節點從服務列表中摘除，並把最近的可用服務節點列表推送給服務消費者。
- 服務消費者摘除機制
雖然註冊中心主動摘除機制可以解決服務提供者節點異常的問題，但如果是因為註冊中心與服務提供者之間的網絡出現異常，最壞的情況是註冊中心會把服務節點全部摘除，導致服務消費者沒有可用的服務節點調用，但其實這時候服務提供者本身是正常的。所以，將存活探測機制用在服務消費者這一端更合理，如果服務消費者調用服務提供者節點失敗，就將這個節點從內存中保存的可用服務提供者節點列表中移除。
負載均衡
常用的負載均衡算法主要包括以下幾種。
- 隨機算法輪訓算法最少活躍調用算法一致性Hash算法
服務路由
對於服務消費者而言，在內存中的可用服務節點列表中選擇哪個節點不僅由負載均衡算法決定，還由路由規則確定。所謂的路由規則，就是通過一定的規則如條件表達式或者正則表達式來限定服務節點的選擇範圍。
為什麼要制定路由規則呢？主要有兩個原因。
- 業務存在灰度發佈的需求多機房就近訪問的需求
服務容錯
服務調用並不總是一定成功的,對於服務調用失敗的情況，需要有手段自動恢復，來保證調用成功。
服務容錯常用的手段主要有以下幾種。
- FailOver：失敗自動切換。就是服務消費者發現調用失敗或者超時後，自動從可用的服務節點列表總選擇下一個節點重新發起調用，也可以設置重試的次數。FailBack：失敗通知。就是服務消費者調用失敗或者超時後，不再重試，而是根據失敗的詳細信息，來決定後續的執行策略。FailCache：失敗緩存。就是服務消費者調用失敗或者超時後，不立即發起重試，而是隔一段時間後再次嘗試發起調用。FailFast：快速失敗。就是服務消費者調用一次失敗後，不再重試。
一般情況下對於冪等的調用，可以選擇FailOver或者FailCache，非冪等的調用可以選擇FailBack或者FailFast。
思維導圖：
前面如有不正確的地方還希望大家多多指教，本文的重點是你有沒有收穫與成長，其餘的都不重要，希望讀者們能謹記這一點。同時我經過多年的收藏目前也算收集到了一套完整的架構學習資料，包括但不限於：高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼、Mybatis、Redis、Mysql、Tomcat、Dubbo、微服務等多個知識點，對於很多初，中級Java工程師而言，想要提升技能，往往是自己摸索成長，不成體系的學習效果低效漫長且無助。整理的這些架構技術希望對Java開發的朋友們有所參考以及少走彎路。
有需要的Java工程師朋友們點贊+關注哦，後臺私信我即可獲取高清思維導圖以及架構面試資料。
閱讀更多 程序人生a 的文章
