java100003字,带你解密双11618电商大促场景下的系统架构体系个人文章

起于2009年,刚开始的双十一还并不出名,电商开展促销月都是以各自的店庆月作为基础的。国美在线是4月份,京东6月份,易购8月份,而淘宝商城选择了双十一作为促销月。促销的初衷是光棍节(11月11日)大家没事干,就该买点啥东西去当礼物送人。于是乎,双11就这样诞生了。

了解双11背景下电商公司的应对措施,有助于提升高访问量背景下的系统架构知识。

从组织架构到技术架构,当前各大电商系统基本趋于中台化。中台在2015由阿里提出,其实是一种企业架构而不是单纯的技术层面,目前几乎各大电商都进行着中台化的建设。

中台没有什么神秘的,说到底,中台就是对”共享“理念系统化的归纳和总结。

即大中台,小前台的前台,电商中直面用户的B2B,B2C等各个业务线。

业务中台基于公共服务的沉淀,需要收敛一些基础的业务服务,如商品、订单、会员、库存、财务、结算等等。

数据中台不是一个平台,也不是一个系统。数据仓库、数据平台和数据中台是有区别的。简单的举例:数据平台可以理解为数据库,数据仓库类比为报表,而数据中台更贴近上层业务,带着业务属性。

与业务无关的基础沉淀,中间件,系统框架,监控,日志,集成部署等等

(根据项目情况有所偏重,例如分布式与一致性是一对矛盾)

该小节从中台的各个团队角度,介绍双11期间的一些应对措施和遇到的问题。

(异步化的目的是什么?大家使用过的mq?遇到的问题?)

场景:

大促期间新增许多需要获取订单状态的服务,比如应对双11而临时增加的数据中台订单大屏展示等

解决:

异步化,并对消息队列调优,多队列分流

问题:

注意异步化引发的乱序问题,一是传输阶段,二是消费阶段

局部有序与绝对有序

图解:

rabbitmq传输:队列级别顺序保障,单消费者消费一个队列可以严格保障顺序性,需要扩充队列数提升性能

kafka传输:分区级别顺序保障,只能保障投放和传输阶段的顺序性

消费阶段:1对1消费存在性能问题,接收消息后对key做二次分发,放入多个内存队列,开启多线程消费

(场景及思考,如果让你做架构设计有什么方案?这些方案有什么优缺点)

双11抢单是最常见的场景,抢单不支付会占据大批量资源,如商品库存。如何取消过期订单是架构师必须面对的问题。主要有以下几种方案:

扫表实现

原理:

通过定时任务轮询扫描订单表,超时的批量修改状态

优点:

缺点:

java延迟队列实现

优点:

消息队列实现

缺点:

redis实现

被动取消

支付交互流程,支付系统设计偏重,关于做过的那些支付系统2014与2018的架构变化,政策的变动经历。

(2018重复支付事故)

原因:

在第一步发起的时候,用户进入支付方式选择页。选第一个支付方式并支付完后因为通知延迟,以为支付失败。在支付又选了第二种,再次支付。

应对方案:

程序屏蔽,前端js触发按钮置灰或者遮罩提示(支付成功?遇到问题?),或者在支付方式选择页直接跳转。

后端处理,发现不同通道下的支付成功回调,抛消息队列或记录日志。

数据修复:

首先查支付日志,确认针对同一笔订单收到了不同支付渠道的回调。

其次,在支付平台管理后端可以查到入账记录,人工介入。

最后对账阶段会发现对方多帐,我方补单时出现重复订单。

问题处理:

调取退款接口或者在支付渠道的管理后台操作退款(一定要多次确认无误)。

支付但未开单

用户明明支付成功,但未开通订单

问题分析:

一般支付渠道会间隔性多次回调开单链接,如果支付未开单,银行未回调的可能性比较小,着重排查开单接口是否可用。如果可用追查日志是否出现异常记录。

应对措施:

未支付但已开单

用户未支付,或者财务中心未收到这笔款项,订单状态已开通。这种就问题比较严重了

首先排除人为操作因素。其次排查系统是否存在漏洞或者级联开单的情况(支付中心测试环境数据回调造成线上意外开单经历)

用户是期望支付完成的同时立马看到结果。但是中间多层远程的调用,可能发生订单状态更新延迟问题。

主动查询。在用户查看订单的时候,如果是类似“支付中”的中间态时,触发远程订单状态查询接口。(大家看到的点击“支付完成”跳转的过程,触发远程支付结果查询)

(你所看到的收银台图标内情...)

背景:

保障支付可用性及支付分流,支付中心对接多家渠道

方案:

大促和活动不分家,一般营销中心所面对的主要是促销策略、优惠方式等业务上的架构问题。

从促销活动的范围来看,分为单品促销活动、套装促销活动、店铺促销活动,平台促销活动。

从促销类型来看,分为满减、折扣、赠品等。

业务复杂度高,一般遵循“同类营销仅可选其一,不同类营销可叠加”的规则。同类叠加意义不大且会造成系统复杂度上升,引发用户困惑。

用户体验上的设计,比如购物车里商品的排序,按商铺分门别类。优惠总价格及时调整。这些依赖于前端的ui设计和交互体验。

(SPU,SKU基础概念,如何设计表结构?京东怎么做的)

赠品有两种设计方案,一种是不做单独的SKU,只有一个空的描述,设计简单,缺点是没有商品详情页,无法给用户直观的查看和估值。

另一种是单独做SKU,赠品也会作为一个商品存在,与主商品关联,下单的时候将会自动加到商品列表,价格降为0。这种更为常见。整个商品有完善的详情页,用户可以直接看到价格甚至单独下单购买。

检查同类别促销,将最大优惠力度的规则应用到订单,并且满足排他性,同类只享受其一。比如满10减3,满20减5,那么用户购买大于20时,只减5即可。

不同类别不做排斥,如购物车整体满减后,不影响单个商品的折扣。在记录数据时,优惠要细化到每个单独的订单明细上。退款也做到明细级别的单独退。

(有没有遇到精度问题?价格字段如何设计?)

满减或平台券等优惠,在多个商品下单时,涉及到金额的分摊。即优惠总额度/购物车总额,得到比例后再按比例均分到每个商品。只有分摊才能在发生部分退款时退回真实金额。

但是这会涉及到一个精度问题。举例如下:满99减9活动,假设用户购买了30+40+50=120,3件商品应付111元。按比例折算的话,9/99取4位小数是0.9090,那么分摊后为30x0.9090+40x0.9090+50x0.9090=109.08与实际支付金额出现偏差。这会造成财务无法平账。

解决方案:记账时在订单明细记录,将误差111-109.08=1.92计入金额最大的明细,也就是50元商品上。那么最终记账为:30x0.9090+40x0.9090+(50*0.909+1.92)=111

退单后要同时恢复用户的权益,比如优惠券的再次使用,限购次数等。确保用户体验。

这个和超时订单设计方案类似,前面已经提到不再赘述。

普通商品可以直接借助数据库锁实现,一般分乐观锁和悲观锁两种方案,如果采用悲观锁(如select语句带forupdate),会带来很大的性能阻塞,所以更多的采用乐观锁设计。(幂等性课题的锁机制有详细讲解)

乐观锁就是在最后执行库存扣减操作时,将事务开始前获取的库存数量带入到SQL语句中作为更新的where条件,如果数量相等,则该条更新库存的语句成功执行返回update条数为1;如果不相等,则表示该商品的库存信息已经被其他事务修改,需要放弃该条update的执行,采用重试处理。

库存秒杀商品因为大批量的访问在一瞬间涌入,数据库扛不住。可以采用redis缓存做decr处理,正常下单后,再使用mq异步更新到db。(秒杀不超卖课题的库存控制)

数据库层的调优,一般发生在大促前的预备阶段,一旦大促开始,对数据库的优化已经来不及了。

(业务篇红包雨课题里有缓存结构的深度应用)

热点数据预热:

(常规加载机制画图展示)

常规缓存设计趋向于懒加载,大促期间的热点数据尽量做到预热加载。比如某个促销专题,不要等待活动开始的一瞬间再读库加缓存,搞不好引发击穿。

细粒度设计:

(细粒度缓存结构画图展示)

集合与单体分开存储,缓存结构细粒度化。如某个橱窗的推荐商品列表,常规存储一个key,value为整个商品集合。优化为列表与每个商品详细信息设置两个独立缓存值,在查询环节组装,可以降低发生修改时对缓存的冲击。新增一个推荐则失效列表,修改商品则仅仅失效当前商品缓存。

可用性:

(回顾三种缓存问题)

优化缓存体系,对关键业务请求,如商品详情页,采用多级缓存处理

首先看浏览器缓存,一般浏览器缓存可分为两种手段,分别交给浏览器和服务端执行

nginx缓存:nginx除了作为负载均衡,也可以作为请求级别的缓存,一段典型配置如下:

proxy_cache_path缓存文件路径

levels设置缓存文件目录层次;levels=2:2:2表示三级目录,每级用2位16进制数命名

keys_zone设置缓存名字和共享内存大小

(算法与数据结构应用-限流算法有详细实现)

CDN的引入本身起到了按ip分流的作用,但是我们可以在下层做到更细粒度化的控制。根据业务情况将不同的请求分流到各自的服务器。

限流不同与分流,是对下层的保护,当系统超过一定流量后,超过的流量做直接拒绝处理,以便保护后端的服务,原则就是要么不进来,进来的都正常服务。常见的限流算法有三种:计数器(滑动窗口)、漏桶、令牌桶。

根据不同的业务线分发请求,配备二级域名如b2b.xxx.com,b2c.xxx.com,或者在nginx软负载层针对不同虚拟主机名做upstream分发

新上的双11活动页,或者促销专题页面,采用新访问入口和机器部署,与主站分离。活动结束后也利于机器资源的快速释放(有没有遇到临时性需求的场景?上线就用1天)

按不同的请求终端分流,在header头的user-agent中可以捕获用户的访问终端。android,ios,pc,根据不同终端设备,做流量分发,到不同的应用机器。同时方便对用户终端流量的监控和统计。

评估双11可能的流量,结合具体业务模块,配备对应限流措施。主要有流量限制和连接数限制两个维度。

#$binary_remote_addr同上limit_conn_zone$binary_remote_addrzone=addr:10m;server{location/b2b/{#限制每个ip下最大只能有一个连接limit_connaddr1;}}4)网关限流从代理服务器放进来的流量,会进入应用服务器,第一道关卡是微服务的网关。应对大促,针对各个微服务具体业务具体分析,配备对应限流措施。zuul和gateway是团队中最常遇到的网关组件。

比如平时客户来我的店铺购买衣服。平时可以试穿,给出建议,帮助搭配,最后下单支付,送用户祝福卡片等。双11大促则简单粗暴响应下单支付收钱发货。其他不太重要的服务关闭开关,腾出资源让位主交易流程。

服务降级可以从前端页面,后端微服务两个点着手。

很好理解,针对页面元素处理,将不重要的操作入口置灰或屏蔽。平时调用后端接口实时呈现数据的地方替换为静态页也可以理解为一种降级操作。

快速熔断可以认为是在应对突发情况时,对服务请求结果准确性的一种妥协。避免因单一服务垮台导致整个调用链路崩溃。常用手段如下:

大促前做好安全防范。常见的DDos,Arp,脚本等攻击平时也会存在,日常防范已经配备。大促期间需要注意的可能更多的是业务层面的入侵,比如抢购或秒杀时的恶意刷接口。

(2018从一次断电看灾备的背景与经历,30分钟以内)

2)数据库配置两地主从,或双主单写。切换前做好数据同步性检查

3)启用脚本,切换代理服务器,代理流量转入灾备机房,正式环境还需要处理dns指向

4)分布式文件灾备日常采用rsync等实时同步,采用云存储的可以忽略

5)es索引等其他数据确保日常同步

6)注意挂好维护页,友好提示

7)配备自动化测试脚本以便快速验证切换结果

包括物理机、Docker容器、以及对交换机、IP进行监控(容器课题)

借助zabbix等开源软件对机器资源配置监控,如果采用云化部署,各大云供应商都会配备完善的监控机制

主动监控,日志或消息队列形式打点输出,定时汇报(日志平台追踪课题)

被动监控,添加监控接口,监控系统定时请求确认可用性

主动监控依然无法察觉的情况下,来自客服的一线反馈成为最后关卡。优先级也最高。开发故障快速响应平台,做到实时性保障。做到客服-业务线-产品-技术排查的及时响应,快速排查。

网络带宽是影响访问流量的重要因素,做好各个机房网络带宽预估,数据在两地机房间传输并且要求低延迟的场景,如数据库主从,可以考虑机房专线。使用公有云的服务,可以购买临时流量。

对容量做预估和硬件资源盘点。配合大促期间不同服务的架构设计,以及项目本身的特性,对cpu,内存做评估。偏运算的项目,重度使用多线程的项目偏cpu,需要大量对象或集合处理的项目偏内存。

所有项目容器化部署,基于镜像即版本理念,打好各个服务的镜像是docker快速复制扩容的基础。大促前对各个中心微服务做统计和盘点。

借助swarm和k8s等编排工具,快速实现容器的伸缩。(运维篇会讲到)

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

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

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

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

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

(全链路压测课题)

(大家当前使用的环境都有哪些?上线模式是什么样的)

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

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

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

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

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

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

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

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

5)做好全压流量规划,按预估2~3倍加压,确定流量比例,打压。

人员互备,防止故障,及时响应,应对双11不是什么神秘事。

THE END
1.快速资讯:短信测压在线使用介绍短信测压免费短信测压使用介绍 短信测压,是一种通过模拟大量短信发送请求,对目标手机或短信服务平台进行压力测试的技术手段。它主要用于检测目标系统在高并发短信流量冲击下的性能表现、稳定性以及https://www.jianshu.com/p/dda87f4476c0
2.短信测压短信测压平台是一款特别好用的手机性能测试软件,大家可以在这里体验非常优质的辅助工具,只需要输入你的手机号码就可以在这里进行模拟短信的发送,帮助大家节省了很多的时间,随时可以在这里检测自己的手机反应速度,不断的提升大家的性能,在接收到短信的时候会更加顺畅。 软件简介 1.帮助大家进行电话号码测试,能够管理好你https://www.zxiyun.com/12750.html
3.手机短信软件app有哪些免费手机短信软件app下载安装QQ这些软件出现前,大家最常用的联系方式除了电话就是发短信,很多的小伙伴都有开过短信包月,今天小编给大家推荐几款好用的手机短信软件,这类app是非常强大的短信管理软件,能够完全的替代大家手机上的短信功能,支持用户发送短信、批量处理短信等,还有各种炫酷的界面特效,支持气泡对话框等各种装饰,感兴趣的用户欢迎下载哦http://www.downcc.com/k/sjdx/
4.MQTT调试器app下载MQTT调试器下载安装失败或使用异常,请 -> 一键举报猜你喜欢 打印 打印软件排行榜 工作学习中会有不少文件需要打印,而我们如果不想去打印店的话就需要通过蓝牙、WiFi等方式连接打印机进行打印,或者是在自助打印机上打印,而打印app就能方便我们手机操控打印机进行打印。那么手机打印软件哪个好呢?小编悉心整理了手机打印https://m.liqucn.com/rj/9109966966090.wml
5.免费短信压力测试工具灵动短信压力是一款免费的短信压,目前支持安卓平台力测试工具,目前软件接口接近9000接口,不过好多都是失效了,能用,效果不是很强,一通操作下来十来条短信,感兴趣的同学可以试试,软件全部权限拒绝也可正常使用,工具仅供娱乐测试使用,勿用做其他用途哈。 灵动短信压力界面 https://blog.yjscloud.com/archives/387
6.Barometer气压计App下载攻略,轻松掌握天气变化,探索v1.7新版本全在如今这个信息化的时代0>,我们对于天气的了解变得越来越重要0>,而barometer气压计App作为一款能够实时监测气压变化0>,预测天气情况的应用0>,受到了广大用户的喜爱0>,本文将为大家详细介绍barometer气压计App的免费下载方法0>,以及v1.7版本的新功能与使用攻略,(。https://m.learningtime.com.cn/bjhgonglue/12737.html
7.TestAndroidCVjava源码下载平台在Android手机测试TFLite、MNN和Paddle Lite的图像分类和目标检测性能点赞(0) 踩踩(0) 反馈 访问所需:1 积分 电信网络下载 访问申明(访问视为同意此申明) 1.在网站平台的任何操作视为已阅读和同意网站底部的版权及免责申明 2.部分网络用户分享TXT文件内容为网盘地址有可能会失效(此类多为视频教程,如发生失效https://java.code.coder100.com/index/index/content/id/64375
8.在线短信压测,惩戒骗子必备在线短信压测,惩戒骗子必备 在线地址:https://www.ceya001.cn/https://www.xc6b.com/qqjs/11440.html
9.短信在线压测平台关于短信在线压测平台 使用F5和Cisco等厂商推出的DDoS解决方案。, DDoS攻击(Distributed Denial of Service)是一种通过同时从多个位置对目标服务器发送高数量的数据包,导致服务器负载过重而无法处理合法用户请求的方式。攻击者使用一个或多个“僵尸网络”(botnet)通过互联网发送大量的请求到特定的目标服务,使其网络出现https://mukrb.lfjmmj.cn/
10.java短信压测平台在线短信压测试java短信压测平台 在线短信压测试 压测时间:正式上线两个月 测试环境:正式环境 测试条件:测试时间选在平台使用时间段较少的时候,通过观察数据库一段时间内数据的增长情况确定在周六的晚上。 数据量:目前数据库有51个部门、62个管理员、短信发送总量约4.5W条,单个用户最大发送量已达2W条数据。前提:用户体验反馈查询https://blog.51cto.com/u_16213686/9350585
11.速云短信测压4.0.6破解版/短信电话测压程序员阿鑫速云短信测压4.0.6破解版_短信电话测压 此版说明 去除收费,去除软件暗桩 使用必看 这个软件暗桩较多(有锁机暗桩,写入文件暗桩,无限弹Dos窗口暗桩等),尽管打开软件,管理员运行破解补丁,把十字箭头拖到辅助上,点击破解,随便输入卡密登入 文件下载: 立即下载 》许可协议授权。 版权声明:未标注转载均为本站原创,转https://www.cxyax.com/?post=743
12.短信轰炸机网页版在线短信轰炸机免费短信云呼轰炸机欢迎来到电话测压在线平台,这是一个集电话测压app、电话测压源码、电话测压api、电话测压下载于一体的前沿在线平台,为用户提供基于电话测压的全面解决方案和分析, 特色电话轰炸, 电话测压2022, 电话压测平台, 电话压测网页, 电话压测1.0, 电话压测网站, 艾皇电话测压, 电https://www.brightbikerebel.com/
13.在线短信测压平台腾讯云开发者社区他们的API简单易用,可以用于发送和接收短信。Nexmo也提供了一些测试工具和文档来帮助你进行短信测压。 Plivo: Plivo是一个全球性的通信平台,提供短信、语音和电话服务。他们的API功能强大,可以用于发送和接收短信。Plivo也提供了一些测试工具和文档来帮助你进行短信测压。 相关搜索: 在线压测 在线压测工具 在线短信测https://cloud.tencent.com/developer/information/%E5%9C%A8%E7%BA%BF%E7%9F%AD%E4%BF%A1%E6%B5%8B%E5%8E%8B%E5%B9%B3%E5%8F%B0-ask
14.阿里云服务器测试阿里云测试报告综合来看,在压测中,示例中的浏览产品A的API和登录的API,会同时发起压测流量。更多性能测试PTS场景示例,可参考阿里云帮助资料: 性能测试 PTS最佳实践 阿里云短信测试专用是哪里的短信 阿里云服务器里面的短信。阿里云短信测试专用短信是阿里云服务器里面的短信。短信服务是阿里云为用户提供的一种通信服务的能力,分为国内短信http://chengdu.cdxwcx.cn/article/ddojgog.html
15.短信压力测试v3.0app手机版下载扫描二维码下载 应用介绍 短信压力测试v3.0是一款可以随时检测手机性能的工具软件,用户可以通过这个平台快速的进行手机性能检测,会通过短信发送的方式查看短信的接收速度,会统计每个用户的短信接收量,检测方式是非常简单的,只需要在平台输入相应的手机号码,就可以快速的发送一些短信。 《短信压力测试v3.0》软件优势: 1.https://www.juxia.com/sjwy/ruanjian-574948.html
16.中国人寿业务稳定性保障:“1+1+N”落地生产全链路压测针对以上问题,中国人寿寿险研发中心在稳定性保障上做了较多落地实践,在稳定性测试层面,整体思路是在能力层建设 4 种能力——无侵入在线压测能力、混沌工程故障演练能力、自动化测试能力、数字化测试管理能力,来实现保稳定、提质效、优效能的目标。 而其中,保证生产部门稳定是重中之重,无侵入在线压测作为赋能生产部门最https://xie.infoq.cn/article/5c3970161430badd9e3718b9a
17.在线短信压力测试多接口dxhz黎明岛在线短信压力测试 dxhz,一个在线短信压力测试,多接口,是一位用户在评论区留的,应该是店家,于是拿着买了个日卡测试了一下,效果不算差,我挑了一个效果比较好的,测试了10分钟,不仅有短信,而且有些还是电话的验证码,工具仅供娱乐测试使用哈,勿做其他范围的事情哈。 https://d.limingdao.com/71
18.短连接微博短链接短网址url生成接口短连接微博短链接HTTP短连接:9000 QPS HTTP 长连接:11000 QPS HTTPS短连接(不复用 session):1500 QPS HTTPS短连接(复用 session):4000 QPS HTTPS 长连接:9000 QPS 压测环境 本次压测所使用的机器配置信息如下:ECS 类型:ecs.sn2ne.2xlarge 短链管理 概述Quick Audience提供长链转换短链的能力,减少短信计费字数,支持将文本短https://help.aliyun.com/wordpower/2577226-1.html
19.短信压力测试webbench压力测试华为云为你分享云计算行业信息,包含产品介绍、用户指南、开发指南、最佳实践和常见问题等文档,方便快速查找定位问题与能力成长,并提供相关资料和解决方案。本页面关键词:短信压力测试。https://www.huaweicloud.com/theme/487053-4-D
20.新一代垃圾回收器ZGC的探索与实践案例二:压测时,流量逐渐增大到一定程度后,出现性能毛刺 日志信息:平均1秒GC一次,两次GC之间几乎没有间隔性能风险:功能如果没有问题,性能是否稳定,能稳定的在线上运行。 经过分类后,每类风险的应对转化成了常见从两个源OpenJDK和OracleJDK下载JDK 11,二个版本的JDK主要区别是长时期的免费和付费,短期内都免费。https://www.528045.com/article/d10c0b06b3.html
21.python性能测试手机号验证码登录压测示例详解python压测脚本: threadmark用来标记任务的,我在模块方法里面返回了token,表示唯一用户登录接口请求操作,方便开发追踪日志。 /** * 100个用户通过发短信然后通过验证码登录 */ class LoginByTel extends OkayBase { public static void main(String[] args) { https://m.jb51.net/article/256314.htm
22.短信群发推广群发国际短信号码空号检测压测优化服务 技术专家根据实际生产环境的现状对系统的性能测试、综合分析,找出性能瓶颈,提出调优解决方案。 了解详情 迁移服务 云上基础设施迁云实施 ;在线业务存储迁云实施 ;在线业务数据库迁云实施 ; 跨平台迁移 ;应用系统整体迁云实施 了解详情 应急响应与排查服务 https://market.juncdt.com/home/