业务中台目标

  • 目标：

    • 整体目标：高内聚、低耦合，便于开发和维护。
    • 五个方向：性能、可用性、扩展性、伸缩性、安全性。

  • 原因：

    • 单体架构的大泥球会导致业务迭代困难、无法针对性伸缩、故障没有隔离等问题，需要向微服务方向演进。
    • 演进过程中为了复用、抽象，需要沉淀中台能力。
    • 业务中台不仅仅需要关注功能性需求，更需要关注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. 交易中台会定义一套三方下单的接口，并公开在开平文档中，供应商提供url和key接入。

伸缩性

分割

  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. 交易中台下单前过风控拦截，下单后、支付前后通知风控分析用户行为。