前些年云计算、分布式架构、微服务架构概念比较火热，这一两年，大家提分布式架构、微服务架构的声音少了很多，转而云原生，云原生架构 这些字眼频繁的出现，什么是云原生，云原生架构跟之前提的分布式架构，微服务架构有什么区别呢，带着这样的疑问，我们寻找云原生的定义。当前对云原生的理解各有各的说法，没有一个统一标准化的描述，现在大家看得比较多的一种说法是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.

云原生技术有利于各组织在公有云、私有云和混合云等现代动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观测的松耦合系统。结合强大的自动化手段，云原生技术使工程师能够以极少的工作量实现频繁和可预测的重大变更。

相信大家初次看到这个解释，还是不能很好地理解云原生。本文就试图以白话的方式来介绍一下云原生相关的概念。云原生的单词是"Cloud Native"， Native 在英文中有土著的意思，意味着云应用像土著一样适应云的环境，熟练使用云环境的弹性等能力，也能从容面对各种云环境带来的复杂度问题。而云原生架构就是为了帮助应用更好的以云原生的方式在云上运行的一组架构原则和最佳实践的集合。云原生架构的核心思想在于将云应用中的非业务代码部分进行最大化的剥离，让云基础设施接管应用大量的非功能特性，例如弹性伸缩能力，应用高可用能力，应用故障自愈能力，应用可观测能力等，让开发和运维人员更专注于业务本身。

云原生架构是为了帮应用更好地在云上使用。那我们首先要了解为什么应用要上云。

从技术的视角来看，有两个好处。

从业务视角来看，上云给业务的商业模式带来了创新的土壤。线下的系统实现在线化的转变，业务价值的交互效率得到大大地提升。上云为企业释放成本红利，帮助企业从原来的 CAPEX 模式转变为 OPEX 模式。系统上云后，系统跟上下游客户联系得更紧密，为系统的生态发展提供了无限可能，有利于更多的业务创新。

看到上云带来的好处，业务就需要根据自身的实际情况，选择合适的上云方式。

在不改变应用程序运行环境的前提下将系统和数据迁移上云。直接迁移一般是将物理机迁移至虚拟机，或将虚拟机迁移至虚拟机。如果企业希望快速上云或者有大型应用需要上云，直接迁移是最为合适和有效的一种迁移方法。

在不改变应用核心架构的前提下，将数据和系统迁移上云时，对用用程序做一些简单的云优化，这种方法称为“修补后迁移”。比如，用云服务商提供的数据库服务代替原有的关系型数据库，或用云服务商提供的消息队列服务代替原有的自建消息中间件。大多数企业都会用这种方法来降低管理成本，并提高效率。

“重新构建”即将应用的架构和开发模式重建，实现云原生的应用服务。当现有的应用环境难以满足日后的使用，或性能和规模无法满足日后的需求，将采用“重新构建”这种迁移模式。“重新构建”相对其他几种方法，成本最高，但是从长远来看，更加满足未来的业务和系统的需求。

这三种方式上云考虑的因素对比如下表格所示：

早期提到云原生架构技术，有三驾马车的提法，微服务+容器化+DevOPS。具于这三种技术体系，应用能实现re-factor模式的上云目标。这是目前已上云的大部分企业采用的技术手段。

另外云原生架构是在不断发展的，一方面，随着业务发展的需要，物联网，5G技术普及使用，企业应用也不满足单一云上运行的形态，希望实现多云，混合云，云边协同，边缘计算等多种形态下更好的运行。另一方面，云原生的技术也在不断地改革创新，例如Service Mesh, Serverless 等技术的出现，降低业务上云的复杂度，降低业务在云上运行的成本。因此云原生架构使用的技术也是在不断更新换代的。CNCF 认为的云原生架构技术添加了服务网络，不可变基础设施和声明式API 这三种技术。

所以我们要从云原生架构的核心理念来看，只要是有助于帮助应用更好实现云原生的技术实践，都应当归为云原生架构技术，接下来介绍一下云原生架构主要使用的哪些技术。

微服务架构是相对于单体架构来说的，两者分属不同的架构风格。在微服务架构中，服务是一个单一的、可独立部署的软件组件，它实现了一些有用的功能，服务的API封装了其内部实现，与单体架构不同，开发人员无法绕过服务的API直接访问服务内部的方法和数据，因此，微服务架构强制实现了应用程序的模块化。

微服务架构的最核心特性是服务之间的松耦合性。服务之间的交互采用API完成，这样做就封装了服务的实现细节，从而实现了在不影响客户端的情况下，对实现方式做出修改。

微服务架构通过将大的系统按照业务服务的粒度进行拆分，每个服务可独立开发、测试、验证和部署，这样分解后，带来的好处有如下几点：

但微服务也不是银弹，引入微服务是有成本的，使用它会引入更多技术挑战，比如问题定位的复杂度，日志分析的复杂度，应用可观测性的复杂度，应用高可用的复杂度等方面，企业需要根据业务的不同的阶段进行合理的引入，不能完全为了微服务而“微服务”。

浩鲸科技在微服务的技术领域提供了微服务框架产品ZDubbo，微服务治理平台产品SGP。

SGP产品功能图示：

DevOPS包含Dev和OPS两个领域，Dev领域践行敏捷研发的理念，实现产品高频的持续交付能力；OPS领域提供各种运维能力，满足系统可观测性的需求。

浩鲸科技在DevOPS领域提供ZCM产品

基于容器镜像的技术，直接将一个应用运行所需的完整环境都打包进了镜像。这样就可以实现应用的集装箱式的交付能力，提升了交付效率；另一方面，基于容器轻量化的特性，满足云应用弹性伸缩时，快速拉起应用的能力要求。

浩鲸科技在容器领域提供容器云平台产品

云原生中间件提供更多的云上应用运行所需的技术组件能力，提供高性能，高稳定，易使用，易运维的技术组件，帮助业务应用屏蔽技术复杂度，实现技术的复用。

浩鲸科技在中间件领域提供分布式缓存中间件产品ZCache, 分布式消息中间件产品ZMQ，分布式数据库中间件产品ZDAAS。

ZCache产品功能示意图

ZDAAS产品功能示意图

服务网格是用于处理服务间通信的专用基础设施层，负责在微服务间进行可靠的请求传递。服务网格通常通过一组轻量级网络代理来实现，这些代理与应用程序代码一起部署，而不需要感知应用程序本身。

随着规模和复杂性的增长，服务网格包含的实现的功能越来越多，它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如A/B测试、金丝雀发布、限流、访问控制和端到端认证等。其部署结构如下图所示：

服务网格有如下几个特点：- 应用程序间通讯的中间层 - 轻量级网络代理 - 应用程序无感知 - 解耦应用程序的重试/超时、监控、追踪和服务发现 - 实现跨语言的服务通讯能力。

一个工作负载（比如容器、虚拟机等）一旦部署以后就不会被修改。当需要更新，修复或修改某些内容的时候，只需要将新的、经过验证的工作负载替换旧的即可。

不可变基础设施的作用主要体现在系统的稳定性方面。传统的应用程序一旦部署到用户特定的服务器上以后，服务器系统是会不断变化的，不是操作系统升级，就是安装了新的应用，可能引起冲突，导致应用程序需要跟着用户系统环境的改变而不断升级，这中间就会不断地出现新的问题。而不可变基础设施就规避了所有的这些问题，因为云原生应用是部署在不可变的基础设施上的，因此就不存在变化的问题。

声明式API是一种比命令式API更高级的接口设计方式，简单来说，命令式API提供给用户怎么做的能力，而声明式API给用户提供了做什么的能力。基于声明式API，可以让云应用更轻松的使用基础设施的能力，让业务开发的精力聚焦业务本身。

如何评估应用上云落地的成效，阿里云给出了云原生架构成熟度模型（SESORA），将云原生化分割成服务化能力(Service)、弹性能力(Elasticity)、无服务器化程度(Serverless)、可观测性(Observability)、韧性能力(Resilience)、自动化水平(Automation)六个不同维度(SESORA)，每个评估维度设立ACNA-1至ACNA-4 四个不同等级并依次计作0至3分，同时设立零级、基础级、发展级、成熟级四个不同成熟等级。云原生架构成熟度模型的提出，对企业云原生化现状、能力和发展路径不清晰等问题，给出评估与优化方向，帮助企业走上数字化转型“最短路径”。