随着企业用户逐渐增多，面对不同场景下的需求和技术问题，CloudWeGo 团队将会持续分享不同企业的落地实践，包含不同行业面临的技术问题、选型参考和最终落地性能和使用分享，来帮助更多用户使用 CloudWeGo 。

近些年电商行业高速发展，森马电商线上业务激增，面临着高并发、高性能的业务场景需求。森马正式成为 CloudWeGo 的企业用户，通过使用 Kitex 接入 Istio，极大地提高了对高并发需求的处理能力。以下内容来自森马开发工程师梁东坡的分享。

1. 森马电商订单流转中心 —— 天枢

业务增长

森马订单流转中心 —— 天枢的主要功能是对接各大电商平台，把订单、商品、退单等信息统一处理后流转到下游系统，是下游系统和平台对接的中间枢纽。目前森马电商在运营的电商平台几十家，如：天猫、抖店、京东、拼多多等，由于每个平台的接口和对接的方式不统一，我们专门开发了这套系统，去统一对接电商平台，然后把数据处理成统一的格式发到下游系统，如：OMS 和 WMS。该系统在电商活动，如 6.18，双十一等订单峰值流量下发挥了重要作用。

从 2015 至 2021 年，森马的双十一业务量增长非常迅速。2015 年双十一的业绩有 3 亿 +，而去年的双十一业绩为 20 亿 +，2021 年商品交易总额（GMV） 更是突破百亿。随着业务的增长，对订单系统的性能和稳定性要求越来越高。而且随着系统的规模增长，集群内的 Pod 数量和 Service 不断增加，对系统底层架构有很大的考验。目前从旧系统迁移的平台有：有赞、抖音、拼多多、快手等，集群内的 Pod 数已经超过 200 个，后续接入京东、唯品会、天猫等平台后，Pod 数会成倍的增长，更需要一个成熟的系统架构作为支撑。

面临问题

随着直播行业的兴起，我们请了一些网红主播和流量明星来直播带货。直播期间，订单量经常会出现几秒内突然爆发的情况，订单推送到系统后，如果系统处理较慢，订单就不能及时流入下游系统，下游系统的 OMS 不知道已经产生如此大的订单量，就会出现不能同步的情况，即超卖现象。在电商行业，超卖是很严重的问题，如果用户下单后不能及时发货，不仅需要大量的人力去跟客户解释道歉，也要以优惠券等形式赔偿用户遭受的损失，甚至会接到大量投诉，严重影响我们在电商平台的信誉，电商平台也会对我们进行处罚。我们经历过当 GMV 超过千万时，订单系统延迟超过半个小时的情况，对我们造成了极大的影响。

因此，当遇到如双十一，6.18 大促等活动时，特别是在直播时订单量短时间内暴增的情况下，森马原有的系统架构已经无法支撑，不能及时处理订单数据。这影响了我们发货及库存同步，间接地产生了不同类型的资损。

技术挑战

技术挑战主要有以下三个方面：

• **高并发：**在电商业务场景下，不管是面向用户，比如秒杀，还是面向业务，比如订单处理，如果实现不了高并发，系统就很难做大，很难适应业务的增长。
• **高性能：**除了用高并发来实现业务的快速处理外，性能也是一个挑战。例如在当前疫情状态下，各行各业都在降本增效，解决不了性能问题，就会不断地增加服务器资源，大大增加企业成本。
• **技术保障：**电商行业公司，大多资源和精力都在销售端，运营端，技术方面投入相对薄弱。因此在技术选型上需要从可靠、安全、支持等维度去考量。

2. 项目技术选型

如何选择

在开发语言的选择方面，开发语言没有好坏之分，只有这个语言在相关场景下合适不合适的问题。我们从性能、多线程、编译、效率等方面综合考虑，选择了 Golang。

在微服务框架的选择方面，团队分别用 Google 开源的 gRPC 和字节跳动开源的 CloudWeGo-Kitex 做了技术评估和性能压测。经过专业测试同学的压力测试，最终选择了 CloudWeGo-Kitex 作为我们的微服务框架。

选择 Kitex 的原因主要有两点：一是 Kitex 背后有强大的技术团队提供及时有效的技术支持；二是经过压力测试，Kitex 的性能优于其他微服务框架。