2026年2月2日--移除与添加多agent相关的约束
This commit is contained in:
YanhaoLuo
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,347 @@
|
||||
---
|
||||
name: java-design-standards
|
||||
description: 阿里巴巴Java开发手册设计规约。Use when designing software architecture, applying design patterns, or making design decisions in Java projects.
|
||||
---
|
||||
|
||||
# 设计规约
|
||||
## 七、设计规约
|
||||
1.【强制】 存储方案 和底层数据结构 的设计获得评审一致通过 ，并沉淀成为文档 。
|
||||
说明 ：有缺陷的底层数据结构容易导致系统风险上升 ，可扩展性下降 ，重构成本也会因历史数据迁移和系统平滑过渡而
|
||||
陡然增加 ，所以 ，存储方案和数据结构需要认真地进行设计和评审 ，生产环境提交执行后 ，需要进行 double check 。
|
||||
正例 ：评审内容包括存储介质选型 、表结构设计能否满足技术方案 、存取性能和存储空间能否满足业务发展 、表或字段
|
||||
之间的辩证关系 、字段名称 、字段类型 、索引等；数据结构变更（如在原有表中新增字段）也需要 在评审通过后上线 。
|
||||
2.【强制】 在需求分析阶段 ，如果与系统交互的 User 超过 一类 并且相关的 UseC ase 超过5个，使用用例图
|
||||
来表达更加清晰的结构化需求 。
|
||||
3.【强制】 如果某个业务对象的状态超过 3个，使用状态图来表达并且明确状态变化的各个触发 条件 。
|
||||
说明 ：状态图的核心是对象状态 ，首先明确对象有多少种状态 ，然后明确两两状态之间是否存在直接转换关系 ，再明确
|
||||
触发状态转换的条件是什么 。
|
||||
正例 ：淘宝订单状态有已下单 、待付款 、已付款 、待发货 、已发货 、已收货等。比如已下单与已收货这两种状态之间是
|
||||
不可能有直接转换关系的 。
|
||||
4.【强制】 如果系统中某个功能的调用链路上的涉及对象超过 3个，使用时序 图来表达并且明确各调用环
|
||||
节的输入与输出 。
|
||||
说明 ：时序图反映了一系列对象间的交互与协作关系 ，清晰立体地反映系统的调用纵深链路 。
|
||||
5.【强制】 如果系统中模型类超过 5个，且存在 复杂的依赖关系 ，使用类图来表达并且明确类之间的关系 。
|
||||
说明 ：类图像建筑领域的施工图 ，如果搭平房 ，可能不需要 ，但如果建造蚂蚁 Z空间大楼 ，肯定需要详细的施工图 。
|
||||
6.【强制】 如果系统中超过 2个对象之间存在协作关系 ，并需要表示复杂的处理流程 ，使用活动图来表示 。
|
||||
说明 ：活动图是流程图的扩展 ，增加了能够体现协作关系的对象泳道 ，支持表示并发等 。
|
||||
7.【强制】 系统设计时要准确识别出弱依赖 ，并针对性地设计降级和应急预案 ，保证核心系统正常可用。
|
||||
说明 ：系统依赖的第三方服务被降级或屏蔽后 ，依然不会影响主干流程继续进行 ，仅影响信息展示 、或消息通知等非关
|
||||
键功能 ，那么这些服务称为弱依赖。
|
||||
正例 ：当系统弱依赖于多个外部服务时 ，如果下游服务耗时过长 ，则会严重影响当前调用者 ，必须采取相应降级措施 ，
|
||||
比如 ，当调用链路中某个下游服务调用的平均响应时间或错误率超过阈值时 ，系统自动进行降级或熔断操作 ，屏蔽弱依
|
||||
赖负面影响 ，保护当前系统主干功能可用。
|
||||
反例 ：某个疫情相关的二维码 出错 ：“服务器开了点小差 ，请稍后重试 ”，不可用时长持续 很久 ，引起社会高度关注 ，
|
||||
原因可能为 调用 的外部依赖服务 RT过高而导致系统假死 ，而在显示端没有做降级预案 ，只能直接抛错给用户 。
|
||||
8.【推荐】 系统架构设计时明确以下目 标：
|
||||
⚫ 确定系统边界 。确定系统在技术层面上的做与不做 。
|
||||
⚫ 确定系统内模块之间的关系 。确定模块之间的依赖关系及模块的宏观输入与输出 。
|
||||
⚫ 确定指导后续设计与演化的原则 。使后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化 。
|
||||
⚫ 确定非功能性需求 。非功能性需求是指安全性 、可用性 、可扩展性等 。
|
||||
9.【推荐】 需求分析与系统设计在考虑主干功能的同时 ，需要充分评估异常流程与业务边界 。
|
||||
10.【推荐】 类在设计 与实现时要符合单一原则 。
|
||||
说明 ：单一原则最易理解却是最难实现的一条规则 ，随着系统演进 ，很多时候 ，忘记了类设计的初衷 。
|
||||
11.【推荐】 谨慎使用继承的方式来进行扩展 ，优先使用聚合 /组合的方式来实现 。
|
||||
说明 ：不得已使用继承的话 ，必须符合里氏代换原则 ，此原则说父类能够出现的地方子类一定能够出现 ，比如 ，“把
|
||||
钱交出来 ”，钱的子类美元 、欧元 、人民币等都可以出现 。
|
||||
12.【推荐】 系统设计阶段 ，根据依赖倒置原则 ，尽量依赖抽象类与接口 ，有利于扩展与维护 。
|
||||
说明 ：低层次模块依赖于高层次模块的抽象 ，方便系统间的解耦 。
|
||||
|
||||
13.【推荐】 系统设计阶段 ，注意对扩展开放 ，对修改闭合 。
|
||||
说明 ：极端情况下 ，交付的代码是不可修改的 ，同一业务域内的需求变化 ，通过模块或类的扩展来实现 。
|
||||
14.【推荐】 系统设计阶段，共性业务或公共行为抽取出来公共模块 、公共配置 、公共类 、公共方法等，在
|
||||
系统中不出现重复代码的情况，即 DRY 原则（ Don't Repeat Yourself ）。
|
||||
说明 ：随着代码的重复次数不断增加 ，维护成本指数级上升 。随意复制和粘贴代码 ，必然会导致代码的重复 ，在维护代
|
||||
码时 ，需要修改所有的副本 ，容易遗漏 。必要时抽取共性方法 ，或者抽象公共类 ，甚至是组件化 。
|
||||
正例 ：一个类中有多个 public 方法 ，都需要进行数行相同的参数校验操作 ，这个时候请抽取 ：
|
||||
private boolean checkPa ram(DTO dto) {...}
|
||||
15.【推荐】 避免如下误解 ：敏捷开发 =讲故事 +编码+发布 。
|
||||
说明 ：敏捷开发是快速交付迭代可用的系统 ，省略多余的设计方案 ，摒弃传统的审批流程 ，但核心关键点上的必要设计
|
||||
和文档沉淀是需要的 。
|
||||
反例 ：某团队为了业务快速发展，敏捷成了产品经理催进度的借口，系统中均是勉强能运行但像面条一样的代码 ，可
|
||||
维护性和可扩展性极差 ，一年之后 ，不得不进行大规模重构 ，得不偿失 。
|
||||
16.【参考】 设计文档的作用是明确需求 、理顺逻辑 、后期维护 ，次要目的用于指导编码 。
|
||||
说明 ：避免为了设计而设计 ，系统设计文档有助于后期的系统维护和重构 ，所以设计结果需要进行分类归档保存 。
|
||||
17.【参考】 可扩展性的本质是找到系统的变化点 ，并隔离变化点 。
|
||||
说明 ：世间众多设计模式其实就是一种设计模式即隔离变化点的模式 。
|
||||
正例 ：极致扩展性的标志 ，就是需求的新增 ，不会在原有代码交付物上进行任何形式的修改 。
|
||||
18.【参考】 设计的本质就是识别和表达系统难点 。
|
||||
说明 ：识别和表达完全是两回事，很多人错误地认为识别到系统难点在哪里，表达只是自然而然的事情，但是大家在
|
||||
设计评审中经常出现语焉不详，甚至是词不达意的情况。准确地表达系统难点需要具备如下能力：表达规则和表达工
|
||||
具的熟练性 。抽象思维和总结能力的局限性。基础知识体系的完备性。深入浅出的生动表达力 。
|
||||
19.【参考】 代码即文档的观点是错误的 ，清晰的代码只是文档的 某个片断 ，而不是全部 。
|
||||
说明 ：代码的深度调用 ，模块层面上的依赖关系网 ，业务场景逻辑，非功能性需求等问题要相应的文档来完整地呈现 。
|
||||
20.【参考】 在做无障碍产品设计时 ，需要考虑 到：
|
||||
⚫ 所有可交互的控件元素必须能被 tab键聚焦 ，并且焦点顺序需符合自然操作逻辑 。
|
||||
⚫ 用于登录校验和请求拦截的验证码均需提供图形验证以外的其它方式 。
|
||||
⚫ 自定义的控件类型需明确交互方式 。
|
||||
正例 ：登录场景中 ，输入框的按钮都需要考虑 tab 键聚焦 ，符合自然逻辑的操作顺序如下 ，"输入用户名 ，输入密码 ，输
|
||||
入验证码，点击登录 "，其中验证码实现语音验证方式。 如有自定义标签实现的控件设置控件类型可使用 role 属性 。
|
||||
|
||||
附1：版本历史
|
||||
版本 号 版本 名 发布日 期 备注
|
||||
-- -- 2016.12.07 试读版 本首次对外发布
|
||||
1.0.0 正式 版 2017.02.09 阿里巴巴集团正式对外发 布
|
||||
1.0.1 -- 2017.02.13 1）修正 String[] 的前后矛盾
|
||||
2）vm 修正成 velocity
|
||||
3）修正 countdown 描述错误
|
||||
1.0.2 -- 2017.02.20 1）去除文底水印
|
||||
2）数据类型中引用太阳系年龄问题
|
||||
3）修正关于异常和方法签名的部分描述
|
||||
4）修正 final 描述
|
||||
5）去除 Comparator 部分描述
|
||||
1.1.0 -- 2017.02.27 1）增加前言
|
||||
2）增加<? extends T> 描述和说明
|
||||
3）增加版本历史
|
||||
4）增加专有名词解释
|
||||
1.1.1 -- 2017.03.31 修正页码总数和部分示例
|
||||
1.2.0 完美版 2017.05.20 1）根据云栖社区的 “聚能聊 ”活动反馈 ，对手册的页码 、排版 、描述进行修正
|
||||
2）增加 final 的适用场景描述
|
||||
3）增加关于锁的粒度的说明
|
||||
4）增加 “指定集合大小 ”的详细说明以及正反例
|
||||
5）增加卫语句的示例代码
|
||||
6）明确数据库表示删除概念的字段名为 is_deleted
|
||||
1.3.0 终极 版 2017.09.25 增加单元测试规约 ，阿里开源的 IDE 代码规约检测插件 ：点此下载
|
||||
1.3.1 纪念版 2017.11.30 修正部分描述 ；采用和 P3C 开源 IDE 检测插件相同的 Apache2.0 协议
|
||||
1.4.0 详尽 版 2018.05.20 增加设计规约大类 ，共16条
|
||||
1.5.0 华山版 2019.06.19 1）鉴于手册是 Java 社区开发者集体智慧的结晶 ，移除 《阿里巴巴 Java 开发手册 》
|
||||
的限定词 “阿里巴巴 ”
|
||||
2）新增 21 条新规约 。比如 ，switch 的NPE 问题 、浮点数的比较 、无泛型限制 、锁
|
||||
的使用方式 、判断表达式 、日期格式等
|
||||
3）修改描述 112 处。比如 ，IFNULL 的判断 、集合的 toArray 、日志处理等
|
||||
4）完善若干处示例 。比如 ，卫语句示例 、enum 示例 、finally 的return 示例等
|
||||
1.6.0 泰山版 2020.04.22 1）发布错误码统一解决方案 ，详细参考 附表 3。
|
||||
2）修改描述 90 处。比如，阻塞等待锁 、建表的小数类型等。
|
||||
3）完善若干处示例 。比如， ISNULL 的示例等。
|
||||
4）新增 34条新规约 。比如 ，日期时间的闰年 、闰月问题 ，三目运算的自动拆箱 ，
|
||||
SQL 查询的表别名限定 ，Collectors 类的 toMap() 方法使用注意等 。
|
||||
|
||||
1.7.0 嵩山版 2020.08.03 1）新增前后端规约 14条。
|
||||
2）新增禁止任何歧视性用语的约定。
|
||||
3）新增涉及敏感操作的情况下日志需要保存六个月的约定 。
|
||||
4）修正 BigDecimal 类中关于 compareTo 和equals 的等值比较 。
|
||||
5）修正 HashMap 关于 1024 个元素扩容的次数 。
|
||||
6）修正架构分层规范与相关说明 。
|
||||
7）修正泰山版中部分格式错误和描述错误 。
|
||||
1.7.1 黄山 版 2022.02.03 1）新增 11条新规约。比如， 浮点数的后缀统一为大写 ；枚举的属性字段必须是私
|
||||
有且不可变 ；配置文件中的密码需要加密等。
|
||||
2）新增描述中的正反例 2条。比如， 多个构造方法 次序 、NoSuchMethodError 处
|
||||
理； 新增 扩展 说明 5条。比如， 父集合元素 的增加或删除 异常 等。
|
||||
3）修改描述 22 处。比如， 魔法值 的示例 代码 、ScheduledThreadPool 问题 等。
|
||||
4）修正 嵩山 版中部分 代码 格式错误和描述错误。
|
||||
|
||||
附2：专有名词解释
|
||||
1. POJO （Plain Ordinary Java Object ）：在本规约中 ，POJO 专指只有 setter / getter / toString 的简单类 ，包括
|
||||
DO / DTO / BO / VO 等。
|
||||
2. DO（Data Object ）： 阿里巴巴专指数据库表一 一对应的 POJO 类。 此对象与数据库表结构 一 一对应 ，通过 DAO 层
|
||||
向上传输数据源对象 。
|
||||
3. PO（Persistent Object ）： 也指数据库表一 一对应的 POJO 类。 此对象与数据库表结构一 一对应 ，通过 DAO 层向上
|
||||
传输数据源对象 。
|
||||
4. DTO （Data Transfer Object ）：数据传输对象 ，Service 或Manager 向外传输的对象 。
|
||||
5. BO（Business Object ）：业务对象 ，可以由 Service 层输出的封装业务逻辑的对象 。
|
||||
6. Query ：数据查询对象 ，各层接收上层的查询请求 。注意超过 2个参数的查询封装 ，禁止使用 Map 类来传输 。
|
||||
7. VO（View Object ）： 显示层对象 ，通常是 Web 向模板渲染引擎层传输的对象 。
|
||||
8. CAS （Compare And Swap ） ：解决多线程并行情况下使用锁造成性能损耗的一种机制，这是硬件实现的原子操作 。
|
||||
CAS 操作包含三个操作数 ：内存位置 、预期原值和新值 。如果内存位置的值与预期原值相匹配 ，那么处理器会自动将该
|
||||
位置值更新为新值 。否则 ，处理器不做任何操作 。
|
||||
9. GAV （GroupId 、ArtifactId 、Version ）：Maven 坐标，是用来唯一标识 jar包。
|
||||
10. OOP （Object Oriented Programming ）：本文泛指类 、对象的编程处理方式。
|
||||
11. AQS （AbstractQueuedSynchronizer ）：利用先进先出队列实现的底层同步工具类，它是很多上层同步实现类的基
|
||||
础，比如 ： ReentrantLock 、CountDownLatch 、 Semaphore 等，它们通过继承 AQS 实现其模版方法 ，然后将 AQS
|
||||
子类作为同步组件的内部类 ，通常命名为 Sync 。
|
||||
12. ORM （Object Relation Mapping ）：对象关系映射，对象领域模型与底层数据之间的转换，本文泛指 iBATIS ，
|
||||
mybatis 等框架 。
|
||||
13. NPE （java.lang.NullPointerException ）：空指针异常。
|
||||
14. OOM （Out Of Memory ）：源于 java.lang.OutOfMemoryError ，当 JVM 没有足够的内存来为对象分配空间并且垃
|
||||
圾回收器也无法回收空间时 ，系统出现的严重状况 。
|
||||
15. GMT （Greenwich Mean Time ）：指位于英国伦敦郊区的皇家格林尼治天文台的标准时间，因为本初子午线被定义
|
||||
在通过那里的经线。地球每天的自转是有些不规则的，而且正在缓慢减速，现在的标准时间是协调世界时（ UTC ），
|
||||
它由原子钟提供。
|
||||
16. 一方库 ：本工程内 部子项目模块依赖的库（ jar包）。
|
||||
17. 二方库 ：公司内部发布到中央仓库，可供公司内部其它应用依赖的库（ jar包）。
|
||||
18. 三方库 ：公司之外的开源库（ jar包）。
|
||||
|
||||
附3：错误码列表
|
||||
错误码 中文描述 说明
|
||||
0000 0 一切 ok 正确执行后的返回
|
||||
A0001 用户端错误 一级宏观错误码
|
||||
A0100 用户注册错误 二级宏观错误码
|
||||
A0101 用户未同意隐私协议
|
||||
A0102 注册国家或地区受限
|
||||
A0110 用户名校验失败
|
||||
A0111 用户名已存在
|
||||
A0112 用户名包含敏感词
|
||||
A0113 用户名包含特殊字符
|
||||
A0120 密码校验失败
|
||||
A0121 密码长度不够
|
||||
A0122 密码强度不够
|
||||
A0130 校验码输入错误
|
||||
A0131 短信校验码输入错误
|
||||
A0132 邮件校验码输入错误
|
||||
A0133 语音校验码输入错误
|
||||
A0140 用户证件异常
|
||||
A0141 用户证件类型未选择
|
||||
A0142 大陆身份证编号校验非法
|
||||
A0143 护照编号校验非法
|
||||
A0144 军官证编号校验非法
|
||||
A0150 用户基本信息校验失败
|
||||
A0151 手机格式校验失败
|
||||
A0152 地址格式校验失败
|
||||
A0153 邮箱格式校验失败
|
||||
|
||||
A0200 用户登录异常 二级宏观错误码
|
||||
A0201 用户账户不存在
|
||||
A0202 用户账户被冻结
|
||||
A0203 用户账户已作废
|
||||
A0210 用户密码错误
|
||||
A0211 用户输入密码错误次数超限
|
||||
A0220 用户身份校验失败
|
||||
A0221 用户指纹识别失败
|
||||
A0222 用户面容识别失败
|
||||
A0223 用户未获得第三方登录授权
|
||||
A0230 用户登录已过期
|
||||
A0240 用户验证码错误
|
||||
A0241 用户验证码尝试次数超限
|
||||
A0300 访问权限异常 二级宏观错误码
|
||||
A0301 访问未授权
|
||||
A0302 正在授权中
|
||||
A0303 用户授权申请被拒绝
|
||||
A0310 因访问对象隐私设置被拦截
|
||||
A0311 授权已过期
|
||||
A0312 无权限使用 API
|
||||
A0320 用户访问被拦截
|
||||
A0321 黑名单用户
|
||||
A0322 账号被冻结
|
||||
A0323 非法 IP 地址
|
||||
A0324 网关访问受限
|
||||
A0325 地域黑名单
|
||||
A0330 服务已欠费
|
||||
|
||||
A0340 用户签名异常
|
||||
A0341 RSA 签名错误
|
||||
A0400 用户请求参数错误 二级宏观错误码
|
||||
A0401 包含非法恶意跳转链接
|
||||
A0402 无效的用户输入
|
||||
A0410 请求必填参数为空
|
||||
A0411 用户订单号为空
|
||||
A0412 订购数量为空
|
||||
A0413 缺少时间戳参数
|
||||
A0414 非法的时间戳参数
|
||||
A0420 请求参数值超出允许的范围
|
||||
A0421 参数格式不匹配
|
||||
A0422 地址不在服务范围
|
||||
A0423 时间不在服务范围
|
||||
A0424 金额超出限制
|
||||
A0425 数量超出限制
|
||||
A0426 请求批量处理总个数超出限制
|
||||
A0427 请求 JSON 解析失败
|
||||
A0430 用户输入内容非法
|
||||
A0431 包含违禁敏感词
|
||||
A0432 图片包含违禁信息
|
||||
A0433 文件侵犯版权
|
||||
A0440 用户操作异常
|
||||
A0441 用户支付超时
|
||||
A0442 确认订单超时
|
||||
A0443 订单已关闭
|
||||
A0500 用户请求服务异常 二级宏观错误码
|
||||
|
||||
A0501 请求次数超出限制
|
||||
A0502 请求并发数超出限制
|
||||
A0503 用户操作请等待
|
||||
A0504 WebSocket 连接异常
|
||||
A0505 WebSocket 连接断开
|
||||
A0506 用户重复请求
|
||||
A0600 用户资源异常 二级宏观错误码
|
||||
A0601 账户余额不足
|
||||
A0602 用户磁盘空间不足
|
||||
A0603 用户内存空间不足
|
||||
A0604 用户 OSS 容量不足
|
||||
A0605 用户配额已用光 蚂蚁森林浇水数或每天抽奖数
|
||||
A0700 用户上传文件异常 二级宏观错误码
|
||||
A0701 用户上传文件类型不匹配
|
||||
A0702 用户上传文件太大
|
||||
A0703 用户上传图片太大
|
||||
A0704 用户上传视频太大
|
||||
A0705 用户上传压缩文件太大
|
||||
A0800 用户当前版本异常 二级宏观错误码
|
||||
A0801 用户安装版本与系统不匹配
|
||||
A0802 用户安装版本过低
|
||||
A0803 用户安装版本过高
|
||||
A0804 用户安装版本已过期
|
||||
A0805 用户 API 请求版本不匹配
|
||||
A0806 用户 API 请求版本过高
|
||||
A0807 用户 API 请求版本过低
|
||||
A0900 用户隐私未授权 二级宏观错误码
|
||||
|
||||
A0901 用户隐私未签署
|
||||
A0902 用户摄像头未授权
|
||||
A0903 用户相机未授权
|
||||
A0904 用户图片库未授权
|
||||
A0905 用户文件未授权
|
||||
A0906 用户位置信息未授权
|
||||
A0907 用户通讯录未授权
|
||||
A1000 用户设备异常 二级宏观错误码
|
||||
A1001 用户相机异常
|
||||
A1002 用户麦克风异常
|
||||
A1003 用户听筒异常
|
||||
A1004 用户扬声器异常
|
||||
A1005 用户 GPS 定位异常
|
||||
|
||||
B0001 系统执行出错 一级宏观错误码
|
||||
B0100 系统执行超时 二级宏观错误码
|
||||
B0101 系统订单处理超时
|
||||
B0200 系统容灾功能被触发 二级宏观错误码
|
||||
B0210 系统限流
|
||||
B0220 系统功能降级
|
||||
B0300 系统资源异常 二级宏观错误码
|
||||
B0310 系统资源耗尽
|
||||
B0311 系统磁盘空间耗尽
|
||||
B0312 系统内存耗尽
|
||||
B0313 文件句柄耗尽
|
||||
B0314 系统连接池耗尽
|
||||
B0315 系统线程池耗尽
|
||||
|
||||
B0320 系统资源访问异常
|
||||
B0321 系统读取磁盘文件失败
|
||||
|
||||
C0001 调用第三方服务出错
|
||||
C0100 中间件服务出错 一级宏观错误码
|
||||
C0110 RPC 服务出错 二级宏观错误码
|
||||
C0111 RPC 服务未找到
|
||||
C0112 RPC 服务未注册
|
||||
C0113 接口不存在
|
||||
C0120 消息服务出错
|
||||
C0121 消息投递出错
|
||||
C0122 消息消费出错
|
||||
C0123 消息订阅出错
|
||||
C0124 消息分组未查到
|
||||
C0130 缓存服务出错
|
||||
C0131 key 长度超过限制
|
||||
C0132 value 长度超过限制
|
||||
C0133 存储容量已满
|
||||
C0134 不支持的数据格式
|
||||
C0140 配置服务出错
|
||||
C0150 网络资源服务出错
|
||||
C0151 VPN 服务出错
|
||||
C0152 CDN 服务出错
|
||||
C0153 域名解析服务出错
|
||||
C0154 网关服务出错
|
||||
C0200 第三方系统执行超时 二级宏观错误码
|
||||
C0210 RPC 执行超时
|
||||
|
||||
C0220 消息投递超时
|
||||
C0230 缓存服务超时
|
||||
C0240 配置服务超时
|
||||
C0250 数据库服务超时
|
||||
C0300 数据库服务出错 二级宏观错误码
|
||||
C0311 表不存在
|
||||
C0312 列不存在
|
||||
C0321 多表关联中存在多个相同名称的列
|
||||
C0331 数据库死锁
|
||||
C0341 主键冲突
|
||||
C0400 第三方容灾系统被触发 二级宏观错误码
|
||||
C0401 第三方系统限流
|
||||
C0402 第三方功能降级
|
||||
C0500 通知服务出错 二级宏观错误码
|
||||
C0501 短信提醒服务失败
|
||||
C0502 语音提醒服务失败
|
||||
C0503 邮件提醒服务失败
|
||||
@@ -0,0 +1,177 @@
|
||||
---
|
||||
name: java-exception-logging
|
||||
description: 阿里巴巴Java开发手册异常日志规约，包含错误码、异常处理、日志规约。Use when handling exceptions, logging, or error codes in Java applications.
|
||||
---
|
||||
|
||||
# 异常日志
|
||||
## 二、异常日志
|
||||
### (一) 错误码
|
||||
1.【强制】 错误码的制定原则 ：快 速溯源 、沟通标准化 。
|
||||
说明 ：错误码想得过于完美和复杂 ，就像康熙字典的生僻字一样 ，用词似乎精准 ，但是字典不容易随身携带且简单易懂 。
|
||||
正例： 错误码回答的问题是谁的错？错在哪？
|
||||
1）错误码必须能够快速知晓错误来源 ，可快速判断是谁的问题。
|
||||
2）错误码必须能够进行清晰地比对（代码中容易 equals ）。
|
||||
3）错误码有利于团队快速对错误原因达到一致认知。
|
||||
2.【强制】 错误码不体现版本号和错误等级信息 。
|
||||
说明 ：错误码以不断追加的方式进行兼容。错误等级由日志和错误码本身的释义来决定。
|
||||
3.【强制】 全部正常 ，但不得不填充错误码时返回五个零 ：00000 。
|
||||
4.【强制】 错误码为字符串类型 ，共5位，分成两个部 分：错误产生来源 +四位数字编号 。
|
||||
说明 ：错误产生来源分为 A/B/C ，A表示错误来源于用户 ，比如参数错误 ，用户安装版本过低 ，用户支付超时等问题；
|
||||
B表示错误来源于当前系统 ，往往是业务逻辑出错 ，或程序健壮性差等问题； C表示错误来源于第三方服务 ，比如 CDN
|
||||
服务出错 ，消息投递超时等问题；四位数字编号从 0001 到9999 ，大类之间的步长间距预留 100，参考文末 附表 3。
|
||||
5.【强制】 编号不与公司业务架构 ，更不与组织架构挂钩 ，以先到先得的原则在统一平台上进行 ，审批生
|
||||
效，编号即被永久固定 。
|
||||
6.【强制】 错误码使用者避免随意定义新的错误码 。
|
||||
说明 ：尽可能在原有错误码附表中找到语义相同或者相近的错误码在代码中使用即可。
|
||||
7.【强制】 错误码不能直接输出给用户作为提示信息使用 。
|
||||
说明 ：堆栈（ stack_trace ）、错误信息 (error_message) 、错误码（ error_code ）、提示信息（ user_tip ）是一个有效关
|
||||
联并互相转义的和谐整体 ，但是请勿互相越俎代庖。
|
||||
8.【推荐 】错误码之外的业务信息由 error_message 来承载 ，而不是让错误码本身涵盖过多具体业务属性 。
|
||||
9.【推荐】 在获取第三方服务错误码时 ，向上抛出允许本系统转义 ，由C转为 B，并且在错误信息上带上原
|
||||
有的第三方错误码 。
|
||||
10.【参考】 错误码分为一级宏观错误码 、二级宏观错误码 、三级宏观错误码 。
|
||||
说明 ：在无法更加具体确定的错误场景中 ，可以直接使用一级宏观错误码 ，分别是 ：A0001 （用户端错误 ）、B0001 （系
|
||||
统执行出错 ）、C0001 （调用第三方服务出错 ）。
|
||||
正例： 调用第三方服务出错是一级 ，中间件错误是二级 ，消息服务出错是三级。
|
||||
11.【参考】 错误码的后三位编号与 HTTP 状态码 没有任何关系 。
|
||||
12.【参考】 错误码有利于不同文化背景的开发者进行交流与代码协作 。
|
||||
说明 ：英文单词形式的错误码不利于非英语母语国家（如阿拉伯语 、希伯来语 、俄罗斯语等）之间的 开发者互相协作 。
|
||||
13.【参考】 错误码即人性 ，感性认知 +口口相传 ，使用纯数字来进行错误码编排不利于感性记忆和分类 。
|
||||
说明 ：数字是一个整体 ，每位数字的地位和含义是相同的。
|
||||
反例 ：一个五位数字 12345 ，第1位是错误等级 ，第2位是错误来源 ，345 是编号 ，人的大脑不会主动地拆开并分辨每
|
||||
位数字的不同含义 。
|
||||
|
||||
### (二) 异常处理
|
||||
1.【强制】 Java 类库中定义的可以通过预检查方式规避的 RuntimeException 异常不应该通过 catch 的方
|
||||
式来处理 ，比如 ：NullPointerException ，IndexOutOfBoundsException 等等 。
|
||||
说明 ：无法通过预检查的异常除外 ，比如 ，在解析字符串形式的数字时 ，可能存在数字格式错误 ，不得不通过 catch
|
||||
NumberFormatException 来实现 。
|
||||
正例 ：if (obj != null) {...}
|
||||
反例 ：try { obj.method(); } catch (NullPointerException e) {…}
|
||||
2.【强制】 异常 捕获后 不要用来做流程控制 ，条件控制 。
|
||||
说明 ：异常设计的初衷是解决程序运行中的各种意外情况 ，且异常的处理效率比条件判断方式要低很多 。
|
||||
3.【强制】 catch 时请分清稳定代码和非稳定代码 ，稳定 代码指的是无论如何不会出错的代码 。对于非稳定
|
||||
代码的 catch 尽可能进行区分异常类型 ，再做对应的异常处理 。
|
||||
说明 ：对大段代码进行 try-catch ，使程序无法根据不同的异常做出正确的应激反应 ，也不利于定位问题 ，这是一种不负
|
||||
责任的表现 。
|
||||
正例 ：用户注册的场景中 ，如果用户输入非法字符 ，或用户名称已存在 ，或用户输入密码过于简单 ，在程序上作出分门
|
||||
别类的判断 ，并提示给用户 。
|
||||
4.【强制】 捕获异常是为了处理它 ，不要捕获了却什么都不处理而抛弃之 ，如果不想处理它 ，请将该异常
|
||||
抛给它的调用者 。最外层的业务使用者 ，必须处理异常 ，将其转化为用户可以理解的内容 。
|
||||
5.【强制】 事务场景中 ，抛出异常被 catch 后，如果需要回滚 ，一定要注意手动回滚事务 。
|
||||
6.【强制】 finally 块必须对资源对象 、流对象进行关闭 ，有异常也要做 try-catch 。
|
||||
说明 ：如果 JDK7 ，可以使用 try-with-resources 方式 。
|
||||
7.【强制】 不要在 finally 块中使用 return
|
||||
说明 ：try块中的 return 语句执行成功后 ，并不马上返回 ，而是继续执行 finally 块中的语句 ，如果此处存在 return 语句 ，
|
||||
则会在此直接返回 ，无情丢弃掉 try块中的返回点 。
|
||||
反例 ：
|
||||
private int x = 0;
|
||||
public int checkReturn () {
|
||||
try {
|
||||
// x等于 1，此处不返回
|
||||
return ++x;
|
||||
} finally {
|
||||
// 返回 的结果是 2
|
||||
return ++x;
|
||||
}
|
||||
}
|
||||
8.【强制】 捕获异常与抛异常 ，必须是完全匹配 ，或者捕获异常是抛异常的父类 。
|
||||
说明 ：如果预期对方抛的是绣球 ，实际接到的是铅球 ，就会产生意外情况 。
|
||||
9.【强制】 在调用 RPC 、二方包 、或动态生成类的相关方法时 ，捕捉异常 使用Throwable 类进行拦截 。
|
||||
说明 ：通过反射机制来调用方法 ，如果找不到方法 ，抛出 NoSuchMethodException 。什么情况会抛出
|
||||
NoSuchMethodError 呢？二方包在类冲突时 ，仲裁机制可能导致引入非预期的版本使类的方法签名不匹配 ，或者在
|
||||
字节码修改框架（比如 ：ASM ）动态创建或修改类时 ，修改了相应的方法签名 。这些情况 ，即使代码编译期是正确
|
||||
的，但在代码运行期时 ，会抛出 NoSuchMethodError 。
|
||||
反例 ：足迹服务 引入了高版本的 spring ，导致运行到某段核心逻辑时，抛出 NoSuchMethodError 错误， catch 用的
|
||||
类却是 Exception ，堆栈向上抛，影响到上层业务。这是一个非核心功能点影响到核心应用的典型反例 。
|
||||
|
||||
10.【推荐】 方法的 返回值可以为 null，不强制返回空集合，或者空对象等，必须添加注释充分说明什么情
|
||||
况下会返回 null 值。
|
||||
说明 ：本规约明确防止 NPE 是调用者的责任。即使被调用方法返回空集合或者空对象 ，对调用者来说 ，也并非高枕无
|
||||
忧，必须考虑到远程调用失败 ，运行时异常等场景返回 null 的情况 。
|
||||
11.【推荐】 防止 NPE ，是程序员的基本修养 ，注意 NPE 产生的场 景：
|
||||
1）返回类型为基本数据类型 ，return 包装数据类型的对象时 ，自动拆箱有可能产生 NPE
|
||||
反例 ：public int method () { return Integer 对象; }，如果为 null，自动解箱抛 NPE 。
|
||||
2）数据库的查询结果可能为 null。
|
||||
3）集合里的元素即使 isNotEmpty ，取出的数据元素也可能为 null。
|
||||
4）远程调用返回对象时 ，一律要求进行空指针判断 ，防止 NPE 。
|
||||
5）对于 Session 中获取的数据 ，建议进行 NPE 检查 ，避免空指针。
|
||||
6）级联调用 obj.getA().getB().getC ()；一连串调用 ，易产生 NPE 。
|
||||
正例 ：使用 JDK8 的Optional 类来防止 NPE 问题 。
|
||||
12.【推荐】 定义时区分 unchecked / checked 异常 ，避免直接抛出 new RuntimeException() ，更不允许
|
||||
抛出 Exception 或者 Throwable ，应使用有业务含义的自定义异常 。推荐业界已定义过的自定义异
|
||||
常，如：DAOException / ServiceException 等。
|
||||
13.【参考】 对于公司外的 http / api开放接口必须使用 错误码 ，而应用内部推荐异常抛出 ；跨应用间
|
||||
RPC 调用优先考虑 使用 Result 方式 ，封装 isSuccess() 方法 、错误码 、错误简短信息；应用内部推荐
|
||||
异常抛出 。
|
||||
说明 ：关于 RPC 方法返回方式使用 Result 方式的理由 ：
|
||||
1）使用抛异常返回方式 ，调用方如果没有捕获到就会产生运行时错误 。
|
||||
2）如果不加栈信息 ，只是 new 自定义异常 ，加入自己的理解的 error message ，对于调用端解决问题的帮助不会太多 。
|
||||
如果加了栈信息 ，在频繁调用出错的情况下 ，数据序列化和传输的性能损耗也是问题 。
|
||||
|
||||
### (三) 日志规约
|
||||
1.【强制】 应用中不可直接使用日志系统（ Log4j 、Logback ）中的API，而应依赖使用日志框架 （SLF4J 、
|
||||
JCL—Jakarta Commons Logging ）中的 API，使用门面模式的日志框架 ，有利于维护和各个类的日志处理
|
||||
方式统一 。
|
||||
说明 ：日志框架（ SLF4J 、JCL--Jakarta Commons Logging ）的使用方式（推荐使用 SLF4J ）
|
||||
使用 SLF4J：
|
||||
import org.slf4j.Logger ;
|
||||
import org.slf4j.LoggerFactory ;
|
||||
private static final Logger logger = LoggerFactory .getLogger (Test.class );
|
||||
使用 JCL：
|
||||
import org.apache .commons .logging .Log;
|
||||
import org.apache .commons .logging .LogFactory ;
|
||||
private static final Log log = LogFactory .getLog (Test.class );
|
||||
2.【强制】 日志文件至少保存 15天，因为有些异常具备以 “周”为频次发生的特点。对于当天日志 ，以
|
||||
“应用名.log” 来保存 ，保存在 /{统一目录 }/{应用名 }/logs/ 目录下 ，过往日志格式为 ：
|
||||
{logname}.log.{ 保存日期 }，日期格式： yyyy-MM-dd
|
||||
正例 ：以mppserver 应用为例 ，日志保存 /home/admin/mppserver/logs/mppserver.log ，历史日志名称
|
||||
为mppserver.log.20 21-11-28
|
||||
|
||||
3.【强制】 根据国家法律 ，网络运行状态 、网络安全事件 、个人敏感信息操作等相关记录 ，留存的日志不
|
||||
少于六个月 ，并且进行网络多机备份 。
|
||||
4.【强制】 应用中的扩展日志（如打点 、临时监控 、访问日志等 ）命名方式 ：
|
||||
appName_logType_logName.log 。logType ：日志类型 ，如stats / monitor / access 等；
|
||||
logName ：日志描述。这种命名的好处：通过文件名就可知道日志文件属于什么应用 ，什么类型 ，什
|
||||
么目的 ，也有利于归类查找。
|
||||
说明 ：推荐对日志进行分类 ，将错误日志和业务日志分开放 ，便于开发人员查看 ，也便于通过日志对系统进行及时监控 。
|
||||
正例 ：mppserver 应用中单独监控时区转换异常 ，如：mppserver_monitor_timeZoneConvert.log
|
||||
5.【强制】 在日志输出时 ，字符串变量之间的拼接使用占位符的方式 。
|
||||
说明 ：因为 String 字符串的拼接会使用 StringBuilder 的append() 方式 ，有一定的性能损耗 。使用占位符仅是替换动
|
||||
作，可以有效提升性能 。
|
||||
正例： logger .debug ("Processing trade with id : {} and symbol : {}", id, symbol );
|
||||
6.【强制】 对于 trace / debug / info 级别的日志输出 ，必须进行日志级别的开关判断 ：
|
||||
说明 ：虽然在 debug( 参数) 的方法体内第一行代码 isDisabled(Level.DEBUG_INT) 为真时（ Slf4j 的常见实现 Log4j 和
|
||||
Logback ），就直接 return ，但是参数可能会进行字符串拼接运算 。此外 ，如果 debug(getName()) 这种参数内有
|
||||
getName() 方法调用 ，无谓浪费方法调用的开销 。
|
||||
正例 ：
|
||||
// 如果判断为真 ，那么可以输出 trace 和debug 级别的日志
|
||||
if (logger .isDebugEnabled ()) {
|
||||
logger .debug ("Current ID is: {} and name is: {}", id, getName ());
|
||||
}
|
||||
7.【强制】 避免重复打印日志 ，浪费磁盘空间 ，务必在日志配置文件中设置 additivity=false
|
||||
正例 ：<logger name="com.taobao.dubbo.config" additivity="false">
|
||||
8.【强制】 生产环境禁止使用 System.out 或System.er r输出或使用 e.printStackTrace() 打印异常堆栈 。
|
||||
说明 ：标准日志输出与标准错误输出文件每次 Jboss 重启时才滚动 ，如果大量输出送往这两个文件 ，容易造成文件大小
|
||||
超过操作系统大小限制 。
|
||||
9.【强制】 异常信息应该包括两类信息 ：案 发现场信息和异常堆栈信息 。如 果不处理 ，那么通过关键字
|
||||
throws 往上抛出 。
|
||||
正例 ：logger.error("inputParams: {} and errorMessage: {}", 各类参数或者对象 toString() , e.getMessage() , e);
|
||||
10.【强制】 日志打印时禁止直接用 JSON 工具将对象转换成 String 。
|
||||
说明 ：如果对象里某些 get方法被覆写 ，存在抛出异常的情况 ，则可能会因为打印日志而影响正常业务流程的执行 。
|
||||
正例 ：打印日志时仅打印出业务相关属性值或者调用其对象的 toString() 方法 。
|
||||
11.【推荐】 谨慎地记录日志 。生产环境禁止输出 debug 日志 ；有 选择地输出 info 日志 ；如果使用 warn
|
||||
来记录刚上线时的业务行为信息 ，一定要注意日志输出量的问题 ，避免把服务器磁盘撑爆 ，并记得及时
|
||||
删除这些观察日志 。
|
||||
说明： 大量地输出无效日志 ，不利于系统性能提升 ，也不利于快速定位错误点。记录日志时请思考：这些 日志真的有
|
||||
人看吗？看到这条日志你能做什么？ 能不能给问题排查带来好处？
|
||||
12.【推荐】 可以使用 warn 日志级别来记录用户输入参数错误的情况 ，避免用户投诉时 ，无所适从 。如非
|
||||
必要 ，请不要在此场景打出 error 级别 ，避免频繁报警 。
|
||||
说明 ：注意日志输出的级别 ，error 级别只记录系统逻辑出错 、异常或者重要的错误信息 。
|
||||
13.【推荐】 尽量 用英文来描述日志错误信息 ，如果日志中的错误信息用英文描述不清楚的话使用 中文描述
|
||||
即可 ，否则容易产生歧义 。
|
||||
|
||||
说明 ：国际化团队或海外部署的服务器由于字符集问题 ，使用全英文来注释和描述日志错误信息 。
|
||||
14.【推荐】 为了保护用户隐私，日志文件中 的用户敏感信息 需要 进行脱敏处理 。
|
||||
说明 ：日志排查问题时，推荐使用 订单号 、UUID 之类的唯一编号进行 查询。
|
||||
|
||||
@@ -0,0 +1,185 @@
|
||||
---
|
||||
name: java-mysql-database
|
||||
description: 阿里巴巴Java开发手册MySQL数据库规约，包含建表规约、索引规约、SQL语句、ORM映射。Use when designing database schemas, writing SQL queries, or working with MySQL in Java applications.
|
||||
---
|
||||
|
||||
# MySQL数据库
|
||||
## 五、MySQL 数据库
|
||||
### (一) 建表规约
|
||||
1.【强制】 表达是与否概念的字段 ，必须使用 is_xxx 的方式命名 ，数据类 型是 unsigned tinyint （1表示
|
||||
是，0表示否 ）。
|
||||
注意 ：POJO 类中的任何布尔类型的变量 ，都不要加 is前缀 ，所以 ，需要在 <resultMap> 设置从 is_xxx 到Xxx 的映射关
|
||||
系。数据库表示是与否的值 ，使用 tinyint 类型 ，坚持 is_xxx 的命名方式是为了明确其取值含义与取值范围。
|
||||
说明 ：任何字段如果为非负数 ，必须是 unsigned 。
|
||||
正例 ：表达逻辑删除的字段名 is_deleted ，1表示删除 ，0表示未删除 。
|
||||
2.【强制】 表名 、字段名必须使用小写字母或数字 ，禁止出现数字开头禁止两个下划线中间只出现数字 。数
|
||||
据库字段名的修改代价很大 ，因为无法进行预发布 ，所以字段名称需要慎重考虑 。
|
||||
说明 ：MySQL 在Windows 下不区分大小写 ，但在 Linux 下默认是区分大小写 。因此 ，数据库名 、表名 、字段名 ，都不允
|
||||
许出现任何大写字母 ，避免节外生枝 。
|
||||
正例 ：aliyun_admin ，rdc_config ，level3_name
|
||||
反例： AliyunAdmin ，rdcConfig ，level_3_name
|
||||
3.【强制 】表名不使用复数名词 。
|
||||
说明 ：表名应该仅仅表示表里面的实体内容 ，不应该表示实体数量 ，对应于 DO 类名也是单数形式 ，符合表达习惯 。
|
||||
4.【强制】 禁用保留字 ，如desc 、range 、match 、delayed 等，请参考 MySQL 官方保留字 。
|
||||
5.【强制】 主键索引名为 pk_字段名 ；唯一索引名为 uk_字段名 ；普通索引名则为 idx_ 字段名 。
|
||||
说明： pk_即primary key；uk_即unique key；idx_ 即index 的简称。
|
||||
6.【强制】 小数类型为 decimal ，禁止使用 float 和double 。
|
||||
说明： 在存储的时候 ，float 和double 都存在精度损失的问题 ，很可能在比较值的时候 ，得到不正确的 结果 。如果存
|
||||
储的数据范围超过 decimal 的范围 ，建议将数据拆成整数和小数并分开存储。
|
||||
7.【强制】 如果存储的字符串长度几乎相等 ，使用 char 定长字符串类型 。
|
||||
8.【强制】 varchar 是可变长字符串 ，不预先分配存储空间 ，长度不要超过 5000 ，如果存储长度大于此
|
||||
值，定义字段类型为 text ，独立出来一张表 ，用主键来对应 ，避免影响其它字段索引率 。
|
||||
9.【强制】 表必备三字段 ：id，create_time ，update_time 。
|
||||
说明 ：其中 id必为主键 ，类型为 bigint unsigned 、单表时自增 、步长为 1。create_time ，update_time 的类型均为
|
||||
datetime 类型 ，如果要记录时区信息，那么 类型设置 为timestamp 。
|
||||
10.【强制】 在数据库 中不 能使用物理删除操作， 要使用逻辑删除。
|
||||
说明 ：逻辑删除在数据删除 后可以 追溯 到行为操作。不过会使得一些情况下的唯一主键变得不唯一，需要根据情况来 酌
|
||||
情解 决。
|
||||
11.【推荐】 表的命名最好是遵循 “业务名称 _表的作用 ”。
|
||||
正例：alipay_task / force_project / trade_config / tes_question
|
||||
12.【推荐】 库名与应用名称尽量一致 。
|
||||
13.【推荐】 如果修改字段含义或对字段表示的状态追加时 ，需要及时更新字段注释 。
|
||||
14.【推荐】 字段允许适当冗余 ，以提高查询性能 ，但必须考虑数据一致 。冗余字段应遵循 ：
|
||||
1）不是频繁修改的字段 。
|
||||
2）不是唯一索引的字段。
|
||||
3）不是 varchar 超长字段 ，更不能是 text 字段。
|
||||
正例： 各业务线经常冗余存储商品名称，避免查询时需要调用 IC服务获取。
|
||||
|
||||
15.【推荐】 单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表 。
|
||||
说明 ：如果预计三年后的数据量根本达不到这个级别 ，请不要在创建表时就分库分表 。
|
||||
16.【参考】 合适的字符存储长度 ，不但节约数据库表空间 、节约索引存储 ，更重要的是提升检索速度 。
|
||||
正例 ：无符号值可以避免误存负数 ，且扩大了表示范围 ：
|
||||
对象 年龄区 间 类型 字节 表示范 围
|
||||
人 150岁之内 tinyint unsigned 1 无符号值 ：0到255
|
||||
龟 数百 岁 smallint unsigned 2 无符号值 ：0到65535
|
||||
恐龙 化石 数千 万年 int unsigned 4 无符号值 ：0到约 43亿
|
||||
太阳 约50亿年 bigint unsigned 8 无符号值 ：0到约 10的19次方
|
||||
|
||||
### (二) 索引规约
|
||||
1.【强制】 业务上具有唯一特性的字段 ，即使是组合字段 ，也必须建成唯一索引 。
|
||||
说明 ：不要以为唯一索引影响了 insert 速度 ，这个速度损耗可以忽略 ，但提高查找速度是明显的 ；另外 ，即使在应用层
|
||||
做了非常完善的校验控制 ，只要没有唯一索引 ，根据墨菲定律 ，必然有脏数据产生 。
|
||||
2.【强制】 超过三个表禁止 join。需要 join 的字段 ，数据类型保持绝对一致 ；多表关联查询时 ，保证被关联
|
||||
的字段需要有索引 。
|
||||
说明 ：即使双表 join 也要注意表索引 、SQL 性能 。
|
||||
3.【强制】 在varchar 字段上建立索引时 ，必须指定索引长度 ，没必要对全字段建立索引 ，根据实际文本区
|
||||
分度决定索引长度 。
|
||||
说明 ：索引的长度与区分度是一对矛盾体 ，一般对字符串类型数据 ，长度为 20的索引 ，区分度会高达 90% 以上 ，可以使
|
||||
用count(distinct left( 列名 ，索引长度 )) / count(*) 的区分度来确定。
|
||||
4.【强制】 页面搜索严禁左模糊或者全模糊 ，如果需要请走搜索引擎来解决 。
|
||||
说明 ：索引文件具有 B-Tree 的最左前缀匹配特性 ，如果左边的值未确定 ，那么无法使用此索引 。
|
||||
5.【推荐】 如果有 order by的场景 ，请注意利用索引的 有序性 。order by最后的字段是组合索引的一部
|
||||
分，并且放在索引组合顺序的最后 ，避免出现 filesort 的情况 ，影响查询性能 。
|
||||
正例 ：where a = ? and b = ? order by c；索引： a_b_c
|
||||
反例 ：索引如果存在范围查询，那么索引有序性无法利用，如： WHERE a > 10 ORDER BY b；索引 a_b 无法排序 。
|
||||
6.【推荐】 利用覆盖索引来进行查询操作 ，避免回表 。
|
||||
说明 ：如果一本书需要知道第 11章是什么标题，会翻开第 11章对应的那一页吗？目录浏览一下就好，这个目录就是起
|
||||
到覆盖索引的作用 。
|
||||
正例 ：能够建立索引的种类分为主键索引 、唯一索引 、普通索引三种，而覆盖索引只是一种查询的一种效果，用 explain
|
||||
的结果， extra 列会出现： using index 。
|
||||
7.【推荐】 利用 延迟关联或者子查询优化超多分页场景 。
|
||||
说明 ：MySQL 并不是跳过 offset 行，而是取 offset+N 行，然后返回放弃前 offset 行，返回 N行，那当 offset 特别大
|
||||
的时候 ，效率就非常的低下 ，要么控制返回的总页数 ，要么对超过特定阈值的页数进行 SQL 改写 。
|
||||
正例 ：先快速定位需要获取的 id段，然后再关联 ：
|
||||
SELECT t1.* FROM 表1 as t1 , (select id from 表1 where 条件 LIMIT 100000 , 20) as t2 where t1.id = t2.id
|
||||
8.【推荐】 SQL 性能优化的目标：至少要达到 range 级别，要求是 ref级别，如果可以是 const 最好 。
|
||||
说明 ：
|
||||
1）consts 单表中最多只有一个匹配行（主键或者唯一索引 ），在优化阶段即可读取到数据。
|
||||
|
||||
2）ref指的是使用普通的索引（ normal index ）。
|
||||
3）range 对索引进行范围检索。
|
||||
反例 ：explain 表的结果， type = index ，索引物理文件全扫描，速度非常慢，这个 index 级别比较 range 还低，与全
|
||||
表扫描是小巫见大巫 。
|
||||
9.【推荐】 建组合索引的时候 ，区分度最高的在最左边 。
|
||||
正例 ：如果 where a = ? and b = ?，a列的几乎接近于唯一值 ，那么只需要单建 idx_a 索引即可 。
|
||||
说明 ：存在非等号和等号混合判断条件时，在建索引时，请把等号条件的列前置。如： where c > ? and d = ? 那么即使
|
||||
c的区分度更高，也必须把 d放在索引的最前列，即建立组合索引 idx_d_c 。
|
||||
10.【推荐】 防止因字段类型不同造成的隐式转换 ，导致 索引失效 。
|
||||
11.【参考】 创建索引时避免有如下极端误 解：
|
||||
1）索引宁滥勿缺 。认为一个查询就需要建一个索引。
|
||||
2）吝啬索引的创建 。认为索引会消耗空间 、严重拖慢记录的更新以及行的新增速度。
|
||||
3）抵制 唯一索引 。认为 唯一索引一律需要在应用层通过 “先查后插 ”方式解决 。
|
||||
|
||||
### (三) SQL 语句
|
||||
1.【强制】 不要使用 count (列名) 或count( 常量) 来替代 count(*) ，count(*) 是SQL92 定义的标准统计行
|
||||
数的语法 ，跟数据库无关 ，跟NULL 和非 NULL 无关 。
|
||||
说明 ：count(*) 会统计值为 NULL 的行 ，而count( 列名) 不会统计此列为 NULL 值的行 。
|
||||
2.【强制】 count(distinct col) 计算该列除 NULL 之外的 不重复行数 ，注意 count(distinct col1 , col2) 如
|
||||
果其中一列全为 NULL ，那么即使另一列有不同的值，也返回为 0。
|
||||
3.【强制】 当某一列的值全是 NULL 时，count(col) 的返回结果为 0；但 sum(col) 的返回结果为 NULL ，因
|
||||
此使用 sum() 时需注意 NPE 问题 。
|
||||
正例 ：可以使用如下方式来避免 sum 的NPE 问题 ：SELECT IFNULL(SUM(column) , 0) FROM table;
|
||||
4.【强制】 使用 ISNULL() 来判断是否为 NULL 值。
|
||||
说明 ：NULL 与任何值的直接比较都为 NULL 。
|
||||
1）NULL<>NULL 的返回结果是 NULL ，而不是 false 。
|
||||
2）NULL=NULL 的返回结果是 NULL ，而不是 true 。
|
||||
3）NULL<>1 的返回结果是 NULL ，而不是 true 。
|
||||
反例 ：在SQL 语句中，如果在 null 前换行，影响可读性。
|
||||
select * from table where column1 is null and column3 is not null；而ISNULL(column) 是一个整体，简洁易懂。
|
||||
从性能数据上分析， ISNULL(column) 执行效率更快一些 。
|
||||
5.【强制】 代码中写分页查询逻辑时 ，若count 为0应直接返回 ，避免执行后面的分页语句 。
|
||||
6.【强制】 不得使用外键与级联 ，一切外键概念必须在应用层解决 。
|
||||
说明 ：（概念解释 ）学生表中的 student_id 是主键 ，那么成绩表中的 student_id 则为外键 。如果更新学生表中的
|
||||
student_id ，同时触发成绩表中的 student_id 更新 ，即为级联更新 。外键与级联更新适用于单机低并发 ，不适合分布式 、
|
||||
高并发集群；级联更新是强阻塞，存在数据库更新风暴的风险；外键影响数据库的插入速度 。
|
||||
7.【强制】 禁止使用存储过程 ，存储过程难以调试和扩展 ，更没有移植性 。
|
||||
8.【强制】 数据订正 （特别是删除或修改记录操作 ）时，要先 select ，避免出现误删除 的情况 ，确认无误才
|
||||
能执行更新语句 。
|
||||
9.【强制】 对于数据库中表记录的查询 和变更 ，只要涉及多个表 ，都需要在列名前加表的别名（或 表名 ）进
|
||||
行限定 。
|
||||
|
||||
说明 ：对多表进行查询记录 、更新记录 、删除记录时，如果对操作列没有限定表的别名（或表名），并且操作列在多个
|
||||
表中存在时 ，就会抛异常 。
|
||||
正例 ：select t1.name from first_table as t1 , second _table as t2 where t1.id = t2.id;
|
||||
反例 ：在某业务中 ，由于多表关联查询语句没有加表的别名（或表名）的限制，正常运行两年后，最近在某个表中增加
|
||||
一个同名字段 ，在预发布环境做数据库变更后 ，线上查询语句出现出 1052 异常 ：
|
||||
Column 'name' infield list is ambiguous 。
|
||||
10.【推荐】 SQL 语句中表的别名前加 as，并且以 t1、t2、t3、...的顺序依次命名 。
|
||||
说明 ：
|
||||
1）别名可以是表的简称，或者是依照表在 SQL 语句中出现的顺序，以 t1、t2、t3的方式命名。
|
||||
2）别名前加 as使别名更容易识别 。
|
||||
正例 ：select t1.name from first_table as t1 , second _table as t2 where t1.id = t2.id;
|
||||
11.【推荐】 in操作能避免则避免 ，若实在避免不了 ，需要仔细评估 in后边的集合元素数量 ，控制在
|
||||
1000 个之内 。
|
||||
12.【参考】 因国际化需要 ，所有的字符存储与表示 ，均采用 utf8mb4 字符集 ，字符计数方法需要注意 。
|
||||
说明 ：
|
||||
SELECT LENGTH(" 轻松工作 ")；--返回为 12
|
||||
SELECT CHARACTER_LENGTH(" 轻松工作 ")；--返回为 4
|
||||
表情 需要用 utf8mb4 来进行 存储 ，注意它与 utf8 编码的区别 。
|
||||
13.【参考】 TRUNCATE TABLE 比DELETE 速度快 ，且使用的系统和事务日志资源少 ，但TRUNCATE
|
||||
无事务且不触发 trigger ，有可能造成事故 ，故不建议在开发代码中使用此语句 。
|
||||
说明： TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同 。
|
||||
|
||||
### (四) ORM 映射
|
||||
1.【强制】 在表查询中 ，一律不要使用 * 作为查询的字段列表 ，需要哪些字段必须明确写明 。
|
||||
说明 ：
|
||||
1）增加查询分析器解析成本 。
|
||||
2）增减字段容易与 resultMap 配置不一致 。
|
||||
3）无用字段增加网络消耗 ，尤其是 text 类型的字段 。
|
||||
2.【强制】 POJO 类的布尔属性不能加 is，而数据库字段必须加 is_，要求在 resultMap 中进行字段与属
|
||||
性之间的映射 。
|
||||
说明 ：参见定义 POJO 类以及数据库字段定义规定，在 sql.xml 增加映射，是必须的 。
|
||||
3.【强制】 不要用 resultClass 当返回参数，即使所有类属性名与数据库字段一一对应，也需要定义
|
||||
<resultMap >；反过来，每一个表也必然有一个 <resultMap> 与之对应 。
|
||||
说明 ：配置映射关系，使字段与 DO 类解耦，方便维护 。
|
||||
4.【强制】 sql.xml 配置参数使用 ：#{}，#param# 不要使用 ${} 此种方式容易出现 SQL 注入 。
|
||||
5.【强制】 iBATIS 自带的 queryForList(String statementName ，int start ，int size) 不推荐使用 。
|
||||
说明 ：其实现方式是在数据库取到 statementName 对应的 SQL 语句的所有记录 ，再通过 subList 取start ，size
|
||||
的子集合 ，线上因为这个原因曾经出现过 OOM 。
|
||||
正例 ：
|
||||
Map<String , Object > map = new HashMap <>(16);
|
||||
map.put("start" , start);
|
||||
map.put("size" , size);
|
||||
|
||||
6.【强制】 不允许直接拿 HashMap 与Hashtable 作为查询结果集的 输出 。
|
||||
反例 ：某同学为避免写一个 <resultMap>xxx</resultMap> ，直接使用 Hash table 来接收数据库返回结果，结果出现
|
||||
日常是把 bigint 转成 Long 值，而线上由于数据库版本不一样，解析成 BigInteger ，导致线上问题 。
|
||||
7.【强制】 更新数据表记录时 ，必须同时更新记录对应的 update_time 字段值为当前时间 。
|
||||
8.【推荐】 不要写一个大而全的数据更新接口 。传入为 POJO类，不管是不是自己的目标更新字段 ，都进行
|
||||
update table set c1 = value1 , c2 = value2 , c3 = value3 ；这 是不对的 。执行 SQL 时，不要更新无改
|
||||
动的字段 ，一是易出错 ；二是效率低 ；三是增加 binlog 存储 。
|
||||
9.【参考】 @Transactional 事务不要滥用 。事务会影响数据库的 QPS ，另外使用事务的地方需要考虑各
|
||||
方面的回滚方案 ，包括缓存回滚 、搜索引擎回滚 、消息补偿 、统计修正等 。
|
||||
10.【参考】 <isEqual> 中的compareValue 是与属性值对比的常量 ，一般是数字 ，表示相等时带上此条
|
||||
件；<isNotEmpty> 表示不为空且不为 null 时执行 ；<isNotNull> 表示不为 null 值时执行 。
|
||||
|
||||
@@ -0,0 +1,115 @@
|
||||
---
|
||||
name: java-project-structure
|
||||
description: 阿里巴巴Java开发手册工程结构规约，包含应用分层、二方库依赖、服务器。Use when structuring Java projects, managing dependencies, or organizing project architecture.
|
||||
---
|
||||
|
||||
# 工程结构
|
||||
## 六、工程结构
|
||||
### (一) 应用分层
|
||||
1.【推荐】 根据业务架构实践 ，结合业界分层规范与流行技术框架分析 ，推荐分层结构如图所示 ，默认上层
|
||||
依赖于下层 ，箭头关系表示可直接依赖 ，如：开放 API 层可以依赖于 Web 层（Controller 层），也可以
|
||||
直接依赖于 Service 层，依此类推 ：
|
||||
|
||||
⚫ 开放 API 层：可直接封装 Service 接口暴露成 RPC 接口 ；通过 Web 封装成 http 接口 ；网关控制层等 。
|
||||
⚫ 终端显示层 ：各个端的模板渲染并执行显示的层 。当前主要是 velocity 渲染 ，JS渲染 ，JSP 渲染 ，移动端展示等 。
|
||||
⚫ Web 层：主要是对访问控制进行转发 ，各类基本参数校验 ，或者不复用的业务简单处理等 。
|
||||
⚫ Service 层：相对具体的业务逻辑服务层 。
|
||||
⚫ Manager 层：通用业务处理层 ，它有如下特征
|
||||
1）对第三方平台封装的层 ，预处理返回结果及转化异常信息 ，适配上层接口。
|
||||
2）对 Service 层通用能力的下沉 ，如缓存方案 、中间件通用处理。
|
||||
3）与 DAO 层交互 ，对多个 DAO 的组合复用。
|
||||
⚫ DAO 层：数据访问层 ，与底层 MySQL 、Oracle 、Hbase 、Ocean Base等进行数据交互 。
|
||||
⚫ 第三方服务 ：包括其它部门 RPC 服务接口，基础平台，其它公司的 HTTP 接口，如淘宝开放平台 、支付 宝付款服务、
|
||||
高德地图服务等 。
|
||||
⚫ 外部数据接口：外部（应用）数据存储服务提供 的接口 ，多见于数据迁移场景中 。
|
||||
2.【参考】 （分层异常处理规约 ）在 DAO 层，产生的异常类型有很多 ，无法用细粒度的异常进行 catch ，
|
||||
使用 catch(Exception e) 方式 ，并throw new DAOException(e) ，不需要打印日志 ，因为日志在
|
||||
Manager 或Service 层一定需要捕获并打印到日志文件中去 ，如果同台服务器再打日志 ，浪费性能和存
|
||||
储。在Service 层出现异常时 ，必须记录出错日志到磁盘 ，尽可能带上参数 和上下文 信息 ，相当于保护案
|
||||
发现场 。Manager 层与 Service 同机部署 ，日志方式与 DAO 层处理一致 ，如果是单独部署 ，则采用与
|
||||
Service 一致的处理方式 。Web 层绝不应该继续往上抛异常 ，因为已经处于顶层 ，如果意识到这个异常
|
||||
将导致页面无法正常渲染 ，那么就应该直接跳转到友好错误页面 ，尽量加上友好的错误提示信息 。开放
|
||||
接口层要将异常处理成错误码和错误信息方式返回 。
|
||||
3.【参考】 分层领域模型规约 ：
|
||||
⚫ DO（Data Object ）： 此对象与数据库表结构一一对应 ，通过 DAO 层向上传输数据源对象 。
|
||||
⚫ DTO （Data Transfer Object ）： 数据传输对象 ，Service 或Manager 向外传输的对象 。
|
||||
|
||||
⚫ BO（Business Object ）： 业务对象 ，可以由 Service 层输出的封装业务逻辑的对象 。
|
||||
⚫ Query ：数据查询对象 ，各层接收上层的查询请求。注意超过 2个参数的查询封装 ，禁止使用 Map 类来传输 。
|
||||
⚫ VO（View Object ）： 显示层对象 ，通常是 Web 向模板渲染引擎层传输的对象 。
|
||||
|
||||
### (二) 二方库依赖
|
||||
1.【强制】 定义 GAV 遵从以下规则 ：
|
||||
1）GroupI d格式 ：com.{ 公司/BU}. 业务线 .[子业务线 ]，最多 4级。
|
||||
说明 ：{公司/BU} 例如 ：alibaba / taobao / tmall / kaikeba 等BU一级 ；子业务线可选 。
|
||||
正例： com.taobao.jstor m或com.alibaba.dubbo.register
|
||||
2）ArtifactI d格式：产品线名 -模块名。语义不重复不遗漏 ，先到中央仓库去查证一下。
|
||||
正例 ：dubbo -client / fastjson -api / jstorm -tool
|
||||
3）Version ：详细规定参考下方 。
|
||||
2.【强制】 二方 库版本号命名方式 ：主 版本号 .次版本号 .修订号
|
||||
1）主版本号 ：产品方向改变 ，或者大规模 API 不兼容 ，或者架构不兼容 升级。
|
||||
2）次版本号：保持相对兼容性 ，增加主要功能特性 ，影响范围极小的 API 不兼容修改。
|
||||
3）修订号 ：保持完全兼容性 ，修复 BUG 、新增次要功能特性等。
|
||||
说明 ：注意起始版本号必须为： 1.0.0 ，而不是 0.0.1 。
|
||||
反例 ：仓库内某二方库版本号从 1.0.0.0 开始 ，一直默默 “升级 ”成1.0.0.64 ，完全失去版本的语义信息 。
|
||||
3.【强制】 线上应用不要依赖 SNAPSHOT 版本（安全包除外 ）；正 式发布的类库必须先去中央仓库进行查
|
||||
证，使RELEASE 版本号有延续性 ，且版本号不允许覆盖升级 。
|
||||
说明 ：不依赖 SNAPSHOT 版本是保证应用发布的幂等性 。另外 ，也可以加快编译时的打包构建 。
|
||||
4.【强制】 二方库的新增或升级 ，保持除功能点之外的其它 jar包仲裁结果不变 。如果有改变 ，必须明确评
|
||||
估和验证 。
|
||||
说明 ：在升级时 ，进行 dependency:resolve 前后信息比对 ，如果仲裁结果完全不一致 ，那么通过 dependency:tree 命
|
||||
令，找出差异点 ，进行<exclude> 排除 jar包。
|
||||
5.【强制】 二方库里可以 定义枚举类型 ，参数可以使用枚举类型 ，但是接口返回值不允许使用枚举类型或者
|
||||
包含枚举类型的 POJO 对象 。
|
||||
6.【强制】 二方库定制包的命名方式，在规定的版本号之后加 “-英文说明 [序号 ]”，英文说明可以是部门
|
||||
简称 、业务名称，序号直接紧跟在英文说明之后，表示此定制包的顺序号 。
|
||||
说明 ：fastjson 给SCM 定制的版本号： 1.0.0 -SCM1 。注：请尽可能在应用端来解决类冲突和加载问题，避免随意发布此
|
||||
类定制包 。
|
||||
7.【强制】 依赖于一个二方库群时 ，必须定义一个统一的版本变量 ，避免版本号不一致 。
|
||||
说明 ：依赖 springframework -core ，-context ，-beans ，它们都是同一个版本，可以定义一个变量来保存版本：
|
||||
${spring.version} ，定义依赖的时候，引用该版本 。
|
||||
8.【强制】 禁止在子项目的 pom 依赖中出现相同的 GroupId ，相同的 Artifact Id，但是不同的 Version 。
|
||||
说明 ：在本地调试时会使用各子项目指定的版本号，但是合并成一个 war，只能有一个版本号出现在最后的 lib目录
|
||||
中。曾经出现过线下调试是正确的，发布到线上却出故障的先例。
|
||||
9.【推荐】 底层基础技术框架 、核心数据管理平台 、或近硬件端系统谨慎引入第三方实现 。
|
||||
10.【推荐】 所有 pom 文件中的依赖声明放在 <depend encies> 语句块中 ，所有版本仲裁放在
|
||||
<dependencyManagement> 语句块中 。
|
||||
|
||||
说明 ：<dependencyManagement> 里只是声明版本 ，并不实现引入 ，因此子项目需要显式的声明依赖 ，version 和
|
||||
scope 都读取自父 pom 。而<dependencies> 所有声明在主 pom 的<dependencies> 里的依赖都会自动引入 ，并默
|
||||
认被所有的子项目继承。
|
||||
11.【推荐】 二方库不要有配置项 ，最低限度不要再增加 配置 项。
|
||||
12.【推荐】 不要使 用不稳定的工具包或者 Utils 类。
|
||||
说明 ：不稳定指的是提供方无法做到向下兼容 ，在编译阶段正常 ，但在运行时产生异常 ，因此 ，尽量使用业界稳定的
|
||||
二方工具包 。
|
||||
13.【参考】 为避免应用二方库的依赖冲突问题 ，二方库发布者应当遵循以下 原则：
|
||||
1） 。移除一切不必要的 API 和依赖 ，只包含 Service API、必要的领域模型对象 、Utils 类、常量 、枚举
|
||||
等。如果依赖其它二方库 ，尽量是 provided 引入 ，让二方库使用者去依赖具体版本号 ；无log 具体实现 ，只依赖日志
|
||||
框架 。
|
||||
2） 。每个版本的变化应该被记录 ，二方库由谁维护 ，源码在哪里 ，都需要能方便查到 。除非用户主动
|
||||
升级版本 ，否则公共二方库的行为不应该发生变化 。
|
||||
|
||||
### (三) 服务器
|
||||
1.【强制】 调用远程操作必须有超时设置。
|
||||
说明 ：类似于 HttpClient 的超时设置需要自己明确去设置 Timeout 。根据经验表明，无数 次的故障都是因为没有设置
|
||||
超时 时间 。
|
||||
2.【推荐】 客户端设置远程接口方法的具体超时时间（单位 ms），超时设置生效顺序一般为： 1）客户
|
||||
端Special Method ；2）客户端接口级别； 3）服务端 Special Method ；4）服务端接口级别 。
|
||||
3.【推荐】 高并发服务器建议调小 TCP 协议的 time_wait 超时时间 。
|
||||
说明 ：操作系统默认 240 秒后 ，才会关闭处于 time_wait 状态的连接 ，在高并发访问下 ，服务器端会因为处于
|
||||
time_wait 的连接数太多 ，可能无法建立新的连接 ，所以需要在服务器上调小此等待值 。
|
||||
正例 ：在linux 服务器上请通过变更 /etc/sysctl.conf 文件去修改该缺省值（秒 ）：net.ipv4.tcp_fin_timeout=30
|
||||
4.【推荐】 调大服务器所支持的最大文件句柄数（ File Descriptor ，简写为 fd）
|
||||
说明 ：主流操作系统的设计是将 TCP / UDP 连接采用与文件一样的方式去管理 ，即一个连接对应于一个 fd。主流的 linux
|
||||
服务器默认所支持最大 fd数量为 1024 ，当并发连接数很大时很容易因为 fd不足而出现 “open too many files” 错误 ，
|
||||
导致新的连接无法建立 。建议将 linux 服务器所支持的最大句柄数调高数倍（与服务器的内存数量相关 ）。
|
||||
5.【推荐】 给JVM环境参数设置 -XX：+HeapD umpOnOutOfMemoryError 参数 ，让JVM碰到 OOM 场
|
||||
景时输出 dump 信息 。
|
||||
说明 ：OOM 的发生是有概率的 ，甚至相隔数月才出现一例，出错时的堆内信息对解决问题非常有帮助。
|
||||
6.【推荐】 在线上生产环境 ，JVM 的Xms 和Xmx 设置一样大小的内存容量 ，避免在 GC后调整堆大小带
|
||||
来的压力 。
|
||||
7.【推荐】 了解每个服务大致的平均耗时，可以通过独立配置线程池，将较慢的服务与主线程池隔离开，
|
||||
免得不同服务的线程同归于尽 。
|
||||
8.【参考】 服务器内部重定向必须使用 forward ；外部 部重定向地址必须使用 URL Broker 生成 ，否则因线
|
||||
上采用 HTTPS 协议而导致浏览器提示 “不安全 ”。此外 ，还会带来 URL 维护不一致的问题 。
|
||||
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: java-security-standards
|
||||
description: 阿里巴巴Java开发手册安全规约。Use when implementing security features, authentication, authorization, or security best practices in Java applications.
|
||||
---
|
||||
|
||||
# 安全规约
|
||||
## 四、安全规约
|
||||
1.【强制 】隶属于用户个人的页面或者功能必须进行权限控制校验 。
|
||||
说明 ：防止没有做水平权限校验就可随意访问 、修改 、删除别人的数据 ，比如查看他人的私信内容 。
|
||||
2.【强制】 用户敏感数据禁止直接展示 ，必须对展示数据进行脱敏 。
|
||||
正例 ：中国大陆个人手机号码显示 ：139****1219 ，隐藏中间 4位，防止隐私泄露 。
|
||||
3.【强制】 用户输入的 SQL 参数严格使用参数绑定或者 METADATA 字段值限定 ，防止 SQL 注入 ，禁止字
|
||||
符串拼接 SQL 访问数据库 。
|
||||
反例 ：某系统签名大量被恶意修改 ，即是因为对于危险字符 #--没有进行转义 ，导致数据库更新时 ，where 后边的信息被注
|
||||
释掉 ，对全库进行更新 。
|
||||
4.【强制】 用户请求传入的任何参数必须做有效性验证 。
|
||||
说明 ：忽略参数校验可能导致：
|
||||
⚫ 页面 page size 过大导致内 存溢出
|
||||
⚫ 恶意 order by导致数 据库慢查询
|
||||
⚫ 缓存击穿
|
||||
⚫ SSRF
|
||||
⚫ 任意重定向
|
||||
⚫ SQL 注入 ，Shell 注入 ，反序列化注入
|
||||
⚫ 正则输入源串拒绝服务 ReDoS
|
||||
扩展 ：Java 代码用正则来验证客户端的输入 ，有些正则写法验证普通用户输入没有问题 ，但是如果攻击人员使
|
||||
用的是特殊构造的字符串来验证 ，有可能导致死循环的结果 。
|
||||
5.【强制】 禁止向 HTML 页面输出未经安全过滤或未正确转义的用户数据 。
|
||||
说明 ：XSS 跨站脚本攻击。它指的是恶意攻击者往 Web 页面里插入恶意 html 代码，当用户浏览时，嵌入其中 Web 里
|
||||
面的 html 代码会被执行，造成获取用户 cookie 、钓鱼、获取用户页面数据、蠕虫、挂马等危害 。
|
||||
6.【强制】 表单 、AJAX 提交必须执行 CSRF 安全验证 。
|
||||
说明 ：CSRF (Cross -site request forgery) 跨站请求伪造是一类常见编程漏洞 。对于存在 CSRF 漏洞的应用 /网站 ，攻击
|
||||
者可以事先构造好 URL ，只要受害者用户一访问 ，后台便在用户不知情的情况下对数据库中用户参数进行相应修改 。
|
||||
7.【强制】 URL 外部重定向传入的目标地址必须执行白名单过滤 。
|
||||
说明 ：攻击者通过恶意构造跳转的链接 ，可以向受害者发起钓鱼攻击 。
|
||||
8.【强制】 在使用平台资源 ，譬如短信 、邮件 、电话 、下单 、支付 ，必须实现正确的防重放的机制 ，如数量
|
||||
限制 、疲劳度控制 、验证码校验 ，避免被滥刷而导致资损 。
|
||||
说明 ：如注册时发送验证码到手机 ，如果没有限制次数和频率 ，那么可以利用此功能骚扰到其它用户 ，并造成短信平台
|
||||
资源浪费 。
|
||||
9.【强制】 对于文件上传功能，需要对于文件大小、类型进行严格检查和控制 。
|
||||
说明 ：攻击者可以利用上传漏洞 ，上传恶意文件到服务器 ，并且远程执行 ，达到控制网站服务器的目的。
|
||||
10.【强制】 配置文件中的密码需要加密 。
|
||||
11.【推荐】 发贴 、评论 、发送 等即时消息 ，需要 用户 输入 内容的场景 。必须实现防刷 、内容违禁词过滤等
|
||||
风控策略 。
|
||||
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
name: java-unit-testing
|
||||
description: 阿里巴巴Java开发手册单元测试规约。Use when writing unit tests, test cases, or testing Java code.
|
||||
---
|
||||
|
||||
# 单元测试
|
||||
## 三、单元测试
|
||||
1.【强制】 好的单元测试必须遵守 AIR 原则 。
|
||||
说明 ：单元测试在线上运行时 ，感觉像空气（ AIR）一样感觉不到 ，但在测试质量的保障上 ，却是非常关键的 。好的单元
|
||||
测试宏观上来说 ，具有自动化 、独立性 、可重复执行的特点 。
|
||||
⚫ A：Automatic （自动化 ）
|
||||
⚫ I：Independent （独立性 ）
|
||||
⚫ R：Repeatable （可重复 ）
|
||||
2.【强制】 单元测试应该是全自动执行的 ，并且非交互式的 。测试用例通常是被定期执行的 ，执行过程必须
|
||||
完全自动化才有意义 。输出结果需要人工检查的测试不是一个好的单元测试 。不允许 使用 System.out 来
|
||||
进行人肉验证 ，单元测试 必须使用 assert 来验证 。
|
||||
3.【强制】 保持 单元测试的独立性 。为了保证单元测试稳定可靠且便于维护 ，单元测试用例之间决不能互相
|
||||
调用 ，也不能依赖执行的先后次序 。
|
||||
反例 ：method2 需要依赖 method1 的执行 ，将执行结果作为 method2 的输入 。
|
||||
4.【强制】 单元测试是可以重复执行的 ，不能受到外界环境的影响 。
|
||||
说明 ：单元测试通常会被放到持续集成中 ，每次有代码 push 时单元测试都会被执行 。如果单测对外部环境（网络 、服
|
||||
务、中间件等 ）有依赖 ，容易导致持续集成机制的不可用 。
|
||||
正例 ：为了不受外界环境影响 ，要求设计代码时就把 SUT （Software under test ）的依赖改成注入 ，在测试时用 Spring
|
||||
这样的 DI框架注入一个本地（内存 ）实现或者 Mock 实现 。
|
||||
5.【强制】 对于单元测试 ，要保证测试粒度足够小 ，有助于精确定位问题 。单测粒度至多是类级别 ，一般是
|
||||
方法级别 。
|
||||
说明 ：测试粒度小才能在出错时尽快定位到出错 的位置。 单元测试 不负责检查跨类或者跨系统的交互逻辑 ，那是集成测试
|
||||
的领域 。
|
||||
6.【强制】 核心业务 、核心应用 、核心模块的增量代码确保单元测试通过 。
|
||||
说明 ：新增代码及时补充单元测试 ，如果新增代码影响了原有单元测试 ，请及时修正 。
|
||||
7.【强制】 单元测试代码必须写在如下工程目 录： src/test/java ，不允许写在业务代码目录下 。
|
||||
说明 ：源码编译时会跳过此目录 ，而单元测试框架默认是扫描此目录 。
|
||||
8.【推荐】 单测的基 本目标 ：语 句覆盖率达到 70% ；核心模块的语句覆盖率和分支覆盖率都 要达到 100%
|
||||
说明 ：在工程规约的应用分层中提到的 DAO 层，Manager 层，可重用度高的 Service ，都应该进行单元测试 。
|
||||
9.【推荐 】编写单元测试代码遵守 BCDE 原则 ，以保证被测试模块的交付质量 。
|
||||
⚫ B：Border ，边界值测试 ，包括循环边界 、特殊取值 、特殊时间点 、数据顺序等 。
|
||||
⚫ C：Correct ，正确的输入 ，并得到预期的结果 。
|
||||
⚫ D：Design ，与设计文档相结合 ，来编写单元测试 。
|
||||
⚫ E：Error ，强制错误信息输入（如 ：非法数据 、异常流程 、业务允许外等 ）， 并得到预期的结果 。
|
||||
10.【推荐】 对于数据库相关的查询 ，更新 ，删除等操作 ，不能假设数据库里的数据是存在的 ，或者直接操
|
||||
作数据库把数据插入进去 ，请使用程序插入或者导入数据的方式来准备数据 。
|
||||
反例 ：删除某一行数据的单元测试 ，在数据库中 ，先直接手动增加一行作为删除目标 ，但是这一行新增数据并不符合业
|
||||
务插入规则 ，导致测试结果异常 。
|
||||
11.【推荐】 和数据库相关的单元测试 ，可以设定自动回滚机制 ，不给数据库造成脏数据 。或者对单元测试
|
||||
产生的数据有明确的前后缀标识 。
|
||||
正例 ：在基础技术 部的内部单元测试中 ，使用FOUNDATION_UNIT_TEST_ 的前缀来标识单元测试相关代码 。
|
||||
|
||||
12.【推荐】 对于不可测的 代码在适当的时机做必要的重构 ，使代码变得可测避免为了达到测试要求而书写
|
||||
不规范测试代码 。
|
||||
13.【推荐】 在设计评审阶 段，开发人员需要和测试人员一起确定单元测试范围 ，单元测试最好覆盖所有测
|
||||
试用例（ UC）。
|
||||
14.【推荐】 单元测试 作为一种质量保障手段 ，在项目提测前完成单元测试 ，不建议项目发布后补充单元测
|
||||
试用例 。
|
||||
15.【参考】 为了更方便地进行单元测试 ，业务代码应避免以下情况 ：
|
||||
⚫ 构造方法中做的事情过多。
|
||||
⚫ 存在过多的全局变量和静态方法 。
|
||||
⚫ 存在过多的外部依赖 。
|
||||
⚫ 存在过多的条件语句 。
|
||||
说明 ：多层条件语句建议使用卫语句 、策略模式 、状态模式等方式重构 。
|
||||
16.【参考】 不要对单元测试存在如下误解 ：
|
||||
⚫ 那是测试同学干的事情 。本文是开发手册 ，凡是本文内容都是与开发同学强相关的 。
|
||||
⚫ 单元测试代码是多余的 。系统的整体功能与各单元部件的测试正常与否是强相关的 。
|
||||
⚫ 单元测试代码不需要维护 。一年半载后 ，那么单元测试几乎处于废弃状态 。
|
||||
⚫ 单元测试与线上故障没有辩证关系 。好的单元测试能够最大限度地规避线上故障 。
|
||||
|
||||
Reference in New Issue
Block a user