随着计算机软件的发展，不同的应用在落地，应用架构随着规模的越来越大，也在一步步的进行演进，从最初的单体架构，到后来的集群，然后分布式架构一步步的发展着。

架构演变

整个过程是重单体架构向微服务发展的过程，下面我们来看看每一代架构的发展。

单体架构

以前使用 Laravel 做 web 项目时，是根据 MVC 去划分目录结构的，即 Controller 层处理业务逻辑，Model 层处理数据库的 CURD，View 层处理数据渲染与页面交互。以及 MVP、MVVM 都是将整个项目的代码是集中在一个代码库中，进行业务处理。这种单一聚合代码的方式在前期实现业务的速度很快，但在后期会暴露很多问题：

1、开发与维护困难：随着业务复杂度的增加，代码的耦合度往往会变高，多个模块相互耦合后不易横向扩展。
2、效率和可靠性低：过大的代码量将降低响应速度，应用潜在的安全问题也会累积。

单体架构最终走向了单体地狱，比如

1、代码全量编译成一个实例，因为一个模块的问题可能会导致全量的模块不能使用
2、问题难以地位，比如有一个死循环，会导致cpu占用100%，还会影响机器上其他的应用的使用，同时，很难知道是哪个模块出问题
3、代码量大，可能编译启动就需要很长时间，到最后就不可维护了，而且线上出问题就没办法处理了，因为重启都需要很长的时间

在这个时候我们使用的组织架构就是最简单的前台-后台在一个实例进程中。

垂直拆分的垂直架构

单体架构的瓶颈太严重了，变的越来越臃肿，每次开发业务，都要将全部功能进行回归，于是就将前后端进行拆分成不同的进程，通过报文进行相互调用，在一定程度上实现了解耦，但是其实并没有很强的水平扩展的能力，所以还算是单体架构。

在这个时候我们使用的组织架构还是最简单的架构前台-后台,但是前台后台已经运行在不同的实例中，实现了一定的解耦，由最初的mvc的api的调用，变成了http的调用模式。

但是随着规模越来越大，每个模块很快各种瓶颈有出现了，需要进行各种水平扩展，这个时候就需要进行服务化，使用分布式系统了。

集群

架构经过了垂直拆分，已具有一定的解耦性，但是随着规模的扩展，每个流程都出现了单机处理的瓶颈，需要进行水平扩展，这时候就需要集群来并行共同处理业务来提高处理的能力。

这个时候我们使用的组织架构还是最简单的架构前台-后台，但是后台已经有了进一步的垂直拆分和水平扩展，随着拆分扩展的越来越多，也就有了微服务的概念，下一代架构的诞生。

第一代微服务—服务化

现在传统的mvc架构带来的单体问题已经十分严重了，基本上已经不再使用了，提倡微服务的思想。

第一代微服务架构是建立在服务化的基础之上的，什么是服务化？核心就是不同服务之间的通信，一种以服务为核心的解决方案。

  • 服务注册
  • 服务发布
  • 服务调用
  • 服务监控
  • 负载均衡

其实简单的说就是将一些服务封装起来，对外提供tcp/http/rpc接口，不需要关心内部的细节，内部有专门的人去维护，就是对这个服务的服务化，这个封装可以是新增一个服务层，也可以是在这个服务的基础提供接口等。

其中最著名的就是SOA的面向服务架构思想。

SOA

SOA是什么？SOA全英文是Service-Oriented Architecture，中文意思是面向服务架构，是一种思想，一种方法论，一种分布式的服务架构。

其实就是每个服务独立治理，相互解耦，服务共享不在重复，通过注册中心来服务发现调用的散装架构。我们最常见的架构就是

  • Spring Cloud为开发者提供了快速构建分布式系统的通用模型的工具（包括配置管理、服务发现、熔断器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态等）
  • Dubbo是一个阿里巴巴开源出来的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，其实主要解决的服务间通信的问题。

在这个时候组织架构就发生了很大的变化，基本都是要加上一层网关或者企业总线，也就是前台-网关（ESB）-后台的结构。

下一代微服务–去中心化

Service Mesh

随着注册中心的出现，任何调用都走网关，网关的瓶颈有到来，于是出现了下一代的微服务架构service mesh，主要落地的项目就是istio，当然还有其他的一些项目，主要是去中心化的设计。

目前流行的 Service Mesh 开源软件有 Linkerd、Envoy 和 Istio，而最近 Buoyant（开源 Linkerd 的公司）又发布了基于 Kubernetes 的 Service Mesh 开源项目 Conduit，来看一下Service Mesh 开源项目简介：

  • Linkerd（https://github.com/linkerd/linkerd）：第一代 Service Mesh，2016 年 1 月 15 日首发布，业界第一个 Service Mesh 项目，由 Buoyant 创业小公司开发（前 Twitter 工程师），2017 年 7 月 11 日，宣布和 Istio 集成，成为 Istio 的数据面板。
  • Envoy（https://github.com/envoyproxy/envoy）：第一代 Service Mesh，2016 年 9 月 13 日首发布，由 Matt Klein 个人开发（Lyft 工程师），之后默默发展，版本较稳定。
  • Istio（https://github.com/istio/istio）：第二代 Service Mesh，2017 年 5 月 24 日首发布，由 Google、IBM 和 Lyft 联合开发，只支持 Kubernetes 平台，2017 年 11 月 30 日发布 0.3 版本，开始支持非 Kubernetes 平台，之后稳定的开发和发布。这个在我们k8s基础平台中最常使用。
  • Conduit（https://github.com/runconduit/conduit）：第二代 Service Mesh，2017 年 12 月 5 日首发布，由 Buoyant 公司开发（借鉴 Istio 整体架构，部分进行了优化），对抗 Istio 压力山大，也期待 Buoyant 公司的毅力。
  • nginMesh（https://github.com/nginmesh/nginmesh）：2017 年 9 月首发布，由 Nginx 开发，定位是作为 Istio 的服务代理，也就是替代 Envoy，思路跟 Linkerd 之前和 Istio 集成很相似，极度低调，GitHub 上的 star 也只有不到 100。
  • Kong（https://github.com/Kong/kong）：比 nginMesh 更加低调，默默发展中。
  • go-micro是基于Go语言实现的插件化RPC微服务框架，与go-kit，kite等微服务框架相比，它具有易上手、部署简单、工具插件化等优点。go-micro框架提供了服务发现、负载均衡、同步传输、异步通信以及事件驱动等机制，它尝试去简化分布式系统间的通信，让我们可以专注于自身业务逻辑的开发。所以对于新手而言，go-micro是个不错的微服务实践的开始。

在云原生模型里，一个应用可以由数百个服务组成，每个服务可能有数千个实例，而每个实例可能会持续地发生变化。这种情况下，服务间通信不仅异常复杂，而且也是运行时行为的基础。管理好服务间通信对于保证端到端的性能和可靠性来说是无疑是非常重要的。种种复杂局面便催生了服务间通信层的出现，这个层既不会与应用程序的代码耦合，又能捕捉到底层环境高度动态的特点，让业务开发者只关注自己的业务代码，并将应用云化后带来的诸多问题以不侵入业务代码的方式提供给开发者。

这个服务间通信层就是 Service Mesh，它可以提供安全、快速、可靠的服务间通讯（service-to-service）。

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

电商系统的演进

我们结合上面的架构演进，通过我们最常见的电商系统来看单体到分布式的变化：

单体

当我们的项目比较小时，我们只有一个系统，并且把他们写到一起，放在一个服务器上，但是随着平台越来越大，数据量越来越大，我们不得不通过分库，把多个模块的数据库分别放在对应得服务器上，每个模块调用自己的子系统即可。

集群

当后台单台没有办法承受的时候，我们需要堆机器来水平扩展集群来处理问题，但是一连串的流程都是在一个实例中进行。

ESB

随着我们系统的进一步复杂度的提示，在集群的基础上，我们不得不进一步对系统的性能进行提升，我们将多个模块分成多个子系统，多个子系统直接互相调用（因为SOA一般用于大型项目，比较复杂，所以一般总系统不会再集成，会拆分多个，分别做成服务，相互调用）。当我们的电商UI进行一个下订单的任务时，多个服务直接互相调用，系统通过数据总线(java的ESB，其实也就是我们所说的网关)，分别调用对于的子系统即可。

  • 企业数据总线：企业数据总线不是对多个子模块的集成，他在这里充当数据通道的作用，数据总线不关心业务，数据总线根据给的地址和协议去调服务，上端不关心服务在哪里是什么，只找数据总线。

    数据总线是起到调度服务的作用，数据总线不是集成服务，数据总线更新一个调度框架，每个服务需要根据约定向数据总线注册服务，那么如何注册那？其实数据总线就像一个字典结构，

    数据总线里面一个key对于一个value，key指的是服务名，value则是服务的调度方式，还有一点需要说明的是，数据总线只是指路人，服务是不经过数据总线的，如上图的黄色线的路径。

    数据总线通过域名解析实现:一个域名绑定多台服务器，ajax也可以，dns也可以，解析域名嘛。

    其实数据总线还有一些高级应用，比如心跳检测，实现负载均衡等等，就不细说了，目前应用数据总线的有阿里的dubbo,还有zookeeper。

  • 这个时候组织架构加上了企业总线前台—ESB—后台的结构。

随着企业发展到一定程度，需要规范化管理的时候，我们上了ERP系统，要通过供应链建设B2C业务的时候，我们上了SRM系统，仓储管理到一定规模我们上WMS，物流管理我们上TMS……整个公司各个系统功能有重叠，有交叉，内部协同成了重大问题。

这就好像我们一直在打是局部信息化战争，头痛医头脚痛医脚，需要解决什么样的问题，就上什么样的系统，最终就形成了所谓烟囱式的系统架构。

导致整个架构重复造轮子，跨系统管理也给运营人员造成了不必要的时间精力浪费。整个系统管理冗杂又造成资源浪费，这时候就需要将原有的系统规范化、一体化，通过数据总线进去进行深度的整合，打通各个信息孤岛，形成前后贯通的信息化建设。

我们把这个时代称之为ESB数据孤岛时代。

大部分情况下基本上都是够用，虽然ESB很重，核心很难改变，不够灵活，但是随着发展，出现了更加灵活的方式。

大中台

其实中台严格意义上来说，不是一种架构，也不是一种系统，而是一种战略。即可以使用第一代微服务架构来构建，也可以使用第二代微服务架构来构建，目前各大企业也正在容器化推进的过程中

中台的核心价值是在于，在对企业业务有了柔性支撑和贯通的前提下，再形成协同与智慧的运营体系。

一般企业架构分成了三个层次：前台、中台、后台。中台又分成三大块，业务中台、数据中台和技术中台。

技术中台支撑企业业务发展，通过打通企业内异构系统，支持业务中台；

业务中台围绕公司业务运营进行服务，将获取的多维度数据传递给数据中台，由数据中台分析反馈给业务中台，以优化业务运营。同时数据中台通过BI智能分析，帮助企业管理者更好的做决策分析。三者是相辅相成，相互协作的。
业务中台其实就是把原有的前端的会员中心、营销中心、商品中心，后端的供应链中心、采配中心等重点模块放在业务中台模块，以后前端不管对接多少个第三方，线上线下增加多少家门店，都能进行统一会员、统一商品编码、统一供应链整合，整个系统一体化。真正做到用技术支持业务，通过业务收集大量数据进行决策，统一高效的进行管理。

数据中台：一般指以数据采集、数据集成、数据治理，指标体系和数据仓库统一建设等数据管理活动为典型特征的中台。

当前最需要建设的中台有两种：

狭义的业务中台：一般指在线业务为典型特征的中台。在OLDI（Online Data-Intensive）时代，越来越多的企业的核心业务都是在线业务，因此把在线业务中台简称为业务中台。
数据中台：一般指以数据采集、数据集成、数据治理，指标体系和数据仓库统一建设等数据管理活动为典型特征的中台。

对业务中台来说，比较符合的场景主要有：

业务系统研发团队至少大几十人（含外包的），需求多变化快，系统又涉及多个领域（比如做ERP、电商的），业务逻辑比较复杂。
这时业务中台可以把系统和业务领域划分清楚，提高研发效率。做相似行业的外包项目为主，业务规模也做的比较大的（一年有两位数的项目）。
这时业务中台可以提升软件复用，降低定制化成本，提高研发效率。如果每个项目都完全不一样，那中台也救不了你。

支持业务中台的技术体系，包括微服务、DevOps、云原生和分布式事务等。

将需求设计成微服务架构，然后每个服务使用各种技术栈来开发业务，比如golang的技术栈的高并发的特性来开发web服务等，然后将一些统一的模块进行统一的接入和输出，使用devops的开发模式，在业务中还是需要解决分布式事务等问题。

比如在网易，是网易轻舟微服务平台，提供微服务应用全生命周期的完整支持，包括下一代微服务Service Mesh支持、经典微服务框架NSF、包括CI/CD的DevOps、分布式事务框架GXTS、APM、API网关、GoAPI全自动化测试以及容器应用管理服务等。

对数据中台来说，比较符合的场景：

数据产品比较多，每天要看数据如果没数据就不知道怎么工作的运营人员比较多的业务。
比如电商就是典型。尤其是数据产品和运营人员还在多个团队。
用数据的姿势比较复杂，问题比较多，比如经常出现指标不一致、数据出错、想要的数据不知道哪里有等问题。

支持数据中台的技术体系，包括指标管理、数据服务、元数据管理、数仓开发与管理、数据安全管理、数据资产管理、大数据计算引擎、数据集成/同步/交换引擎等，

其实数据中台就是将数据进行处理，不同数据资源，统一的输出标准，中间用到大部分就是数据引擎，比如kafka队列，sprak，flink等流式引擎，hadoop，hbase和hive等大数据引擎。

比如在网易，是以网易猛犸为核心的网易全链路数据中台解决方案。