苏宁数据中台基于Spring Cloud微服务架构实践

前言：从单体程序到微服务，再到当下流行的服务网格概念，Spring连接起了这两个时代，他曾是单体程序的代名词，但是在微服务时代他浴火重生，给我们带来了Spring Cloud。苏宁大数据中心，借助于Spring Cloud完成了微服务架构转型，实践中并不是一帆风顺，有思索、有迷茫，更有解决问题的乐趣。

1. 项目背景1.1 为什么是Spring Cloud？

苏宁数据中台后端传统开发架构， VIP负载均衡 + Nginx + SpringMVC，代码以单体程序为主。正常情况下一个项目使用统一域名，在苏宁现有开发架构下，统一域名导致，后端只能有一个war包，程序变成单体程序成为必然。下图所示，这是典型的旧式的项目代码目录， 项目名称-web：对外war包模块，项目名称-interface：统一定义接口，项目名称-service：统一定义接口实现，整个项目管理、开发思路，围绕单体程序开发模型设计，带来的弊端很明显

• 代码职责不清晰， 每个人都在同一模块下提交代码
• 违反高内聚低耦合
• 服务扩展不方便
  

• 首先微服务化思路，并不高大上，我们为什么选择微服务化，首要原因是管理问题，结合苏宁现有开发架构，整个微服务架构如图：域名解析 + VIP负载均衡 + Nginx + 服务网关 + 各个服务 。
  

下图是某一个项目采用微服务化后的工程代码目录：项目名称-模块1，项目名称-模块2。整个代码目录更清晰，利于模块拆分、人员职责安排

1.2 数据中台项目背景介绍

苏宁数据中台是一个大项目群：OLAP、百川、UDMS、天工、慧眼。

Olap是底层的加速、查询引擎，底层支持Druid、ES、PG Citus集群，类似Presto，跟Presto不同的是Olap会主动对数据进行Cube预加速。

百川是指标平台层，让用户建模、定义指标，对外提供指标查询服务， 百川主要支持的建模方式是：星型模型，数据建模自然离不开维表维度，Udms系统就是来定义、管理所有维度、维表，目前收录了整个集团近200多个维度， 对外提供维度、维表信息服务。

天工是类似Tableau、Superset的可视化报表设计平台，与这些BI软件最大的不同点，天工基于百川的指标、Udms的维度来制作报表，数据来源已经高度标准化、归一化，目前商业报告分析工具：cognos、阿里QuickBI等，是将数据建模、可视化设计能力放到一起，这是天工与他们的最大区别

慧眼，是统一报表门户，所有的报表统一发布到慧眼面向业务， 慧眼最大的挑战在于报表权限管控与自动匹配，，总共4000多张报表，用户2w多，一张报表开放给8000+人员是很常见的，所有这一切靠人工维护，既容易出错不利于数据安全，也不能及时响应用户需求，这些都是慧眼系统要解决的问题。

2. 服务框架选型2.1 Dubbo架构介绍

Dubbo主要有四个模块：Monitor（监控）、Regsitry（注册中心）、Provider（服务方）、Consumer(消费方)， Provider注册服务到Regsitry，Consumer向Regsitry订阅服务信息， Monitor服务监控服务调用情况，整个服务调用流程如下:

• 消费方在本地发起服务调用
• 动态代理将调用交给Loadbalance模块
• Loadbalance从Registry拿到服务实例信息
• 将请求发送到一台服务实例
• 记录监控日志等信
  

2.2 Spring Cloud架构介绍

Eureka（注册中心）、gateway（服务网关）、Provider（服务方）、Consumer(消费方)、Zipkin（监控），整个架构与dubbo非常类似，不同的有如下几点

• Spring cloud是Http Rest接口，Dubbo不是
• Spring cloud注册中心不使用Zookeeper，使用自研的Eureka，关于zookeeper是否适合做注册中心，请参考文章: 《Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery》、《阿里巴巴为什么不用 ZooKeeper 做服务发现》
• Spring Cloud提供了Gateway网关组件
• 与spring生态兼容，生态链丰富，自定义Filter、拦截器，来加强功能, 如：权限校验、日志打印等；Spring Cloud Netflix 提供了熔断、限流等组件。
  

综合以上几点，考虑到架构统一，未来发展趋势， 我们选择了Spring Cloud， Spring Cloud主要来帮助我们做系统内部服务化，REST接口形式，不会破坏现有服务，前端服务调用无需做任何调整。

还有一个重要原因Dubbo与苏宁RSF服务框架高度重合，在对外服务接口上，我们还是以RSF接口为主。

3. 基于spring cloud的服务化实践3.1 整体架构介绍

整体有几个组件：注册中心、服务网关、服务监控、负载均衡器。注册中心使用Spring Cloud提供的Eureka， 服务网关使用Spring Cloud提供的Zuul组件， 负载均衡器使用Ribbon组件，服务网关的负载均衡策略选择的是：WeightedResponseTimeRule，根据服务器响应时间来决定路由到哪个节点。 服务监控组件，用来监控服务性能、调用情况， 最重要的一点，是将整个服务链路能串联起来。

3.2 服务监控设计

监控是一个系统的眼睛，是断然不可缺少的一部分，Zipkin提供了很好的服务链路监控，结合我们自身的使用场景，最终我们没有选择Zipkin， 为什么？

首先了解下Zipkin整体架构：数据采集（Brave、Sleuth）、Tranport数据传输（支持Kafka、直接发送Collector）、Collector（数据收集）、Storage（存储：ES）、Search+Webui（监控展示），整体架构如下图所示，Zipkin监控数据格式如下：

字段名	类型	描述
traceId	String	根ID
name	String	服务名
id	String	当前ID
parentId	String	父节点ID
timestamp	Long	时间
duration	Long	耗时
annotations	数组	用于记录事件

Zipkin有如下缺点

• 我们不止是监控Spring Cloud服务调用，如：苏宁RSF服务调用、Sql的执行时间、本地方法执行时间等
• 监控数据格式不满足业务需要
• Collector节点容易出现性能瓶颈， ES聚合查询性能较差
• 跨线程，链路无法串联。
  

基于以上几点，我们决定自研服务链路监控系统，整个系统架构如下， 我们利用Kafka、Druid原则上提供了无限扩展性， Druid对应Zipkin中的角色：Collector（数据收集） + Storage（存储：ES）

结合我们的业务需要，设计了监控日志格式如下图所

一条调用链路，有相同的根ID，服务名由三部分组成：系统名、一级名称、二级名称， 一级名称有7种值：

• url：http接口
• url-call：调用http接口
• rsf: rsf接口
• rsf-call:调用rsf接口
• sql:执行sql
• cache:操作缓存
• method:本地方法。
  

你可能会问，没有存储父id，如何判断一条链路中的父子关系？ 这里我们设计一个特殊的事务id生成规则，通过事务ID本身接能判断父子关系，如下图所示。

下图监控系统的链路展示页面：

3.3 基于Hystrix的熔断设计

hystrix对应的中文名字是”豪猪”，豪猪周身长满了刺，能保护自己不受天敌的伤害，代表了一种防御机制，这与hystrix本身的功能不谋而合，因此Netflix团队将该框架命名为Hystrix，并使用了对应的卡通形象做作为logo。

在一个分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，如何能够保证在一个依赖出问题的情况下，不会导致整体服务失败，这个就是Hystrix需要做的事情。Hystrix提供了熔断、隔离、Fallback、cache、监控等功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用。

使用Hystrix很简单，只需要添加相应依赖即可， 最方便的方式是使用注解：HystrixCommand，

• fallbackMethod：指定Fallback方法
• threadPoolKey：线程池名称
• threadPoolProperties：指定线程池参数（线程池大小、最大队列排队数量）
• commandProperties：CIRCUIT_BREAKER开头的参数配置熔断相关参数，METRICS_ROLLING开头的参数设置指标计算相关参数
• 相关参数定义，参考类：HystrixPropertiesManager
  

• @RestController
• public class HystrixTest {
• @RequestMapping(value = "/query/user/name", method = RequestMethod.GET )
• @HystrixCommand(fallbackMethod = "getDefaultUserName", threadPoolKey = "query_user",
• threadPoolProperties = {
• @HystrixProperty(name = CORE_SIZE, value = "10"),
• @HystrixProperty(name = MAX_QUEUE_SIZE, value = "10")
• },
• commandProperties = {
• @HystrixProperty(name = CIRCUIT_BREAKER_ENABLED, value = "true"),
• @HystrixProperty(name = CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD, value = "1000"),
• @HystrixProperty(name = CIRCUIT_BREAKER_ERROR_THRESHOLD_PERCENTAGE, value = "25")
• }
• )
• static String getUserName(String userID) throws InterruptedException {
• Thread.sleep(-1);
• return userID;
• }
• public String getDefaultUserName(String userID) {
• return "";
• }
• }
  

3.4 基于服务网关Zuul实现的广播功能。

有些时候我们希望url请求被所有服务实例执行，这里我们对Zuul做了一个改造，增加了一个BroadCastFilter， 在url请求header设置gate_broadcast为true，那么这个请求，将被转发给所有服务实例。逻辑流程如下：

• 判断gate_broadcast参数为true
• 从url获取ServiceId
• 从Ribbon获取服务所有实例
• 将请求发送给所有实例
• 将所有实例返回结果封装，返回
  

3.5 微服务带来的问题 3.5.1 服务拆分粒度不好把握

Spring Cloud的微服务有一个ServiceId的概念，通常一个war包对应一个ServiceId，这个ServiceId下可以有多个服务。粒度拆分方式主要有：横向、纵向.

纵向切分主要有如下几个方式：

• 按功能切，如：用户管理、指标管理、模型管理等
• 按角色切，如：管理员、商家、用户。
  

横向切分，一般用来提取公共的基础服务，比如：用户名密码校验服务、用户基本信息查询。

3.5.2 运维、开发复杂度增加

单体程序时代只有一个war包，微服务鼓励服务拆分，war数量、部署节点大大增加。此外，一个流程处理往往会由多个分布式服务协同完成， 带来了不少棘手的问题：

• 需要通过分布式事务保障数据最终一致性
• 防止单个服务问题造成雪崩
  

这些都给开发者提出了更高的要求。

3.5.3 调试难度增加

微服务方式鼓励服务拆分，通过服务间依赖完成功能，给开发、测试带来了挑战，合理选择微服务、代码复用两种方案。

4. 后续架构演进4.1 服务版本控制

没有版本控制，意味着我们无法做灰度发布， 毁灭性版本发布后，无法做到对老版本兼容，下图为服务A、B、C、D间的版本依赖关系

我们实现思路是对Zuul进行改造

• 打版本标签，在Zuul对访问来源判断（比如app版本5.1 那么对应的查询接口版本为2.1），打上版本标签
• 根据版本信息，路由到对应版本服务实例
  

4.2 基于gateway的服务熔断、限流机制

目前有一些开源的框架如Ratelimit，通过在Ruul增加filter来实现限流熔断，目前有几个问题，1、不支持动态配置 2、不能满足业务变化，如配合版本控制 。综上所述， 我们已经着手一些自研工作，能与我们业务场景贴合得更紧密

5. 总结

16年到现在，两年的时间，苏宁大数据中心，从传统的单例开发模式，切换到基于Spring Cloud的微服务开发模式，摸索出了一条适合自己的路，这不只是技术框架的切换，更是开发思维的升级。令人欣喜的是，这两年间Spring Cloud飞速发展，18年发布了革命性的2.0版本，这离不开社区的支持，许多像Netflix一样的公司在笔根不戳的为Spring Cloud生态添砖加瓦。 我们基于Spring Cloud开发出了一些服务于自己业务的组件，让我们认识到自己也是有能力有责任去回馈社区。路漫漫其修远兮，好的架构一定是适应业务发展的架构，对于Spring这不是终点， 对于我们更不是。

作者：王富平 ,苏宁易购大数据中心数据中台技术负责人，历任百度大数据部高级工程师、1 号店搜索与精准化部门架构师。多年来，一直从事大数据方向的研发工作，对大数据工具、机器学习有深刻的认知，在实时计算领域经验丰富，对 Storm、Spark Streaming 有深入了解。热爱分享和技术传播，目前关注数据分析平台的建设，旨在打通数据建模到数据分析，基于 Druid、Kylin 等 OLAP 技术，提供一个平台级别的数据指标服务，打造”数据即服务”的一站式解决方案。