系统架构规范百度版本修订稿.docx

系统架构规范百度版本修订稿.docx

《系统架构规范百度版本修订稿.docx》由会员分享，可在线阅读，更多相关《系统架构规范百度版本修订稿.docx（16页珍藏版）》请在冰豆网上搜索。

系统架构规范XX版本修订稿

集团标准化工作小组[Q8QX9QT-X8QQB8Q8-NQ8QJ8-M8QMN]

系统架构规范XX版本

系统架构规范说明

2016年9月

文档信息

文档编号：

文档名称：

系统架构规范说明

文档类别：

规范类

密级：

普通

版本信息：

V0.5

建立日期：

2016-08-29

创建人：

审核者：

[审核人姓名]

批准人：

[批准人姓名]

批准日期：

[批准日期]

项目/客户：

内部用

日期：

存放位置：

编辑软件：

发行软件：

文档状态：

[√]草稿；[]正式发布；[]正在修改

文档修订记录|OutstandingIssues

V0.1

A

说明：

版本编号栏中填入版本编号或者更改记录编号。

变化状态分为三种状态：

A——增加；M——修改；D——删除。

在简要说明栏中填写变更的内容和变更的范围。

表中所有日期格式为：

YYYY-MM-DD。

文档审批信息

说明：

表中所有日期格式为：

YYYY-MM-DD。

[系统架构规范—正文]

1前言

本系统架构规范仅适用于中型系统和大型系统，对此类项目，一般需要较多人员的参与，如不在开发进行之前定义好一些规范、原则，很容易在开发中产生各种各样的问题，如功能切分不合理、服务拆分粒度不足、数据冗余、性能受影响等各式各样的问题。

在构建此类系统前，我们要进行统一的系统层级的设计，来尽量避免文中这些问题的出现。

对于影响不大、重要性不大或存活时间不久的项目，可以采用更为灵活的方式进行自行开发，以免过多人力投入产生浪费。

2技术选型

应以满足系统的需求为出发,考虑选择某个技术对整个系统生命周期的影响:

1.需求层面的影响

是否能够满足当前或未来的业务需求,在整个系统生命周期中,应该优先满足目前业务情况,再考虑未来不确定的业务需求。

2.系统设计层面的影响

系统设计时需要考虑技术特性对整个系统生命周期的适应性,稳定性,可替代性,可维护性,是否可以跨平台,以及开发难度的综合考量,避免系统依赖于某项专用技术,或者和某项技术耦合紧密,降低技术选型变更成本。

3.系统开发层面的影响

应当为开发人员提供技术相关使用文档,以及入门指南等技术资料,应以技术透明为原则做好技术封装工作,和应用规范,减轻开发人员使用该技术的难度,降低开发人员学习成本。

4.系统实施层面的影响

应当考虑所采用技术在实施安装部署的技术难度以及硬件的兼容性,稳定性,以及资源消耗问题。

并提供系统所采用技术安装部署操作文档。

5.技术实现难度的评估

评估所选技术实现的难点,算法,技术团队是否能够很好的掌握和使用,开发时间,以及是否会提高系统复杂程度。

6.技术的优缺点评估及同类技术之间差异评估

调研所选技术在行业内是否普遍认可和使用,社区维护情况,系统版本是否趋于成熟稳定的状态

7.技术是否开源以及是否成熟稳定

3接口以及协议

3.1原子性

接口原子性,包含三个层面的定义,一个是接口数据的粒度定义,一个是接口在进行写操作的不可打断原则,一个是组合接口的数据拼装的完整。

1.接口粒度：

定义的粒度是否合适，是否充分考虑接口使用者需求。

接口定义是否清晰，通用以及粒度适中原则。

2.不可打断：

接口调用是不可被打断的，如果调用失败则数据不会被修改，要么成功要么失败。

3.组合接口:

是指某个接口的数据来源于其它多个接口的数据进行拼装的结果,这时接口要么返回其它接口都正常返回进行拼装的数据,要么返回接口异常。

原则上，对于服务系统，其接口应该是完成单独的某个功能，应该提供原子级（不可再拆分）的接口，某个复杂的功能，可拆分成几个不同的接口调用来完成。

对于原子级的接口，出错回滚处理也会比较简单。

对于原子级别接口的定义,应当基于对数据操作的不可打断为原则,例如:

用户下单,需要扣减库存生成订单两个数据操作步骤,正确定义:

提供创建订单接口,在创建订单接口里进行库存扣减,错误定义:

创建订单接口+库存扣减接口

3.2可组合性

1.基于接口的原子粒度，根据不同的业务需要，灵活调整接口的拼装调用，完成业务需求的快速实现。

2.定义接口时，要区分服务系统和业务系统或是业务服务组合的系统，服务系统完成服务的提供，业务系统完成业务的封装和转发调用。

3.组合性的接口原则上只用于数据的读取进行组合,当接口存在写操作时,则不建议用组合接口的方式完成事务工作。

具体参考

3.3可读性

1.所有系统提供的接口文档，应该是统一、规范的、格式一致的。

2.接口文档的定义，可读，可理解。

在接口中，完整的定义好上传报文和返回报文的相关字段、报文头、报文格式的规范。

3.接口字段中的数据字典要明晰，每个字段代表的意义要明确，每个标准数据对应的值，要明确，或标明在哪里可以查询（附录或其他）。

4.不同的服务系统，应有统一的接口命名规则，可根据服务模块直接查找响应接口功能及要求，并可在代码内简单查找。

5.接口还应该明示接口是否会对数据进行读或写的操作。

3.4兼容性

1.接口的调用如果产生异常，或接口参数非法等情况时，接口是否做到充分的提示。

2.系统接口设计，要避免依赖于开发语言特性，应考虑兼容于其它开发语言为原则。

3.接口是否充分考虑了各种终端的接入，不同开发语言间的接入等

4.接口应当考虑不同开发语言对于数据类型的定义与区别,应当避免不同语言对数据类型的解析问题,例如:

java的doubble类型,在php里面是有区别的。

3.5独立性

每个接口都应该是独立可被调用的，不因依赖于其它接口被调用为前提才可以正常被调用。

接口的调用不依赖于会话状态的建立,接口调用者只需根据接口参数的定义,满足于接口调用的参数要求后既可正常调用接口返回相应数据。

3.6安全性

1.接口是否公开开放，如果开放是否充分考虑接口调用的合法性问题，如果接口被非法调用怎么处理。

2.接口调用者的合法性校验。

3.接口是否有做入参的合法性检查。

4.接口应当仅限于内部系统网络可以访问,并且具有安全性的检测机制防止接口异常调用的发生,非开放式接口不应暴露于公网环境

5.开放接口必须要做好接口鉴权工作,不允许任何一个接口绕过鉴权直接调用,以及做好沙箱隔离。

4数据

数据是系统的产出结果，数据的一致性、原子性、完整性、隔离性直接反映了系统架构设计是否合理以及是否严谨。

维护数据的一致性,原子性,完整性,隔离性需要系统在各个层面（数据库设计,系统架构设计,事务处理机制,编码规范）进行系统的设计规划以及对编码有严格的约束和要求,才能够很好的保证数据的四性要求。

在数据操作中,事务对于数据的四性原则起到关键作用,事务操作确保了数据的真实有效。

在系统中事务操作,不仅指数据库的事务还指业务逻辑的事务。

良好的系统架构理应对数据的四性,以及事务的粒度做到统一的平衡保证系统在高负荷情况下也不会崩溃以及数据出错。

4.1一致性

在系统设计时,跨系统之间的调用要考虑事务数据的一致性,要么A系统和B系统成功完成数据操作,要么A系统和B系统都回滚。

系统需要考虑异步处理时保障数据的一致性,不因系统的异步处理导致数据的不一致因而导致数据失真。

系统需要保障数据在系统于系统之间，模块于模块之间，同一时间数据是一致的。

跨系统间的数据要保障数据最终一致性。

数据的一致性也包括在跨系统或模块之间对同一数据的定义也应当是一致的,例如用户名称的数据类型以及长度或格式等在不同系统中对用户名称的数据类型是一致的,长度是一致的,数据格式也是一致的。

4.2原子性

数据的原子性是指,在系统中的业务处理逻辑被执行时导致的数据（创建、修改、删除、文件保存、删除、改名）变更,在整个事务中或许存在多次的数据操作,此时在进入某个数据操作时发生异常应当回滚之前完成的数据操作,以保障本事务要么全部数据修改完成要么全部不做修改。

这里的数据原子性区别于接口的原子性,接口的原子性还包含了接口粒度的原子性,即接口的粒度小到不能再拆分的。

4.3完整性

系统需要保障用户操作的数据是完整的,在数据库设计时应当考虑好表之间的数据约束关系。

代码层面主表与外表的数据操作应当在同一个事务里面完成,不可分割不可打断。

当某个表数据操作失败时,相应的其它表数据的修改也需要同时回滚。

尤其在跨系统间的数据操作,必须保证同一数据A系统存在,B系统对应存在,这设计到分布式事务的处理机制。

数据的完整性,不仅包含于数据库表之间的完整性,还包含于系统的业务逻辑中,假如上传一个商品,其中包含图片信息,商品信息,分别存放于文件服务器,以及多个商品表中,这时应当完整保存商品数据到对应的商品表中以及文件服务器中,如果其中一个表或一个文件保存异常,应当全部回滚保障数据的完整性。

数据的完整性,还包含于单个表内的数据完整,假如用户录入信息必须包含时间,如果用户没有填写时间则也不应当保存数据。

这除了数据库范式进行约束,在代码层面也应当进行约束,以保障数据的完整性。

4.4持久性

数据修改后，对系统的影响是永久性的，即使系统停机或故障也不会丢失修改后的数据。

数据的持久性不仅限于数据是否正常保存到数据库当中,还包括数据保存介质的可靠,以及保存的数据是否有冗余备份,在数据存储环节出现故障或其它不可遇见的风险时,如何保障数据长久的安全和不丢失。

持久性的另一层意思,是在系统经过持续的更新升级后,老的数据,是否还可以被系统使用的,可读的,可追查的,以及可以被转化再利用的。

当系统出现故障时或硬件出现故障时能保证系统及时恢复故障前的数据。

4.5隔离性

系统与系统间或模块与模块之间对同一数据的操作需要遵循一定原则，避免事务死锁的情况发生，保障系统和模块间的事务操作是隔离的，不会导致A，B，C三个数据之间互相等待对方锁的情况发生。

假如三个事务同时需要对三个数据A，B，C进行操作，这应当遵循优先操作A数据的事务肯定也会优先操作B数据和C数据。

数据的隔离性需要在系统设计和编码阶段尤其需要考虑的工作。

事务的隔离直接影响到系统的稳定性以及系统的可用性。

严重情况会导致整个系统崩溃无法运行和导致数据出错。

以下举例错误的事务隔离和正确的事务隔离例子

错误的事务隔离:

X事务与Y事务需要同时对A,B数据进行操作,此时X事务的操作顺序是BA而Y事务的操作顺序是AB,在极端情况下X事务在锁定B数据后等待A数据的锁释放,而同时Y事务才锁定A数据后等待B数据释放锁,进而X事务与Y事务循环等待对方释放锁导致数据的死锁问题。

正确的事务隔离:

X事务与Y事务需要同时对A,B数据进行操作,此时X事务的操作顺序是AB而Y事务的操作顺序也是AB,在极端情况下X事务在锁定A数据后,此时由于Y事务也优先操作A数据只能等待X事务完成后Y事务再继续操作,进而避免了事务之间循环等待对方事务释放所的可能。

数据的隔离也既事务的隔离,在分布式系统在多个事务对同一数据的操作应当遵循先启动事务者先锁定数据的原则,进行事务操作。

4.6可移植性

在大型的分布式系统中,不可避免的存在不同系统使用不同的数据库以及数据库版本的不一致问题,虽然可移植性不是系统架构的必须要求,但基于数据的可移植性考虑，在数据定义时应当避免使用数据库特性来定义数据属性，数据的定义应当兼容于不同数据