互联网框架的演变

对于互联网的框架，我们主要按照 Dubbo 官网曾经给出的一张图来说明互联网的演变。对于一本讲微服务的图书来说，了解框架的演变是必要的，因为只有了解 “曾经”，才能更好理解当下的框架，做到 “知其然知其所以然”。

图 1.1 是按照规模大小进行划分的框架图，对于每一个具体的框架，后面的章节都会具体描述。

Figure 1. 图1.1 互联网框架的演变图

图1.1 是互联网框架的演变图，目的是让我们更加方便地理解框架的变动。在对象关系映射（Object Relational Mapping, ORM）框架中，我们可以发现只有一个应用程序；模型-视图-控制器（Model View Controller, MVC）框架开始发展成垂直的应用框架；在 RPC 框架中，开始出现微服务；在 SOA 框架中，形成了应用与微服务中心交互的概念。

ORM框架

互联网刚诞生时，服务器成本比较高，访问流量也不多，所有的应用程序被放在一起，然后发布到一台服务器上，如图 1.2 所示。

Figure 2. 图1.2 ORM框架

在图 1.2 中，所有的应用程序都被放在一起，并且文件和数据库也与应用程序被放在一台服务器上。这样将所有功能都部署在一起，不仅可以减少节点部署和成本，而且可减少输入/输出（I/O）的操作，降低网络通信成本。

此时，这种框架可以满足需求。应用中用于简化 “增删改查” 工作，数据访问框架（ORM）是关键的一环，因此这种框架被我们称为 ORM 框架。

MVC框架

当访问量开始增加时，单一应用 ORM 框架已经不能满足需求，从而成为互联网发展的瓶颈。此时，开发人员想到新的方式来解决，将原本的单个应用拆成互不相干的几个应用，以提升效率，分散流量压力。通过图 1.3 可以看到，每个应用都是垂直的，因此，也被称为垂直应用框架。在这种情况下，通过增加机器，我们可以把曾经的单一应用系统分解成子模块，分到各个服务器上。每个子模块都是按照 MVC 框架进行分层的，就是常说的展示层、控制层以及数据库访问层。

Figure 3. 图1.3 MVC框架

此时，用于提高前端页面开发效率的互联网框架（MVC）是关键，所以，我们常称这种框架为 MVC 框架。经典的 MVC 垂直应用框架，通常分为三层。

数据库访问层（M）：包含业务数据和执行逻辑。
展示层（V）：向用户展示进行用户交互的界面。
控制层（C）：用于接收前端的请求，控制后台进行业务处理。

标准的 MVC 框架并不包括数据库访问层，这里不单独进行说明。通常，在 MVC 框架中还有专门的 ORM 框架，这部分一般被放在数据库操作层中，用来屏蔽对底层数据源或者数据库连接池的实现，并直接提供给 Service 对数据库进行访问，以提升开发效率。

MVC 框架可以在单台服务器进行部署，也可以在多台服务器进行部署。但通常情况下，我们会遇到更复杂的并发场景，以及更大的访问流量，这时可使用多台服务器进行集群部署，并采用 Nginx 等技术进行负载均衡处理。虽然这个框架很不错，但也有其缺点。

在应付复杂的业务场景时，开发和维护的成本大大增加。
在每个应用中，公共功能重复开发，重复代码多，不利于团队合作。
系统的可靠性差，节点的故障会使得整个系统出现雪崩效应。
系统开发完成后，对其维护困难，并且在定制化的时候，修改代码会影响整个系统。

那是否还有更好的框架？

RPC框架

在特定时期，MVC 框架扮演了重要的角色。上文说过，MVC 框架中有一些程序在几个垂直的应用中被重复开发，有些浪费。因此，当垂直应用越来越多时，重复的代码就会越多。所以，开发人员开始把核心业务抽取出来，作为独立的服务使用，并做成一个稳定的服务中心。同时除了核心业务之外，开发人员开始将更多的公共的应用程序接口（Application Programming Interface, API）抽取出来，作为独立的公共服务给调用者调用消费，最终实现服务的共享和重用。这样解决了垂直应用的代码重复问题，也使得前端能够更快地响应市场需求。

然后，根据上文的说法，我们可以抽象出两个重要的对象，分别是提供者和消费者。但实际上，图1.4 才是常见的 RPC 框架，它多一个注册中心（Registry）。

Figure 4. 图1.4 RPC 框架图

在普及 RPC 原理之后，很快就有很多 RPC 框架涌现，在后面介绍的 Dubbo 就是 RPC 框架中的典型代表。RPC 这种通信方式的框架，屏蔽了底层的传输协议（TCP/UDP）、序列化技术（XML /Json / ProtoBuf）和通信细节。图 1.4 只是一幅抽象的原理框架图，那么底层的 RPC 原理是什么？

图1.5 是 RPC 的底层原理图，学习它有利于帮助我们区分 HTTP 的通信方式。

Figure 5. 图1.5 RPC框架

在图1.5 中可以看到，RP 框架主要分为 RPC Server 与 RPC Client 两个部分，这里没有注册中心，说明了 “直接更加纯净” 的原理。

在两个终端中，服务方通过 RPC Server 导出 export 远程接口方法，而消费方通过 RPC Client 引入 import 远程接口方法。在内部，RPC 框架采用接口的代理实现，具体也是两个方面，调用委托给代理 RPC Proxy，然后代理封装调用信息并将调用转交给 RPC Invoker 去实际执行。

在这里还有一个比较重要的点，就是服务方与消费方的通信。在客户端，RPC Invoker 通过连接器 RPC Connector 维持与服务端的通道 RPC Channel，并使用 RPC Protocol 进行协议编码，然后把编码后的请求消息由通道 RPC Channel 发送到服务方。在服务端，接收器 RPC Acceptor 接收来自客户端的调用请求，同样使用 RPC Protocol 执行协议解码，然后把解码后的调用信息传递到 RPC Processor 控制调用过程，最后委托调用给 RPC Invoker 执行并返回调用结果。

本地应用通过暴露接口和远程服务的方式去调用，但是在大规模服务时，会出现以下情况。

大量的服务配置难以管理。
服务间的依赖关系错综复杂，难以分清哪个应用要在哪个应用前启动。
服务的调用量越来越大，服务的容量难以估计。

SOA框架

SOA 是一个组件模型，是一种粗粒度、松耦合，以服务为中心的框架，接口之间通过定义明确的协议和接口进行通信。

通过上面的定义，我们可以看到，这个框架的重点是以服务为中心。SOA 框架以服务为中心，应用直接变成分布式。大规模系统的框架设计原则就是尽可能地拆分，以达到更好的独立扩展与伸缩、更灵活的部署、更好的隔离和容错、更高的开发效率。其核心为分布式框架，拆分策略是横向拆分与纵向拆分。

为了方便说明 SOA 框架，这里展示其业务横向拆分的框架，如图 1.6 所示。

Figure 6. 图1.6 SOA框架

从图 1.6 可以看出，上层是应用系统，中层是暴露的各种接口，底层则是数据库。读者可对比图 1.1 进行理解，外加上文的说明，就能知道 SOA 框架的优点。