欢迎访问Spring Cloud中国社区

我们致力于成为中国最专业的Spring Boot和Spring Cloud交流社区。推荐使用Github直接登录,欢迎加微信号Software_King进入社区微信交流群。若发现网站bug欢迎反馈!

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

admin · 29天前 · 2946 ·

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


加微信号:Software_King进入社区微信群与作者深入交流。

前言:从单体程序到微服务,再到当下流行的服务网格概念,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

    1. @RestController
    2. public class HystrixTest {
    3. @RequestMapping(value = "/query/user/name", method = RequestMethod.GET )
    4. @HystrixCommand(fallbackMethod = "getDefaultUserName", threadPoolKey = "query_user",
    5. threadPoolProperties = {
    6. @HystrixProperty(name = CORE_SIZE, value = "10"),
    7. @HystrixProperty(name = MAX_QUEUE_SIZE, value = "10")
    8. },
    9. commandProperties = {
    10. @HystrixProperty(name = CIRCUIT_BREAKER_ENABLED, value = "true"),
    11. @HystrixProperty(name = CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD, value = "1000"),
    12. @HystrixProperty(name = CIRCUIT_BREAKER_ERROR_THRESHOLD_PERCENTAGE, value = "25")
    13. }
    14. )
    15. static String getUserName(String userID) throws InterruptedException {
    16. Thread.sleep(-1);
    17. return userID;
    18. }
    19. public String getDefaultUserName(String userID) {
    20. return "";
    21. }
    22. }

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这不是终点, 对于我们更不是。