參考地址：https://www.cnblogs.com/alisystemsoftware/p/13064620.html
註冊中心資料結構格式改變（service：介面服務，application：同個應用例項組成的集合，instance：單個應用例項），帶來的是“服務自省”
以 Dubbo 當前的地址發現資料格式為例，它是“RPC 服務粒度”的，它是以 RPC 服務作為 key，以例項列表作為 value 來組織資料的：
而我們新引入的“應用粒度的服務發現”，它以應用名（Application）作為 key，以這個應用部署的一組例項（Instance）列表作為 value。這帶來兩點不同：
資料對映關係變了，從 RPC Service -> Instance 變為 Application -> Instance；
資料變少了，註冊中心沒有了 RPC Service 及其相關配置資訊。
以上的改變是稱為應用級服務發現的基本機制，接著解釋它為什麼會被叫做“服務自省”？
其實這還是得從它的工作原理說起，上面我們提到，應用粒度服務發現的資料模型有幾個以下明顯變化：資料中心的資料量少了，RPC 服務相關的資料在註冊中心沒有了，現在只有 application - instance 這兩個層級的資料。為了保證這部分缺少的 RPC 服務資料仍然能被 Consumer 端正確的感知，我們在 Consumer 和 Provider 間建立了一條單獨的通訊通道：Consumer 和 Provider 兩兩之間通過特定埠交換資訊，我們把這種 Provider 自己主動暴露自身資訊的行為認為是一種內省機制，因此從這個角度出發，我們把整個機制命名為：服務自省。
這樣的改變給出了 Dubbo 往應用級服務發現靠攏的好處或原因，但這麼做的同時介面粒度的服務治理能力還是要繼續保留，這是 Dubbo 框架程式設計模型易用性、服務治理能力優勢的基礎。
以下是服務自省的一個完整工作流程圖，詳細描述了服務註冊、服務發現、MetadataService、RPC 呼叫間的協作流程。
服務提供者啟動，首先解析應用定義的“普通服務”並依次註冊為 RPC 服務，緊接著註冊內建的 MetadataService 服務，最後開啟 TCP 監聽埠；
啟動完成後，將例項資訊註冊到註冊中心（僅限 ip、port 等例項相關資料），提供者啟動完成；
服務消費者啟動，首先依據其要“消費的 provider 應用名”到註冊中心查詢地址列表，並完成訂閱（以實現後續地址變更自動通知）；
消費端拿到地址列表後，緊接著對 MetadataService 發起呼叫，返回結果中包含了所有應用定義的“普通服務”及其相關配置資訊；
至此，消費者可以接收外部流量，並對提供者發起 Dubbo RPC 呼叫。
後設資料同步機制
Client 與 Server 間在收到地址推送後的配置同步是服務自省的關鍵環節，目前針對後設資料同步有兩種具體的可選方案，分別是：內建 MetadataService；獨立的後設資料中心，通過中細化的後設資料叢集協調資料。
內建 MetadataService：MetadataService 通過標準的 Dubbo 協議暴露，根據查詢條件，會將記憶體中符合條件的“普通服務”配置返回給消費者。這一步發生在消費端選址和呼叫前；
後設資料中心：複用 2.7 版本中引入的後設資料中心，provider 例項啟動後，會嘗試將內部的 RPC 服務組織成後設資料的格式到後設資料中心，而 consumer 則在每次收到註冊中心推送更新後，主動查詢後設資料中心。
注意 consumer 端查詢後設資料中心的時機，是等到註冊中心的地址更新通知之後。也就是通過註冊中心下發的資料，我們能明確的知道何時某個例項的後設資料被更新了，此時才需要去查後設資料中心。
引用服務配置帶來的改變：
