关于开源:Kitex-在森马电商场景的落地实践

随着企业用户逐步增多，面对不同场景下不同需要和技术问题，CloudWeGo 团队将会继续分享不同企业的落地实际，蕴含不同行业面临的技术问题、选型参考和最终落地性能和应用分享，来帮忙更多用户开始应用 CloudWeGo。

近些年电商行业高速倒退，森马电商线上业务激增，面临着高并发、高性能的业务场景需要。森马正式成为 CloudWeGo 的企业用户，通过应用 Kitex 接入 Istio，极大地提高了对高并发需要的解决能力。

本文将从四个方面为大家解说 Kitex 在森马电商场景下的落地实际：

1. 森马电商订单流转核心——天枢所面临的业务挑战；
2. 我的项目的技术选型过程；
3. 我的项目上线性能压测比照；
4. CloudWeGo 团队的技术支持。

以下内容来自森马开发工程师 梁东坡 的分享。

01 森马电商订单流转核心——天枢

业务增长

第一局部给大家介绍订单流转核心——天枢。天枢的次要性能是对接各大电商平台，把订单、商品、退单等信息对立解决后流转到上游零碎，是上游零碎和平台对接的两头枢纽。目前森马电商在经营的电商平台几十家，如：天猫、抖店、京东、拼多多等，因为每个平台的接口和对接的形式不对立，咱们专门开发了这套零碎，去对立对接电商平台，而后把数据处理成对立的格局发到上游零碎，如：OMS 和 WMS。该零碎在电商流动，如 6·18，双十一等订单峰值流量下施展了重要作用。

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

面临的问题

随着直播行业的衰亡，咱们请了一些网红主播和流量明星来直播带货。直播期间，订单量常常会呈现几秒内忽然暴发的状况，订单推送到零碎后，如果零碎解决较慢，订单就不能及时流入上游零碎，上游零碎的 OMS 不晓得曾经产生如此大的订单量，就会呈现不能同步的状况，即超卖景象。在电商行业，超卖是很重大的问题，如果用户下单后不能及时发货，不仅须要大量的人力去跟客户解释赔罪，也要以优惠券等模式抵偿用户蒙受的损失，甚至会接到大量投诉，重大影响咱们在电商平台的信用，电商平台也会对咱们进行处罚。咱们经验过当 GMV 超过千万时，订单零碎提早超过半个小时的状况，对咱们造成了极大的影响。因而，当遇到如双十一，6·18 大促等流动时，特地是在直播时订单量短时间内暴增的状况下，咱们原有的零碎架构曾经无奈撑持，不能及时处理订单数据。这影响了咱们发货及库存同步，间接地产生了不同类型的资损。

技术挑战

咱们在技术上面临的挑战次要有以下三个方面：

• 高并发。在电商业务场景下，不论是面向用户，比方秒杀，还是面向业务，比方订单解决，如果实现不了高并发，零碎就很难做大，很难适应业务的增长。
• 高性能。除了用高并发来实现业务的疾速解决外，性能也是一个挑战。例如在以后疫情状态下，各行各业都在降本增效，解决不了性能问题，就会一直地减少服务器资源，大大增加企业老本。
• 技术保障。咱们电商行业的公司，大多资源和精力都在销售端，经营端，技术方面投入绝对单薄。因而在技术选型上须要从牢靠、平安、反对等维度去考量。

02 我的项目的技术选型

如何抉择

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

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

抉择 Kitex 的起因次要有两点。第一是 Kitex 背地有弱小的技术团队提供及时无效的技术支持。第二是通过压力测试，Kitex 的性能优于其余微服务框架。

对于微服务

应用微服务框架，肯定会波及到抉择第三方开源的服务注册核心，那么是抉择罕用的开源注册核心（Zookeeper、Eureka、Nacos、Consul 和 ETCD），还是间接抉择云原生的服务网格（Istio）？那么我从流量转发、服务注册和服务发现维度介绍一下微服务集群的两种模式。

第一种是 Kubernetes Native，Kubernetes 集群中的每个节点都部署了一个 Kube-proxy 组件，该组件与 Kubernetes API Server 进行通信，观测服务和节点中的变动，进行负载平衡的转发。这种开源注册核心默认应用 TCP 协定，因为 K8s 负载平衡不反对 RPC 协定（HTTP2），因此须要额定的第三方服务注册核心反对。

第二种是基于 Istio 的服务网格，它并不需要额定的注册核心组件反对。Istio 接管了 K8s 的网络，通过 Sidecar Proxy 的形式将 Kubernetes 中的流量管制从服务层中抽离进去，Istio 基于 Enovy 的 xDS 协定扩大了其管制立体，每个 Pod 中放入原有的 Kube-proxy 路由转发性能。Istio 具备了流量治理、策略管制、可察看性等特点，将“应用程序”与“网络”解耦，因而不须要额定应用第三方注册核心。

那么这两种服务注册与发现的流程是怎么的呢？下图中左侧就是罕用的服务注册核心应用流程。指标服务先把实例注册到服务注册核心，客户端从服务注册核心拿到指标实例的数据，依据负载平衡策略去抉择一个服务实例，实现整个申请。右侧是应用了基于 Istio 的服务网格。大略流程是 Client 拜访指标服务的时候，流量先进入 Service 的 Proxy，被 Proxy 拦挡，Proxy 会从服务发现（Pilot）拿到服务与服务实例的映射关系，同时会拿到负载平衡的策略，去抉择 Service 一个实例。总体来看，这两种流程大致相同，但实现形式有所差异，各有千秋。

天枢零碎根本架构

像抖音、快手、拼多多和有赞等这样成熟的平台在产生订单时，都会将订单以音讯推送的模式发送到服务网格中。咱们先后通过 Ingress Gateway 网格入口管理程序、VirtualService 把订单转发到网格的不同服务中，外部再通过不同服务之间进行调用。其中，Kitex 作为微服务的 RPC 框架，服务发现和服务注册均是基于云原生的服务网格 Istio。

Kitex 接入 Istio

那么 Kitex 接入 Istio 是怎么实现的呢？如下图所示，服务端注册服务之后，在创立客户端的时候，客户端的 Server-host 要写理论集群中的内网地址，例如：server-douyin.default.svc.cluster.local，如上文所说，不必再搭配第三方的服务注册核心。

因为 Kitex 应用 gRPC 协定，在创立客户端的时候需指定应用 gRPC 协定：

在 Istio 中怎么部署咱们的客户端或者服务端呢？有以下两种形式：

1. 为命名空间开启主动注入：kubectl label namespace default istio-injection=enabled。注入之后会产生两个重要的容器，第一个是 Istio-proxy，负责流量拦挡和流量代理，比方做流量转发；第二个是 Server-douyin，是负责开发的利用容器。

2. 把 Go 代码打包的镜像部署到集群中：

例如咱们创立了一个 Deployment，名为 Server-douyin，另外作为服务端须要创立相应的 Service。

压测比照

咱们将 Kitex 和 gRPC 在以下雷同服务器硬件资源和网络环境下进行了压测比照：

• 压测工具：JMeter；
• 阿里云 ECS（8 vCPU，16 GiB，5 台）；
• 集群：Kubernetes 1.20.11；
• 服务网格：Istio v1.10.5.39。

通过比照发现，在指定工夫雷同的状况下，Kitex 在单位工夫内解决订单数量更多。在指定订单数量的状况下，Kitex 对于解决雷同数量的订单所需工夫更短，且订单量越大，这种性能差异越显著。总体来看，Kitex 在解决少量订单时劣势还是十分突出的。

Kitex 产生性能劣势的起因

CloudWeGo 团队来森马做技术支持时讲到对自研网络库 Netpoll 做了一些性能优化，比方：

• 连贯利用率；
• 调度提早优化；
• 优化 I/O 调用；
• 序列化 / 反序列化优化；
• …….

更多材料能够查看 CloudWeGo 官网：https://www.cloudwego.io

或参考官网博客：https://www.cloudwego.io/zh/b…

CloudWeGo 团队的技术支持

咱们抉择 Kitex 之后，CloudWeGo 技术团队给予了足够的技术支持，包含现场反对和近程帮助。这也让咱们对应用 Kitex 有了信念，不论遇到什么样的技术难题，都会有弱小的技术团队来帮助解决。

03 后续布局

Thrift 和 Protobuf 如何抉择

咱们在我的项目初期抉择 gRPC 协定 Protobuf 是因为抉择了 Istio 服务网格，而抉择 Istio 服务网格次要是因为它有多流量转发和服务治理等性能，例如在电商场景下，不同平台的推送音讯都能够通过 VirtualService 转发到不同的服务，相当不便。然而目前每个 Pod 中放入原有的 Kube-proxy 路由转发性能，会减少响应提早。因为 Sidecar 拦挡流量时跳数更多，会耗费更多的资源。

而对于 Thrift，它是 Kitex 默认反对的协定，字节官网对它做了很多性能上的优化，如：应用 SIMD 优化 Thrift 编码，缩小函数调用，缩小内存操作等，还开源了高性能 Thrift 编解码器 Frugal，Frugal 具备 无需生成代码 、 高性能 （在多核场景下，Frugal 的性能能够达到传统编解码形式的 5 倍）和 稳定性 等特点，进一步晋升了性能和开发效率。

因而，咱们目前也在思考在下一次零碎版本的架构中改用 Thrift 协定。

服务、单干共赢

咱们开发的电商相干产品不仅能够为本人电商品牌所应用，产品成熟后还能够服务于其余类似的电商公司。因而咱们也心愿和 Kitex 官网有更深的技术单干，如电商云。

企业用户反对

欢送企业用户扫描二维码，填写企业反对问卷，并退出飞书交换群，获取 CloudWeGo 团队企业技术支持。

关上飞书，扫描左侧二维码填写 企业反对问卷 ，扫描右侧二维码可退出 飞书交换群。

我的项目地址

GitHub：https://github.com/cloudwego
官网：www.cloudwego.io