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

Posted 2021-04-14 技术琐话

前言：从单体程序到微服务，再到当下流行的服务网格概念，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这不是终点， 对于我们更不是。

· END ·

 往期推荐：

   ……

技术琐话 

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。