架构新纪元（一）：从分布式架构到云原生架构

信息技术从出现伊始到渐成主流，其发展历程经历了软件、开源、云三个阶段。从软件到开源，再到云，这也是信息技术的发展趋势。

1.软件改变世界

纵观人类社会漫长的发展历程，农耕时代、工业时代与信息时代可谓三个明显的分水岭， 每个时代都会出现很多新兴的领域。作为信息时代最重要的载体，互联网越来越成为当今社会 关注的焦点，互联网的基石之一——软件，正在迅速地改变着这个世界。

2.开源改变软件

随着软件行业的成熟，相比于“重复造轮子”，“站在巨人的肩膀上”明显可以更加容易和 快速地创造出优秀的新产品。随着开源文化越来越被认可，以及社区文化越来越成熟，使用优 秀的开源产品作为基础构架来快速搭建系统以实现市场战略，成了当今最优的资源配比方案。

3.云吞噬开源

仅通过开源产品搭建并运维一个高可用、高度弹性化的平台，进而实现互联网近乎 100% 的可用性，难度可想而知。因此，在提供技术思路的同时，进一步提供整套云解决方案以保障 不断扩展的非功能需求，便成了当今新一代互联网平台的追求。

在信息技术的大潮中，每一次通信模式的升级都会给这个世界的合作模式带来变革。

随着互联网在 21 世纪初被大规模接入，互联网由基于流量点击赢利的单方面信息发布的 Web 1.0 业务模式，转变为由用户主导而生成内容的 Web 2.0 业务模式。因此，互联网应用系统 所需处理的访问量和数据量均疾速增长，后端技术架构也因此面临着巨大的挑战。Web 2.0 阶段的互联网后端架构大多经历了由 All in One 的单体式应用架构渐渐转为更加灵活的分布式应用 架构的过程，而企业级架构由于功能复杂且并未出现明显的系统瓶颈，因此并未跟进。后端开 发不再局限于单一技术栈，而是越来越明显地被划分为企业级开发和互联网开发。企业级开发 和互联网开发的差别不仅在于技术栈差异，也在于工作模式不同，对质量的追求和对效率的提 升成了两个阵营的分水岭，互联网架构追求更高的质量和效率。

随着智能手机的出现以及 4G 标准的普及，互联网应用由 PC 端迅速转向更加自由的移动端。 移动设备由于携带方便且便于定位，因此在出行、网络购物、支付等方面彻底改变了现代人的 生活方式。在技术方面，为了应对更加庞大的集群规模，单纯的分布式系统已经难于驾驭，因 此技术圈开启了一个概念爆发的时代——SOA、DevOps、容器、CI/CD、微服务、Service Mesh 等概念层出不穷，而 Docker、Kubernetes、Mesos、Spring Cloud、gRPC、Istio 等一系列产品的 出现，标志着云时代已真正到来。

从分布式架构到云原生架构

从分布式架构到云原生架构随着虚拟化技术的成熟和分布式架构的普及，用来部署、管理和运行应用的云平台被越来越多地提及。IaaS、PaaS 和 SaaS 是云计算的三种基本服务类型，分别表示关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务，以及关注业务应用的软件即服务。容器的出现，使原有的基于虚拟机的云主机应用，彻底转变为更加灵活和轻量的“容器+编排调度”的云平台应用。

新纪元的分水岭——容器技术

在过去几年里，云平台发展迅速，但其中困扰运维工程师最多的，是需要为各种迥异的开发语言安装相应的运行时环境。虽然自动化运维工具可以降低环境搭建的复杂度，但仍然不能从根本上解决环境的问题。

Docker 的出现成为了软件开发行业新的分水岭，容器技术的成熟也标志着技术新纪元的开启。Docker 提供了让开发工程师可以将应用和依赖封装到一个可移植的容器中的能力，这项举措使得 Docker 大有席卷整个软件行业并且进而改变行业游戏规则的趋势，这像极了当年智能手机刚出现时的场景——改变了整个手机行业的游戏规则。Docker 通过集装箱式的封装方式，让开发工程师和运维工程师都能够以 Docker 所提供的“镜像+分发”的标准化方式发布应用，使得异构语言不再是捆绑团队的枷锁。

新纪元的编排与调度系统

容器单元越来越散落使得管理成本逐渐上升，大家对容器编排工具的需求前所未有的强烈，Kubernetes、Mesos、Swarm 等为云原生应用提供了强有力的编排和调度能力，它们是云平台上的分布式操作系统。

Kubernetes 是目前世界范围内关注度最高的开源项目，它是一个出色的容器编排系统，用于提供一站式服务。Kubernetes 出身于互联网行业巨头——Google，它借鉴了由上百位工程师花费十多年时间打造的 Borg 系统的理念，安装极其简易，网络层对接方式十分灵活。

Mesos 则更善于构建一个可靠的平台，用来运行多任务关键工作负载，包括 Docker 容器、遗留应用程序（如 Java）和分布式数据服务（如 Spark、Kafka、Cassandra、Elastic）。Mesos 采用两级调度的架构，开发人员可以很方便地结合公司的业务场景定制 Mesos Framework。

其实无论是 Kubernetes 还是 Mesos，它们都不是专门为了容器而开发的。Mesos 早于 Docker 出现，而 Kubernetes 的前身 Borg 更是早已出现，它们都是基于解除资源与应用程序本身的耦合限制而开发的。运行于容器中的应用，其轻量级的特性恰好能够与编排调度系统完美结合。

唯一为了 Docker 而生的编排系统是 Swarm，它由 Docker 所在的 Moby 公司出品，用于编排基于 Docker 的容器实例。不同于 Kubernetes 和 Mesos，Swarm 是面向 Docker 容器的，相较于 Kubernetes 面向云原生 PaaS 平台，以及 Mesos 面向“大数据+编排调度”平台，Swarm 显得功能单一。在容器技术本身已不是重点的今天，编排能力和生态规划均略逊一筹的 Swarm 已经跟不上前两者的脚步。

Kubernetes 和 Mesos 的出色表现给行业中各类工程师的工作模式带来了颠覆性的改变。他们再也不用像照顾宠物那样精心地“照顾”每一台服务器，当服务器出现问题时，只要将其换掉即可。业务开发工程师不必再过分关注非功能需求，只需专注自己的业务领域即可。而中间件开发工程师则需要开发出健壮的云原生中间件，用来连接业务应用与云平台。

架构设计的变革——微服务

单体应用虽然简单且深入人心，但是随着越来越多的应用被部署到云端，它的劣势也体现得愈加明显。因为应用变更的范围和周期被捆绑在一起，因此即使只变更应用的一部分，也需要重新构建并部署整个单体应用，而且扩展时无法只对需要更多资源的部分模块进行单独扩展，必须将应用整体扩展。这种粗粒度的划分，不利于对系统进行管理，也不利于资源的充分利用。因此，人们越来越倾向于将应用进行合理的拆分。

在过去的几年中，微服务已经迅速成为了技术圈最热门的术语之一，微服务是一种架构风格，它将一个复杂的单体应用分解成多个独立部署的微型服务，每个服务运行在自己的进程中，服务间的通信采用轻量级通信机制，如 RESTful API。服务可以使用不同的开发语言和数据存储技术。通过服务拆分，系统可以更加自由地将资源分配到所需的应用中，而无须直接扩展整个应用。图 1-5 直观地展现了单体应用与微服务的区别。

图 单体应用与微服务的区别

采用微服务架构风格的团队将围绕业务组织团队，而不是围绕技术组织团队，这一点和 DevOps 有异曲同工之妙。实施微服务前的组织结构如图 1-6 所示，对于集中式架构而言，拆分大型应用通常需要在技术层面上设立 UI 团队、后端开发团队、数据库团队。在这种团队划分方式下，即使进行简单更改也会导致协作团队垮掉。

微服务架构风格则采用围绕业务线进行划分的方式，以保证一个团队中能拥有 UI 工程师、开发工程师、DBA 和项目经理。实施微服务后的组织结构如图 1-7 所示。

微服务的优势是通过清晰的模块边界构建易于理解的架构风格，它可以让每个服务具有独立部署、与开发语言无关的能力。分布式系统的开发成本和运维开销则是伴随微服务的普及而需要付出的代价。

图 实施微服务前的组织结构

图 实施微服务后的组织结构

相比于集中式架构，微服务架构需要额外处理的分布式开发和运维工作包括以下几点。

• 配置管理。相比于集中式架构的属性文件配置方式，微服务架构更加倾向于使用集中化的配置中心来存储配置数据。配置中心不一定在任何时候都是100%高可用的，大部分时间，配置是从客户端的缓存中读取的，如果配置中心恰好在配置修改时不可用，就会带来很大的影响，导致配置修改无法及时生效。配置修改要想及时生效，配置中心必须有推送配置变更事件的能力。如果配置中心是高可用的，也要慎重考虑如何保证多个配置中心间的数据一致性。

• 服务发现。单体应用的服务是可数且可人工运维的，而对于基于微服务架构的应用而言，其服务数非常多，数不胜数。因此，微服务框架要具有服务发现的能力。一般情况下，服务发现是通过向注册中心注册服务实例的运行时标识以及对其进行监听并反向通知其状态变化来实现的。

• 负载均衡。与服务发现类似，大量的微服务应用实例无法通过静态修改负载均衡器的方式进行运维，因此需要反向代理或使用客户端负载均衡器配合服务发现动态调整负载均衡策略。

• 弹性扩缩容。这是集中式架构所不具备的能力，即能够在流量洪峰期通过增加应用实例的水平伸缩来增强服务的处理能力，并且能够在流量回归正常时简单地关闭应用实例，平滑地将多余的资源移出集群。

• 分布式调用追踪。大量微服务应用的调用和交互，需要依靠一套完善的调用链追踪系统来实现，包括确定服务当前的运行状况，以及在出现状况时迅速定位相应的问题点。

• 日志中心。在微服务架构中，散落在应用节点上的日志不易排查，而且随着应用实例的销毁，日志也会丢失，因此需要将日志发送至日志中心统一进行存储和排查。

• 自愈能力。这是一个进阶功能，如果微服务应用可以通过健康检查感知各个服务实例的存活状态，并通过系统资源监控以及SLA分析获知应用当前的承载量，同时应用本身具有弹性扩缩容能力且微服务管控系统具有自动服务发现以及调整负载均衡的能力，那么便可以根据合理的调度策略配置通过调度系统来自动增加、关闭和重启应用实例，达到系统自愈的效果，使系统更加健壮。

在容器技术开源社区、编排系统开源社区的推动，以及微服务等开发理念的带动下，将应用部署到云端已经是不可逆转的趋势。随着云化技术的不断发展，云原生的概念也应运而生。在现有业务代码不变的情况下，要想让分布式系统无缝入云，需要改变的就是中间件。因此，从分布式中间件向云原生中间件变迁，便成为重中之重。

本文节选自图书《未来架构：从服务化到云原生》第一章。本书对快速演进中的云原生数据架构、典型分布式数据库中间件进行了剖析，重点介绍 Service Mesh 等新兴概念，创新性地提出了 Database Mesh 的理念，深度揭秘 Apache 项目——ShardingSphere。

购买链接：https://u.jd.com/sbmG4Y

作者简介：

张亮

京东数科数据研发负责人，Apache ShardingSphere 发起人兼 PPMC 成员。热爱分享，拥抱开源，主张代码优雅化，擅长以 Java 为主的分布式架构以及以 Kubernetes 和 Mesos 为主的云平台的构建。ShardingSphere 已进入 Apache 软件基金会，是京东集团首个进入 Apache 的开源项目，也是 Apache 首个分布式数据库中间件。

吴晟

Apache SkyWalking 创始人及 PPMC 成员，Apache ShardingSphere 原型作者及 PPMC 成员，Apache Zipkin 贡献者，Apache 孵化器导师，CNCF 基金会 OpenTracing 标准化委员会成员，W3C Trace Context 规范贡献者。擅长分布式架构、性能监控与诊断、分布式追踪、云原生监控等领域。

敖小剑

具有十七年软件开发经验，资深码农，微服务专家，Cloud Native 拥护者，敏捷实践者，Service Mesh 布道师，ServiceMesher 中文社区联合创始人。专注于基础架构建设，对微服务、云计算等相关技术有着深入研究和独到见解。

宋净超

蚂蚁金服云原生布道师，ServiceMesher 中文社区联合创始人，Kubernetes 社区成员，Istio 社区成员，《Cloud Native Go》《Python 云原生》《云原生 Java》等图书译者。