随着企业用户逐渐增多,面对不同场景下不同需求和技术问题,CloudWeGo 团队将会持续分享不同企业的落地实践,包含不同行业面临的技术问题、选型参考和最终落地性能和使用分享,来帮助更多用户开始使用 CloudWeGo。
近些年电商行业高速发展,森马电商线上业务激增,面临着高并发、高性能的业务场景需求。森马正式成为 CloudWeGo 的企业用户,通过使用 Kitex 接入 Istio,极大地提高了对高并发需求的处理能力。
本文将从四个方面为大家讲解 Kitex 在森马电商场景下的落地实践:
- 森马电商订单流转中心——天枢所面临的业务挑战;
- 项目的技术选型过程;
- 项目上线性能压测对比;
- 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 中怎么部署我们的客户端或者服务端呢?有以下两种方式:
- 为命名空间开启自动注入:kubectl label namespace default istio-injection=enabled。注入之后会产生两个重要的容器,第一个是 Istio-proxy,负责流量拦截和流量代理,比如做流量转发;第二个是 Server-douyin,是负责开发的应用容器。
- 把 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 团队企业技术支持。
打开飞书,扫描左侧二维码填写企业支持问卷,扫描右侧二维码可加入飞书交流群。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。