作者 | 潘义文（空易）
起源 | 阿里巴巴云原生公众号

起源

1. 云原生（Cloud Native）的由来

云原生的概念最早开始于 2010 年，在过后 Paul Fremantle 的一篇博客中被提及，他始终想用一个词表白一种架构，这种架构能形容应用程序和中间件在云环境中的良好运行状态。因而他形象出了 Cloud Native 必须蕴含的属性，只有满足了这些属性能力保障良好的运行状态。过后提出云原生是为了能构建一种合乎云计算个性的规范来领导云计算利用的编写。

起初到 2013 年 Matt Stine 在推特上迅速推广云原生概念，并在 2015 年《迁徙到云原生架构》一书中定义了合乎云原生架构的特色：12 因素、微服务、自服务、基于 API 合作、扛脆弱性 。而因为这本书的推广滞销，这也成了很多人对云原生的晚期印象，同时云原生也被 12 因素变成了一个形象的概念。Matt Stine 认为在单体架构向 Cloud Native 迁徙的过程中，须要文化、组织、技术独特改革。 解读：云原生架构实质上也是一种软件架构，最大的特点是在云环境下运行，也算是微服务的一种延长。

2. CNCF 基金会成立及云原生概念的演变

2015 年由 Linux 基金会发动了一个 The Cloud Native Computing Foundation（CNCF）基金组织，CNCF 基金会的成立标记着云原生正式进入高速倒退轨道，Google、Cisco、Docker 各大厂纷纷退出，并逐渐构建出围绕 Cloud Native 的具体工具，而云原生这个的概念也逐步变得更具体化。因而，CNCF 基金最后对云原生定义是也是深窄的，过后把云原生定位为容器化封装 + 自动化治理 + 面向微服务：

The CNCF defines“cloud-native”a little more narrowly, to mean using open source software stack to be containerized, where each part of the app is packaged in its own container, dynamically orchestrated so each part is actively scheduled and managed to optimize resource utilization, and microservices-oriented to increase the overall agility and maintainability of applications.

这次要因为 CNCF 基金会在过后的外围拳头软件就是 K8s，因而在概念定义上次要是围绕着容器编排建设起来的生态。其实这也是为什么咱们能够看到 CNCF 定义云原生的时候有时感觉就是再说容器生态。

到了 2017 年, 云原生利用提出者之一的 Pivotal 在其官网上将云原生的定义概括为 DevOps、继续交付、微服务、容器四大特色，这也成了很多人对 Cloud Native 的根底印象。

而到 2018 年，随着 Service Mesh 的退出，CNCF 对云原生的定义产生了扭转，而这也逐步成为被大家认可的官网定义：

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone. 

总结一下就是：

• 基于容器、服务网格、微服务、不可变基础设施和申明式 API 构建的可弹性扩大的利用。
• 基于自动化技术构建具备高容错性、易治理和便于察看的松耦合零碎。
• 构建一个对立的开源云技术生态，能和云厂商提供的服务解耦。

能够看出，CNCF 在以后定义根底上加上了 服务网格 (service mesh) 和 申明式 API，这为云原生的概念论述减少了更深一层的意义，也就是建设一个 绝对中立的开源云生态。这对云原生的生态定位是很重要的，也算 CNCF 最后成立的主旨之一，突破云巨头的垄断。

解读：概念随着新的技术倒退而演变

• 第一阶段：容器化封装 + 自动化治理 + 面向微服务
• 第二阶段：DevOps、继续交付、微服务、容器
• 第三阶段：DevOps、继续交付、容器、服务网格、微服务、申明式 API

3. 对云原生的解构

对一个词的解读，除了看其历史倒退背景，还有一种偏差于语言学的办法解读，也就是咱们常说的从“字面意思”来了解。

Cloud Native，从词面上拆解其实就是 Cloud 和 Native，也就是云计算和土著的意思——云计算上的原生居民，即天生具备云计算的亲和力。

首先从 Cloud 来了解，云能够看作是一种提供稳固计算存储资源的对象。为了实现这一点，云提供了像 虚拟化、弹性扩大、高可用、高容错性、自复原 等根本属性，这是云原生作为一种云计算所具备的第一层含意。第二层要从 Native 来看，云原生和在云上跑的传统利用不同。一些基于私有云搭建的利用是基于传统的 SOA 架构来搭建的，而后再移植到云下来运行，那么这些利用和云的整合非常低。

为什么低呢？云作为一种 分布式架构，其“土著居民”也应该是基于分布式架构设计进去的，而微服务或 Serverless 这种将服务或函数拆分成一个个模块的松耦合零碎，人造具备分布式设计的属性。这是 Native 的第一种体现。

其次云作为一种 PaaS 服务，这位“土著居民”从出世 (设计) 到成长 (开发)，再到生存(部署) 都应该是基于云的理念来实现的，那么就须要一套自动化的开发流程 CI/CD 来实现。这是 Native 的第二种体现。

而最初“土著居民”的特点心愿做到可能适应所有云端，都能做到无缝的运行和连贯。

解读 ： 后面三节都是来自《什么是云原生？聊聊云原生的今生》这篇文章中。

关键点

上面介绍云原生架构的一些关键技术点。波及内容由微服务、分布式常见架构设计(性能、数据一致性、可扩展性、高可用)、研发流程、DevOps、组织文化等，能够依据目录选择性的看看，基本上都是一些介绍，具体的设计能够查看相干文档进一步理解。

1. 微服务

Martin Fowler 与 James Lewis 独特提出了微服务的概念，定义了微服务架构是以开发一组小型服务的形式来开发一个独立的利用零碎，每个服务都以一个独立过程的形式运行，每个服务与其余服务应用轻量级（通常是 HTTP API）通信机制。这些服务是围绕业务性能构建的，能够通过全自动部署机制独立部署，同时服务会应用最小规模的集中管理（例如 Docker）能力，也能够采纳不同的编程语言和数据库。

1）劣势

• 麻利开发帮忙咱们缩小节约、疾速反馈，以用户体验为指标。
• 继续交付促使咱们更快、更牢靠、更频繁地改良软件；基础设施即代码（Infrastructure As Code）帮忙咱们简化环境的治理。

2）什么时候开始微服务架构

• 简直所有胜利的微服务架构都是从一个微小的单体架构开始的，并且都是因为单体架构太大而被拆分为微服务架构。
• 在所一开始就构建微服务架构的故事中，往往都有人遇到了微小的麻烦。

3）如何决定微服务架构的拆分粒度

微服务架构中的“微”字，并不代表足够小，应该解释为适合。

4）单体架构 VS 微服务架构比照

风行的微服务框架：spring-cloud/dubbo。

2. 麻利基础设施及公共根底服务

麻利基础设施及公共根底服务是微服务架构成败的关键因素之一，可能简化业务开发。

1）麻利基础设施的指标

• 标准化：所有的基础设施最好都是规范的。
• 可替换：任意节点都可能被轻易地创立、销毁、替换。
• 自动化：所有的操作都通过工具自动化实现，毋庸人工干预。
• 可视化：以后环境要做到可控，就须要对以后的环境情况可视。
• 可追溯：所有的配置对立作为代码进行版本化治理，所有的操作都能够追溯。
• 疾速：资源申请及开释要求秒级实现，以适应弹性伸缩和故障切换的要求。

2）基于公共根底服务的平台化

• 平台化 是指利用公共根底服务晋升整体架构能力。
• 公共根底服务 是指与业务无关的、通用的服务，包含监控服务、缓存服务、音讯服务、数据库服务、负载平衡、分布式协调、分布式任务调度等。

3）常见的平台服务

• 监控告警服务
• 分布式消息中间件服务
• 分布式缓存服务
• 分布式任务调度服务

3. 分布式架构 – 可用性设计

可用性（Availability）是对于零碎能够被应用的工夫的形容，以失落的工夫为驱动（Be Driven by Lost Time）。

可用性公式：A=Uptime /（Uptime+Downtime）。其中，Uptime 是可用工夫，Downtime 是不可用工夫。

1）什么升高了可用性

• 公布
• 故障
• 压力
• 内部依赖

2）设计阶段思考如下几个比拟重要的办法

• 20/10/5，设计零碎的时候，以理论流量的 20 倍来设计；开发零碎的时候，以理论流量的 10 倍来开发零碎；公布零碎的时候，以理论流量的 5 倍来部署。这只是一个通用的准则，能够依据理论状况来确定，不须要严格依照倍数来执行。
• Design for failure，预测可能产生的问题，做好预案。

3）容错设计

如果说谬误是不可避免或者难以避免的，那么咱们应该换一个思路，保障谬误产生时，咱们能够从容应对。

• 打消单点
• 个性开关
• 服务分级
• 降级设计
• 超时重试

4）隔离策略

隔离是为了在零碎产生故障时，限度流传范畴和影响范畴，特地要留神非核心零碎的故障对外围零碎的影响。

• 线程池隔离
• 过程隔离
• 集群隔离
• 用户隔离
• 租户隔离
• 逻辑隔离
• 物理隔离
• 混合隔离

5）熔断器

熔断器模式（Circuit Breaker Patten）的原理相似于家里的电路熔断器的原理。当产生短路或者超负荷时，熔断器可能被动熔断电路，以防止劫难产生。

Spring Cloud Hystrix 提供了熔断器、线程隔离等一系列服务爱护的能力，应用起来非常简单，引入依赖的 JAR 包，通过简略的注解即可实现。

6）流控设计

• 限流算法。限流也就是调节数据流的均匀速率，通过限度速率爱护本人，常见的算法有：

  •  固定窗口算法（fixed window）。
  •  漏桶算法（Leaky Bucket）：漏桶算法次要目标是控制数据注入网络的速率，平滑网络上的突发流量。
  • 令牌桶算法（token bucket）：令牌桶管制的是一个工夫窗口内通过的数据量，通常咱们会以 QPS、TPS 来掂量。

• 流控策略

  • 申请入口处。
  • 业务服务入口处。
  • 公共根底服务处。
  • 基于 Guava 限流：Guava 是 Google 提供的 Java 扩大类库，其中的限流工具类 RateLimiter 采纳的就是令牌桶算法，应用起来非常简单。
  • 基于 Nginx 限流。

7）容量预估

互联网公司广泛采纳全链路压测的形式，来进一步预估容量。

8）故障演练

• 随机敞开生产环境中的实例。
• 让某台机器的申请或返回变慢，察看零碎的体现，能够用来测试上游服务是否有服务降级能力，当然如果响应工夫特地长，也就相当于服务不可用。
• 模仿 AZ 故障，中断一个机房，验证是否跨可用区部署，业务容灾和复原的能力。
• 查找不合乎最佳实际的实例，并将其敞开。

9）数据迁徙

• 逻辑拆散，物理不拆散。
• 物理拆散。

4. 分布式架构 – 可扩大设计

• 程度扩大，指用更多的节点撑持更大量的申请。
• 横向扩大通常是为了晋升吞吐量，响应工夫个别要求不受吞吐量影响即可。

1）AKF 扩大立方体

2）如何扩大数据库

• X 轴扩大——主从复制集群
• Y 轴扩大——分库、垂直分表
• Z 轴扩大——分片（sharding）

5. 分布式架构 – 性能设计

1）性能指标

• 响应工夫（Latency），就是发送申请和返回后果的耗时。
• 吞吐量（Throughput），就是单位工夫内的响应次数。
• 负载敏感度，是指响应工夫随工夫变动的水平。例如，当用户减少时，零碎响应工夫的衰减速度。
• 可伸缩性，是指向零碎减少资源对性能的影响。例如，要使吞吐量增加一倍，须要减少多少服务器。

2）如何建立指标

• 通过缓存晋升读性能。
• 通过消息中间件晋升写性能。

6. 分布式架构 – 一致性设计

1）事务的四大特色

• 原子性（Atomicity）。
• 一致性（Consistency）是指通过事务保证数据从一种状态变动到另一种状态。
• 隔离性（Isolation）是指事务内的操作不受其余操作影响，当多个事务同时解决同一个数据的时候，多个事务之间是互不影响的。
• 持久性（Durability）是指事务被提交后，应该长久化，永恒保留下来。

2）CPA 定理

该定理认为对于一个分布式计算零碎来说，不可能同时满足以下三点：

• 一致性（Consistence）
• 可用性（Availability）
• 分区容错性（Partition tolerance）

分布式意味着必须满足分区容错性，也就是 P，因而个别只能是 AP 或 CP。

3）BASE 实践

BASE 实践的核心思想是：如果无奈做到强一致性，或者做到强一致性要付出很大的代价，那么利用能够依据本身业务特点，采纳适当形式来使零碎达到最终一致性，只有对最终用户没有影响，或者影响是可承受的即可。

• BA:Basically Available，根本可用。
• S:Soft state，软状态。
• E:Eventually consistent，最终统一。

4）Quorum 机制（NWR 模型）

如果多个服务别离向三个节点写数据，为了保障强统一，就必须要求三个节点全副写胜利才返回；同步写三个节点的性能较低，如果换一个思路，一致性并不一定要在写数据的时候实现，能够在读的阶段再决策，只有每次能读到最新版本即可。

Quorum 机制就是要满足公式 W+R>N，式中 N 代表备份个数，W 代表要写入至多 W 份才认为胜利，R 示意至多读取 R 个备份。

5）租约机制（Lease）

如果当初咱们有三个节点，为了实现一致性，要确保有且只有一个是 Leader，另外两个为 Follower，只有 Leader 是可写的，Follower 只能读。治理节点 M 通过心跳判断各个节点的状态，用 M 去指定 Leader，一旦 Leader 死掉，就能够从新指定一个 Leader。

6）脑裂问题

• 一种是采纳投票机制（Paxos 算法）。
• 一种是采纳租约机制——Lease，租约机制的外围就是在肯定工夫内将权力下放。

7）分布式系统的一致性分类

• 建设多个正本。能够把正本放到不同的物理机、机架、机房、地区，当一个正本生效时，能够让申请转到其余正本。
• 对数据进行分区。复制多个正本解决了读的性能问题，然而无奈解决写的性能问题。

8）以数据为核心的一致性模型

从数据存储的角度登程的，包含数据库、文件等。

• 严格一致性（Strict Consistency）
• 程序一致性（Sequential Consistency）
• 因果一致性（Causal Consistency）

9）以用户为核心的一致性模型

以下一致性模型适应的场景为不会同时产生更新操作，或者同时产生更新操作时可能比拟容易地化解。因为这里的数据更新默认有一个与之关联的所有者，此所有者领有惟一被容许批改数据的权限，能够依照用户 ID 进行路由。

• 枯燥读一致性（Monotonic-read Consistency）
• 枯燥写一致性（Monotonic-write Consistency）
• 写后读一致性（Read-your-writes Consistency）
• 读后写一致性（Writes-follow-reads Consistency）

10）业界罕用的一致性模型

• 弱一致性：写入一个数据 a 胜利后，在数据正本上可能读出来，也可能读不进去。不能保障每个正本的数据肯定是统一的。
• 最终一致性（Eventual Consistency）：写入一个数据 a 胜利后，在其余正本有可能读不到 a 的最新值，但在某个工夫窗口之后保障最终能读到。
• 强一致性（Strong Consistency）：数据 a 一旦写入胜利，在任意正本任意时刻都能读到 a 的最新值。

11）如何实现强一致性

• 两阶段提交
• 三阶段提交（3PC）

12）如何实现最终一致性

• 重试机制：超时工夫，重试的次数，重试的间隔时间，重试间隔时间的衰减度。
• 本地记录日志。
• 牢靠事件模式。
• Saga 事务模型：又叫 Long-running-transaction，核心思想是把一个长事务拆分为多个本地事务来实现，由一个 Process manager 对立协调。
• TCC 事务模型：两阶段提交是依赖于数据库提供的事务机制，再配合内部的资源协调器来实现分布式事务。TCC（Try Confirm Cancel）事务模型的思维和两阶段提交尽管相似，然而却把相干的操作从数据库提到业务中，以此升高数据库的压力，并且不须要加锁，性能也失去了晋升。

7. 十二因素

12 因素利用是一系列云原生利用架构的模式汇合。这些模式能够用来阐明什么样的利用才是云原生利用，关注速度、平安、通过申明式配置扩大、可横向扩大的无状态 / 无共享过程以及部署环境的整体松耦合。

在 12 因素的背景下，利用指的是独立可部署单元。组织中常常把一些相互合作的可部署单元称作一个利用。

• 基准代码，一份基准代码，多份部署，应用 GIT 或者 SVN 治理代码，并且有明确的版本信息。
• 依赖，显示申明依赖。
• 配置：环境中存储配置。
• 后端服务：把后端服务当作附加资源。后端服务是指程序运行所须要的通过网络调用的各种服务，如数据库（MySQL、CouchDB）、音讯 / 队列零碎（RabbitMQ、Beanstalkd）、SMTP 邮件发送服务（Postfix），以及缓存零碎（Memcached）。
• 构建、公布、运行：严格拆散构建和运行。
• 过程，以一个或多个无状态过程运行利用，如果存在状态，应该将状态外置到后端服务中，例如数据库、缓存等。
• 端口绑定，通过端口绑定提供服务，利用通过端口绑定来提供服务，并监听发送至该端口的申请。
• 并发，通过过程模型进行扩大，扩大形式有过程和线程两种。过程的形式使扩展性更好，架构更简略，隔离性更好。线程扩大使编程更简单，然而更节俭资源。
• 易解决，疾速启动和优雅终止可最大化健壮性，只有满足疾速启动和优雅终止，能力使服务更强壮。
• 开发环境与线上环境等价，尽可能放弃开发、预公布、线上环境雷同。
• 日志，把日志当作事件流，微服务架构中服务数量的暴发须要具备调用链分析能力，疾速定位故障。
• 治理过程，把后盾治理工作当作一次性过程运行，一些工具类在生产环境上的操作可能是一次性的，因而最好把它们放在生产环境中执行，而不是本地。

8. 研发流程

1）为什么抉择 DevOps

能进步交付速度、更新频率，这两点是掂量一个公司能力的重要指标。

2）Gartner 提出的 DevOps 模型

文化、技术、过程和人，其中团队文化才是最难扭转的，技术方面包含基础设施即代码、全局监控、继续监控。

3）自动化测试

• 自动化测试能够代替人工测试。
• 测试成了全栈工程师的工作，因为不沟通才是最有效率的沟通。

4）Code Review

• 晋升代码易读性。
• 对立标准、规范。
• 技术交换，晋升能力。
• Code Review 准则：以发现问题为指标，团队凋谢、通明，整个 Code Review 的过程对事不对人，不设置惩办。
• 线上线下接合的形式，长期线上，定期线下。

5）流水线

继续交付：升高交付周期，通过自动化工具实现设计、开发、测试、公布、运维各个阶段的重复性工作，通过工具实现标准化、规范化，升高出错概率。

6）开发人员自服务

对于开发过程来说，少交换、少沟通、少散会就是最高效的。

• 高覆盖率的自动化测试
• 全面的监控
• 继续交付流水线
• 麻利基础设施
• 自动化 / 智能化运维
• 好的架构
• 全栈工程师
• 服务型治理
• 工程师文化
• 信赖文化
• 分享文化

7）代码即设计

• 含糊麻利研发流程阶段性：业务需要太多和技术变动速度太快。
• 整个进化设计须要简略的架构 + 继续集成 + 重构 + 整个研发流程设计。

9. 团队文化

团队文化就好比土壤，要造就什么样的员工，就要有适宜他的土壤。

1）团队规模导致的问题

• 不足信赖。因为人数泛滥，难于治理，只能通过制度、流程、标准、绩效束缚。
• 没有责任感。高层管理者忙着开各种决策会议。
• 部门墙。跨部门协调还不如与第三方单干。
• 不尊重专业人士。当所有的生杀大权都把握在多数人手中的时候。
• 管理层级太深。管理层级太深导致的问题很多。

2）组织构造 – 康威定律

设计零碎的组织，其产生的设计和架构等价于组织间的沟通构造。艰深来讲，就是什么样的团队构造，就会设计出什么样的零碎架构。如果将团队拆分为前端、后端、平台、数据库，那么零碎也会依照前端、后端、平台、数据库构造隔离。

• 第一定律：Communication dictates design，即组织沟通形式会通过零碎设计出现。
• 第二定律：There is never enough time to do something right,but there is always enough time to do it over，即工夫再多，一件事件也不可能做得完满，但总有工夫做完一件事件。
• 第三定律：There is a homomorphism from the linear graph of a system to the linear graph of its design organization，即线型零碎和线型组织架构间有潜在的异质同态个性。
• 第四定律：The structures of large systems tend to disintegrate during development,qualitatively more so than with small systems，即大的零碎组织总是比小零碎更偏向于合成。

3）“沟通漏斗”是指工作中团队沟通效率降落的一种景象

如果一个人心里想表述事项指标的 100%，当你在众人背后、在散会的场合用语言表达时，你说进去的只剩下 80%。而进入他人的耳朵时，因为文化程度、常识背景等关系，只留存了 60%。实际上，真正被他人了解了大略只有 40%。等到这些人遵循领悟的 40% 具体口头时，只具备了当初事项指标的 20% 了。三个月后信息只剩下 5% 了。

4）环境气氛

• 公开通明的工作环境.
• 学习型组织：让团队领有独特愿景、指标，并继续学习。
• 缩小有效的正式汇报。
• 高效的会议：放大会议范畴，惯例会议不应该超过 45 分钟；限度“意见首领”的发言时长；会议中不容许开小差；会议中的一致不应该延长到会议之外。

10. Serverless

随着以 Kubernetes 为代表的云原生技术成为云计算的容器界面，Kubernetes 成为云计算的新一代操作系统。面向特定畛域的后端云服务 (BaaS) 则是这个操作系统上的服务 API，存储、数据库、中间件、大数据、AI 等畛域的大量产品与技术都开始提供全托管的云状态服务，现在越来越多用户已习惯应用云服务，而不是本人搭建存储系统、部署数据库软件。

当这些 BaaS 云服务日趋完善时，Serverless 因为屏蔽了底层设施的运维复杂度，让开发人员能够将更多精力用于业务逻辑设计与实现，而逐步成为云原生支流技术之一。Serverless 计算蕴含以下特色：

• 全托管的计算服务，客户只须要编写代码构建利用，无需关注同质化的、累赘沉重的基础设施开发、运维、平安、高可用等工作。
• 通用性，联合云 BaaS API 的能力，可能撑持云上所有重要类型的利用。
• 主动的弹性伸缩，让用户无需为资源应用提前进行容量布局。
• 按量计费，让企业应用老本得无效升高，无需为闲置资源付费。

函数计算 (Function as a Service) 是 Serverless 中最具代表性的产品状态。通过把应用逻辑拆分多个函数，每个函数都通过事件驱动形式触发执行，例如当对象存储 (OSS) 中产生的上传 / 删除对象等事件，可能主动、牢靠地触发 FaaS 函数解决且每个环节都是弹性和高可用的，客户可能疾速实现大规模数据的实时并行处理。同样的，通过消息中间件和函数计算的集成，客户能够疾速实现大规模音讯的实时处理。

Serverless 有余的中央：

• 胜利案例太少
• 很难满足个性化
• 不足行业标准
• 首次拜访性能差
• 不足开发调试工具

11. Service Mesh 技术

Service Mesh 是分布式应用在微服务软件架构之上倒退起来的新技术，旨在将那些微服务间的连贯、平安、流量管制和可观测等通用性能下沉为平台基础设施，实现利用与平台基础设施的解耦。这个解耦意味着开发者无需关注 微服务相干治理问题而聚焦于业务逻辑自身，晋升利用开发效率并减速业务摸索和翻新。换句话说，因为大量非功能性从业务过程剥离到另外过程中，Service Mesh 以无侵入的形式实现了利用轻量化，下图展现了 Service Mesh 的 典型架构：

在这张架构图中，Service A 调用 Service B 的所有申请，都被其下的 Proxy(在 Envoy 中是 Sidecar) 截获，代理 Service A 实现到 Service B 的服务发现、熔断、限流等策略，而这些策略的总控是在 Control Plane 上配置。

服务网格的技术倒退上数据立体与管制立体间的协定标准化是必然趋势。管制立体能够认为是注册核心及治理配置面板；数据立体能够认为是由服务化框架依赖的组件独立而成的一个过程，数据立体代理业务服务的注册发现、负载平衡、容错等能力。为什么须要 Service Mesh：

• 在微服务架构中，让开发人员感觉不到微服务之间的通信。
• 当服务数量越来越多，降级微服务框架变得越来越简单的时候，微服务框架不可能始终不变且没有 bug。
• Service Mesh 则从业务过程集成客户端的形式演进为独立过程的形式，客户端变成了一个独立过程。
• 对这个独立过程降级、运维要比绑在一起强得多。
• 微服务架构更强调去中心化、独立自治、跨语言。Service Mesh 通过独立过程的形式进行隔离，低成本实现跨语言。
• 每个服务独立占用一个容器，将服务、依赖包、操作系统、监控运维所需的代理打包成一个镜像。这种模式促成了 Service Mesh 的倒退，让 Service Mesh 实现起来更容易。

12. 云原生架构成熟度模型

因为云原生架构蕴含了 6 个要害架构维度(简写为 SESORA，Service + Elasticity + Serverless + Observability + Resilience + Automation)，因而咱们先定义要害维度的成熟度级别：

现状

容器的标准化应用扭转了软件开发形式，基于云原生的开发可能帮忙咱们构建更灵便、更弱小的利用。近日，CNCF（云原生计算基金会）就公布了云原生开发现状的报告解读。

该报告通过对 17,000 多位软件开发人员的考察数据，对云原生开发深入分析，心愿可能帮忙大家更好地把握云原生开发生态系统的当前状况。其要点包含：

• 寰球云原生开发人员超过 470 万。
• 应用 Kubernetes 的开发人员超过 170 万。
• 应用 Serverless 架构及云函数的开发人员超过 330 万。
• Kubernetes 用户更有可能影响购买决策。

1. 市场规模

据估计，寰球云原生开发人员数量超过 470 万，占后端开发的 36%。其中包含 290 万应用编排的用户，以及 330 万应用云函数或 Serverless 架构的开发人员。二者别离占据了后端开发的 22% 和 25%。

该估算数据还思考了 150 万同时应用编排和 Serverless 技术的开发人员。

2. 各个国家及地区的状况

寰球范畴内云原生技术的应用差别很大。

总的来说，欧洲和北美的容器使用率远超亚洲。容器的应用已在东欧失去遍及，54% 的后端开发人员应用容器。北美和西欧等发达地区的使用率也很高。在北美、西欧和以色列，一半后端开发人员都应用了容器。同时在三个地区内，25%-26% 的后端开发人员采纳编排技术来治理这些容器。

大洋洲地区云原生技术的应用状况十分独特。只管容器的应用在该地区并没有其余地区那么广泛，但与寰球其余地区相比，Serverless 以及容器编排等技术在大洋洲的普及率最高。

亚洲、中东和非洲地区的开发人员采纳容器和云原生技术的速度较慢。中国的各大公司在向云的迁徙方面始终滞后，并且云原生技术的应用也出现同样的趋势。随着阿里巴巴的 CaaS 取得市场的青眼，置信未来东亚地区会涌现更多云原生开发人员。

3. 云原生开发人员把握多种基础架构

云原生开发的灵活性让各个组织更灵便地操作分布式基础架构，并按需正当调配工作资源。

与未参加云原生的开发人员相比，云原生开发人员把握的计算基础架构的确更多。这些开发人员更加违心在公有云、公共云、混合云和本地服务器等四种环境中运行代码，且均匀应用了 1.8 种环境，而未参加云原生开发人员的平均值为 1.5。数据显示，270 万云原生开发人员（58%）在公共云上运行后端代码，220 万开发人员（47%）抉择了公有云，抉择本地服务器的开发人员为 220 万（47%），而抉择混合云的开发人员为 170 万（36%）。

无论是云原生开发人员还是传统开发人员，抉择在本地服务器上运行代码的比例都雷同。这表明，只管云原生开发人员曾经把握了云的灵活性，但他们并未放弃本地服务器。

4. 云的应用在各个行业各不相同

尽管开发人员采纳了云原生开发策略，但运行这些软件的计算资源在各个行业往往各不相同。

例如，与本地服务器或公有云相比，软件公司更偏向于在公共云中运行代码。在软件公司工作的云原生开发人员中，近三分之二在公共云中运行代码，同时该行业一半的开发人员在公有云上运行代码。

数据分析、商业智能以及硬件畛域的开发人员更偏向于在公共云上运行软件。与其余行业的平均水平相比，这些行业中的云原生开发人员在公共云中运行代码的概率高 7%。

在波及敏感数据的行业工作的云原生开发人员更偏向于在本地服务器或公有云上运行代码。与其余行业相比，金融服务畛域的云原生开发人员在本地服务器上运行代码的比例高 12%，而医疗保健畛域的开发人员的比例高 8%。

他们心愿通过本地计算，更好地管制敏感数据。

市场营销、娱乐和房地产畛域的云原生开发人员不太可能在本地服务器上运行代码。这些行业的重点是内容，因而须要轻松疾速地拜访。可拜访性和性能对这些畛域的胜利至关重要，而本地服务器可能无奈满足这些要求。

另外，电信和政府 / 国防畛域的云原生开发人员应用公有云、公共云和本地服务器的比例大致相同。这些开发人员应用公共云的比例绝对较低。

将来

“将来的软件肯定是成长于云上的”，这是云原生理念的最外围假如。

1. 容器技术发展趋势

1）趋势一：无处不在的计算催生新一代容器实现

随着互联网的倒退到万物智联，5G、AIoT 等新技术的涌现，随处可见的计算需要曾经成为事实。针对不同计算场景，容器运行时会有不同需要。KataContainer、Firecracker、gVisor、Unikernel 等新的容器运行时技术层出不穷，别离解决平安隔离性、执行效率和通用性三个不同维度要求。OCI(Open Container Initiative)规范的呈现，使不同技术采纳统一的形式进行容器生命周期治理，进一步促成了容器引擎技术的继续翻新。

2）趋势二：云原生操作系统开始浮现

Kubernetes 曾经成为云时代的操作系统。比照 Linux 与 Kubernetes 概念模型，两者都定义了凋谢的、标准化的拜访接口：向下封装资源，向上撑持利用。

它们都提供了对底层计算、存储、网络、异构计算设施的资源形象和平安拜访模型，能够依据利用需要进行资源调度和编排。Linux 的计算调度单元是过程，调度范畴限度在一台计算节点。而 Kubernetes 调度单位是 Pod，能够在分布式集群中进行资源调度，甚至逾越不同云环境。

过往 Kubernetes 上次要运行着无状态的 Web 利用。随着技术演进和社区倒退，越来越多有状态利用和大数据 / AI 利用负载逐步迁徙到 Kubernetes 上。Flink、Spark 等开源社区以及 Cloudera、Databricks 等商业公司都 开始加大对 Kubernetes 的反对力度。

对立技术栈晋升资源利用率：多种计算负载在 Kubernetes 集群对立调度，能够无效晋升资源利用率。

对立技能栈升高人力老本：Kubernetes 能够在 IDC、云端、边缘等不同场景进行对立部署和交付。云原生提 倡的 DevOps 文化和工具集能够无效晋升技术迭代速度并升高人力老本。

减速数据服务的云原生化：因为计算存储拆散具备微小的灵活性和老本劣势，数据服务的云原生化也逐步成为 趋势。容器和 Serverless 的弹性能够简化对计算工作的容量布局。联合分布式缓存减速 (比方 Alluxio 或阿里云 Jindofs) 和调度优化，大大晋升数据计算类和 AI 工作的计算效率。

3）趋势三：Serverless 容器技术逐步成为市场支流

Serverless 和容器技术也开始交融失去了疾速的倒退。通过 Serverless 容器，一方面根本性解决 Kubernetes 本身复杂性问题，让用户无需受困于 Kubernetes 集群容量布局、平安保护、故障诊断等运维工作; 一方面进一步开释云计算能力，将平安、可用性、可伸缩性等需要下沉到基础设施实现。

4）趋势四：动静、混合、分布式的云环境将成为新常态

上云已是大势所趋，但对于企业而言，有些业务出于对数据主权、平安隐衷的考量，会采纳混合云架构。一些企业为了满足平安合规、老本优化、晋升地区覆盖性和防止云厂商锁定等需要，会抉择多个云厂商。混合云 / 多云架构已成为企业上云新常态。Gartner 指出“到 2021，超过 75% 的大中型组织将采纳多云或者混合 IT 策略。”

2. 基于云原生的新一代利用编程界面

Kubenetes 曾经成为了云原生的操作系统，而容器成为了操作系统调度的根本单元，同时定义了利用交付的规范。但对于开发者来说，这些还远没有深刻到利用的架构，扭转利用的编程界面。然而这种改革曾经在悄悄产生了，而且有一直减速之势。

• Sidecar 架构彻底改变了利用的运维架构。因为 Sidecar 架构反对在运行时隔离利用容器与其余容器，因而 本来在虚拟机时代和业务过程部署在一起的大量运维及管控工具都被剥离到独立的容器里进行对立治理。对于利用来说，仅仅是按需申明应用运维能力，能力实现成为云平台的职责。
• 利用生命周期全面托管。在容器技术根底上，利用进一步形容清晰本身状态(例如通过 Liveness Probe)，形容本身的弹性指标以及通过 Service Mesh 和 Serverless 技术将流量托管给云平台。云平台可能全面治理利用的生命周期，包含服务的高低线、版本升级、欠缺的流量调配、容量治理等保障业务稳定性。
• 用申明式配置形式应用云服务。云原生利用的外围特点之一就是大量依赖云服务(包含数据库、缓存、音讯等) 构建，以实现疾速交付。
• 语言无关的分布式编程框架成为一种服务。为了解决分布式带来的技术挑战，传统中间件须要在客户端 SDK 编写大量的逻辑治理分布式的状态。咱们看到很多我的项目在把这些内容下沉到 Sidecar 中，并通过语言无关的 API (基于 gRPC/HTTP) 提供给利用。这一变动进一步简化利用代码逻辑和利用研发的职责，例如配置绑定，身份认证和鉴权都能够在 Sidecar 被对立解决。

综上，包含生命周期治理、运维治理、配置范畴和扩大和治理、以及语言无关的编程框架，一起形成了簇新的利用与云之间的编程界面。这一改革的外围逻辑还是把利用中和业务无关的逻辑和职责，剥离到云服务，并在这一过程中造成规范，让利用开发者可能在专有云、私有云或者混合云的场景中，能有统一的研发运维体验。

Sidecar 架构模式

将应用程序的组件部署到独自的过程或容器中以提供隔离和封装。这种模式还能够使应用程序由异构组件和技术组成，该模式被命名为 Sidecar，因为它相似于连贯到摩托车的辅助车，辅助车被附加到父应用程序并为应用程序提供反对性能。

3. Serverless 发展趋势

近年来，Serverless 始终在高速倒退，呈现出越来越大的影响力。在这样的趋势下，支流云服务商也在不断丰富云产品体系，提供更便捷的开发工具，更高效的利用交付流水线，更欠缺的可观测性，更丰盛的产品间集成。

1）趋势一：Serverless 将无处不在

任何足够简单的技术计划都可能被实现为全托管、Serverless 化的后端服务。不只是云产品，也包含来自单干 搭档和三方的服务，云及其生态的能力将通过 API + Serverless 来体现。事实上，对于任何以 API 作为性能透出形式的平台型产品或组织，Serverless 都将是其平台策略中最重要的局部。

2）趋势二：Serverless 将通过事件驱动的形式连贯云及其生态中的所有

通过事件驱动和云服务连贯，Serverless 能力也会扩大到整个云生态。

3）趋势三:Serverless 计算将继续进步计算密度，实现最佳的性能功耗比和性能价格比

虚拟机和容器是两种取向不同的虚拟化技术，前者安全性强、开销大，后者则相同。Serverless 计算平台一方面要求兼得最高的安全性和最小的资源开销，另一方面要放弃对原有程序执行形式的兼容，比方反对任意二进制文件，这使得实用于特定语言 VM 的计划不可行。

当 Serverless 计算的规模与影响力变得越来越大，在利用框架、语言、硬件等层面上依据 Serverless 负载特点进行端对端优化就变得十分有意义。新的 Java 虚拟机技术大幅提高了 Java 利用启动速度，非易失性内存帮忙实例更快被唤醒，CPU 硬件与操作系统合作对高密环境下性能扰动实现精密隔离，新技术正在发明簇新的计算环境。

实现最佳性能功耗比和性能价格比的另一个重要方向是反对异构硬件。因为 x86 处理器的性能越来越难以晋升，而在 AI 等对算力要求极高的场景，GPU、FPGA、TPU(Tensor Processing Units)等架构处理器的计算效率更具劣势。随着异构硬件虚拟化、资源池化、异构资源调度和利用框架反对的成熟，异构硬件的算力也能通过 Serverless 的形式开释，大幅升高企业应用门槛。

4. 参考文献

• Paul Fremantle’s Blog
• Cloud-Native: What It Is and How It All Started
• The Twelve Factor App
• shikanon’s Blog
• Migrating to Cloud Native Application Architectures
• 迁徙到云原生利用架构
• 微软技术文档: 云原生的定义
• CNCF 官网
• 什么是云原生？聊聊云原生的今生
• 考察近两万程序员，以后云原生开发现状到底如何？
• 阿里云云原生架构白皮书