服務框架是系統從集中式過渡到分佈式的基礎服務和條件，需要在分佈式系統之前就遷移、準備完畢；服務框架是解決應用服務化的問題
3.1 網站功能持續豐富後的困境和應對
一個網站在經歷一個快速發展的時期，當每天有百萬級別的有效訪問量(購網網站的成交單數量)；系統基本會演化成下面的系統：
系統按照功能分成幾個“巨大”的應用，每個應用都可以訪問底層的基礎系統；比如db/分佈式緩存、搜索系統、分佈式文件系統,應該說這樣的結構足夠的清晰、簡單、解決大部分問題.
但是隨着訪問量的持續增加，最簡單的方式是增加應用的機器，但是這樣會增加DB 的壓力，因爲主要一臺DB 支撐寫，所以最終還是要進行DB中間件進行分庫、分表；隨着開發人員越來越多，每個應用的代碼也變的無比巨大、臃腫；很多重複、冗餘的代碼。這樣就會採取分拆應用的方案，應用分拆有2種方案：
- 簡單的分拆應用，所有應用都直接訪問底層系統
這樣的分拆簡單，但不能解決數據庫的連接壓力和代碼重複、冗餘的問題，所以採用下面的一種方案
- 在應用和底層系統中間加上一層服務層
這就是我們說的服務化的方案，在應用層和底層數據庫層加上服務層，真正系統中服務層可能是多層，彼此之間可以相互調用。
服務化的優點：－-> 可以理解爲微服務化
- 從整體結構上看：架構更清晰、更立體
- 穩定性上看：散落在各個應用中重複的代碼也變成了服務，有統一的團隊進行維護；保證代碼的質量
- 因爲服務的代碼穩定、發佈次數也會變少或者限制，一定程度上也增加了系統的穩定性
- 底層的系統資源也由服務層統一管理，結構清晰、提高效率
- 高擴展性：隨着業務的發展，應用數量會越來越多，服務化後可以讓應用更加快速的開發 【中臺策略】
3.2 服務框架的設計與實現
3.2.1 應用從集中式走向分佈式遇到的問題
先來看看服務框架要解決的問題：
在做服務框架時，我們用的最基礎的知識是網絡通信，在遠程網絡通信時我們需要把發送的數據進行編碼，服務端收到請求數據先解碼然後進行相關的處理；
- 單機單進程的調用
- 遠程服務、調用客戶端
- 服務端的僞代碼實現：
3.2.2 RPC 調用的流程方式
