互联网架构演进

前言

        互联网时代发展至今，网站架构已经经历了多次的演进，究其原因无外乎以下两点：

        l 用户越来越多，意味着并发要求越来越高

        l 数据越来越多，意味着存储挑战越来越大

 

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

正文

单体架构(MonolithsArchitecture)

        单体架构是指业务功能的实现全部在一个进程（process）内完成。用户请求的接收，相关业务逻辑的调用，从数据库中获取数据等处理全部在一个进程内完成，如图1所示，最终打包成一个WAR包，放入tomcat等web容器里运行。

1     适用场景：

        单体架构适用于哪些场景？

        l 创业初期，人手紧张，又需要快速完成业务需求。

        l 对性能要求极其苛刻场景，哪怕请求慢1ms都无法接受（比如在金融行业，量化交易场景，响应时间就是生命线）。

图1单体架构

 

2     单体架构的优点：

        l 请求响应延迟低，接收客户端请求，经过一次网络交互从数据库批量获取数据，其余的功能全部在进程内完成，避免了多次网络交互。

        l 仅一个进程，部署和运维成本小。

 

3     单体架构的缺点

        l 业务功能单元间耦合严重、扩展性差、技术选型单一（在一个进程内是否可以采用多种开发语言？）等。

        l 单体架构最大的问题是架构粒度过粗，导致系统迭代速度快不起来。互联网业务又是持续高速发展的业务，采用单体架构很难满足需求。

 

        单体架构需要按照某些维度进行拆分：按照系统水平方向进行拆分（水平分层架构）、按照业务功能垂直拆分（SOA架构）、既按照业务功能垂直拆分又按照系统水平方向进行拆分（微服务架构）。

水平分层架构(Horizontallayered Architecture)

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

图2水平分层架构

 

        水平分层架构分为网关层、业务逻辑层、数据访问层以及DB/Cache。每一层都是独立的进程，每个进程职责分明。

1.   分层描述

1.1   网关层

        网关层接收客户端请求，对请求合法性校验以及鉴权、对请求根据URI路由转发到相应的业务逻辑层

1.2   业务逻辑层

        业务逻辑层负责请求具体的业务逻辑处理，在微信端发送消息给好友，业务逻辑层会对发送消息进行黄反等策略检查、会校验发送者的权限（你遇到过“消息已发送，被对方拒收”的情况吗？）、判断接收方是否在线等等。

1.3  数据访问层

        业务逻辑层不会直接和数据库交互，它需要的数据通过数据访问层获取。数据访问层有三部分功能构成：

        l 第一是ORM，接收业务逻辑层发送的数据协议（JSON等文本协议或者PB等二进制协议）转换成SQL协议；

        l 第二是Sharding，数据库存储数据超过千万级别时，为了进一步提升性能，会按照业务功能垂直拆分库以及水平方向拆分表。因此在此层提供分库分表支持，对业务逻辑层透明，使之无感知。

        l 第三是随着业务请求量继续增大，Sharding后依然无法满足性能需求，进一步增加Cache功能，对业务逻辑层透明。存储层往往使用MySQL提供关系存储，使用Redis提供缓存。

 

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

 

2.   异步化水平分层

图3异步化水平分层架构

 

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

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

 

面向服务化架构(SOAArchitecture)

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

图4 SOA架构

 

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

        SOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。

        基于这些基础的服务，可以将业务过程用类似BPEL流程的方式编排起来，而BPEL反映的是业务处理的过程，这些过程对于业务人员更为直观，调整也比hardcode的代码更容易。

         当然企业还需要对服务治理，比如服务注册库，监控管理等。

         我们知道企业计算领域，如果不是交易系统的话，并发量都不是很大的，所以大多数情况下，一台服务器就容纳将许许多多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中。虽然说是面向服务了，但还是单一的系统。

微服务架构(MicroServicesArchitecture)

        服务架构的出现，解决了水平分层架构以及SOA架构拆分不彻底的问题。微服务架构是Martin Fowler 在2014年提出的架构模式（如图5）。

图5 微服务定义

 

        微服务首先按照业务领域模型垂直拆分，即根据不同的业务功能单元进行垂直拆分。对垂直拆分后的服务，在水平方向继续进行拆分。

1.   特点

        微服务架构有如下特点：按照业务领域拆分服务、一系列小服务构成、服务独立部署、独立运行、服务间去中心化管理（任何一个服务都可以采用任何开发语言 C/PHP/Go/Java等，也可以运行于任何的平台Linux/Windows等）。

2.   例子

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

图6 微服务架构

3.  微服务架构组成元素

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

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

4.  为服务架构的缺点

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

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

        能否让业务开发人员仅关注业务开发，服务间通讯以及请求管理功能不再关心？服务网格架构解决了这个问题，让业务开发人员真正解脱。

 

服务网格架构(ServiceMesh Architecture)

1.   定义

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

图7服务网格定义

 

        如果用一句话来解释什么是服务网格，可以将它比作是应用程序或者说微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用服务网格也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。

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

2.   特点

        Service mesh有如下几个特点

        l 应用程序间通讯的中间层

        l 轻量级网络代理

        l 应用程序无感知

        l 解耦应用程序的重试/超时、监控、追踪和服务发现

3.   理解服务网格

        我们来看一个例子，如图8:

图8 服务网格例子

 

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

        继续来看一下服务网格的架构，如图9:

 

图9 服务网格架构

 

        服务网格作为 sidecar 运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在服务网格中实现。

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

4.  未来

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

        无服务器(Serverless)计算（如Amazon的Lambda）正好需要Service Mesh的命名和链接模型，这让Service Mesh在云原生生态系统中的角色得到了彰显。服务识别和访问策略在云原生环境中仍显初级，而Service Mesh毫无疑问将成为这方面不可或缺的基础。就像TCP/IP一样，Service Mesh将在底层基础设施这条道上更进一步。

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

总结

        互联网架构的演进，看似简单，但这其中凝聚了无数IT人的努力和智慧。不断增长的业务需求是技术发展的动力，期待将来会有更多更好的互联网架构诞生。