互联网架构究竟如何演进？

自身“捣鼓”架构多年，也时常与人交流架构的魅力。今天就互联网架构演进聊聊我的看法。

在我看来，互联网架构经历了单体架构、水平分层架构、面向服务架构、微服务架构以及服务网格架构等几个不同阶段，每个架构有什么特点？这些架构间有什么不同？为什么要演进？让我们一探究竟！

单体架构(Monoliths Architecture)

单体架构是指业务功能的实现全部在一个进程（process）内完成。二手交易平台标配的商品推荐功能，单体架构接受APP客户端发送的请求、从数据库获取推荐商品、对推荐的商品列表过滤／排序等业务处理全部在一个进程里完成，如图1所示，最终打包成一个WAR包，放入tomcat等web容器里运行。

图1 单体架构

单体架构的优点第一请求响应延迟低，接收客户端请求，经过一次网络交互从数据库批量获取数据，其余的功能全部在进程内完成，避免了多次网络交互。第二仅一个进程，部署和运维成本小。

那么单体架构适用于哪些场景？第一创业初期，人手紧张，又需要快速完成业务需求。第二是对性能要求极其苛刻场景，哪怕请求慢1ms都无法接受（比如在金融行业，量化交易场景，响应时间就是生命线）。

单体架构的缺点也非常明显，业务功能单元间耦合严重、扩展性差、技术选型单一（在一个进程内是否可以采用多种开发语言？）等。

单体架构最大的问题是架构粒度过粗，导致系统迭代速度快不起来。互联网业务又是持续高速发展的业务，采用单体架构很难满足需求，系统架构如何演进？单体架构需要按照某些维度进行拆分：按照系统水平方向进行拆分（水平分层架构）、按照业务功能垂直拆分（SOA架构）、既按照业务功能垂直拆分又按照系统水平方向进行拆分（微服务架构）。

水平分层架构(Horizontal layered Architecture)

对单体架构在水平方向进行拆分，就会演变成水平分层架构，水平分层架构解决了单体架构存在的高耦合、低扩展性的问题，如图2：

图2 水平分层架构

水平分层架构分为网关层、业务逻辑层、数据访问层以及DB/Cache。每一层都是独立的进程，每个进程职责分明。其中网关层接收客户端请求，对请求合法性校验以及鉴权、对请求根据URI路由转发到相应的业务逻辑层；业务逻辑层负责请求具体的业务逻辑处理，在微信端发送消息给好友，业务逻辑层会对发送消息进行黄反等策略检查、会校验发送者的权限（你遇到过“消息已发送，被对方拒收”的情况吗？）、判断接收方是否在线等等。业务逻辑层不会直接和数据库交互，它需要的数据通过数据访问层获取。数据访问层有三部分功能构成：第一是ORM，接收业务逻辑层发送的数据协议（JSON等文本协议或者PB等二进制协议）转换成SQL协议；第二是Sharding，数据库存储数据超过千万级别时，为了进一步提升性能，会按照业务功能垂直拆分库以及水平方向拆分表。因此在此层提供分库分表支持，对业务逻辑层透明，使之无感知。第三是随着业务请求量继续增大，Sharding后依然无法满足性能需求，进一步增加Cache功能，对业务逻辑层透明。存储层往往使用MySQL提供关系存储，使用Redis提供缓存。

大家熟知的MVC架构，本质上是水平分层架构，分为Model层、View层、Control层。水平分层架构分层不易过多，每增加一层，请求响应延迟相应会增加；分层越多，定位线上问题难度越大。根据业务使用场景的不同，常常对水平分层架构分为三层（MVC）、四层（图2）、五层（图3）。

图3 异步化水平分层架构

图3和图2相比，增加MQ层（消息队列层），APP端更新请求经过网关层后持久化到MQ层，返回给APP端。业务逻辑层从MQ层读取更新请求消费。在架构上，通过MQ层把更新请求的处理进行了异步化。图3即变成了异步化水平分层架构。采用异步化水平分层架构，提升了系统整体吞吐量。在社区等高并发业务场景适合异步化架构。异步化架构会带来数据处理的延迟情况，因此对数据一致性要求苛刻的业务场景，比如金融、支付等，异步化架构不适合，这些场景常使用图2同步水平分层架构。

水平分层架构解决了单体架构的问题，它存在明显问题是每层粒度过粗，在每一层并没有按照业务功能单元进一步垂直拆分。

面向服务化架构(SOA Architecture)

单体架构按照业务功能在垂直方向进行拆分，就变成了SOA架构，如图4:

图4 SOA架构

图4按照业务功能单元进行拆分，分为了交互服务、信息服务等，每一个服务都是单体，单体服务之间通过企业服务总线（ESB）进行交互。可知SOA架构仅进行了垂直方向拆分，对每个服务并没有按照水平方向进一步拆分，因此SOA架构拆分也不彻底。

微服务架构(MicroServices Architecture)

服务架构的出现，解决了水平分层架构以及SOA架构拆分不彻底的问题。微服务架构是Martin Fowler 在2014年提出的架构模式（如图5），微服务架构有如下特点：按照业务领域拆分服务、一系列小服务构成、服务独立部署、独立运行、服务间去中心化管理（任何一个服务都可以采用任何开发语言 C/PHP/Go/Java等，也可以运行于任何的平台Linux/Windows等，理想是丰满的，现实呢？）。微服务首先按照业务领域模型垂直拆分，即根据不同的业务功能单元进行垂直拆分。对垂直拆分后的服务，在水平方向继续进行拆分。

图5 微服务定义

二手交易平台转转，包括了用户功能、商品功能、交易功能、搜索功能以及推荐功能。各个业务单元相对独立，首先按照业务垂直拆分成用户、商品、交易、搜索、推荐微服务。对每一个功能单元（商品等），继续进行水平拆分，分为商品网关层、商品业务逻辑层、商品数据访问层、商品DB/Cache，对用户、交易、搜索、推荐等业务同样方式进行水平拆分，最终微服务架构如图6:

图6 微服务架构

那么典型的微服务架构由哪些元素组成？如图6，包括网关、微服务业务逻辑层（聚合层）、数据访问层（原子层）、数据存储、注册中心、配置中心。网关负责请求接入，聚合层用于各种业务逻辑的处理，数据原子层用做数据访问代理，提供ORM、数据Sharding以及屏蔽底层存储的差异性等功能。

因此，第一从业务角度看，微服务架构本质上一个业务架构，对业务了解越深刻，微服务拆分越合理；第二从系统角度看，微服务架构是水平分层架构和SOA架构的结合体。

采用微服务架构后，一方面请求链条变长，对请求响应要求苛刻的场景不适合微服务架构；另一方面服务变多，实施数据一致性的难度变大，对数据要求强一致性的场合也不适合使用微服务架构。

采用微服务架构后，项目能够做到快速迭代，持续交付。微服务架构也存在明显的弊端：开发人员除了关注业务逻辑的实现外，还需要在微服务模块里处理一系列问题，比如服务注册、服务发现、服务通讯、负载均衡、服务熔断、请求超时重试等，这是非常糟糕的。业务开发团队的强项在于业务理解，而不是技术。能否让业务开发人员仅关注业务开发，服务间通讯以及请求管理功能不再关心？服务网格架构解决了这个问题，让业务开发人员真正解脱。

服务网格架构(Service Mesh Architecture)

服务网格由Buoyant公司提出，2017年初Buoyant公司CEO William Morgan给出服务网格的定义如下 （图7）：

图7 服务网格定义

服务网格是一个基础设施层，用于处理服务间通信。对于有着复杂拓扑结构的云原生服务，服务网格负责实现这些服务间请求的可靠传递。在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，并对应用程序透明。

我们来看个简单的例子，如图8:

图8 简单服务网格例子

一个应用请求首先发送给远程的服务网格实例，服务网格完成服务发现、服务通讯、负载均衡等完整调用流程，最后将请求发送给目标服务。

继续看一个复杂的例子，如图9:

图9 复杂服务网格例子

图9左边绿色方格表示服务，右边蓝色的方格表示服务网格，蓝色之间的线表示服务间的调用关系。服务网格连接就形成了一个网络，这就是服务网格名字的由来。

因此服务网格是一个基础设施层，独立于服务之外，对服务透明，实现了请求的可靠传递。有了服务网格，业务开发人员再也不用关注服务发现、负载均衡、服务重试、熔断等，可以专注在业务开发上。

开源的服务网格产品陆续Release出来：来自buoyant公司的Linkerd、来自Lyft公司的Envoy、来自nginx的nginmesh以及来自Google/IBM/Lyft公司的Istio等。最值得关注的当数Isto，出身名门，王者风范，期待Istio像k8s一样成为现象级的重量产品。

服务网格这个词仅出现一年的时间，服务网格产品实施落地还需要一些时间，期待后续继续完善，使业务开发同学能够真正回归业务开发本身。

互联网架构究竟如何继续演进，且行且期待。

We Are Hiring Now.

转转公司基础架构部、大数据部（Hadoop生态构建）、搜索推荐技术部招聘工程师，只要能力强，薪资上不封顶，简历砸过来吧：sunxuan@zhuanzhuan.com

个人简介

孙玄 转转公司基础架构负责人，前58集团技术委员会主席，百度高级工程师，毕业于浙江大学。“架构之美”公众号作者。