dubbo2.7.X版本帶來的服務註冊和服務調用方式改變
參考地址：//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 端查詢元數據中心的時機，是等到註冊中心的地址更新通知之後。也就是通過註冊中心下發的數據，我們能明確的知道何時某個實例的元數據被更新了，此時才需要去查元數據中心。
引用服務配置帶來的改變：
