交易系统设计原则

• 高并发
  • 无状态（应用无状态，配置文件有状态。不同机房读取不同数据源，需要通过配置文件或配置中心指定）
  • 拆分
    • 系统维度：功能/业务拆分(商品系统，购物车，结算，订单)
    • 功能维度：
    • 读写维度
    • AOP维度
    • 模块维度
  • 服务化：进程内服务->单机远程服务->集群手动注册服务->自动注册和发现服务->服务的分组/隔离/路由->服务治理如限流/黑白名单
  • 消息队列：解耦一些不需要同步调用的服务或者订单一些自己关心的变化。实现服务解耦、异步处理、流量肖峰/缓冲等。注意处理消息失败及消息重复接收场景。以下场景需要进行防重处理
    • 大流量缓冲：牺牲强一致性，保证最终一致性。（redis扣减库存->记录扣减日志->同步worker->库存DB）
    • 数据校对
  • 数据异构
  • 缓存
    • 浏览器缓存：如expires,cache-control，对实时性要求不高的数据
    • APP客户端缓存：js/css/image提前下发到客户端缓存
    • CDN缓存：有些页面、图片放到离用户最近的CDN节点。一般有推送机制（当内容变更后推送到CDN边缘节点）和拉取机制（先访问边缘节点，当没有内容时，回源到源服务器拿到内容并存储到节点上）。使用CDN 时，URL中不能有随机数，不然会穿透CDN。
    • 接入层缓存
  • 并发化
• 高可用
  • 降级：对一个高可用系统，很重要的一个设计就是降级开关。有如下思路：
    • 开关集中化管理：通过推送机制把开关推送到各个应用。
    • 可降级的多级读服务：如服务降级为只读本地缓存，只读分布式缓存，只读默认降级数据（如库存默认有货）
    • 开关前置化：如架构nginx->tomcat,可将开关前置到nginx接入层，在nginx层做开关，请求流量回源后端应用或者只是一部分流量回源。
    • 业务降级：当高并发流量时，如电商系统保证用户正常下单，支付是核心要求，并保证数据最终一致性即可。这样就可以把同步调用改为异常调用，优先处理高优先级数据和特殊特征的数据，合理分配进入系统的流量。
  • 限流：原则是限制恶意穿透到后端薄弱层。目的是防止恶意请求流量，恶意攻击，或者防止流量超过系统峰值。可考虑如下思路：
    • 恶意请求流量只访问到cache
    • 对于穿透后端应用的流量可以使用nginx的limit模块处理
    • 对恶意IP可以使用nginx的deny限制访问
  • 切流量：如某个服务器挂了，需要切流量。有如下方式：
    • DNS：切换机房入口
    • HttpDNS：主要在APP场景下，在客户端分配好流量入口，绕过运营商localDNS，并实现更精准的流量调度。
    • lVS/HAProxy：切换故障的nginx接入层
    • nginx：切换故障的应用层
  • 可回滚：事务回滚、代码库回滚、部署版本回滚、数据版本回滚、静态资源版本回滚等

业务设计原则

• 防重设计：如结算页需要考虑重复提交，下单减库存时需要防止重复扣减库存。解决廊可以考虑防重key,防重表。有些场景如重复支付，是因为有的电商网站同时支持微信支付，支付宝支付，渠道不一样是无法防止重复支付的。但是，在系统设计时，需要将支付的每笔情况都记录下来。
• 幂等设计：消息中间件不保证不发生重复消息消费，第三方支付异步回调，也要做好回调的幂等处理。
• 流程可定义
• 状态与状态机
• 后台系统操作可反馈
• 后台系统审批化
• 文档和注释：设计架构、设计思想、数据字典/业务流程、现有问题文档，业务代码和特殊需求都要有注释。
• 备份：代码和人员备份。

转载请注明：MitNick » 01-亿级流量网站架构核心技术-交易系统设计原则