原生技术面临的安全问题， 其作为一种新兴的安全理念，强调以原生的思维实现云上安全并推动安全与云计 算深度融合。我们在 2022 年发布的中国联通云原生安全实践白皮书中[2]，对比 分析了不同的组织和企业对云原生安全理念的理解，其中包括 CNCF 认为云原 生安全是一种将安全构建到云原生应用程序中的方法[3]、k8s 提出的云原生 4C 安全模型[4]、腾讯所理解的云原生安全指云平台安全原生化和云安全产品原生化 需要采用持续安全集成和交付的实践，结合自动化的安全测试、漏洞扫描和合规 性检查等工具，以确保安全策略和控制的持续有效性。 面对这些新的挑战，国内外都开展了云原生安全技术的研究和相关标准规范 的制定完善工作，CNCF、CSA 等组织以及行业联盟等纷纷提出云原生安全标 准及参考技术规范。同时，主要经济体国家的标准也在制订和完善过程中，使得 行业逐步走向规范，推动了产品和解决方案逐步走向成熟。 在中国信息通信研究院、云安全联盟和相关企业的共同努力下，云原生的安 2 部分：业务应用 由中国信息通信研究院牵头编写，规定了基于云原生构建的业务应用的能力 成熟度评估模型，从服务架构、服务治理能力、弹性伸缩能力、业务高可用、 自动化与智能化、可观测性、开放性、组织架构以及安全性等方面对业务应 用进行评估。 云原生安全威胁分析与能力建设白皮书 16 5 云原生能力成 熟度模型 第 3 部分：架构安全 范围 由中国信息通信研究院牵头编写，规定了基于云原生构建的平台与应用的安

重新定义云原⽣开发环境 前⾔ 随着业务的快速发展，技术部⻔的组织架构在横向及纵向不断扩⼤和调整，与此同时，企业的⽣产资料：应 ⽤系统，也变得越来越庞⼤。为了让应⽤系统适配企业组织架构的调整，梳理组织架构对于应⽤权责的边 界，⼤部分组织会选择使⽤“微服务”架构来对应⽤系统进⾏横向拆分，使得应⽤系统的维护边界适配组织架 构的权责边界。 ⼀般来说，越庞⼤的组织架构，应⽤系统会被拆分地越来越细，“微服务”的数量也变得越来越多。⽽在“微服 变得越来越多。⽽在“微服 务”的拆分的实践中，很容易出现将组织架构的权责边界⼀股脑地对标到“微服务”�的拆分粒度中，这可能导致 “微服务”拆分粒度过细，数量进⼀步剧增的问题。最终，“微服务”之间的调⽤关系就像跨部⻔协作，也变得 越来越复杂，问题在想要新增需求时尤为突出。 “微服务”带来便利的同时，对开发⼈员⽽⾔，还带来了额外的挑战：如何快速启动完整的开发环境？开发的 需求依赖于其他同事怎么联调？如何快速调试这些微服务？ 在单体应⽤的时代，对于开发者来说是极为友好的，�开发者使⽤本机运⾏应⽤，修改代码后实时⽣效，通过 浏览器访问 Localhost 实时查看代码效果。 单体应⽤和“微服务”应⽤不同，单体应⽤是 “ALL-IN-ONE” 组织⽅式，所有的调⽤关系仅限于在⾃身的类和函 数，应⽤对硬件的要求⼀般也不会太⾼。 ⽽开发“微服务”应⽤则⼤不相同，由于相互间的依赖关系，当需要开发某⼀个功能或微服务时，不得不将所 有依赖的服务都启动起

提供者，通过双中台可 以将最上层业务产品诉求直接下沉到能力端，比如我们需要快速搭建一 个电商下单APP，只需要利用中台提供的能力要素，并在APP端组织业务 流程或者产品流程，下单后，商品自动送到用户手中，而无需企业打通 上下游业务链路，可以支撑快速的组织创新和业务创新。 高级能力-低代码或无代码平台 为了进一步加速业务APP交付速度，而专业业务人员并不熟悉IT领域知识，但是低代码可以使得非I 在精细化的基础上，完整较为成熟的自 动化能力，节约了人力成本同时提高了 效率，也极大得保证了业务连续性。 • 但是，目前真正落地的企业很少，原因 在于大部分企业组织或者文化问题在落 实上的顾虑，因为“机器人”比人是否可靠 仍然在争论中，可参考或者背书的实例 少，导致落地缓慢。 • 组织结构升级 • 企业IT文化、工作流程、知识体系、工具集的总合升级 • 应用架构升级 • re-platform • re-build • 2017-2019 核心系统全面云原生化 2020- 云原生技术全面升级 • 以业务场景为驱 动，以时代趋势 为助推，阿里超 前的实现云原生 的落地。 • 企业应该结合自 己的组织、业务、 市场特点来规划 实施云原生。 攘外必先安内 项目 说明 全托管K8S 全托管K8S服务带来了发布和扩容效率的提升、更稳定的容器运行时、节点自愈能力，结合发 布自动化、资源管理自动化等能力可以实现应用与基础设施层的全面解耦

在云原生场景下，希望应用能够适应敏态化 的业务场景，数据应用也不例外，目前都在 进行服务化改造和云原生改造 • 大数据引擎早就上云了(IaaS),但是并未云原 生化。 • 但是大数据引擎平台，架构思路过时、组件 众多、体系完整等，以及组织认知和能力、 在线业务的依赖等等，大量的历史包袱导致 大数据平台在云原生环境下落地艰难。那么 如何实现大数据云原生化呢？立足满足现在 和未来的企业需求进行渐进式改造推进是比 较合理的方式。(阿里巴巴甚至根据新时代的 慢应用的发布。 资源弹性扩容不及时 无法满足业务需要 资源使用率低 导致使用成本过高 操作系统和应用部署复杂 拖慢业务发布 云原生化可以解决上面的问题，演进的挑战有： 改造成本高 迁移风险高 组织架构造成额外的成本 主要体现在Yarn的复杂性 主要体现在领域专业性上 应用改造成本高：将运行在Hadoop平台的大数据应用迁移到云原生平台，一方面需要大数据团队将业务应用进行 容器化改造，如系 基础架构，改动面比较大，风险相 对也更高。 组织架构造成额外的成本：企业里负责开发和运维Hadoop系统的团队，和容器团队通常分属不同的部门，其技术 栈也有明显区别，在迁移的过程中，存在过多的跨部门沟通，带来额外的迁移成本，如果改动比较大，跨部分沟 通的成本会非常大。 高级能力-云原生大数据|AI-业务赋能的基石-3-解决办法 大数据本身架构和组织因素导致改造投入成本很高，云原生化应该遵循循循进进的渐进式演进道路，

而已，并不想了解API背后的运维细节或者需要协调运维能力！API成了一 种可以交易的商品，可以购买增强自己APP的能力，比如在自己APP里显示天气预报数据，从外部去管理应用平台，形成了一种新PaaS组织方式。 • 逻辑API：已有API的组 合，形成一个新API • 声明API：需要生成代 码框架（任何语言）， 契约驱动研发 • BaaS API:数据库接口、 中间件接口外化成API 云原生蓬勃而多样的生态成了这种Paas的基础。 • 编排不在以服务为单位，而是以应用为单位， 再也不会出现由于理解不一致导致的交付失败 的情况，而不论底层容器云实现如何，应用的 交付的方式都是一致的。 DevOps是一种文化，是一种组织赋能，在无所不在，OAM除了在交付过程中提供了基于应用的 交付方案，同时将CICD与底层实现解耦，可以插接无限制的工具组件，使得可以对应不同交付 场景所要求的不同工具链。比如叠加serverless 标准化能力-微服务PAAS-OAM交付流程模式-抽象流程 • 基于CICD和服务市场，通过OAM 集群镜像式打包的方式向团队、 组织或者公司进行整体化交付， 并通过Docker+SDN+云原生存储 +K8S+OAM彻底隔离了不同环境 底层的细节和差异，可以整体化 交付到这些组织所在的数据中心 里去 标准化能力-微服务PAAS-OAM交付流程模式-场景流程 • 由于互联网迭代相对于其 他企业业务更新迭代更加

在提供对云原生应用可见性方面 发挥着基础性作用，但只有三分之一的组织遵循 SBOM 最佳实践。 SBOM的应用现状 云原生基于“责任自负”的开源世界 云原生开源应用漏洞 OpenSCA扫描结果 h********r-main p********s-main c**********a-main 云原生时代下的软件供应链攻击 “到2025年，全球45%的组织会受到软件供应链攻击，比2021年增长三倍”——Gartner

- 资源清理与垃圾回收 - 构建高可用(HA)制品仓库服务 - Harbor集成与扩展 - 路线图 - 参与贡献Harbor社区 云原生与制品管理 [1] 云原生(cloud-native)技术使组织能够在现代化和动态的环境下（如公有云、私有云 和混合云）构建和运行可扩展的应用程序。云原生典型技术包括容器、服务网络、 微服务、不可变基础设施和声明性API等。 v1.0 by CNCF 容器-更轻量级和灵活的虚拟化

Mesh’s Control Plane • 通过将服务治理、通信、安全等从微服务框架中以独立进程剥离出来，解决了微服 务治理的碎片化以及基础设施耦合问题。 • 但是Sidecar（数据面）在国际化组织和企业联盟的努力下，也形成了叫做UDPA （Universal Data Plane API）的标准，使得在不同场景下的数据面在API层面达成统 一，比如云端Mesh和边缘Mesh由于API的统一，可以使用统一的控制面(配置下发管