传统的项目遗留额外难题：
| 代码重复率高； |
| 需求变更（开发维护）困难； |
| 部署效率低； |
| 学习成本高； |
| 团队协作效率差，部分功能重复开发； |
| 系统可靠性变差； |
| 维护和定制困难； |
| 新功能上线周期变长； |
| 缺乏统一的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框架应用场景不同，因此技术选择也会存在很大差异。 |
|
|
|