架构设计内容分享(二十七)：理解构架的视角，分层，演进，服务演化_能力视角流程视角业务架构的关键交付物-CSDN博客

本文链接：https://blog.csdn.net/qq_45038038/article/details/135092781

架构的视角

在笔者的知识体系中，实际上将架构分为业务架构、应用架构、云基础架构这几大类，业务架构主要着眼于控制业务的复杂性，基础架构着眼于解决分布式系统中存在的一系列问题。无论何种架构，都希望能实现系统的可变的同时保障业务的高可用。

注意：

很多时候架构的视角/分类没有明显的边界，通常是交叉的；
有意思的是，软件架构及其视角往往和它所在的部门组织架构有着直接关系。@pdai

业务架构

核心是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目定义，现有环境；梳理高阶需求和非功能性需求，进行问题域划分与领域建模等工作；沟通，方案建议，多次迭代，交付总体架构。

看看京东业务架构（网上分享图）：

应用/技术架构

根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（性能、安全、稳定性等）。技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

不限于如下视角，主要表示应用开发中的软件架构视角...

视角：功能视角

功能视角和业务视角有重合的地方，主要针对开发而言的服务功能；

#视角：技术视角-总体

技术框架（technological Framework）是整个或部分技术系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种定义认为，技术框架是可被技术开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。

从技术层面描述，主要是分层模型，例如持久层、数据层、逻辑层、应用层、表现层等，然后每层使用什么技术框架，例如Spring、hibernate、ioc、MVC、成熟的类库、中间件、WebService等，分别说明，要求这些技术能够将整个系统的主要实现概括。

视角：技术视角-数据架构

专注于构建数据中台，统一数据定义规范，标准化数据表达，形成有效易维护的数据资产。打造统一的大数据处理平台，包括数据可视化运营平台、数据共享平台、数据权限管理平台等。

视角：技术视角-基础架构

PAAS，IAAS...

视角：技术视角-运维架构

负责运维系统的规划、选型、部署上线，建立规范化的运维体系。

物理架构

物理架构关注软件元件是如何放到硬件上的，专注于基础设施，某种软硬件体系，甚至云平台，包括机房搭建、网络拓扑结构，网络分流器、代理服务器、Web 服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。

以一个银行系统为例

下面为业务性能及网络性能监控的物理部署架构图，分网络接入层和汇聚层两个层次对网络流量报文进行捕获和深入分析。

物理部署架构设计说明：

（1）通过4台TAP设备获取青山湖和艾溪湖两个数据中心、五个机房相关应用服务器接入交换机的镜像流量，并进行规则过滤；
（2）通过1台高性能汇聚TAP来获取艾溪湖数据中心二层汇聚交换机和核心交换机的镜像流量，并进行规则过滤；
（3）艾溪湖主数据中心各机房接入层TAP设备的流量共享给汇聚TAP设备；
（4）BPC系统的5台BPC服务器在两个数据中心的每个机房进行分布式部署、解码和分析，并集中展示；
（5）NPM系统在艾溪湖数据中心部署一台管理端服务器，并在每个数据中心各部署一台NPM探针服务器，通过分布式部署、捕获数据，集中监控展示的方式，监控两个数据中心的各业务系统的网络性能；
（6）通过双数据中心、多机房分布式部署的方式，端到端的监控业务在各个环节的流转情况，实时监控，快速定位。

下面为运维大数据平台的物理部署拓扑图，分为三个集群，Hadoop集群、ES日志集群和Kalfka消息集群。

物理部署架构设计说明：

配置多台服务器做Hadoop集群，满足不同应用和系统日志的单系统与跨系统交易日志统计与分析，满足数千个基础监控分区的基础性能分析与运行性能指标预测等，以及指性能标入库与历史日志数据入库的存储需要。
配置多台服务器做ES集群，承载实时统一日志查询与分析平台的任务，满足数天至一个月不同需求的日志查询和分析需求，历史日志查询需要从HDFS中将数据导入至ES中，进行二次查询。
配置多台服务器做Kafka集群用于实时的指标型与日志型数据流的采集，满足实时监控的需求。

架构的分层

于开发者而言，实际工作从通常采用的是分层模型，总结下经典的七层逻辑架构。

以上采用七层逻辑架构，第一层客户层，第二层前端优化层，第三层应用层，第四层服务层，第五层数据存储层，第六层大数据存储层，第七层大数据处理层。

客户层：减少Http请求数，浏览器缓存，启用压缩，Js异步，减少Cookie传输；
前端层：DNS负载均衡，CDN本地加速，反向代理服务；
应用层：业务拆分；负载均衡，分级管理，应用缓存，服务集群，快速失败，异步调用，服务降级，消息队列，幂等设计等。
服务层：提供公用服务，比如用户服务，订单服务，支付服务等；
数据层：分布式, 数据库集群，读写分离，NOSQL集群，文件系统集群；分布式缓存；冗余备份（冷，热备[同步，异步]，温备），失效转移（确认，转移，恢复）。CAP理论，一致性算法。
大数据存储层：支持应用层和服务层的日志数据收集，关系数据库和NOSQL数据库的结构化和半结构化数据收集；
大数据处理层：通过Mapreduce进行离线数据分析或Storm实时数据分析，并将处理后的数据存入关系型数据库。（实际使用中，离线数据和实时数据会按照业务要求进行分类处理，并存入不同的数据库中，供应用层或服务层使用）。

架构演进

大型网站的技术挑战主要来自于庞大的用户，高并发的访问和海量的数据，任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户，问题就会变得很棘手。大型网站架构主要就是解决这类问题。

架构选型是根据当前业务需要来的，在满足业务需求的前提下，既要有足够的扩展性也不能过度设计，每次的架构升级都是为了解决系统瓶颈而做的。

初始阶段的网站架构

初始阶段都比较简单，通常一台服务器就可以搞定一个网站了，看图。

应用服务和数据服务分离

随着网站业务的发展，一台服务器逐渐不能满足需求；这时候就需要将应用和数据分离，如图。

使用缓存改善网站性能

毫无疑问，现在的网站基本上都会使用缓存，即：80%的业务访问都会集中在20%的数据上。

使用应用服务器集群改善网站的并发处理能力

因为单一应用服务器能够处理的请求连接有限，在网站访问高峰时期，应用服务器会成为整个网站的瓶颈。因此使用负载均衡处理器势在必然。通过负载均衡调度服务器，可将来自浏览器的访问请求分发到应用的集群中的任何一台服务器上。

数据库读写分离

当用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。而目前主流的数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库的数据更新同步到另一台服务器上。网站利用数据库这一功能实现数据库读写分离，从而改善数据库负载压力。

使用反向代理和CDN加上网站相应

提高网站的访问速度，主要手段有使用CDN和反向代理。

CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，而反向代理是部署在网站的中心机房，当用户请求到达中心机房后，首先访问的反向代理，如果反向代理缓存着用户请求的资源，则直接返回给用户。

使用分布式文件系统和分布式数据库系统

任何强大的单一服务器都满足不了大型网站持续增长的业务需求。

分布式数据库时网站数据库拆分的最后手段，只用在单表数据规模非常大的时候才使用。不到不得已时，网站更常用的数据库拆分手段是业务拆分，将不同业务的数据部署在不同的物理服务器上。

使用NoSQL和搜索引擎

搜索引擎也基本已经形成现在大型网站必须提供的功能了，网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎。

业务拆分

大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将真个网站业务拆分成不同的产品线。

具体到技术上，也会根据产品线话费，将一个网站拆分成许多不同的应用，每个应用独立部署维护。应用之间可以通过超链接建立管理，也可以通过消息队列进行数据分发，当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

分布式服务

由于每一个应用系统都需要执行许多相同的业务操作，比如用户管理，session管理，那么可以将这些公用的业务提取出来，独立部署。

示例:电商系统架构演进

具体以电子商务网站为例，展示web应用的架构演变过程。

1.0时代

这个时候是一个web项目里包含了所有的模块，一个数据库里包含了所需要的所有表，这时候网站访问量增加时，首先遇到瓶颈的是应用服务器连接数，比如tomcat连接数不能无限增加，线程数上限受进程内存大小、CPU内核数等因素影响，当线程数到达一定数时候，线程上下文的切换对性能的损耗会越来越严重，响应会变慢，通过增加web应用服务器方式的横向扩展对架构影响最小，这时候架构会变成下面这样：

2.0时代

这时候随着网站访问量继续增加，继续增加应用服务器数量后发现数据库成了瓶颈，而数据库的最主要的瓶颈体现在两方面：

数据库的最大连接数是有限的，比如当前数据库的连接数设置8000，如果每个应用服务器与数据库的初始连接数设置40，那么200台web服务器是极限，并且连接数太多后，数据库的读写压力增大，耗时增加
当单表数量过大时，对该表的操作耗时会增加，索引优化也是缓兵之计

这时，根据业务特点，如果读写比差距不大，并且对数据一致性要求不是很高的情况下，数据库可以采用主从方式进行读写分离的方案，并且引入缓存机制来抗读流量。如果读写比差距很大或者对数据一致性要求高时，就不适合用读写分离方案，需要考虑业务的垂直拆分，这时期的系统架构图如下：

3.0时代

3.1 读写分离

这时候仍然是垂直架构，所有业务集中在一个项目里。项目维护、快速迭代问题会越来越严重，单个模块的开发都需要发布整个项目，项目稳定性也受到很大挑战，这是需要考虑业务的垂直拆分，需要将一些大的模块单独拆出来，这时候的架构图如下：

4.0 业务垂直拆分

这时候为了进一步提升用户体验，加速用户的网站访问速度，会使用CDN来缓存信息，用户会访问最近的CDN节点来提升访问速度。此时的架构图如下：

4.1 使用CDN来缓存信息

随着业务量增大，一些核心系统数据库单表数量达到几千万甚至亿级，这时候对该表的数据操作效率会大大降低，并且虽然有缓存来抗读的压力，但是对于大量的写操作和一些缓存miss的流量到达一定量时，单库的负荷也会到达极限，这时候需要将表拆分，一般直接采用分库分表，因为只做分表的话，单个库的连接瓶颈仍然无法解决。分库分表后的架构如下：

4.2分库分表架构

随着流量的进一步增大，这时候系统仍然会有瓶颈出现，以订单系统为例：单个机房的机器是有限的，不能一直新增下去，并且基于容灾的考虑，一般采用同城双机房的方式，机房之间用专线链接，同城跨机房质检的延时在几毫秒，此时的架构图如下：

4.3 同城双机房

由于数据库主库只能是在一个机房，所以仍然会有一半的数据库访问是跨机房的，虽然延时只有几毫秒，但是一个调用链里的数据库访问太多后，这个延时也会积少成多。其次这个架构还是没能解决数据库连接数瓶颈问题

随着应用服务器的增加，虽然是分库分表，但每增加一台应用服务器，都会与每个分库建立连接，比如数据库连接池默认连接数是40，而如果mysql数据库的最大连接数是8000的话，那么200台应用服务器就是极限。
当应用的量级太大后，单个城市的机器、电、带宽等资源无法满足业务的持续增长。这时就需要考虑SET化架构，也就是单元化架构，大体思路就是将一些核心系统拆成多个中心，每个中心成为一个单元，流量会按照一定的规则分配给每个单元，这样每个单元只负责处理自己的流量就可以了。每个单元要尽量自包含、高内聚。这是从整体层面将流量分而治之的思路。这是单元化后的机构简图如下：

5.0 单元化

从上面的架构图里能看到，流量从接入层按照路由规则（比如以用户ID来路由）路由到不同单元，每个单元内都是高内聚，包含了核心系统，数据层面的分片逻辑是与接入层路有逻辑一致，也解决了数据库连接的瓶颈问题，但是一些跨单元的调用是无法避免的，同时也有些无法拆分的业务需要放在中心单元，供所有其他单元调用。

服务演化简介

Kubernetes、Service Mesh 和 Serverless 三者共同演绎不同层次的封装和向上屏蔽下面的细节。

方向一:架构服务化

单体分层架构

在 Web 应用程序发展的早期，大部分工程是将所有的服务端功能模块打包到单个巨石型（Monolith）应用中，譬如很多企业的 Java 应用程序打包为 war 包，最终会形成如下的架构：

巨石型应用易于搭建开发环境、易于测试、易于部署；其缺陷也非常明显，无法进行局部改动与部署，编译时间过长，回归测试周期过长，开发效率降低等。集中式架构分为标准的三层：数据访问层、服务层和 Web 层。

在 Web2.0 时代刚刚流行的时候，互联网应用与企业级应用并没有本质的区别，集中式架构分为标准的三层：数据访问层、服务层和 Web 层。

数据访问层用于定义数据访问接口，实现对真实数据库的访问；
服务层用于对应用业务逻辑进行处理；
Web 层用于处理异常、逻辑跳转控制、页面渲染模板等。

面向服务架构 - SOA

SOA（Service-Oriented Architecture）面向服务架构，是在互联网应用规模迅速增长，集中式架构已无法做到无限制地提升系统的吞吐量的背景下，产生的涉及模块化开发、分布式扩展部署等相对宽泛的概念。

SOA 是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。SOA 中的接口独立于实现服务的硬件平台、操作系统和编程语言，采用中立的方式进行定义。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是 SOA 的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

实施 SOA 的关键目标是实现企业 IT 资产的最大化作用。要实现这一目标，就要在实施 SOA 的过程中牢记以下特征：可从企业外部访问、随时可用、粗粒度的服务接口分级、松散耦合、可重用的服务、服务接口设计管理、标准化的服务接口、支持各种消息模式、精确定义的服务契约。

服务消费者（Service Consumer）可以通过发送消息来调用服务，这些消息由一个服务总线（Service Bus）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引（Business Rules Engine），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（Service Management Infrastructure），用来管理服务，类似审核，列表（billing），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（Regulatory Requirement），例如 Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。

由于分布式系统十分复杂，因此产生了大量的用于简化分布式系统开发的分布式中间件和分布式数据库，服务化的架构设计理念也被越来越多的公司所认同。如下是 Dubbo 官方文档公布了一张有关 SOA 系统演化过程的图片：

微服务架构 - Microservices

微服务（Microservices Architecture Pattern）由 Martin Fowler 在 2014 年提出的，是希望将某个单一的单体应用，转化为多个可以独立运行、独立开发、独立部署、独立维护的服务或者应用的聚合，从而满足业务快速变化及分布式多团队并行开发的需求。如康威定律（Conway’s Law）所言，任何组织在设计一套系统（广义概念）时，所交付的设计方案在结构上都与该组织的通信结构保持一致，微服务与微前端不仅仅是技术架构的变化，还包含了组织方式、沟通方式的变化。

对于微服务，不同背景的人也有不同的见解，对于熟悉 SOA 的开发者，微服务也可以认为是去除了 ESB 的 SOA 的一种实现方案；ESB 是 SOA 架构中的中心总线，设计图形应该是星形的，而微服务是去中心化的分布式软件架构。SOA 更多强调重用，而微服务偏向于重写。SOA 偏向水平服务，微服务偏向垂直服务；SOA 偏向自上而下的设计，微服务偏向自下而上的设计。

微服务与微前端原理和软件工程，面向对象设计中的原理同样相通，都是遵循单一职责(Single Responsibility)、关注分离(Separation of Concerns)、模块化(Modularity)与分而治之(Divide & Conquer)等基本的原则。从巨石型应用到微服务的衍化也并非一蹴而就，如下图也演示了简单的渐进式替代过程：

云原生架构 - Cloud Native

云原生是通过构建团队、文化和技术，利用自动化和架构来管理系统的复杂性和解放生产力。 — Joe Beda，Heotio CTO，联合创始人

Pivotal 是云原生应用的提出者，并推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。早在 2015 年 Pivotal 公司的 Matt Stine 写了一本叫做迁移到云原生应用架构的小册子，其中探讨了云原生应用架构的几个主要特征：符合 12 Factors 应用、面向微服务架构、自服务敏捷架构、基于 API 的协作以及抗脆弱性。2015 年 Google 主导成立了云原生计算基金会（CNCF），起初 CNCF 对云原生（Cloud Native）的定义包含以下三个方面：应用容器化、面向微服务架构、应用支持容器的编排调度。

云原生应用程序简单地定义为从头开始为云计算架构而构建应用程序；这意味着，如果我们将应用程序设计为预期将部署在分布式、可扩展的基础架构上，我们的应用程序就是云原生的。随着公共云将承载越来越多的算力，未来云计算将是主流的 IT 能力交付方式，CNCF 也对云原生进行了重新定义：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用；云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

Codeless 对应的是服务开发，实现了源代码托管，你只需要关注你的代码实现，而不需要关心你的代码在哪，因为在整个开发过程中你都不会感受到代码库和代码分支的存在。
Applicationless 对应的是服务发布，在服务化框架下，你的服务发布不再需要申请应用，也不需要关注你的应用在哪。
Serverless 对应的则是服务运维，有了 Serverless 化能力，你不再需要关注你的机器资源，Servlerless 会帮你搞定机器资源的弹性扩缩容这些技术组合搭配，能够构建容错性好、易于管理和便于观察的松耦合系统；再结合可靠的自动化手段，云原生技术能够使工程师轻松地对系统作出频繁和可预测的重大变更。由此可见，云原生是保障系统能力灵动性地有效抓手；云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。微服务架构非常适合云原生应用程序；但是，云原生同样存在着一定的限制，如果你的云原生应用程序部署在 AWS 等公有云上，则云原生 API 不是跨云平台的。

云原生应用的关键属性包括了：使用轻量级的容器打包、使用最合适的语言和框架开发、以松耦合的微服务方式设计、以 API 为中心的交互和协作、无状态和有状态服务在架构上界限清晰、不依赖于底层操作系统和服务器、部署在自服务、弹性的云基础设施上、通过敏捷的 DevOps 流程管理、自动化能力、通过定义和策略驱动的资源分配。云原生是分布式应用当下重要的发展路径，其终态应当是 Distributionless，所有与分布式相关的问题由云平台解，分布式应用的开发会跟传统应用的开发一样方便，甚至更加便捷。

方向二:部署容器编排化

本部分节选自《分布式基础架构之虚拟化与编排》

虚拟机

虚拟机由某些特定的硬件和内核虚拟化组成，运行客户操作系统。称为管理程序的软件创建虚拟化硬件，其可以包括虚拟磁盘，虚拟网络接口，虚拟 CPU 等。虚拟机还包括可以与此虚拟硬件通信的宾客内核。管理程序可以托管，这意味着它是一些在主机操作系统（MacOS）上运行的软件，如示例中所示。它也可以是裸机，直接在机器硬件上运行（替换你的操作系统）。无论哪种方式，管理程序方法都被认为是重量级的，因为它需要虚拟化多个部分（如果不是全部硬件和内核）。

VM 需要硬件虚拟化才能实现机器级隔离，而容器则只需要在同一操作系统内进行隔离操作。随着隔离空间数量的增加，开销差异变得非常明显。

容器

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

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

容器是包含应用程序代码，配置和依赖关系的软件包，可提供运营效率和生产力。容器为我们提供了可预测的，可重复的和不可变的运行预期，容器的兴起是 DevOps 即服务的一个巨大推动因素，可以克服当今面临的最大安全障碍。容器化通过在操作系统级别进行虚拟化来使应用程序可移植，从而创建基于内核的隔离的封装系统。容器化的应用程序可以放在任何地方，无需依赖项运行或需要整个 VM，从而消除了依赖关系。

作为独立的单元，容器能够在任何主机操作系统，CentOS，Ubuntu，MacOS，甚至是像 Windows 这样的非 UNIX 系统中运行。容器还充当标准化的工作或计算单元。一个常见的范例是每个容器运行单个 Web 服务器，数据库的单个分片或单个 Spark 工作程序等，只需要扩展容器的数量就能够便捷地扩展应用。每个容器都有一个固定的资源配置（CPU，RAM，线程数等），并且扩展应用程序需要只扩展容器的数量而不是单个资源原语。当应用程序需要按比例放大或缩小时，这为工程师提供了更容易的抽象。容器也是实现微服务架构的一个很好的工具，每个微服务只是一组协作容器。例如，可以使用单个主容器和多个从容器来实现 Redis 微服务。

Kubernetes 与编排

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

然而容器单元越来越散落使得管理成本逐渐上升，大家对容器编排工具的需求前所未有的强烈，Kubernetes、Mesos、Swarm 等为云原生应用提供了强有力的编排和调度能力，它们是云平台上的分布式操作系统。容器编排是通常可以部署多个容器以通过自动化实现应用程序的过程。像 Kubernetes 和 Docker Swarm 这样的容器管理和容器编排引擎，使用户能够指导容器部署并自动执行更新，运行状况监视和故障转移过程。

Kubernetes 是目前世界范围内关注度最高的开源项目，它是一个出色的容器编排系统，用于提供一站式服务。Kubernetes 出身于互联网行业巨头 Google，它借鉴了由上百位工程师花费十多年时间打造的 Borg 系统的理念，安装极其简易，网络层对接方式十分灵活。Kubernetes 和 Mesos 的出色表现给行业中各类工程师的工作模式带来了颠覆性的改变。他们再也不用关注每一台服务器，当服务器出现问题时，只要将其换掉即可。业务开发工程师不必再过分关注非功能需求，只需专注自己的业务领域即可。而中间件开发工程师则需要开发出健壮的云原生中间件，用来连接业务应用与云平台。

Kubernetes、Service Mesh 和 Serverless 三者共同演绎不同层次的封装和向上屏蔽下面的细节。Kubernetes 引入了不同的设计模式，实现对各种云资源全新、有效和优雅的抽象和管理模式，让集群的管理和应用发布变成了件相当轻松且不易出错的事。被广泛采用的微服务软件架构将分布式应用的各种复杂度迁移到了服务之间，如何通过全局一致、体系化、规范化和无侵入的手段进行治理就变成了微服务软件架构下至关重要的内容。Kubernetes 细化的应用程序的分解粒度，同时将服务发现、配置管理、负载均衡和健康检查等作为基础设施的功能，简化了应用程序的开发。而 Kubernetes 这种声明式配置尤其适合 CI/CD 流程，况且现在还有如 Helm、Draft、Spinnaker、Skaffold 等开源工具可以帮助我们发布 Kuberentes 应用。

Service Mesh 通过将各服务所共用和与环境相关的内容剥离到部署于每个服务边上的 Sidecar 进程而轻松地做到了。这一剥离动作使得服务与平台能充分解耦而方便各自演进与发展，也使得服务变轻而有助于改善服务启停的及时性。Service Mesh 因为将那些服务治理相关的逻辑剥离到了 Sidecar 中且作为独立进程，所以 Sidecar 所实现的功能天然地支持多语言，为上面的服务采用多语言开发创造了更为有利的条件。通过 Service Mesh 对整个网络的服务流量进行技术收口，让异地多活这样涉及流量调度的系统工程实现起来更加优雅、简洁与有效，也能更加方便地实现服务版本升级时的灰度、回滚而改善安全生产质量。由于技术收口，给服务流量的治理和演进、排错、日志采集的经济性等疑难问题创造了新的发展空间。