微服务体系和云原生架构的区别

1 云原生架构简介

CloudNative 直译过来是云原生，是面向云环境而设计的软件架构。云原生并不是新的技术，它是基于微服务架构思想、以容器技术为载体，一种产品研发运营的全新模式。详细信息可见 https://github.com/cncf/landscape 。

2015 年 Pivotal 公司的 Matt Stine 写了一本叫做迁移到云原生应用架构的文章，第一次提出了云原生（ Cloud Native ）的概念。 Pivotal 不但是云原生应用的提出者，而且还推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。

Pivotal 最初的定义，其中探讨了云原生应用架构的几个主要特征：（ 1 ）符合 12 因素应用；（ 2 ）面向微服务架构；（ 3 ）自服务敏捷架构；（ 4 ）基于 API 的协作；（ 5 ）抗脆弱性等。

CNCF （ Cloud Native ComputingFoundation ，一个组织）对云原生做了重新定义，云原生技术帮助公司和机构在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API 。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术可以使开发者轻松地对系统进行频繁并可预测的重大变更。云原生总体内容如图 1 所示。

图1   云原生总体图

目前业界公认的云原生主要包括以下四个层面的内容，如图 2 所示。

图 2  云原生的内容

CNCF 给出了云原生应用的三大特征：

• 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。

• 动态管理：通过集中式的编排调度系统来实现动态的管理和调度。

• 面向微服务：明确服务间的依赖，互相解耦。

云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生由微服务架构， DevOps 和以容器为代表的敏捷基础架构组成。持续交付、 DevOps 以及微服务分别面向云原生机制的三项根本性重点，即为什么、如何以及什么。

持续交付能力正是软件迈向云原生方向的主要动力：软件发布速度的加快能够有效降低反馈周期的持续时间。 DevOps 代表着全面实现云原生战略过程中需要遵循的文化与技术转变。微服务则是一套软件架构模式，其已经被成功且广泛地应用于开发及交付运营工作的规模扩展当中，且能够有效规避缓慢、高风险及单一性部署策略。

2 微服务体系和云原生架构的区别

如果是架构师、开发工程师讲技术架构，一般都讲微服务架构体系，以微服务微基础，然后把 CI/CD 、 DevOps 、容器等基础设施环境都包含在内。如果是运维工程师讲架构，一般都讲云原生架构，以容器等基础设施环境为基础，把微服务、 CI/CD 、 DevOps 等包含在内。这就是这两个概念的区别。

微服务体系和云原生架构的组成部分有各自的部分，也有重叠的部分。这样就可以划分为三个部分，如图 3 所示。

图3   微服务体系与云原生架构的对应

这三个组成部分的描述：

第 1 部分为微服务体系所具有部分：微服务业务体系，该部分从业务需求出发，如何来搭建微服务的业务模型。这部分内容在云原生架构中没有说明。

第 2 部分为云原生架构所具有部分：基础设施部分，通信基础部分。在微服务技术体系中，只是涉及到关于微服务技术架构及其相关的框架、平台和工具。但对于基础设施和基础网络及通信，对于微服务体系本身而言仅仅是外部依赖，故微服务技术体系中并不包含该部分内容。

第 3 部分为微服务体系与云原生架构共有部分：这里面的内容比较复杂。也包括两个部分的内容。

第一部分是微服务技术体系部分共用功能。主要是微服务技术架构和相关集成 工具 部分。云原生架构在此更多强调的是云平台和容器化能力。

第二部分是微服务管理体系部分共用功能。微服务体系更多是从业务角度来获取相关的管理支持，如研发过程中的敏捷、研发规范和度量，运维过程的 CI\CD 等。而云原生架构更多是从基础设施的角度来讲述如何支撑 DevOps 和 CI\CD 。