Professional Documents
Culture Documents
云巧组件定义
云巧组件可以被定义为:预集成阿里云产品、按统一规范开发,包含独立而完整的业务逻辑的技术单元模块。
云巧组件构成
云巧组件的内容构成由内部能力和外部集成两大分类构成。
内部能力
软件架构信息 内部服务调用关系、领域模型设计(DDD)
软件版本信息 代码仓库与镜像仓库地址、打包代码版本和镜像版本
文档 功能介绍、适用场景等
质量 质量检测结果,包括:静态扫描/安全扫描结果、单元测试通过率和覆盖率、
测试用例执行率、自动化测试覆盖情况等
数据 数据库表结构(DDL)、种子数据(Seed Data)
元数据 资源定义、配置定义、流程数据、表单数据
外部集成
外部资源依赖 阿里云产品集成、外部接口/消息依赖
接口 对外API列表。自动发现并注册到云巧资产市场
消息 对外输出消息定义
数据交换 与外部数据源的数据交换
用户界面 页面名及URI清单,用于微前端页面装配
为什么需要云巧标准
心理学里有一个术语:非我所创综合症,也称为NIH综合症(英语:Not Invented Here Syndrome),指的是人
们只是由于某种产品、研究成果或知识来源于其他地方就抵制的心理。在软件开发领域,非我所创综合症表现为
不信任别人的成果,而宁愿重复造轮子。(甚至你可能都不一定信任自己3个月前开发的代码LOL。)而重复造
轮子最终会走向低效重复建设。
对于同一个小组内,还可以通过互相代码评审、结对编程等方式来增强信任感。而云巧资产市场上目前已有500
多个技术资产,其中大部分来自其他团队,甚至来自于其他公司。要抵抗这种心理倾向,使用户能信任“非我所
创”的组件,这就对组件提出了更高的要求。
云巧组件标准
云巧组件标准的理论支撑
对在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明确组件优化方
向。
云巧成熟度指标
通过对云巧组件各维度的实现程度加权评分,可以度量出其所处的成熟度,以“云巧成熟度指标”的形式展现在资
产市场上。
对于支持自动检查的检查项,会进行自动打分;对于目前尚不支持自动检查的检查项,会在组件首次上传和后续
每次大版本更新时,由云巧资产市场的平台管理员评分。
对于组件开发者,可以将成熟度指标作为进一步打磨和优化组件的方向参考;
对于组件使用者,可以将成熟度指标作为选择组件的参考依据。
自治的度量
维度 目标 说明
自治 接口定义清晰
只暴露必要的公开接口和公共方法 不直接对外暴露领域层或数据模型层
组件间不共用数据库
环境变量预定义
数据自包含 将数据和元数据(流程和表单定义)封装在组件内
部。
推荐使用数据库管理工具
无第三方服务依赖 对依赖的外部第三方服务已mock。
云原生的度量
维度 目标 说明
应用启动时间短
支持健康检查机制
可发现的度量
维度 目标 说明
关键可发现信息 组件文档中“组件SOW”、“依赖云资源”、“API/SDK文
档”部分不为空
明确业务价值 组件文档中“业务价值”部分不为空
明确架构 组件文档中“架构图”部分不为空
明确性能设计 组件文档中“性能设计”部分不为空
明确测试报告 组件文档中“测试报告”部分不为空
可编排的度量
维度 目标 说明
可编排 接口定义使用版本隔离机制
支持常见协议 如RESTFUL、RPC、消息等
接口支持向后兼容
前端性能在阈值范围 避免前端响应时间超长
接口幂等 支持重试机制,做幂等控制
遵循统一设计风格 推荐使用B-Design设计
可观测 支持调用链跟踪、日志信息规范
支持微前端
健壮的度量
维度 目标 说明
健壮 知识产权合规 对ISV自有知识产权组件已提供软著
源代码、内容及数据抽象 源代码、文档及演示环境数据不包含未抽象脱敏的信息
(包括但不限于客户/其他交付项目信息等)
无敏感信息 源代码、文档及演示环境数据不包含敏感信息(密码、
AKSK等)
敏感信息加密存储
通过静态代码扫描 不存在高危级别的静态代码扫描问题
中危静态代码扫描问题密度可控
通过安全扫描 不存在高危级别的安全扫描问题
中危安全扫描问题密度可控
通过敏感信息扫描 不存在高危级别的敏感信息扫描问题
中危敏感信息扫描问题密度可控
单元测试覆盖 达成可满足质量保障要求的单元测试覆盖率和通过率
冗余代码少 重复冗余代码密度低
易于维护 高圈复杂度密度低
代码坏味道少
模块化的度量
维度 目标 说明
模块化 领域驱动设计
按照DDD(Domain-driven design,领域驱动设计)的
理念维护了该组件的领域模型。
应用领域驱动设计实体、值对象设计了界限上下文和领域
蓝图等。
无循环依赖 组件间不存在循环依赖
领域模型维护质量 不存在独立的领域模型层。
领域模型在代码中可见
云巧标准的分档
标准的每个规则有一个重要等级。总共分为4个档位:BLOCKER、CRITICAL、MAJOR、MINOR:
BLOCKER的为红线,代码存在敏感信息,严重的安全漏洞等。如果存在,不允许发布。
CRITICAL为较严重的质量或安全问题。如果存在,需要人工审核才能发布。
MAJOR为影响效率和质量的问题。建议重构,不影响发布。
MINOR为需优化的问题,可能会影响到易用性和可维护性。建议重构,不影响发布。
举例来说,“健壮”维度中的“知识产权合规”的重要等级就是BLOCKER级别的,必须完成修改才能上架。
我们在云巧资产市场和云巧工坊已经实现了上述部分标准的度量。后续也会不断进一步丰富可度量的标准。
即使所有的严重的问题都修复了,成熟度还是能够指导持续改进,精益求精。没有严重问题的是合格,而合格更
上一层的标准就是云巧认证。
云巧认证
在每个时间周期(暂定自然季度)结束时,由阿里侧技术和业务专家组成的云巧评审委员会,对云巧资产市场上
的所有组件进行全方位的评分。对于满足一定阈值的云巧成熟度指标得分的组件,综合评估组件业务价值后,授
予“云巧认证”。云巧认证是云巧评审委员会对组件可信任度的最高评价。
云巧评审委员会承诺:
公正品宣:基于统一的云巧成熟度指标为入围标准,不会对阿里或其他ISV设定双重标准
专业权威:评审委员会由不同领域的专家组成,保证评审结果的权威性
云巧标准的实践
新开发应用如何遵循标准
新开发的应用可以借云巧工坊的标准流程,打造符合标准的云巧组件。
更多参见云巧工坊简介。
已交付项目代码如何按照标准沉淀组件/交付模板
对于已交付项目的代码,通常执行步骤如下:
1. 划分通用技术部分和业务部分:通用技术部分可直接复用云巧基础技术平台交付模板,只需要针对业务部分评
估是否沉淀
2. 将业务部分的应用沉淀到云巧工坊
3. 合规改造
4. 通过领域驱动设计,划分业务边界
5. 定义需要组件需要对外暴露的API
6. 进行代码静态扫描、敏感信息扫描、安全扫描,修复扫描出的高危漏洞
7. 补完单元测试用例
8. 云原生改造
9.
9. 按结构化文档标准补完文档