云巧组件定义

云巧组件可以被定义为：预集成阿里云产品、按统一规范开发，包含独立而完整的业务逻辑的单元。

云巧组件构成

云巧组件由内部能力和外部集成两大分类构成。

内部能力

外部集成

为什么需要云巧标准

心理学里有一个术语：非我所创综合症，也称为NIH综合症（英语：Not Invented Here Syndrome），指的是人们只是由于某种产品、研究成果或知识来源于其他地方就抵制的心理。在软件开发领域，非我所创综合症表现为不信任别人的成果，而宁愿重复造轮子。（甚至你可能都不一定信任自己3个月前开发的代码LOL。）而重复造轮子最终会走向低效重复建设。

对于同一个小组内，还可以通过互相代码评审、结对编程等方式来增强信任感。而云巧资产市场上目前已有300多个技术资产，其中大部分来自其他团队，甚至来自于其他合作伙伴公司。要抵抗这种心理倾向，使用户能信任“非我所创”的组件，这就对组件提出了更高的要求。

云巧组件标准

云巧组件标准的理论支撑

对在2022年12大战略趋势中的组装式应用，Gartner将其具体落地拆解为4个维度：

• 编排
• 模块化
• 发现
• 自主性

• 模块化：模块化是可组装的关键。无论是规划应用、组织还是业务模型。组成整个系统的每个组件都必须是具有独立而完整业务逻辑的单元。业务单元的粒度十分重要，太大不足以提高开发过程的敏捷，太小又无法保证组件内业务的完整性。
• （可）发现：组件开发出来后，是否能让交付团队快速找到？组件的文档是否足够清晰和完整，能让交付团队准确评估适用性？可发现的高级要求包含了组件的运维特性，包括资源和性能等。
• 自治（自主性）：每个交付项目都有其特殊性，经常会根据客户要求或现实限制，只选配少部分组件，或将组件替换成其他外部系统。自治意味着组件能不强依赖其他组件独立运作，并在被替换时具有最小的改造负担。
• （可）编排：基础的可编排需要支持业界通用协议，不限于特定编程语言。可编排还体现在支持观测和跟踪、安全、支持DevOps等能力。

六大维度：ACCORD

可组装式应用的理论，结合了云原生的理念和交付质量要求，云巧对云巧组件设计了六大维度的标准。根据这六大维度名称的英文首字母组成单词ACCORD：

• Autonomous（自治）

• 关键字：封装
• 组件封装良好，最小化组件间的依赖，只暴露必要的公开接口和公共方法，隔离需求变更带来的影响。对应Gartner4个维度中的“自主性”。

• Cloud Native（云原生）

• 关键字：弹性、自动化
• 符合云原生最佳实践，支持容器化部署与弹性运维。参考The Twelve-Factor App。

• Cataloged（可发现）

• 关键字：易用
• 具有良好自我描述能力，易于在一个统一的市场里被找到和评估适用性。对应Gartner4个维度中的“发现”。

• Orchestrated（可编排）：

• 关键字：被集成
• 可以被放心地集成，可观测，设计风格统一。对应Gartner4个维度中的“编排”。

• Robust（健壮）

• 关键字：安全、质量
• 质量保障，符合安全标准，易维护，易扩展。

• Domain Driven（领域驱动）

• 关键字：边界
• 领域驱动设计，具备明确的业务价值与清晰的边界划分。对应Gartner4个维度中的“模块化”。

通过ACCORD云巧组件标准对沉淀的云巧组件加以持续的约束，可以保证组件在更大范围内的互通与互信。符合标准的组件也能以统一的体验去被复用、集成、部署。

云巧组件的红线：合规

违反合规要求会对阿里和生态合作伙伴公司带来严重的法务风险，造成不可控的经济和声誉损失。所以保证组件的合规是红线要求。
合规主要包含以下三个方面：

• 知识产权合规：阿里自有知识产权的组件由阿里侧负责合规材料，ISV自有知识产权的组件需由ISV提供软著（计算机软件著作权证明材料）
• 源代码及数据合规：源代码及演示环境数据不包含敏感信息（客户/其他交付项目信息等）
• 内容合规：文档不包含敏感信息（客户/其他交付项目信息等）

云巧标准的度量

为什么需要对标准进行度量

光靠云巧资产市场的开发人力，必然无法对每个组件的每个版本更新进行代码评审。但是否我们就此束手无策了？一切业务数字化，我们可以：

• 制定组件标准
• 将标准自动化度量
• 度量结果实时生成综合了多个维度的度量指标

通过指标，一方面可以将组件的信息对适使用方透明化，增强信任感；另一方面也为组件owner明确组件优化方向。

云巧成熟度指标

通过对云巧组件各维度的实现程度加权评分，可以度量出其所处的成熟度，以“云巧成熟度指标”的形式展现在资产市场上。

对于支持自动检查的检查项，会进行自动打分；对于目前尚不支持自动检查的检查项，会在组件首次上传和后续每次大版本更新时，由云巧资产市场的平台管理员评分。

对于组件开发者，可以将成熟度指标作为进一步打磨和优化组件的方向参考；

对于组件使用者，可以将成熟度指标作为选择组件的参考依据。

自治的度量

云原生的度量

可发现的度量

可编排的度量

健壮的度量

模块化的度量

云巧标准的分档

标准的每个规则有一个重要等级。总共分为4个档位：BLOCKER、CRITICAL、MAJOR、MINOR：

• BLOCKER的为红线，代码存在敏感信息，严重的安全漏洞等。如果存在，不允许发布。
• CRITICAL为较严重的质量或安全问题。如果存在，需要人工审核才能发布。
• MAJOR为影响效率和质量的问题。建议重构，不影响发布。
• MINOR为需优化的问题，可能会影响到易用性和可维护性。建议重构，不影响发布。

举例来说，“健壮”维度中的“知识产权合规”的重要等级就是BLOCKER级别的，必须完成修改才能上架。

我们在云巧资产市场和云巧工坊已经实现了上述部分标准的度量。后续也会不断进一步丰富可度量的标准。

即使所有的严重的问题都修复了，成熟度还是能够指导持续改进，精益求精。没有严重问题的是合格，而合格更上一层的标准就是云巧认证。

云巧认证

在每个时间周期（暂定自然季度）结束时，由阿里侧技术和业务专家组成的云巧评审委员会，对云巧资产市场上的所有组件进行全方位的评分。对于满足一定阈值的云巧成熟度指标得分的组件，综合评估组件业务价值后，授予“云巧认证”。云巧认证是云巧评审委员会对组件可信任度的最高评价。

云巧评审委员会承诺：

• 公正品宣：基于统一的云巧成熟度指标为入围标准，不会对阿里或其他ISV设定双重标准
• 专业权威：评审委员会由不同领域的专家组成，保证评审结果的权威性

云巧标准的实践

新开发应用如何遵循标准

新开发的应用可以借云巧工坊的标准流程，打造符合标准的云巧组件。

更多参见云巧工坊简介。

已交付项目代码如何按照标准沉淀组件/交付模板

对于已交付项目的代码，通常执行步骤如下：

1. 划分通用技术部分和业务部分：通用技术部分可直接复用云巧基础技术平台交付模板，只需要针对业务部分评估是否沉淀
2. 将业务部分的应用沉淀到云巧工坊
3. 合规改造
4. 通过领域驱动设计，划分业务边界
5. 定义需要组件需要对外暴露的API
6. 进行代码静态扫描、敏感信息扫描、安全扫描，修复扫描出的高危漏洞
7. 补完单元测试用例
8. 云原生改造
9. 按结构化文档标准补完文档