系统架构规范
- 目录
- 一、架构规范
- 二、数据库规范
- 三、SOA规范
- 四、安全规范
目录
一、架构规范
- 所有的输入参数需要做合法性检验;
- 不允许出现空指针异常和数组越界异常;
- 不允许出现不受控制的大对象,如没有限定大小的本地缓存,或者没有限定大小的数据库结果集;
- 避免系统串联,对任何资源的依赖都要考虑该资源失败后的降级处理,包括缓存,数据库,Service 等;
- 系统需要做容量规划,对超限的请求主动失败,并告知原因;
- 所有的远程调用需要设置超时时间;
- 如果循环的次数由用户输入,一定要限制最大循环次数;
- 对于非核心特性,考虑提供开关,在必要时主动关闭,释放资源供核心特性;
- 不允许捕获异常后不做任何处理;
- 对于源数据就不存在的Key,需要将空值缓存一段时间,防止缓存穿透;
- 所有应用必须是无状态的,使用分布式缓存或者在调用方存放状态;
二、数据库规范
- 所有表必须有主键;
- 所有表必须有CREATE_TIME,CREATED_BY,UPDATE_TIME,UPDATED_BY 四个字段;
- 业务应用不能直接连接BI 库;如果需要用到BI 的数据,需要在业务系统的数据库中建立相关表,从BI 库中同步数据;
- BI 只能从业务数据库中批量抽取原始数据,不能再业务数据库上面直接进行数据分析;
- 所有持续增长的表必须有明确的数据归档方案;
- 不允许在数据库中存放二进制数据;
- 尽量减少表Join,超过3 个表JOIN 的SQL 需要通过DBA 的评审;
- 不允许Select *;
- 所有的数据库表名不可以重名,水平分库的除外,相同的表名在逻辑上就是同一张表;
- 分表的表名统一以,BASE_TABLE_XX 方式命名,其中_XX 为数字,只要BASE_TABLE 相同,逻辑上就认为是相同的表;
三、SOA规范
- Service(系统)间不允许出现循环依赖;
- Service 调用需要做故障隔离,当依赖的Service 调用失败,需要做优雅降级;
- 因失败而降级的服务恢复后,系统要自动恢复对其的调用;
- 所有Service 提供者需要做容量规划并做限流,当调用流量超限,主动失败并告知调用方原因;
- 尽可能异步调用写的Serivce,减少强依赖;
每当有依赖其他的Service 的时候,确认异步调用不可行才使用同步调用。 - 所有的Serivce 调用需要有一个全局时间ID 关联整个调用栈,由入口生成该Id,在调用其他Service 将该Id 作为参数传递;
- Service 最多允许两层调用(连同应用最多三层),KISS;
- 异步调用的必须控制QUEUE 大小;
四、安全规范
- 必须使用参数化SQL,不允许拼硬编码SQL;
- 坚决不允许将服务器异常直接暴露给客户端;
- 尽量使用POST 而不是GET 提交表单;
- 检查用户输入的合法性,确信输入的内容只包含合法的数据;
- 迫不得已一定要使用硬编码SQL,必须转义单引号,防止攻击者修改SQL命令的含义;
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)