服務框架

服務框架：解決應用服務化問題

• 代碼臃腫複雜

• 拆分後，數據庫鏈接還在，存在重複代碼

服務化框架設計與實現：

• 規則器
• 軟硬負載均衡
• 名稱服務

• 調用者實現

• 服務端實現

服務框架倆重要問題：

1. 自身部署問題
   • 方案一：服務框架做爲應用依賴jar 包一塊兒打包
   • 方案二：服務框架做爲容器一部分  
   • 方案三：服務框架做爲容器來部署應用
2. 自身的jar 包和應用的jar 包衝突問題
   • 服務框架和應用各自獨立的ClassLoader，這樣jar 包被隔離

• 遠程通訊

• 集羣方案

• 中間代理來解決遠程服務調用

• 控制器的方式解決遠程服務調用

• 基於接口、方法、參數的路由

• 路由規則集中管理，將不一樣的接口路由到不一樣的服務器
  • 能夠在細分，基於具體方法路由

• 同城機房

• java 自己的序列化
  • 存在性能問題和跨語言問題
• 能夠考慮使用json、xml、二進制流序列化

網絡通訊實現選擇

• IO線程專門負責和socket 打交道
• 請求線程把數據放入數據隊列後，產生通訊對象放入通訊隊列，而且在隊列上等待
• 通訊對象在超時前有返回對象會喚醒請求線程
• 定時任務負責處理超時請求

支持多種異步服務調用方式

• oneway方式異步調用
  • 單向通知
• 不關心是否返回數據

• callback 方式異步調用
  • callback 的執行不在原請求線程中
• 請求發送後繼續執行本身的程序，設置回調

• Future 模式異步調用
  • 請求執行結果仍在原線程中

• 可靠方式異步調用
  • 須要保證異步請求在遠端被執行，通常經過消息中間件保證

一個請求調用多個遠程服務

• 變成並行服務（Future 模式）

服務提供端

• 服務端工做包括
  • 對本地服務的註冊管理
  • 根據進來的請求定位服務並執行

•  

• 執行不一樣服務的線程池隔離

服務升級

• 接口中增長方法
• 接口中某些方法修改調用參數列表
  • 應對方式：
    1. 對使用原來方法代碼都進行修改，而後和服務端一塊兒發佈
       • 不太可行
    2. 經過版本號解決
       • 比較經常使用，調取根據版本號，互不影響
    3. 設計方法上考慮方法的擴展性
       • 會使得參數校驗過於複雜
• 有了服務框架，集中式系統很容易變成分佈式框架

• 分佈式環境請求合併

• 引入分佈式須要解決新的問題

服務治理

• 管理服務
  • 管理須要去操縱、控制整個分佈式系統中的服務
• 查看服務
  • 看運行時的狀態，或一些具體信息、歷史數據等

ESB 和服務框架區別

1. 服務框架是點對點模型；ESB是總線模型
2. 服務框架基本上面對的都是同構的系統，不須要考慮整合
   • ESB更多考慮不一樣廠商提供服務的整合

總結：：：