爲什麼使用服務框架：應用直接訪問底層的服務（數據庫，緩存，分佈式文件系統，搜索引擎等）足夠解決問題，比如商品模塊訪問底層服務，交易模塊訪問底層服務，它們都會用到用戶相關的功能，會有很多代碼冗餘且不利於管理。在應用和底層間添加服務，可以使結構更爲清晰，提高穩定性，避免代碼冗餘。
服務框架的設計和實現：
本地調用變爲遠程調用：服務框架客戶端從上到下依次爲：接口調用，尋址路由，編碼，通信，服務端從下到上依次爲：通信，解碼，實例定位，服務調用。
客戶端實現過程：
獲取可用服務地址列表和確定要調用的目標機器：這可以藉助控制器實現。
構造請求數據包，也就是將對象變爲二進制數據，也就是常說的序列化。
利用Socket通信，把序列化後的數據發送過去。等待遠程服務的調用以及結果的返回。
反序列化，得到執行結果。
服務端實現過程：
持續接受請求並處理：
對於接收到的數據，首先進行反序列化得到請求對象，從而得到服務名稱，服務版本號，需要調用的方法以及參數，以及調用的連接。
定位服務，根據服務註冊表得到具體的實例，進行服務調用，通過反射實現。
序列化後返回。
服務調用端的具體設計和實現：
確定服務框架的使用方式：通過Spring配置客戶端Bean，因爲JAVA有動態代理的支持，因此可以使用一個通用的對象。在具體調用發起時，其實時調用了Bean爲具體接口產生的一個動態代理對象。該動態代理對象在被調用後會進行如同服務請求方的處理，完成尋址等工作。
存在問題：
服務框架的部署問題：一是把服務框架作爲應用的一個依賴包，如果升級服務框架需要更新應用。二是把服務框架作爲容器的一部分，例如針對JBOSS，可以通過MBean實現服務框架的啓動，將其部署爲一個sar包來爲應用提供服務。
jar包衝突問題：將服務框架自身用到的類和應用用到的類都控制在User-Defined ClassLoader級別，這樣就實現了相互間的隔離。
服務調用者和提供者間通信方式的選擇：控制器的實現。
序列化反序列化的實現：可以使用java序列化，也可以使用XML作爲序列化方式。
網絡通信實現選擇：
同步方式調用NIO，
異步服務調用方式：
OneWay：只管發送請求不關心結果；
CallBack：請求方發送請求後會繼續執行自己的操作，等對方有響應時進行回調；
Future：跟CallBack差不多，但是能主動控制超時，獲取結果。
可靠異步：保證異步請求能在遠程被執行，一般通過消息中間件來完成。
服務提供端的設計和實現：
通過Spring暴露爲遠程服務。