原创

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

业务架构设计规范

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 业务子网

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

正文到此结束
该篇文章的评论功能已被站长关闭