电商系统-数据中台

数据中台

数据中台多为大数据相关架构体系，大促期间，同样可能面临大批数据洪峰，比如订单量激增、用户行为数据暴涨等场景。简单看一下可能需要做的一些应对。（大屏实时计算）

数据通道

对数据传输通道扩容，比如kafka扩大分区数，rabbitmq增加细分队列。一方面实现了扩容，另一方面在传输的起始阶段就对数据做了一定的分类。

数据降级，关闭某些非核心数据的通道采集，让位网络带宽给核心业务数据。

数据展示

数据大屏开发。对实时性有一定要求，多采用流式运算。

其他准备

流量预估

对关键业务的体量做好预估。如用户的注册、下单量、首页，商品详情页等关键页面的qps，为压测提供参考指标。

资源预估

架构师统计各中心服务关系，对各个服务扩容做预估，汇总。

压测准备

1）线下压测

当前成熟系统都具备各种环境，开发环境、测试环境、准生产环境等，对线下可以选择准生产环境做为压测，模拟线上。

线下压测数据安全，不必担心对线上造成干扰。所压测的值可以用于相对性比较，比如其中全链路的某个环境哪个是瓶颈。但是无法精准反馈线上的真实场景。

2）线上压测（谨慎！）

重点看线上压测，线上压测压出的数据是最真实有效的。但是因为使用的是生产环境，操作不当可能引
发灾难性后果。

1）在全链路压测环境下，服务调用关系错综复杂，最重要的是实现压测流量的标识，以及标识在服务上下文间如何有效传递不丢失。服务内借助threadlocal，但是要注意多线程下失效。服务间通过改写远程调用框架或借助框架提供的Context设置。（分布式日志平台，访问链路追踪）

2）数据隔离，数据库可以创建影子表，redis等缓存可以设置shadow_等前缀，从开发框架层面封装处理，对数据层持久化框架做二次开发，使其自动发现压测数据。

3）外部服务可以借助服务降级功能，添加开关判断属于压测流量时开关进入降级或mock，比如收银程序添加挡板，直接返回成功，短信应用直接默认一个短信号码。

4）日志打印需要隔离，可以借助分布式日志平台收集时采用不同的输出通道和队列。

5）压测数据最好的方式是流量克隆（TCPCopy工具等），将线上的实际访问请求克隆放大几倍加压到压测入口，如果实现不了，尽量模拟线上的真实数据结构和体量。

6）做好全压流量规划，按预估2~3倍加压，确定流量比例，打压。

人员配备

人员互备，防止故障，及时响应。