CNStack 2.0：云原生的技术中台

在进入千禧年后，随着计算机技术的发展和业务创新的不断涌现，许多大公司内的 IT 计算中心也在酝酿着变革。一方面，各部门相对独立的 IT 管理平台已经难以满足日益增长和不断变化的计算管理需求；另一方面，IT 计算中心也越来越多的成为业务创新的发源地，从一个成本中心向营收来源发展。相应的，一种围绕着资源和负载管理平台的技术领域逐渐称为学术界和产业界的热点。它在不同的发展阶段和不同的应用场景有着不同的名字，从最早的集群（Cluster），网格（Grid），到后来的数据中心操作系统（DCOS），云计算（Cloud Computing）。同时，在资源管理和负载管理这两大方面也不断的拓展着自身的边界。

目前，以 Kubernetes 为核心代表的云原生技术逐渐称为这一领域的主流。它所带来的不可变基础设施，以资源为管理对象，描述性的 API，最终一致性等等理念，不仅改变了平台使用者的习惯，能够更好的在资源弹性变化的环境中保持业务访问的连续性；更改变了服务和应用研发人员的思维模式，逐渐以这种云原生的方式来设计和开发，提高创新效率。

阿里云有“公共云”、“专有云”两种产品形态，使用同样基于飞天操作系统的技术路线，为用户提供从服务器开始一整套资源和负载的管理能力，以及运行在上面的各种服务。与此同时，也有很多客户由于种种原因无法完全使用公有云服务，也无法采购和部署一整套大专。在基于云原生的产品领域中，这些客户或者接触了 Kubernetes 等开源项目，或者试用过红帽，Rancher 等厂商提供的 Openshift，Rancher 等平台产品，甚至体验了围绕这些产品构成的整个产品家族生态，如 IBM Cloud Pak 等。他们惊喜与这些云原生技术带来的敏捷，开放，韧性等特点。同时，也希望在此基础上获得支持不同业务场景的丰富服务，以便快速提升创新能力。

应对这种需求，云原生 PaaS 团队经过长时间的技术和经验积累，历时近半年的研发，创建了 CNStack 2.0 云原生技术中台产品。在接下来的内容里，将分享在 CNStack 2.0产品，架构，研发中主要的设计思想和心得体会。

产品目标

阿里云使用云原生技术在资源和负载管理这一领域的探索已经有一段历史了。在长期与解决方案团队，产品团队，外部客户的沟通合作中，发现使用者对云原生技术带来的以下特点最为关注。

敏捷

敏捷并不简单的等同于轻量，它更多的代表灵活性和因此而带来的效率的提升。

用户希望平台和服务能够随着不同的应用场景和规模，提供不同的部署配置选项。既能够管理三五台服务器，提供一两种服务或者公共负载类型，也能够管理百台服务器，满足几个业务团队的不同诉求，甚至管理数千上万台服务器，跨越多个地域，支持不同行业线的复杂服务。

针对这些场景和规模的差异，用户需要的只是做好资源规划，在部署平台和服务时，选择不同的配置选项。无论场景和规模的差异，平台都会提供一致的使用体验。同时，所需的管理资源开销最好能够随着规模的增大和功能的增加，对数或者线性级别的增长。此外，用户也可以很方便的获取产品，不需要复杂的硬件资源就可以部署和试用，例如公有云申请的服务器上，甚至是自己的笔记本电脑上。

敏捷还体现在产品功能的组合和升级，可以根据需要，增加和减少功能和服务，以响应不断变化的创新诉求。

开放

用户希望能保护已有的技术投资，也希望能方便，快速的补充开源社区或者其他厂商的技术创新。这就需要产品具备开放的特点。这里的开放主要是指采用具有开源社区生命力的技术框架和标准的协议规范，产品自身也拥有丰富的扩展机制。

一个开放的产品，可以让用户

• 方便的获取技术资料和试用环境，降低学习门槛
• 通过标准的协议规范和扩展机制，集成其他厂商的产品或者被其他厂商产品集成，保护技术投资
• 支持更多的基础设施类型和工作负载类型
• 与开源社区一起不断发展，保持技术先进性

生态

技术中台作为业务创新的核心，需要支持多种业务类型，涵盖业务创新的生命周期。从微服务框架，中间件，到 AI，数据处理；从研发设计，制品管理，到应用发布，容灾高可用；从本地数据中心，到边缘，公有云。

为了支持如此丰富的能力，需要围绕技术中台构建产品生态，创建云服务，云组件的标准规范和支持标准规范的工具链。

• 云服务：通过服务的形式在平台提供能力扩展，可以使用平台提供的用户，租户，鉴权，审计，许可证，多集群部署，UI 框架等基础能力，与平台既有能力或其他服务无缝的协作。和整个平台的运维一样，云服务的生命周期管理由管理员负责。
• 云组件：通过部署声明的方式为平台用户提供软件的部署和运维，所部署的软件可以和用户自研软件一起编排实现业务流程。和用户自研软件一样，云组件的生命周期管理由具体的使用者负责。

上述是 CNStack 2.0 当前所支持的云服务一览。这些云服务与平台自身的发布完全解耦，阿里云研发团队或者合作伙伴可以方便的针对业务场景扩展技术中台能力，独立发布云服务。需要重点强调的是，CNStack 平台自身也是以云服务方式开发，运维，管理的。

CNStack 2.0 为云服务和云组件的集成，测试和发布提供了一整套规范的工具链，它就是阿里云云原生应用交付平台（Application Delivery Platform，简称 ADP）[1]。CNStack 2.0 自身也是使用 ADP 开发和发布的。

在 ADP 平台上，开发者可以将构成云服务的组件以 helm charts 的形式上传。平台根据研发规范扫描检查后，以自有组件的形式进行版本管理。此后，开发者可以把这些自有组件和 ADP 平台上提供的公共研发中间件，如数据库，消息，微服务框架等一起编排为云服务，并在指定的公有云环境创建验证环境，部署 CNStack 2.0（也被称为底座）一起完成功能测试和一系列验证，如高可用等，最终打包为云服务（或者云组件）。云服务（云组件）的发布包规范遵循云原生 PaaS 团队贡献给社区的 CNCF Sealer 开源项目。交付时，在用户环境部署的 CNStack 2.0 平台上，管理员将云服务（云组件）发布包导入能力中心。在能力中心，管理员可以完成云服务的部署，升级，变配等一系列生命周期管理。