设计规范(业务，应用，技术)

业务架构设计规范

1 业务模块化

Ø 业务模块之间相互独立，如支付模块、权益模块，运营活动中心等。

Ø 基础业务下沉，可复用。如用户模块、商品类目等。

2 核心业务、非核心业务分离

Ø 系统核心业务与非核心业务分离，核心业务精简（利于稳定），非核心业务多样化。

核心业务如：用户登录注册服务，订单支付服务，权限查询服务等；

非核心业务如：运营活动配置，广告推送等；

3 区分主流程、附流程

Ø 区分哪些是系统主流程。运行时，优先保证主流程顺利完成，辅流程可以采用后台异步化的方式。避免主流程失败导致主流程的回滚。

4 隔离不同类型的业务

Ø 订单支付业务，需要确保高可用性，让用户能够快速下单；

Ø 非核心业务对可用性没有太高的要求，可以优先保证一致性；

Ø 秒杀业务对高并发要求很高，应该跟普通业务隔离。

应用架构设计规范

1 稳定性原则

Ø 一切以稳定为中心

Ø 架构尽可能简单、清晰

Ø 不过度设计

2 解耦/拆分

Ø 稳定部分与易变部分分离

Ø 核心业务与非核心业务分离

Ø 主流程与辅流程分离

Ø 应用与数据分离

Ø 服务与实现细节分离

3 抽象化

Ø 应用抽象化：应用只依赖服务抽象，不依赖服务实现细节、位置

Ø 数据库抽象化：应用只依赖逻辑数据库，不需要关心物理数据库的位置和分片

Ø 服务器抽象化：应用虚拟化部署，不需要关心实体机配置，动态调配资源

4 松耦合

Ø 跨域调用异步化：不同业务域之间尽量异步化解耦。

Ø 非核心业务尽量异步化：核心、非核心业务之间，尽量异步解耦

Ø 必须同步调用时，需要设置超时时间和任务队列长度

5 容错设计

Ø 服务治理：服务能彼此独立修改、部署、发布和管理。避免引发连锁反应

Ø 集群容错：应用系统集群，避免单点

Ø 多机房容灾：多机房部署，多活

技术架构设计原则

1 N+1原则

Ø 确保为故障多搭一套系统，避免单点问题。

Ø 功能开发与运维分开。系统开发完成后，交给专业的运维团队管理和运营。

2 D-I-D原则

Ø 设计20倍的容量（Design）

Ø 实现3倍的容量（Implement）

Ø 部署1.5倍的容量（Deploy）

3 支持灰度发布

Ø 系统新上线，要求支持“灰度发布，分步切流量，故障回滚”

4 虚拟化部署

Ø 虚拟部署：系统采用虚拟机部署，节省资源和管理成本

5 业务子网

Ø 以业务域划分：基本服务和数据库，相同业务域的服务器部署在一起；不同业务域的服务器物理隔离