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

? ? ? ? ? ? ? ? 苏宁数据中台基于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接口形式，不会破坏现有