电商系统框架演变

1、单一应用框架（ORM）

当网站流量很小时，只需一个应用，将所有功能如下单支付等都部署在一起，以减少部署节点和成本。

缺点：单一的系统框架，使得在开发过程中，占用的资源越来越多，而且随着流量的增加越来越难维护。

2、垂直应用框架（MVC）

解决了ORM所面临的阔容问题，流量能够分散到各个子系统当中，且系统的体积可控，一定程度上降低了开发人员之间协同以及维护的成本，提升了开发效率。

缺点：在垂直框架中相同逻辑的代码需要不断的复制，不能复用。

3、分布式应用框架（RPC）

当垂直应用越来越多，应用之间交互不可避免，将核心业务提取出来，作为独立的服务，逐渐形成稳定的服务中心。

4、流动计算架构（SOA）

随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体系（SOA），也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。

 

RPC(Remote Procedure Call Protocol)：远程过程调用：

RPC是一种通过网络葱远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据，在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC采用客户机/服务器模式。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

 

RPC需要解决的问题：

1、通讯问题：主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以试按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。

2、寻址问题：A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpointURI，或者是葱UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。

3、序列化与反序列化：