今天准备再写一篇文章来讲解下云原生的一些核心概念和思想，虽然前面已经写过多篇文章再谈云原生，但是这篇文章尽量将相关内容谈的更加简单和容易理解。

     为什么会发展出来云原生？

    要谈云原生概念的提出和快速发展，还是要回答云计算服务本身的发展上面。

     对于公有云服务厂商来讲，大家谈得最多的就是提供弹性计算和弹性存储服务，或者在更多人眼里，阿里云，华为云更多的就是给你提供虚拟机资源和存储资源。

     而当云服务厂商只提供资源池能力的时候，那么云厂商实际变不出什么花样，常见的资源本身就只有计算，存储和网络，各大云服务商的竞争也逐步转变为了价格上的竞争。在规模没有做上来的时候， 云服务商要做到盈利相当困难。

    典型的类似青云，规模做不起来，一直也处于亏损状态。

      这个有点类似电信运营商提供的5G网络或宽带网络服务，这就是典型的资源层能力提供，你实际很难赚钱，而实际赚钱的往往是基于你的网络资源开发出来的各种移动互联网应用，比如特别是手机游戏应用等。

那么云计算厂商如何更好地挣钱？

    简单来说就是你需要简单地提供资源池能力到提供多样化的服务层能力，从资源层不断朝服务层抽象，从IaaS平台的资源到PaaS平台的服务，提供资源层之上的各种增值服务能力。

     这个实际也是在谈云原生的时候，经常会谈到的一个内容点。不管是云计算本身的发展演进还是云原生的技术发展趋势，从IaaS服务到PaaS服务，都是从对底层物理资源或逻辑资源的依赖，不断的进行抽象，转变为对服务能力的依赖。

     比如资源池都是虚拟机和存储，但是基于这些资源你可以提供类似数据库，消息，缓存，对象存储，安全，日志各种技术服务能力。也就是你能够提供的增值服务能力多样化了，增值服务本身往往运营的利润更高。

    这也是有人提出为何我购买阿里云的Mysql数据库服务比我单独购买虚拟机安装Mysql数据库还贵，因为你享受了增值服务，显然收费更贵是合理的。你自己购买虚拟机，如果数据库性能无法满足应用需求，你想下你实际扩展起来相当麻烦。但是你当前购买Mysql数据库服务，整个DB服务的扩展性由云服务来帮助你解决，同时对于Mysql的日常运维监控也由平台帮助你搞定，这些多余的付出换来了这些增值服务。

     在清楚了云服务商希望从资源层转向服务层，更多提供PaaS层服务能力，在这点想清楚后再来看，整个PaaS层能力如何更加快速，灵活，可扩展的提供？

     这里就出来一个一个关键点，即从传统的虚拟机资源进一步朝上抽象，抽象为更加轻量化的容器资源池，容器资源最大特点就是可以更加快速的创建，销毁，更加快速的进行资源的调度和扩展。

      但是云服务商在提供这些容器资源和各种技术服务能力的时候，对于托管上来的应用有了更多的要求。如果你是传统的单体应用，一个部署包都好几百兆，这么庞大的应用实际并不适合部署和托管到容器资源上。

      因此在这里出现了一个关键点，即传统的单体应用最好进行拆分，将大单体拆分为更小的微服务，而且确保每个微服务都独立自治。

    当应用开发拆分为微服务后，云服务商还需要考虑如何更好地衔接应用开发到应用部署交付的过程，如果还是按传统的方式应用在内部开发测试完成，再打包为独立的部署包，然后在云平台上去做相关的手工部署操作，这显然无法满足敏捷和快速交付的需求。

      因此，为了更好地提供云平台的服务层能力，云厂商考虑的是将这个软件开发生命周期都管理起来，即帮助你实现持续集成和持续交付过程。即对应到我们常说的DevOps核心能力，通过DevOps实施，你发现你的应用开发，集成，和交付到云平台的过程彻底实现了持续交付和自动化。

所以你如何理解云原生？

    简单来说云原生的核心驱动力是云服务商从资源到服务层能力的不断抽象，在这个过程中出现了更加轻量高效的容器云资源池，同时为了让应用开发和云平台的服务层能力对接，衍生出了微服务，DevOps持续集成和交付以实现完整的自动化和上云协同。

如何理解云原生核心要素

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

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

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

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

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

1. 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用。

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

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

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

     当你看了上面的定义和三和核心特征的时候，实际还是很难理解云原生。对于云原生，我们仍然应该从定义去理解核心内涵。

原生如何定义？

     原生简单来讲就是这个东西从一出生开始就是属于我的，典型的概念如原生家庭，你不是抱来或捡来的，而是在我这出生，在我这个家庭成长和养大。华为在一次云计算会议上提出了云原生2.0的概念，指出云原生应该是从长在云上发展到生在云上。而云原生的本质就应该是生在云上，从一个IT应用的一诞生就生长在云上。

在传统的云平台服务使用中，大家都比较清楚。

      即IT应用往往是在内部开发和测试完成，最后打包为一个独立的部署包，再到阿里云等云服务商申请虚拟机和存储资源，将应用部署到云平台上面去使用。这完全类似于抱养一个小孩，等孩子都长大了，再寄养在你这里。

因此云原生的核心概念就是要改变这个传统方式，而是让应用一开始就生长在云上。

如何一开始就生长在云上？

     简单来说就是应用在一开始从开发框架和语言的选择，平台的选择，技术服务的选择等都需要考虑云服务厂商能力提供哪些能力，将云服务能力做为一个核心的设计输入融入到自己的架构和方案设计里面。

    只有这样你最终开发完成的应用才能够平滑地交付到云平台上面去。

     所以在云原生下不是简单地使用微服务，使用DevOps和容器云就是云原生，更加重要的是你的应用系统在一开始设计的时候就是为生在云上而设计，应用从从刚开始诞生的Alpha版本就是可以交付到云平台上的。

再来回顾云原生的核心要素

     在前面的核心思想理解清楚后，我们明白云原生核心是应用为云而生，为了达到这个目标需要实现应用设计开发的全生命周期管理。

要实现这个首先是静态的技术视角，其次是动态的过程视角。

     技术支撑视角也很明确，从应用开发全生命周期来看，包括了开发态，运行态和管控治理态。你会看到云原生的各个技术实践正好是为各个生命周期阶段服务的。类似微服务开发框架和环境是开发态能力，容器云资源池是运行态能力，而ServiceMesh服务网格，不可变基础设施则是管控治理和运维态能力。

    对于过程支撑也很明确，就是要实现应用开发全生命周期管理，这里既有需求驱动的需求端到端管理流程，也有技术驱动的CI/CD持续集成，持续部署，乃至持续交付和持续发布过程。而这块最核心的即是敏捷研发过程管理和DevOps过程支撑。

     所以你会看到所有的技术实践和过程管理实践都是为了实现云原生的核心目标服务，这些关键要素和原则不是孤立的，而是融合为一个整体，缺一不可。

云原生技术中台和子系统规划

     最后再对IT架构转型过程中，我们提供的平台化产品体系进行下梳理，重点还是要搞清楚里面会涉及到哪些子系统，以及这些子系统间关键的集成关系等。

敏捷研发管理子系统：这个基于scrum敏捷方法论来实现最基本的敏捷研发过程管理，核心对象为需求，产品，项目，版本，任务，团队，日志，缺陷，变更等，实现最基本的研发过程管理。

DevOps支撑平台：核心是实现持续集成和持续交付能力，同时在支撑平台中实现环境管理，配置管理，测试管理和自动化测试，流水线设计编排等关键能力。

容器化PaaS平台：单独拿出来形成一个子系统，核心是Docker+kubernates调度平台，实现容器化的中间件资源池，资源的动态分配和调度，中间件集群等。

监控运维平台：核心是实现中间件资源的监控，服务和服务链的监控，问题的发现和自动化运维流程。当然这里也很可能会拆分为两个独立的子系统，一个是监控系统，一个是运维系统。监控发现的问题会进入到运维系统，当然用户反馈的问题也可以进入到运维系统。

技术服务平台：核心的技术服务能力实现，包括了流程，缓存，消息，文件存储等。该技术服务平台是要企业大应用大PaaS的必须部分，但是在前期我们整体架构中可以不用太关心。

API服务网关：原来在微服务架构开发框架中本身就包含，我们现在将其提出来形成独立的API网关子系统，同时在网关子系统中整合服务注册中心，服务链监控，服务限流熔断等关键能力。

门户和4A平台：在构建要应用架构体系的时候是必须的，实现底层业务模块组件的整合，在我们整个大PaaS思路里面应该包括这个内容。

服务运营平台：在整个能力开放平台的架构中需要，即将API网关聚合后的API服务能力作为商品进行运营，涉及到服务的订购，消费，服务计费，服务接入流程等相关内容。

      实际上我们看到以上整体的平台架构规划和我们多年前的私有云PaaS平台架构规划相当类似，只是PaaS平台替换为了容器化的PaaS平台，ESB总线替换为了轻量的API网关，内部的PaaS门户替换为了服务运营服务平台。同时在整个研发生命周期中引入了DevOps支撑集成和持续交付方法论，引入了敏捷研发管理平台和工具。