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、序列化与反序列化: