應用架構演進《一》
傳統的專案遺留額外難題：
| 程式碼重複率高； |
| 需求變更（開發維護）困難； |
| 部署效率低； |
| 學習成本高； |
| 團隊協作效率差，部分功能重複開發； |
| 系統可靠性變差； |
| 維護和定製困難； |
| 新功能上線週期變長； |
| 缺乏統一的RPC框架：由於web框架只提供了HTTP/https協議，例如soap，smpp等協議棧需要業務自行整合第三方的開源庫岸賈，超時重發，網路斷連等底層故障需要在應用上層統一封裝和處理，工作繁瑣而且容易出錯，對業務開發人員的技能要求也非常高。 |
為了應對複雜的業務，通過業務公共能力抽象成原子服務，對複雜應用進行水平拆分和服務化，實現服務消費者和應用者的解耦。公共能力抽取和複用，可以有效降低公共模組重複開發建設的成本。
傳統的垂直應用架構【LAMP】：
| linux+apache+php+mysql（讀寫分離）； |
| spring+struts+ibatis+hibernate+tomcat ； |
| EJB |
在高併發，大流量的應用場景中，需要做叢集，通常的組網方案是前端通過F5等負載均衡做七層負載均衡（或者使用SLB等軟負載），後端做對等叢集部署。
RPC: remote procedure call ,它是一種程序間通訊方式。允許像呼叫本地服務一樣呼叫遠端服務。它的具體實現方式可以不同，例如：spring的http invoker,facebook 的thrift 二進位制私有協議通訊。
RPC 的原理：prc框架的目標就是讓遠端過程（服務）呼叫更加簡單，透明，RPC框架負責遮蔽底層的傳輸方式（TCP/UDP），序列化方式（xml/json二進位制）和通訊方式。
PRC框架的核心技術點：
| 遠端服務提供者需要以某種形式提供服務呼叫相關的資訊，包括但不限於服務介面定義，資料結構，或者中間態的服務定義檔案。例如thrift 的IDL檔案，ws-rpc的wsdl檔案定義，甚至也可以是服務端的介面說明文件；服務呼叫者需要通過一定的途徑獲取遠端服務呼叫相關資訊，例如服務端介面定義jar包匯入，獲取服務端IDL檔案等。 |
|
| 遠端代理物件： |
服務呼叫者呼叫的服務實際是遠端服務的本地代理，對於Java語言，它的實現就是JDK的動態代理，通過動態代理的攔截機制，將本地呼叫封裝成遠端服務呼叫。 |
| 通訊： |
RPC框架與具體的協議無關，例如spring 的遠端呼叫支援http invoke,rmi invoke,messagepack 使用的是私有的二進位制壓縮協議。 |
| 序列化： |
遠端通訊，需要將物件轉換成二進位制碼流進行網路傳輸，不同的序列化框架，支援的資料型別，資料包大小，異常型別及效能等都不同。不同的RPC框架應用場景不同，因此技術選擇也會存在很大差異。 |
|
|
|