设计规范(业务,应用,技术)
业务架构设计规范
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 业务子网
Ø 以业务域划分:基本服务和数据库,相同业务域的服务器部署在一起;不同业务域的服务器物理隔离