作者：奥陌
11 月 5 日，在 2022 杭州 · 云栖大会上，云原生技术中台 CNStack2.0 正式发布。
阿里巴巴资深技术专家 谢吉宝介绍 CNStack2.0
企业在数字化转型的过程中，一部分问题得到了解决，但随着 IT 水平的不断提升，新问题也在逐渐显现。业务系统越加复杂，所需的计算、存储和网络设施也变得越来越难以管理。
以往一台虚拟机、一个数据库便能部署应用的时代已经一去不复返了。复杂的系统架构需要更多基础软件的支持才能良好运行，而开源社区的蓬勃发展，虽然为决策者提供了更多选择的可能性，但从选型开始问题就接踵而至。交付、运维、故障处理和选型后维护，所有这些都与业务价值无关，但又必不可少，基础软件出现问题对上层业务系统来说将是致命的，而这对于缺少丰富生产经验的运维人员来说，更是雪上加霜。
随着云原生技术的深入发展和行业解决方案的不断落地，企业越来越希望看到这样一种平台，依托云原生技术能力，不但可以支撑大规模业务系统的发布与运行，也可以将内部各种复杂、零散、不统一和不标准的软硬件体系给集中管理起来，以中台化的运作方式，向企业内部源源不断的输出经过实践检验的成熟技术能力与标准体系，推动企业数字化建设向着更高效的方向发展。在这样一个趋势背景下，云原生技术中台 CNStack 隆重发布了其具有革新意义的新一代 2.0 版本。
接下来我们将从几个企业数字化转型遇到的常见困难开始，向大家逐一介绍 CNStack 2.0 所具备的突破性能力，以及能给企业带来哪些核心价值。
异构资源管理困难
大部分企业已经从“建好云”的阶段过渡到了“用好云”，不管是共有云还是私有云，用云和上云的理念已经深入人心。但云平台的种类和数量都在不断增加，尤其是基础设施部分，这就如同 PC 时代的主机硬件，需要有更通用的操作系统加以屏蔽和提升，否则面对形形色色的 IaaS 基础设施，管理、运维和适配都将是重复且效率低下的工作。
跨云、混合云和分布式云早已从理论步入生产，对异构资源的管理能力也需要更上一层楼。在某些局点的实践中，我们发现客户现场有存在多家云厂商的平台，且都分布在不同机房中，单开通资源这一项操作，就需要经历繁琐的申请过程，更不必说对整个环境体系的维护了。
CNStack 2.0 面向基础设施提供了云原生化的管理手段，可以对不同厂商、不同架构（x86/ARM）、不同计算类型（CPU/GPU）和不同地域（公有云/本地云/边缘云）的资源进行管理。多集群纳管可以将分散的基础设施统一纳管到平台下，并能进行跨集群的资源分配、统一调度和集中运维，极大降低了异构基础设施的管理难度。
不仅如此，CNStack 在项目实践中可以管控上千节点或上万核规模的集群资源，特别适用于零售和互联网行业等对于大规模、高并发和低成本管控的要求。而且在超融合及混部等能力的加持下，系统资源利用率可以由通常水平的 6%~12%，提升到 45%。
系统软件选型与维护困难
一个平台如果只能解决资源问题，其实还无法为业务提供可用的环境，因为在资源之上还存在各种系统软件，对这些系统软件进行技术选型并解决选型后的持续维护问题，也是平台必须要解决的。
现如今，开源技术在软件领域有着举足轻重的地位，单 CNCF 下注册的项目就已经超过了 140 个，是否使用开源技术已经成为了评估软件标准化和开放性的必要条件之一。但问题是，这么多开源项目，该如何进行技术选型？哪些项目能满足需要？哪些版本能用于生产？哪些技术经历过大规模实战？这些都是技术选型需要考虑的问题。
与此同时，对技术选型的持续维护也同样重要。版本迭代、技术革新，每次都需要投入新的人力、物力和财力才能跟得上开源社区的快速发展，否则就会面临版本生命周期终结、功能落后和性能低下等问题，更有甚者会遗留严重的安全风险，这些都是数字化决策者所不得不考虑的问题。
CNStack 2.0 可以从两个方面来解决技术选型时遇到的问题。首先，平台提供了很多内置的、开箱即用的产品组件和中间件，正是这些内置组件所提供的能力才使我们所倡导的“让企业数字创新只需专注业务本身”变为可能。
这些内置组件从资源管理到应用管理，从服务管理到流量管理，从可观测到可运维，从平台稳定性到数字化安全生产……渗透到了平台和业务系统的方方面面。如果想要通过开源产品搭建具备同等能力的技术中台，其投入将是无比巨大的。
CNStack 背靠阿里云云原生团队，其所提供的中间件产品无论在功能、性能、规模还是可靠性方面都是有目共睹的，且经历过非常多的生产实践检验，能默默地为业务系统保驾护航。另外，在能力中心里，CNStack 还精选了各种原厂和伙伴提供的产品及组件，当内置功能不足以满足业务需要的时候可以在此进行无限扩展，并享受平台提供的一致化产品体验。
多环境交付困难
基于云原生技术的 PaaS 平台是近年来管理 IaaS 的首选方案。从开源到商业化，企业总能找到满足业务需要的解决方案，但也不是全然没有问题。
比如，既往的工作模式和管理规范都是建立在非云原生的基础设施之上，简言之，就是以物理机或虚拟机为单元进行资源管理的。那个时候环境的申请几乎等同于准备主机节点，但这并不意味着一个环境处于可用状态，最终使用者还需要在上面部署很多系统软件和基础组件，这些软件系统的重复部署，不仅浪费人力和时间，后续维护也是一笔持续的开销，更不利于环境的复用、开支的节省和标准的建立，整体成本非常之高。当开发和测试等工作涉及多个系统和集成商的时候，环境获取成本将成倍增长，甚至失控。
CNStack 2.0 的环境交付是基于容器来实现的。在系统建设之初，交付人员将基础设施资源整合成资源池（即容器集群），之后资源的申请便等同于在集群中划分配额。这些被分配的配额仅用于部署实际业务系统即可，系统软件的交付则是通过能力中心来完成。能力中心里分发的产品与组件是开箱即用的，平台管理员只需轻点鼠标即可实现全自动的安装与部署，交付即可用。能力中心分发的是组件能力，不再是资源本身，完全有可能在企业内部复用这些能力，并依此建立完善的基础软件使用标准。
在实践中，资源分配和能力供给是有严格权限隔离的，完全适用于多地域、多组织和多项目的企业级管理模式。环境搭建周期从月变为天或小时，而且使用能力中心交付的组件会天然具备平台级的运维能力，不但能够提升环境搭建的效率，长期运维的成本也会一降再降。
生产运维困难
环境交付和应用部署都是一次性投入，而环境自身和其上业务系统的运维却是需要持续投入的。对大多数的运维人员来说，由于缺乏大规模访问下的生产运维经验，在突发状况时想做到系统的平稳运行是非常困难的，这往往不仅需要难得的实践经验，更需要专业工具或产品能力的支持。
即便在正常情况下，想要确保系统稳定也是看似简单，实则困难的目标。倘若没有平台的支持，运维人员将无法预知问题的产生，产生问题时也无法做到及时止血或快速定位，最后迅速恢复和平稳升级才能让系统回归到往日的正常状态。所有这些远非“一个有经验的运维人员”所能轻易做到的。
但依托 CNStack 2.0 的产品能力，保障线上系统的稳定运行只需要一个普通运维人员即可，这全都依靠了平台提供的一站式应用管理能力。复杂的业务系统催生了应用形态的多样化，微服务应用、多语言应用、批处理或定时任务应用、AI 应用和大数据应用等，所有这些在完成上线之后都需要针对性的运维和管理能力。
CNStack 提供了完备的图形化运维控制台，不出平台即可完成 80% 的运维工作。同时，应用系统在发布态和运行态的稳定性也是由平台来自动保障的，运维人员仅需对规则进行配置，CNStack 的诸多特色能力，就可以让发布如丝般顺滑，让系统在突发状况时也能平稳度过并发出告警。
最后，在应用故障逃脱平台的管控能力之后，系统提供的各种辅助工具和产品能力，也可以帮助运维团队精准定位故障，快速恢复系统，为研发部门介入修复赢得宝贵时间。
总结
诚然，在云原生运动的驱使下，将会有越来越多的企业尝试拥抱这项技术，以新的理念、新的架构和新的能力为业务注入新的活力，在这期间既往的平台解决了一些问题，又产生了一些问题，在不断的更新迭代中，加速释放创新的力量。
CNStack 2.0 让企业以最低的成本和门槛享受来自技术革新的发展红利，而在遇到种种必然的困难阻碍时，也能提供强有力的支撑手段，终究能以更开放、更全面和更轻量的形态为客户打造更具竞争力的云原生技术中台产品，进而服务企业数字化转型步入下一个阶段。
标签：原生,CNStack,正式,运维,平台,能力,CNStack2.0,选型 From： https://www.cnblogs.com/alisystemsoftware/p/16915980.html