1、 系统架构规范说明2016 年 9 月系统架构规范Page: 1/26 机密 版权所有文档信息文档编号：文档名称： 系统架构规范说明文档类别： 规范类密 级： 普通版本信息： V0.5建立日期： 2016-08-29创 建 人： 审 核 者： 审核人姓名批 准 人： 批准人姓名批准日期： 批准日期系统架构规范Page: 2/26 机密 版权所有项目/客户： 内部用日 期：存放位置：编辑软件：发行软件：文档状态：草稿； 正式发布； 正在修改文档修订记录 | Outstanding Issues版本编号变化状态简要说明 修订日期 变更人 批准日期批准人V0.1 A系统架构规范Page: 3/2
2、6 机密 版权所有说明：版本编号栏中填入版本编号或者更改记录编号。变化状态分为三种状态：A 增加；M 修改；D删除。在简要说明栏中填写变更的内容和变更的范围。表中所有日期格式为：YYYY-MM-DD。文档审批信息序号 审批人 角色 审批日期 签字说明：表中所有日期格式为：YYYY-MM-DD。系统架构规范Page: 4/26 机密 版权所有目 录文档信息 .1文档修订记录 | Outstanding Issues.2目 录 .3系统架构规范 正文 .51 前言 .52 技术选型 .53 接口以及协议 .63.1 原子性 .63.2 可组合性 .63.3 可读性 .63.4 兼容性 .73.
3、5 独立性 .73.6 安全性 .74 数据 .74.1 一致性 .74.2 原子性 .84.3 完整性 .84.4 持久性 .84.5 隔离性 .84.6 可移植性 .8系统架构规范Page: 5/26 机密 版权所有4.7 标准数据定义 .85 系统 .95.1 系统可靠性 .95.2 系统稳定性 .95.3 系统安全性 .95.4 系统扩展性 .105.5 系统移植性 .105.6 系统独立性 .105.7 系统可监控性 .115.8 系统易维护性 .116 处理机制 .116.1 缓存使用机制 .116.2 日志处理机制 .116.3 异常处理机制 .116.4 权限控制机制 .12
4、6.5 事务处理机制 .126.6 回滚机制 .126.7 并发处理机制 .127 使用技术已经中间件 .127.1 标准化 .127.2 开放性 .127.3 稳定性 .12系统架构规范Page: 6/26 机密 版权所有7.4 可替代 .137.5 是否可满足需求 .13系统架构规范Page: 7/26 机密 版权所有系统架构规范 正文1 前言本系统架构规范仅适用于中型系统和大型系统，对此类项目，一般需要较多人员的参与，如不在开发进行之前定义好一些规范、原则，很容易在开发中产生各种各样的问题，如功能切分不合理、服务拆分粒度不足、数据冗余、性能受影响等各式各样的问题。在构建此类系统前，我
5、们要进行统一的系统层级的设计，来尽量避免文中这些问题的出现。对于影响不大、重要性不大或存活时间不久的项目，可以采用更为灵活的方式进行自行开发，以免过多人力投入产生浪费。2 技术选型应以满足系统的需求为出发,考虑选择某个技术对整个系统生命周期的影响:1.需求层面的影响是否能够满足当前或未来的业务需求,在整个系统生命周期中,应该优先满足目前业务情况,再考虑未来不确定的业务需求。2.系统设计层面的影响系统设计时需要考虑技术特性对整个系统生命周期的适应性,稳定性,可替代性,可维护性,是否可以跨平台,以及开发难度的综合考量,避免系统依赖于某项专用技术,或者和某项技术耦合紧密,降低技术选型变更成本。3.系
6、统开发层面的影响应当为开发人员提供技术相关使用文档,以及入门指南等技术资料,应以技术透明为原则做好技术封装工作,和应用规范,减轻开发人员使用该技术的难度,降低开发人员学习成本。4.系统实施层面的影响系统架构规范Page: 8/26 机密 版权所有应当考虑所采用技术在实施安装部署的技术难度以及硬件的兼容性,稳定性,以及资源消耗问题。并提供系统所采用技术安装部署操作文档。5.技术实现难度的评估评估所选技术实现的难点,算法,技术团队是否能够很好的掌握和使用,开发时间,以及是否会提高系统复杂程度。6.技术的优缺点评估及同类技术之间差异评估调研所选技术在行业内是否普遍认可和使用,社区维护情况,系统版本
7、是否趋于成熟稳定的状态7.技术是否开源以及是否成熟稳定3 接口以及协议3.1原子性接口原子性,包含三个层面的定义,一个是接口数据的粒度定义,一个是接口在进行写操作的不可打断原则,一个是组合接口的数据拼装的完整。1. 接口粒度：定义的粒度是否合适，是否充分考虑接口使用者需求。接口定义是否清晰，通用以及粒度适中原则。2. 不可打断：接口调用是不可被打断的，如果调用失败则数据不会被修改，要么成功要么失败。3. 组合接口:是指某个接口的数据来源于其它多个接口的数据进行拼装的结果 ,这时接口要么返回其它接口都正常返回进行拼装的数据,要么返回接口异常。原则上，对于服务系统，其接口应该是完成单独的某个功能，
8、应该提供原子级（不可再拆分）的接口，某个复杂的功能，可拆分成几个不同的接口调用来系统架构规范Page: 9/26 机密 版权所有完成。对于原子级的接口，出错回滚处理也会比较简单。对于原子级别接口的定义,应当基于对数据操作的不可打断为原则,例如:用户下单,需要扣减库存生成订单两个数据操作步骤,正确定义:提供创建订单接口 ,在创建订单接口里进行库存扣减,错误定义:创建订单接口+库存扣减接口3.2可组合性1. 基于接口的原子粒度，根据不同的业务需要，灵活调整接口的拼装调用，完成业务需求的快速实现。2. 定义接口时，要区分服务系统和业务系统或是业务服务组合的系统，服务系统完成服务的提供，业务系统完成
9、业务的封装和转发调用。3. 组合性的接口原则上只用于数据的读取进行组合,当接口存在写操作时,则不建议用组合接口的方式完成事务工作。具体参考 3.3可读性1. 所有系统提供的接口文档，应该是统一、规范的、格式一致的。2. 接口文档的定义，可读，可理解。在接口中，完整的定义好上传报文和返回报文的相关字段、报文头、报文格式的规范。3. 接口字段中的数据字典要明晰，每个字段代表的意义要明确，每个标准数据对应的值，要明确，或标明在哪里可以查询（附录或其他）。4. 不同的服务系统，应有统一的接口命名规则，可根据服务模块直接查找响应接口功能及要求，并可在代码内简单查找。5. 接口还应该明示接口是否会对数据进行读或写的操作。3.4兼容性1. 接口的调用如果产生异常，或接口参数非法等情况时，接口是否做到充
