統一管理服務註冊發布和訂閱。
服務提供者在啟動時，根據配置，向註冊中心發布服務相關資訊；
服務消費者啟動時，根據配置，向註冊中心訂閱所需服務，本地快取；
註冊中心返回服務提供者資訊給消費者，如有變更，主動推送消費者，消費者重新整理本地快取；
服務消費者根據本地快取的服務提供者位址列表，選擇相應提供者進行呼叫；
鏈路的安全性：指的是註冊中心與客戶端連線的安全認證，基於ip的黑白名單或基於使用者名稱+密碼或基於秘鑰+數字證書的認證；
資料安全性：指的是資料的許可權控制：
服務提供者需要支援通過配置、註解、api介面呼叫等方式發布服務，同理，服務消費者也可以通過這些方式引用服務。
感覺少了一步，在完成服務註冊後，服務提供者需要啟動監聽，等待服務呼叫。
作用參考ab測試，保證系統的穩定性前提下，灰度發布解決公升級後的相容性問題。
沒搞過這些流程，而且，服務發布可以只發布部分集群，然後為集群配置路由規則引入流量，所以對這一塊沒想太深入。
服務消費者和提供者之間的互動通訊，除了正常的業務引數，可能需要攜帶額外的資訊，如消費者的ip位址，呼叫鏈的id等，要保證這些額外資訊不影響正常業務引數，即使有執行緒切換的場景發生。
作者說這些額外引數不能通過業務介面來進行傳遞，需要框架支援這種引數傳遞，不太同意，正確的說應該不要影響正常業務介面引數即可。
服務上線後的功能變更，bug修復，需要多版本管理。
服務提供者：發布時，支援指定服務的版本號；
服務消費者：消費服務的時候，支援指定引用的服務版本號或版本範圍。
服務提供者，發布服務的時候，指定版本號，對於經常變動的服務，單獨部署發布；
服務提供者引用服務時指定版本號或版本範圍；
**的hsf基於osgi，挺牛，能把osgi玩好的不容易。
osgi基於外掛程式管理，支援熱部署和熱公升級，參考eclipse的外掛程式體系。
不使用osgi的原因很多，最主要的就是學習成本太高，不易理解，實現複雜，而他的有點又可以通過其他技術解決，所以除了**的hsf實在沒聽說太多應用。
下節繼續學習….
分布式服務框架dubbo原理解析
alibaba有好幾個分布式框架，主要有 進行遠端呼叫 類似於rmi的這種遠端呼叫 的 dubbo hsf jms訊息服務 napoli notify kv資料庫 tair 等。這個框架 工具 產品在實現的時候，都考慮到了容災，擴充套件，負載均衡，於是出現乙個配置中心 configserver 的東...
分布式服務框架 Zookeeper
createmode persistent 建立後只要不刪就永久存在 ephemeral 會話結束年結點自動被刪除，ephemeral結點不允許有子節點 sequential 節點名末尾會自動追加乙個10位數的單調遞增的序號，同乙個節點的所有子節點序號是單調遞增的 persistent sequen...
大型分布式服務框架
1 首先遠端服務呼叫有三種模式 同步 非同步 future 非同步 callback 三種呼叫模型,正常的都是同步呼叫，呼叫的時候阻塞當前執行緒，非同步一般只會在特殊的情景下有用。2 全域性配置 所有服務的配置應該是需要在乙個全域性配置中心配置 zookeeper集群 的，而不是寫死在 裡面，避免出...