开发者学堂课程【场景实践-阿里云微服务产品在斯凯奇全渠道业务中台的最佳实践：斯凯奇全渠道业务中台最佳实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/978/detail/14899
斯凯奇全渠道业务中台最佳实践
内容介绍：
一、项目背景
二、架构设计
三、MSE 云原生网关大促航保障
四、案例分享
一、项目背景
1.斯凯奇云原生网关案例
客户简介:斯凯奇（SKECHERS)1992年诞生于美国加州，如今已遍布全球170多个国家地区。在美国是仅次于耐克的第二大鞋类品牌。2020年11月斯凯奇宣布与阿里云达成合作，加速数字化升级。引入阿里云中台后，进一步推动全渠道优化，提升运营效率和供应链管理能力。
客户需求:斯凯奇的全渠道业务中台通过统一接入网关提供API接口供外部调用。由于斯凯奇业务场景丰富且系统众多，近年来由于业务高速发展，双11大促等活动的流量高峰对当前系统的性能和稳定性提出更多的挑战。而外部渠道、内部老系统、第三方服务需要与业务中台互通或者由中台提供能力，由于接入系统形态各异，急需丰富的安全认证手段并进行统一管理。新一代云原生网关可以提供微服务实例自动发现、路由转发、金丝雀发布及细粒度可观测等能力，极大影响服务开放的开发效率和运维成本。
关联产品:MSE，EDAS，MQ，ARMS，ACK，AHAS，DRDS
针对斯凯奇的需求，目前，我们在整个技术选型阶段，包括像网关的选型，中间件的选型。
在中间件的选型方面，有一系列的云产品清单；在网关方面，有Spring cloud Gateway，也可以选择注网关，也可以选择自建、开元和商业化的网关。因为斯凯奇的体量比较大，最终选择使用商业化的网关，商业化网关初步选择是阿里的几个产品，一个是微服务网关，它是MSE旗下的云原生网关，是号称阿里的下一代网关。另外是API网关，对于斯凯奇的业务体量来说，目前初步是将各个系统打通，提供统一的接入和认证鉴权。经过调研，决定使用MSE云产品（云原生网关），云原生网关已经商业化，策略是开元、自研和商业化，它使用公共云，支持集团上云，并且以开元为内核做内部扩展，以商业化为基础做内部定制；后端是Bus化，开箱即用；客户端是轻量化、serveless化。它也是无侵入式，Java Agent云产品，通过无侵入式，Java Agent云产品实现了限流降级、故障注入、线路追踪、微服务治理，包括多注册中心等；也可以实现无损下线、离群实例摘除等功能。
相比于其他网关，云原生网关是集成了认证登录系统，利用JWT认证功能和黑白名单，让业务快速构建安全屏障。
解决方案：
①斯凯奇选用阿里云MSE云原生网关作为业务中台的统一接入层，直接打通了已有的微服务注册中心，直连后端服务，快速实现微服务之间的互通互访和统一管理。通过多种路由规则实现的灰度发布，能轻松满足大促前业务快速迭代上线的需求;
②相比Spring Cloud Gateway等微服务网关，MSE云原生网关性能更好，同时其负载均衡、流量控制能力可增强后端服务的可用性，确保中台系统顺利应对双11流量洪峰;
③云原生网关集成了认证登录系统，利用JWT认证功能和黑白名单，让业务快速构建安全屏障;
④云原生网关提供了丰富的可观测数据，包括流量全局看板、日志检索、业务TOP榜、延迟/失败率/错误码等多种响应指标等，并辅以报警管理，使运维人员对服务的整体状态及异常情况尽在掌握，减轻大促期间的工作负担。
上云价值:MSE云原生网关给斯凯奇提供了统一的微服务路由、流控、安全管理等能力，方便内外部多系统间的集成，极大提高了中台服务开放的开发效率，并降低运维成本，支撑斯凯奇双11业绩超12亿的交易系统。
目前来看，系统使用是比较稳定的。下面我们详细讲述一下斯凯奇全渠道业务中台的架构设计。
二、架构设计
1.应用架构图
斯凯奇以前的系统全都是在ADC机房，通过对中台的建设就规划成了混合云的架构，比如目前新建的业务中台是all in 阿里云的，也是整个云原生的最佳实践，里面应用了多达四十几项云产品。下面讲述一下目前的架构：
斯凯奇的全渠道接入，是通过全渠道接入网关，包括一些前台的应用，比如云pos客户端、O2O Portal、全渠道的运营平台都是通过网关接入的。
在全渠道接入方面，像淘宝，天猫是在聚石塔里，也是通过全渠道接入网关，目前已经推进了MSE的注册中心、云原生网关，还有中间件产品，比如ARMS，已经都接入了聚石塔，可以极大地提高聚石塔的稳定性，现在在和聚石塔交谈如何推进聚石塔更加稳定。同时还要接入斯凯奇现有的内部的一些系统，比如OA、DRP等系统，当然还有一些第三方的系统，比如物流系统、仓库管理系统。
整个底层是中间件，比如 EDAS、DRDS、MQ、ARMS、K8S、AHAS 等产品；整个基座由 ECS、RDS、SLB、VPC、SLS、OSS 等组成。目前，整个应用是依赖于阿里云的，通过整个阿里云提供服务和能力。
2.技术架构图
原来的框架是基于Dubbo的开发框架，所以业务中台里面也用到了Dubbo、Zookeeper，但是也要对外提供服务，所以也会用到MSE、Nacos网关，中间件引用了DRDS、MQ。为了减轻数据库的压力，用到了Redis，整个商品订单是放在 ElasticSearch 上的，像ES的同步，一些业务库里的 Polar DB、RDS 是通过 DTS 将数据同步，整个系统的DevOps 使用的 GTS 统一工作台；整个配置中心目前用的是阿波罗和 nacos。
3. 斯凯奇整体架构设计
整体分三类，一类是业务中台本身涵盖建设的，例如小程序，pos，客户端等等这些终端和平台，是通过外部网关进入的。
第二类是斯凯奇现有的旧系统，例如DRP、WING等等，通过MSE内网地址接入。
第三类是第三方开发托管的应用系统，比如物流、运输这些系统，它们的一些数据、状态会回执中台，所以，目前是通过外网网关进入的，并给它们颁发了appkey、appsecret，包括签名等一些配置来访问中台的系统。
目前整体架构是这样的，后续会将API分级来进行一些安全管理。
4. 微服务架构设计
整体框架是基于 Dubbo，内部服务的调用是通过RPC、zookeeper访问调用。服务之间，给外部调用的，比如web、app、pos系统调用的话，提供http接口能力是通过locas将服务注册、路由转发发现的。
整个认证鉴权使用的体系是JWT；整个MS云原生网关是集成了AHAS，是可以做限流熔断、可以控制每个api的QPS，在整个微服务中心的划分上主要有订单、促销、库存、商品中心等。整个服务之间的调用是通过RPC调用。
通过Redis可以做整个服务的管理，包括一键扩缩容、监控，并且现在它有专业版，集成了arms的能力，包括了全链路追踪的能力。整个应用都是部署在docker里面的，整个中台都接入了全链路监控，包括日志服务和安全，整个系统入口都是从 Web 进来做一层防护。
5. 会员中心技术架构
如果前端要调用会员信息的话，会通过 CDN 进入到 WAF，之后到内网SLB，通过云原生网关入口到达中台，MSE 云原生网关将流量网关和业务网关合二为一了，然后云原生网关会将请求转发到后台的服务，后台服务会统一通过接口适配层到外部的第三方系统，第三方系统给的回执访问需要通过网关进入，然后一些数据的缓存会存到 redis里，以上就是整个会员中心的架构。
大家可以看到以上基本上是基于云原生的产品去实现整个架构设计，除了一些代码。
