业务中台的架构案例_销售系统的业务架构

业务中台目标

• 目标：
  • 整体目标：高内聚、低耦合，便于开发和维护。
  • 五个方向：性能、可用性、扩展性、伸缩性、安全性。
• 原因：
  • 单体架构的大泥球会导致业务迭代困难、无法针对性伸缩、故障没有隔离等问题，需要向微服务方向演进。
  • 演进过程中为了复用、抽象，需要沉淀中台能力。
  • 业务中台不仅仅需要关注功能性需求，更需要关注5个方向的非功能性需求，才能高效稳健的支持业务的发展，否则极容易演化成分布式单体。
• 实现方式：
  • 战略上：
    • 横向分层：分散关注、松散耦合。
      • 应用层：提供具体业务的API和视图，和用户直接交互。
      • 服务层：提供业务编排和业务原子能力。
      • 数据层：提供存储服务，如数据库、缓存、搜索引擎、文件。
    • 纵向分割：通常按照不同业务划分，专人做专事、不同等级保障。
    • 分布式部署：包括服务应用、静态资源、数据存储、计算、配置、锁、文件的分布式。由于通常需要避免单点，需要在C和A之间权衡。
  • 战术上（几种方式可能组合使用）：
    • 集群。负载均衡和失效转移提供并发特效和可用性。
    • 缓存。在数据热点不均匀、数据有一定有效期的情况下使用。
    • 异步。堆积消息避开故障时刻提高可用性、减少rt、削峰。
    • 冗余。包括集群备份、冷热备份、灾备数据中心。
    • 自动化。发布过程、代码管理、安全监测、监控、失效转移恢复、降级、分配资源都可以自动化。
    • 安全措施。密码、验证码、加密、过滤、风控等。
    • …
      

详细理论内容可参考：大型网站架构

具体案例

结合电商商品中台、交易中台、春晚红包的工作经历梳理使用场景

性能

缓存

1. 分布式缓存。主流的redis的3种集群，是电商商品中心各种场景的缓存主力。
   1. 主从redis。client 路由。
      1. 一致性hash路由。商品主库上的缓存，用于商详等商品单查。已经成功支持过200+ redis实例，抗500w+ qps。
      2. 多副本路由。上一条的二级缓存，存放热点数据，防止单redis和主库单分片被打挂。50个 redis实例可抗100w+ qps。
   2. codis。proxy路由。用于C端列表大流量的批量查询，通常多集群部署。单集群256主从server+100proxy可抗近千万qps，并且可以通过节点的方式最多支持到3000w qps。、
   3. redis cluster。前两者的替代品，扩容更加方便。集群规模受限，建议最多200 server和2T内存，可以通过多集群分片的方式扩展集群的规模。
2. 本地缓存。主流Caffeine，用于列表场景大内存（56G）实例抗突发热点，保护分布式缓存。
3. 线程缓存。ThreadLocal，用于aop带出上下文，如商品B端编辑在aop中校验商品状态，并把商品数据带到业务逻辑中修改，减少查库的次数。

异步

1. 消息队列。
   1. 消息中间件。春晚红包抢红包实时链路db只记录中奖流水，后续发奖通过kafka异步。抢红包需要支持600w tps，下游发奖等无法支持，并且异步也可以减少用户等待时间能再次摇奖。
   2. 事件驱动。用户下单后的预约流程需要商家接单，接单等待时间较长。实现为用户申请落库后直接放回，后续通知商家流程通过可靠领域事件驱动，商家接单之后回调。
2. rpc异步。商品列表聚合素材、标签等数据使用异步dubbo，并行调用减少列表渲染时间。
3. 线程池。商品列表的缓存回写通过线程池异步，减少为命中缓存时用户请求等待的时间。

集群

1. 服务层k8s实例的集群化。商品列表场景单机房上千实例可抗300w+ qps，并在10ms内返回。单机压力大会导致cpu飙升的长尾。
2. 缓存的集群化。商品列表的缓存集群抗300w+ qps的批量查询流量，并保证rt在1ms左右。
3. 持久化存储的集群化。
   1. mysql。
      1. 商品256库256表，可以支持百万qps的查询，日常流量下商详场景的redis雪崩，也可以基本支持业务。
      2. 春晚预热的全局预算累计拆分到32个库，可支持几十万的写入。
   2. hbase。商品列表缓存下的持久化存储，支持百万qps的查询。

代码优化

1. 多线程。春晚红包下单回滚库存、限购等资源时并行回滚，减少用户等待时间。
2. 资源复用。下单页对大ab参数的解析只做一次，后续都使用解析后的对象。解析大json有可能占用机器将近一半的cpu耗时。
3. GC调优。
   1. 更换gc方式。商品敏感数据服务由于需要使用本地缓存，gc压力大，上游50ms经常超时。使用zgc，通过损失一定cpu获得1-2ms的gc时间，极大的降低了上游的超时率。
   2. 调整其他gc参数。

存储优化

1. 存储选型。商品操作日志这种写多读少的场景，使用hbase这种追加式的存储，做到毫秒级写入。
2. 索引调优。
   1. 添加索引减少每次扫描的数据行数，从而降低响应时间。
      1. 商品的sku包含删除和未删除的sku，热门商品修改频繁，删除的sku较多，导致每次可能需要查到上万sku，但实际生效的只有几十上百个。添加商品Id+SKU状态的索引解决这一问题。
   2. 添加查询条件引导优化器走扫描数据量少的索引。
      1. 春晚红包的索引优化。

可用性

分布式场景判断是否可用的一般方式：超时

集群

1. 服务层的无状态化k8s集群。可负载均衡+重试做到失效转移。
   1. dubbo调用支持配置retry属性，也可二次开发健康度lb，从而使得请求最终落到下游的正常实例上。
2. 存储层的数据备份。可失效转移。
   1. 单主写入
      1. 同步备份。mysql同步复制
      2. 异步备份。mysql异步复制，redis主从复制
      3. 半同步备份。商品库采用mysql半同步复制，主备同步复制，主从异步复制，主到灾备异步复制，是C和A的折中。
   2. 无主写入。
      1. 商品中心的缓存采用单机房三集群，同步时串行写入，异常时跨集群降权重试。

多活

1. 同城双活，异地、跨云多活。
   1. 商品中心、交易中心等核心服务均部署两个以上的机房，同时提供服务，并且定期做切流量演练。

风险识别

1. 热点流量。
   1. 业务识别。热点商品通过定时任务拉秒杀服务获取，并刷到多副本缓存中，用于商品详情页和下单，避免数据库被打崩。
   2. 系统识别。
      1. 商品列表使用caffeine本地缓存，通过tiny-lfu识别热点并缓存到本地，保护分布式缓存。
      2. 商品详情、下单服务使用改造之后的sentinel，发现db访问热点，并刷到多副本缓存。

分级

1. 高优先级的服务占用更好的硬件资源，部署在不同的宿主机上，甚至异地容灾。
   1. 商品服务独立宿主机，和其他服务隔离，并做多机房部署和异地灾备。
2. 高优先级的场景和其他场景隔离，避免被影响。
   1. 商品详情的缓存使用独立的redis集群，和其他缓存独立。
   2. 电商核心的盈利部门广告从单独的商品集群查询商品。

异步

1. 方式同上一节中的mq,dubbo。
   1. 下单流程生成交易快照使用mq+异步dubbo双通道，不影响核心的下单链路。

限流

1. 保证有效流量不超过自身的处理能力。分为集群限流和单机限流。几种限流算法。
   1. 集群限流。用存储如redis计数，适合流量小、精度高的场景，如1w qps左右。
   2. 单机限流。本地内存限流，适用于流量大精度不高的场景。
      1. 商品服务均使用单机限流 。dubbo在filter中用sentinel的滑动窗口，每个窗口默认0.5s。

熔断

1. 抛弃下游请求。下单页服务对下游的所有依赖如果超过50%，会被mesh层熔断。

降级

1. 强依赖降级：
   • 无损降级。如读容灾存储。
     1. 交易支付流程如果查询账号服务失败，则从容灾的redis中获取账户信息。账号信息每次查询账号服务后更新，由于账户变更不频繁，读容灾存储基本等于无损降级。
   • 有损降级。如异步补偿写。
     1. 交易下单流程中如果限购服务异常，可以降级成读历史订单后补偿扣限购，而不是同步扣限购。可能造成超卖。
2. 弱依赖降级：可以失败
   • 缩短超时时间。交易下单页对于历史留资等若依赖超时时间设置成200ms而不是框架默认的1s
   • 支持丢弃请求。以上的留资服务可以手动降级，不去请求。

重试

1. 需要注意：
   1. 下游保证幂等。
   2. 重试的错误类型。网络超时可以重试，业务异常需要具体问题具体分析，有些异常重试没有意义。
      1. 某分布式事务组件的思路是一阶段提交，二阶段无限重试，但是二阶段调下游的入参有问题被拦截，无限重试卡住。
   3. 重试次数限制。过多的重试会造成读或写扩散，打挂下游。

规范流程

1. 版本管理。分布式服务场景下，分支开发、主干发布。
   1. 大多数互联网公司的做法，开发分支本地调试，测试分支发布到测试环境，主干分支发布到生产环境
   2. 测试分支可以建设泳道，减少需求之间的影响，但是也可能遗漏多个需求同时修改触发的bug
2. 自动化发布、自动化测试。
   1. 整个公司使用发布平台发布，减少人工操作失误的概率。
3. 预发布、灰度发布。
   1. 公司所有上线必须走预发验证，之后滚动发布。

监控告警

1. 监控+告警人工介入。如cat可以监控应用并通过电话消息等多种方式触达开发人员，及时介入线上故障。

扩展性

领域建模

1. 通过DDD战略层面拆分各个业务域
   1. 交易中台拆分成商品、营销、交易、履约、结算5个业务域，大多数需求可以闭环在各个业务域内。
2. DDD战术层面搭建微服务。
   1. 使用六边形框架搭建微服务。
      1. 交易中台的服务使用DDD构建，切下游模型、接口变更时只需要对rpc适配层进行少量代码改动，无须修改领域层。
   2. 领域模型的通用性，必要时可分离为业务子域或者基础设施子域。
      1. 商品中心的商品扩展属性通过k-v形式存储，shema通过groovy脚本校验，可以做到不发版迭代业务。已经迭代过数十个需求。
      2. 商品详情装修组件也设计为通用的组件+schema+数据的形式，支持业务动态配置详情页。
      3. 商品消息通过配置化每个业务可以单独订阅感兴趣的组合，如只关心商品和SKU的消息。
      4. 通用的能力，如商品黑名单、商品店铺协议、商品操作日志、计数能力单独抽业务子域，其他业务可以复用。

微服务

1. 通过微服务分解业务模块。是DDD的技术实现。
2. 微服务之间可以通过多种方式交互
   1. 同步的rpc、http调用。
   2. 异步的消息中间件、异步rpc。
3. 微服务之间的交互协议也是可扩展的
   1. json, hessian，thrift等序列化方式
   2. hbase等nosql存储

扩展点

1. 开放平台。注重对外部开发者的扩展性。
   1. 交易中台会定义一套三方下单的接口，并公开在开平文档中，saas根据供应商提供client_key路由到指定的url
2. 中台扩展点。交易中台通过在编排层流程节点定义接口，业务侧实现接口的方式，将业务定制逻辑剥离。

伸缩性

分割

1. 水平方向：按照业务处理流程分离，比如API层、编排层、原子能力层、中间件层、存储层。
   1. 交易中台的服务层无状态，可以快速扩容。有状态的存储层相对伸缩性较差。
2. 垂直方向：
   1. 按照业务模块分离。
      1. 交易中台新建设预约能力，和正向、履约独立，不用再对现有流程进行修改。
      2. 商品中心的库存服务单独拆分，和商品数据动静分离。商品可以往大流量支持场景，使用缓存伸缩，库存往小流量写场景堆存储伸缩。
   2. 按照数据冷热程度分离。
      1. 商品库会hive表捞删除1年的商品，通过kafka推给业务删除商品库的相关数据并存储到hbase中，hbase提供只读能力。

集群

1. 服务层的无状态化k8s集群。可扩容支持大促流量，负载均衡业务无感知。
   1. 双11等大促时，商品中台需要两倍以上的k8s实例做压测和保障，可扩容并依赖dubbo的负载均衡支持业务。
2. 有状态的存储集群可以扩容，并通过2种方法识别到数据在哪个分片上。
   1. 元数据服务器。
      1. 商品中心使用hbase，依赖meta节点获取rowkey的分布，扩容无须业务感知。
      2. redis cluster的槽迁移，依赖槽的路有扩容同样无须业务感知
   2. 路由算法。商品中心客户端路由缓存使用一致性hash，扩容通过平台配置，业务无须修改代码

安全性

校验

1. 字符串强校验。不拼接字符串作为sql入参
   1. 下单流程对手机号会进行正则校验，防止sql注入。

加密

1. 单向hash加密（MD5、SHA），对称加密（DES、RC），非对称加密（RSA）等。
   1. 订单的用户信息属于用户隐私，需要通过AES加密之后存储在DB，防止泄漏。

风控

1. 规则引擎+统计模型识别黑产。
   1. 交易中台下单前过风控拦截，下单后、支付前后通知风控分析用户行为。