服務調用
幾個誤區
- NIO就是異步服務：
- 需要區分通信框架的NIO，不等於上層應用調用的異步，2個完全是不同角度，不是一個層面的事情，即使是底層通信的NIO也可以實現上層同步調用服務的功能；
- NIO的好處：
關於這個看之前那章裡面推薦文章。
3.服務調用和通信框架的關係
這裡是通過中間的消息隊列來實現隔離上層同步異步跟底層通信框架的IO解耦的，現實中會去掉消息隊列，使用future模式來實現。
- 服務調用天生就是同步的：
- 現在rpc這麼普及，應該不會有人還存在這種觀點了吧；
- OneWay模式，只有請求沒有應答：
3.請求-應答模式：
異步調用性能更高：個人覺得首先要想清楚為什麼需要異步，需要分佈式，而不是單純考慮那個性能更好。
調用方式
- 同步：
異步
- 並行
- 泛化，框架提供通用接口方法，應用實現具體服務，然後發佈和引用
- 回調，單列出來，在異步的基礎上執行回調方法。
服務註冊中心
統一管理服務註冊發佈和訂閱。
概念
- 服務提供者
- 服務消費者
- 服務註冊中心，有幾個特點：
- 高HA：支持數據持久化，支持集群；
- 數據一致性問題；
- 數據變更主動推送。
關鍵功能特性設計
- 服務提供者在啟動時，根據配置，向註冊中心發佈服務相關信息；
- 服務消費者啟動時，根據配置，向註冊中心訂閱所需服務，本地緩存；
- 註冊中心返回服務提供者信息給消費者，如有變更，主動推送消費者，消費者刷新本地緩存；
- 服務消費者根據本地緩存的服務提供者地址列表，選擇相應提供者進行調用；
- 支持對等集群
- 註冊中心提供CRUD接口
- 安全加固
- 鏈路的安全性：指的是註冊中心與客戶端連接的安全認證，基於IP的黑白名單或基於用戶名+密碼或基於秘鑰+數字證書的認證；
- 數據安全性：指的是數據的權限控制：
發佈訂閱機制：除了啟動時的發佈訂閱，最關鍵的是動態發佈訂閱的支持；
- 可靠性：註冊中心集群部署，任意一臺宕機，不影響註冊中心的使用，集群不可用，只會影響新服務的發佈訂閱，不影響已緩存服務的使用。
基於zk的服務註冊中心設計
服務發佈和引用
服務提供者需要支持通過配置、註解、api接口調用等方式發佈服務，同理，服務消費者也可以通過這些方式引用服務。
服務發佈
- 服務發佈的幾種方式：
- xml配置，註解，api接口調用
本地實現類封裝成代理，其好處：
- 發佈流程享受，通過抽象代理層，可對服務發佈行為本身進行封裝和抽象；
- 通過動態代理，可對服務發佈進行動態攔截，方便對服務發佈定製；
- 擴展和替換；
- 服務發佈成指定協議
- 服務提供者信息註冊，目的：
- 供消費者訂閱服務地址信息；
- 基於註冊中心的統一服務治理；
- 服務註冊的目錄結構可以按照主機、服務名、url來，按實際需求判斷，例如按主機來：
感覺少了一步，在完成服務註冊後，服務提供者需要啟動監聽，等待服務調用。
服務引用
- 本地接口調用轉換成遠程服務調用，主要是根據配置或註解的遠程服務信息，生成服務的動態代理；
- 服務地址本地緩存，在生成動態代理之前，就會根據引用的服務信息，連接註冊中心，獲取服務相關配置信息和服務提供者列表，緩存到本地，後期就可以直接在本地查詢。
- 遠程服務調用，從本地緩存列表獲取服務提供者地址信息，根據路由策略，選擇鏈路，然後就是一系列的服務治理，最後遠程調用。
最佳實踐
- 對等設計：服務的發佈或引用，配置支持的，必須也能夠通過註解或api接口實現支持；
- 啟動順序，主要是服務提供者、註冊中心、服務消費者3者的系統啟動順序無法控制，其實最主要的是要支持註冊中心的斷連重連機制，客戶端（提供者和消費者）和註冊中心定時通信，發佈或獲取服務信息，這樣就無所謂啟動順序；
- 同步還是異步發佈服務，這個主要是服務太多了，如果系統啟動時，就發佈服務，會影響啟動時間，看需求吧；
- 警惕網絡風暴，對於註冊中心，可能需要註冊的服務太多或者服務變更頻繁，擠佔註冊中心網絡帶寬，需要考慮的是那些信息需要向註冊中心同步；
- 配置擴展，主要是發佈或引用需要支持擴展。
服務灰度發佈
作用參考AB測試，保證系統的穩定性前提下，灰度發佈解決升級後的兼容性問題。
流程設計
- 環境準備
- 灰度規則設置，這個更多的是灰度路由規則，將流量引入灰度環境；
- 灰度規則下發；
- 灰度路由；
- 失敗回滾
- 灰度發佈總結，為下一輪灰度打基礎
沒搞過這些流程，而且，服務發佈可以只發布部分集群，然後為集群配置路由規則引入流量，所以對這一塊沒想太深入。
參數傳遞
服務消費者和提供者之間的交互通信，除了正常的業務參數，可能需要攜帶額外的信息，如消費者的ip地址，調用鏈的ID等，要保證這些額外信息不影響正常業務參數，即使有線程切換的場景發生。
作者說這些額外參數不能通過業務接口來進行傳遞，需要框架支持這種參數傳遞，不太同意，正確的說應該不要影響正常業務接口參數即可。
內部傳參
- 業務內部參數傳遞
- 硬編碼，api接口傳參，也可以通過ThreadLocal傳遞（無線程切換場景）；
- 業務編排引擎對業務進行編排，參數通過編排上下文進行；
- 專業的BPM流程引擎進行編排，流程上下文傳遞參數；
- 服務框架內部參數傳遞，內部模塊可能發生線程切換，可以直接把所有參數帶上，也可以通過將一次調用的參數放入框架的context中，後續參數從其中取值；
外部傳參
- 通信協議支持，參考之前的協議設計，在自定義協議中，支持參數的擴展；
- 傳參接口定義，框架提供接口，用於跨進程的參數傳遞，通過context線程變量供傳參使用。
最佳實踐
- 防止參數互相覆蓋，框架的參數不能覆蓋業務參數；
- 參數的生命週期管理，主要是放入context的變量，要記得在調用完成或異常等場景下清理。
服務多版本
服務上線後的功能變更，bug修復，需要多版本管理。
服務多版本管理設計
- 服務提供者：發佈時，支持指定服務的版本號；
- 服務消費者：消費服務的時候，支持指定引用的服務版本號或版本範圍。
- 服務版本號管理，主版本+副版本+微版本
- 服務提供者，服務消費者：
- 服務提供者，發佈服務的時候，指定版本號，對於經常變動的服務，單獨部署發佈；
- 服務提供者引用服務時指定版本號或版本範圍；
- 基於版本號的服務路由
- 服務熱升級
與OSGI的對比
淘寶的HSF基於osgi，挺牛，能把osgi玩好的不容易。
osgi基於插件管理，支持熱部署和熱升級，參考eclipse的插件體系。
不使用osgi的原因很多，最主要的就是學習成本太高，不易理解，實現複雜，而他的有點又可以通過其他技術解決，所以除了淘寶的HSF實在沒聽說太多應用。
服務的多版本管理感覺就是發佈服務和引用服務的時候需要指定版本，不能單靠服務的多版本解決問題兼容性問題，更多的關注點應該放在服務本身的兼容性設計上。
閱讀更多 Java高級架構技術 的文章
