《系统架构规范方案_版本》由会员分享，可在线阅读，更多相关《系统架构规范方案_版本（32页珍藏版）》请在金锄头文库上搜索。
1、 范文范例参考系统架构规范说明2016年9月 完美Word格式整理版 范文范例参考文档信息文档编号：文档名称：系统架构规范说明文档类别：规范类密 级：普通版本信息：V0.5建立日期：2016-08-29创 建 人：审 核 者：审核人姓名批 准 人：批准人姓名批准日期：批准日期项目/客户：内部用日 期：存放位置：编辑软件：发行软件：文档状态：草稿； 正式发布； 正在修改文档修订记录 | Outstanding Issues版本编号变化状态简要说明修订日期变更人批准日期批准人V0.1A说明：版本编号栏中填入版本编号或者更改记录编号。变化状态分为三种状态：A增加；M修改；D删除。在简要说明栏中填写变
2、更的内容和变更的范围。表中所有日期格式为：YYYY-MM-DD。文档审批信息序号审批人角色审批日期签字说明：表中所有日期格式为：YYYY-MM-DD。目 录文档信息1文档修订记录 | Outstanding Issues2目 录3系统架构规范正文51 前言52 技术选型53 接口以及协议63.1 原子性63.2 可组合性63.3 可读性63.4 兼容性73.5 独立性73.6 安全性74 数据74.1 一致性74.2 原子性84.3 完整性84.4 持久性84.5 隔离性84.6 可移植性84.7 标准数据定义85 系统95.1 系统可靠性95.2 系统稳定性95.3 系统安全性95.4 系统
3、扩展性105.5 系统移植性105.6 系统独立性105.7 系统可监控性115.8 系统易维护性116 处理机制116.1 缓存使用机制116.2 日志处理机制116.3 异常处理机制116.4 权限控制机制126.5 事务处理机制126.6 回滚机制126.7 并发处理机制127 使用技术已经中间件127.1 标准化127.2 开放性127.3 稳定性127.4 可替代137.5 是否可满足需求13 系统架构规范正文1 前言本系统架构规范仅适用于中型系统和大型系统，对此类项目，一般需要较多人员的参与，如不在开发进行之前定义好一些规范、原则，很容易在开发中产生各种各样的问题，如功能切分不合理
4、、服务拆分粒度不足、数据冗余、性能受影响等各式各样的问题。在构建此类系统前，我们要进行统一的系统层级的设计，来尽量避免文中这些问题的出现。对于影响不大、重要性不大或存活时间不久的项目，可以采用更为灵活的方式进行自行开发，以免过多人力投入产生浪费。2 技术选型应以满足系统的需求为出发,考虑选择某个技术对整个系统生命周期的影响:1. 需求层面的影响是否能够满足当前或未来的业务需求,在整个系统生命周期中,应该优先满足目前业务情况,再考虑未来不确定的业务需求。2. 系统设计层面的影响系统设计时需要考虑技术特性对整个系统生命周期的适应性,稳定性,可替代性,可维护性,是否可以跨平台,以及开发难度的综合考量
5、,避免系统依赖于某项专用技术,或者和某项技术耦合紧密,降低技术选型变更成本。3. 系统开发层面的影响应当为开发人员提供技术相关使用文档,以及入门指南等技术资料,应以技术透明为原则做好技术封装工作,和应用规范,减轻开发人员使用该技术的难度,降低开发人员学习成本。4. 系统实施层面的影响应当考虑所采用技术在实施安装部署的技术难度以及硬件的兼容性,稳定性,以及资源消耗问题。并提供系统所采用技术安装部署操作文档。5. 技术实现难度的评估评估所选技术实现的难点,算法,技术团队是否能够很好的掌握和使用,开发时间,以及是否会提高系统复杂程度。6. 技术的优缺点评估及同类技术之间差异评估调研所选技术在行业内是
6、否普遍认可和使用,社区维护情况,系统版本是否趋于成熟稳定的状态7. 技术是否开源以及是否成熟稳定3 接口以及协议3.1 原子性接口原子性,包含三个层面的定义,一个是接口数据的粒度定义,一个是接口在进行写操作的不可打断原则,一个是组合接口的数据拼装的完整。1. 接口粒度：定义的粒度是否合适，是否充分考虑接口使用者需求。接口定义是否清晰，通用以及粒度适中原则。2. 不可打断：接口调用是不可被打断的，如果调用失败则数据不会被修改，要么成功要么失败。3. 组合接口:是指某个接口的数据来源于其它多个接口的数据进行拼装的结果,这时接口要么返回其它接口都正常返回进行拼装的数据,要么返回接口异常。原则上，对于
7、服务系统，其接口应该是完成单独的某个功能，应该提供原子级（不可再拆分）的接口，某个复杂的功能，可拆分成几个不同的接口调用来完成。对于原子级的接口，出错回滚处理也会比较简单。对于原子级别接口的定义,应当基于对数据操作的不可打断为原则,例如:用户下单,需要扣减库存生成订单两个数据操作步骤,正确定义:提供创建订单接口,在创建订单接口里进行库存扣减,错误定义:创建订单接口+库存扣减接口3.2 可组合性1. 基于接口的原子粒度，根据不同的业务需要，灵活调整接口的拼装调用，完成业务需求的快速实现。2. 定义接口时，要区分服务系统和业务系统或是业务服务组合的系统，服务系统完成服务的提供，业务系统完成业务的封
8、装和转发调用。3. 组合性的接口原则上只用于数据的读取进行组合,当接口存在写操作时,则不建议用组合接口的方式完成事务工作。具体参考3.3 可读性1. 所有系统提供的接口文档，应该是统一、规范的、格式一致的。2. 接口文档的定义，可读，可理解。在接口中，完整的定义好上传报文和返回报文的相关字段、报文头、报文格式的规范。3. 接口字段中的数据字典要明晰，每个字段代表的意义要明确，每个标准数据对应的值，要明确，或标明在哪里可以查询（附录或其他）。4. 不同的服务系统，应有统一的接口命名规则，可根据服务模块直接查找响应接口功能及要求，并可在代码内简单查找。5. 接口还应该明示接口是否会对数据进行读或写
9、的操作。3.4 兼容性1. 接口的调用如果产生异常，或接口参数非法等情况时，接口是否做到充分的提示。2. 系统接口设计，要避免依赖于开发语言特性，应考虑兼容于其它开发语言为原则。3. 接口是否充分考虑了各种终端的接入，不同开发语言间的接入等4. 接口应当考虑不同开发语言对于数据类型的定义与区别,应当避免不同语言对数据类型的解析问题,例如:java的doubble类型,在php里面是有区别的。3.5 独立性每个接口都应该是独立可被调用的，不因依赖于其它接口被调用为前提才可以正常被调用。接口的调用不依赖于会话状态的建立,接口调用者只需根据接口参数的定义,满足于接口调用的参数要求后既可正常调用接口返
10、回相应数据。3.6 安全性1. 接口是否公开开放，如果开放是否充分考虑接口调用的合法性问题，如果接口被非法调用怎么处理。2. 接口调用者的合法性校验。3. 接口是否有做入参的合法性检查。4. 接口应当仅限于内部系统网络可以访问,并且具有安全性的检测机制防止接口异常调用的发生,非开放式接口不应暴露于公网环境5. 开放接口必须要做好接口鉴权工作,不允许任何一个接口绕过鉴权直接调用,以及做好沙箱隔离。4 数据数据是系统的产出结果，数据的一致性、原子性、完整性、隔离性直接反映了系统架构设计是否合理以及是否严谨。维护数据的一致性,原子性,完整性,隔离性需要系统在各个层面(数据库设计,系统架构设计,事务处
11、理机制,编码规范)进行系统的设计规划以及对编码有严格的约束和要求,才能够很好的保证数据的四性要求。在数据操作中,事务对于数据的四性原则起到关键作用,事务操作确保了数据的真实有效。在系统中事务操作,不仅指数据库的事务还指业务逻辑的事务。良好的系统架构理应对数据的四性,以及事务的粒度做到统一的平衡保证系统在高负荷情况下也不会崩溃以及数据出错。4.1 一致性在系统设计时,跨系统之间的调用要考虑事务数据的一致性,要么A系统和B系统成功完成数据操作,要么A系统和B系统都回滚。系统需要考虑异步处理时保障数据的一致性,不因系统的异步处理导致数据的不一致因而导致数据失真。系统需要保障数据在系统于系统之间，模块
12、于模块之间，同一时间数据是一致的。跨系统间的数据要保障数据最终一致性。数据的一致性也包括在跨系统或模块之间对同一数据的定义也应当是一致的,例如用户名称的数据类型以及长度或格式等在不同系统中对用户名称的数据类型是一致的,长度是一致的,数据格式也是一致的。4.2 原子性数据的原子性是指,在系统中的业务处理逻辑被执行时导致的数据(创建、修改、删除、文件保存、删除、改名)变更,在整个事务中或许存在多次的数据操作,此时在进入某个数据操作时发生异常应当回滚之前完成的数据操作,以保障本事务要么全部数据修改完成要么全部不做修改。这里的数据原子性区别于接口的原子性,接口的原子性还包含了接口粒度的原子性,即接口的
13、粒度小到不能再拆分的。4.3 完整性系统需要保障用户操作的数据是完整的,在数据库设计时应当考虑好表之间的数据约束关系。代码层面主表与外表的数据操作应当在同一个事务里面完成,不可分割不可打断。当某个表数据操作失败时,相应的其它表数据的修改也需要同时回滚。尤其在跨系统间的数据操作,必须保证同一数据A系统存在,B系统对应存在,这设计到分布式事务的处理机制。数据的完整性,不仅包含于数据库表之间的完整性,还包含于系统的业务逻辑中,假如上传一个商品,其中包含图片信息,商品信息,分别存放于文件服务器,以及多个商品表中,这时应当完整保存商品数据到对应的商品表中以及文件服务器中,如果其中一个表或一个文件保存异常,应当全部回滚保障数据的完整性。数据的完整性,还包含于单个表内的数据完整,假如用户录入信息必须包含时间,如果用户没有填写时间则也不应当保存数据。这除了数据库范式进行约束,在代码层面也应当进行约束,以保障数据的完整性。4.4 持久性数据修改后，对系统的影响是永久性的，即使系统停机或故障也不会丢失修改后的数据。数据的持久性不仅限于数据是否正常保存到数据库当中,还包括数据保存介质的可靠,以及保存的数据是否有冗余备份,在数据存储环节出现故障或其它不可遇见的风险时,如何保障数据长久的安全和不丢失。持久性的另一层意思,是在系统经过持续的更新升级后,
