从单体程序到微服务，再到当下流行的服务网格概念，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服务监控服务调用情况，整个服务调用流程如下:
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有如下缺点
基于以上几点，我们决定自研服务链路监控系统，整个系统架构如下， 我们利用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进行改造
4.2 基于gateway的服务熔断、限流机制
目前有一些开源的框架如Ratelimit，通过在Ruul增加filter来实现限流熔断，目前有几个问题，1、不支持动态配置 2、不能满足业务变化，如配合版本控制 。综上所述， 我们已经着手一些自研工作，能与我们业务场景贴合得更紧密
5. 总结
16年到现在，两年的时间，苏宁大数据中心，从传统的单例开发模式，切换到基于Spring Cloud的微服务开发模式，摸索出了一条适合自己的路，这不只是技术框架的切换，更是开发思维的升级。令人欣喜的是，这两年间Spring Cloud飞速发展，18年发布了革命性的2.0版本，这离不开社区的支持，许多像Netflix一样的公司在笔根不戳的为Spring Cloud生态添砖加瓦。 我们基于Spring Cloud开发出了一些服务于自己业务的组件，让我们认识到自己也是有能力有责任去回馈社区。路漫漫其修远兮，好的架构一定是适应业务发展的架构，对于Spring这不是终点， 对于我们更不是。
本文作者:王富平 来源:网络收集
CIO之家 www.ciozj.com 微信公众号:imciow