对于最近1到2年，我谈的最多的就是微服务+DevOps+容器化PaaS平台。其中在微服务里面重点又谈了中台和API网关两个关键点，在DevOps里面兼谈了敏捷研发管理。同时自己也指出了这些关键技术和方法是传统IT企业进行转型的基础，不会独立存在，而应该是形成一个完整的整体。

在整个产品规划里面又分为了云台，云网和云镜三个方面的内容。

1. 云台：重心从原来的IaaS平台转到Docker容器化的PaaS平台，并提供DevOps支撑能力平台

2. 云网：对应原来的ESB服务总线，同时ESB转为轻量化的微服务或API网关，并提供大数据集成能力

3. 云镜：提供整个平台的资源监控，业务运行监控，性能分析，服务链监控等关键能力。

对于集团型大企业，按上述思路来构建新应用完全是没有问题的，但是里面对各个组件的能力都需要进一步增强和我完善，包括我在前面博客文章也提到过，对于我们DevOps平台，虽然整体功能上已经完全支撑整个研发持续交付过程，但是实际使用的时候仍然还存在一些关键功能缺失，这些也是需要进一步完善的地方。而对于云镜而言，要实现完整的监控分析能力，往往也需要很大的研发投入才能够完成。

微服务架构+容器化+DevOps 将成为后续企业信息化转型的主流趋势。

以上部分内容也是我在18年11月的一篇产品规划杂谈里面的谈到的，而一直以来自己也在思考如何用一个概念将上面几点全部整合起来。而云原生刚好就是覆盖上述所有关键技术和方法的一个概念。

什么是云原生？

对于Cloud Native翻译为云原生，是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。

Cloud Native既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。Cloud Native也可以说是一系列Cloud技术、企业管理方法的集合。

https://baijiahao.baidu.com/s?id=1606406149473084309&wfr=spider&for=pc

在一般用法中，“云原生”是一种构建和运行应用程序的方法，它利用了云计算交付模型的优势。“云原生”是关于如何创建和部署应用程序，和位置无关。 这意味着应用程序位于云中，而不是传统数据中心。

CNCF将“云原生”定义的更为狭窄，意味着使用开源软件堆栈进行容器化，其中应用程序的每个部分都打包在自己的容器中，动态编排，以便每个部分都被主动调度和管理，以优化资源利用率和面向微服务的应用程序，以提高应用程序的整体灵活性和可维护性。

咨询公司Deloitte的董事总经理Mike Kavis说：“云原生应用程序专门设计用于运行现代云计算平台所需的弹性和分布式特性。” “这些应用程序松散耦合，意味着代码不会硬连接到任何基础架构组件，因此应用程序可以按需伸缩，并采用不可变基础架构的抽象。通常，这些架构是使用微服务构建的，但这不是强制性要求。”

云服务提供商Splunk的首席技术支持者Andi Mann表示，对于云原生应用程序而言，最大的不同之处在于应用程序的构建，交付和运维方式。“利用云服务意味着使用敏捷和可扩展的组件（如容器）来提供离散和可重用的功能，这些功能以良好描述的方式集成，甚至跨越多云等技术边界，这使得交付团队可以使用可重复的自动化和编排来快速迭代。”

云原生应用程序开发通常包括DevOps，敏捷方法，微服务，云平台，Kubernetes和Docker等容器，以及持续交付，简而言之，每种新的和现代的应用程序部署方法。

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

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

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

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

可以参考网上的要给核心导图：

因此，你确实希望拥有平台即服务（PaaS）模型。PaaS不是必需的，但它使事情变得更容易。绝大多数云客户从基础架构即服务（IaaS）开始，这有助于从底层硬件中抽象出他们的应用程序。但PaaS增加了一个额外的层来抽象底层操作系统，因此你可以完全专注于应用程序的业务逻辑，而不必担心进行操作系统调用。

实际上我们看到对于完整的DevOps是包括了持续交付方面的内容的。因此对于云原生的概念完全和我前面经常谈到的微服务，容器化PaaS和DevOps相吻合。

即云原生 = 微服务+ DevOps + 容器化PaaS

云原生本身包括了云原生平台和云原生应用，而平台则是指容器PaaS平台和DevOps能力支撑平台，而云原生应用可以理解微基于微服务思想和开发框架开发的微服务应用。

如果仅仅如此，那么对云原生的理解还是关键技术和方法的一个集合，那么这些集合的目标又是什么？简单理解来说元原生核心是让软件的开发和交付面向云平台或云服务基础设施而进行，能够充分利用云平台提供的能力和服务快速的完成软件的开发和集成，面向客户的持续交付，同时又能够做到足够的敏捷响应变化。

如何做到，核心底层技术是容器化PaaS，小而灵活，而且具备编排属性和能力，传统应用架构通过微服务化后变得足够小而自治，方便进行敏捷开发和迭代，快速的交付和响应，同时也方便部署和托管到容器中。而DevOps更多是一套完全适应云端协同的敏捷管理方法和流程，来实现持续集成和交付。

软件因云而生，即云原生，需要的就是上面三者的密切配合来完成。

虽然对于容器化PaaS和微服务我在博客文章里面谈的比较多，这里还是摘录下元原生一篇文章里面的一些对容器化PaaS，服务编排和微服务的一些关键描述：

参考：http://dockone.io/article/2991

■ 容器化封装

最近几年Docker容器化技术很火，经常在各种场合能够听到关于Docker的分享。Docker让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中。Docker背后的想法是创建软件程序可移植的轻量容器，让其可以在任何安装了Docker的机器上运行，而不用关心底层操作系统。Docker可以解决虚拟机能够解决的问题，同时也能够解决虚拟机由于资源要求过高而无法解决的问题。其优势包括：

1. 隔离应用依赖

2. 创建应用镜像并进行复制

3. 创建容易分发的即启即用的应用

4. 允许实例简单、快速地扩展

5. 测试应用并随后销毁它们

自动化运维工具可以降低环境搭建的复杂度，但仍然不能从根本上解决环境的问题。在看似稳定而成熟的场景下，使用Docker的好处越来越多。

■ 服务编排

Kubernetes——让容器应用进入大规模工业生产。

这个总结确实很贴切。编排调度的开源组件还有：Kubernetes、Mesos和Docker Swarm。

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

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

他们为云原生应用提供的强有力的编排和调度能力，它们是云平台上的分布式操作系统。在单机上运行容器，无法发挥它的最大效能，只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势，而对于容器的编排管理，Swarm、Mesos和Kubernetes的大战已经基本宣告结束，Kubernetes成为了无可争议的赢家。

■ 微服务架构

传统的Web开发方式，一般被称为单体架构（Monolithic）所有的功能打包在一个WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了DO/DAO，Service，UI等所有逻辑。其架构如下图所示。

单体架构进行演化升级之后，过渡到SOA架构，即面向服务架构。近几年微服务架构（Micro-Service Archeticture）是最流行的架构风格，旨在通过将功能模块分解到各个独立的子系统中以实现解耦，它并没有一成不变的规定，而是需要根据业务来做设计。

微服务架构是对SOA的传承，是SOA的具体实践方法。微服务架构中，每个微服务模块只是对简单、独立、明确的任务进行处理，通过REST API返回处理结果给外部。在微服务推广实践角度来看，微服务将整个系统进行拆分，拆分成更小的粒度，保持这些服务独立运行，应用容器化技术将微服务独立运行在容器中。

过去设计架构时，是在内存中以参数或对象的方式实现粒度细化。微服务使用各个子服务控制模块的思想代替总线。不同的业务要求，服务控制模块至少包含服务的发布、注册、路由、代理功能。

容器化的出现，一定程度上带动了微服务架构。架构演化从单体式应用到分布式，再从分布式架构到云原生架构，微服务在其中有着不可或缺的角色。微服务带给我们很多开发和部署上的灵活性和技术多样性，但是也增加了服务调用的开销、分布式系事务、调试与服务治理方面的难题。

微服务架构当前主流开发框架SpringCloud，基本包括了微服务架构开发和运行过程中常用的组件，其中包括：服务发现与注册、熔断机制、路由、全局锁、中心配置管理、控制总线、决策竞选、分布式会话和集群状态管理等基础组件。

■ 元原生应用和传统应用开发的一个对比

参考：https://cloud.tencent.com/developer/article/1360266

其它参考：https://www.cnblogs.com/IT-Evan/p/CloudNative.html

返回上页