从单体程序到微服务，再到当下流行的服务网格概念，Spring连接起了这两个时代。它曾是单体程序的代名词，但是却在微服务时代浴火重生，给我们带来了SpringCloud。
借助于SpringCloud，苏宁大数据中心完成了微服务架构转型，在实践中并不是一帆风顺，有思索、有迷茫，更有解决问题的乐趣。
为什么要微服务化？
为什么是SpringCloud？
苏宁数据中台后端是传统的开发架构，VIP负载均衡+Nginx+SpringMVC，代码以单体程序为主。
正常情况下一个项目使用统一域名，在苏宁现有开发架构下，统一域名导致后端只能有一个war包，程序变成单体程序变成必然。
如下图所示是典型的旧式项目代码目录：
项目名称-web：对外war包模块项目名称-interface：统一定义接口项目名称-service：统一定义接口实现
整个项目管理、开发思路，围绕单体程序开发模型设计，带来的弊端很明显：
代码职责不清晰，每个人都在同一模块下提交代码违反高内聚低耦合服务扩展不方便
首先微服务化思路，并不高大上，我们为什么选择微服务化，首要原因是管理问题。
结合苏宁现有开发架构，整个微服务架构如图：域名解析+VIP负载均衡+Nginx+服务网关+各个服务。
下图是某个项目采用微服务化后的工程代码目录：
项目名称-模块1项目名称-模块2
整个代码目录更清晰，利于模块拆分、人员职责安排。
数据中台项目背景介绍
苏宁数据中台是一个大项目群：
OLAP是底层的加速、查询引擎，底层支持Druid、ES、PGCitus集群，类似Presto，跟Presto不同的是OLAP会主动对数据进行Cube预加速。百川是指标平台层，让用户建模、定义指标，对外提供指标查询服务。百川主要支持的建模方式是：星型模型。数据建模自然离不开维表维度，UDMS系统就是来定义、管理所有维度、维表，目前收录了整个集团近多个维度，对外提供维度、维表信息服务。天工是类似Tableau、Superset的可视化报表设计平台，与这些BI软件最大的不同点是，天工基于百川的指标、UDMS的维度来制作报表，数据来源已经高度标准化、归一化。目前商业报告分析工具：Cognos、阿里QuickBI等，是将数据建模、可视化设计能力放到一起，这是天工与它们的最大区别。慧眼，是统一报表门户，所有的报表统一发布到慧眼面向业务。慧眼最大的挑战在于报表权限管控与自动匹配，总共多张报表，用户2w多，一张报表开放给+人员是很常见的。所有这一切靠人工维护，既容易出错又不利于数据安全，也不能及时响应用户需求，这些都是慧眼系统要解决的问题。
微服务框架选型
Dubbo架构介绍
Dubbo主要有四个模块：
Monitor（监控）Regsitry（注册中心）Provider（服务方）Consumer(消费方)
Provider注册服务到Regsitry，Consumer向Regsitry订阅服务信息，Monitor服务监控服务调用情况。
整个服务调用流程如下：
消费方在本地发起服务调用动态代理将调用交给Loadbalance模块Loadbalance从Registry拿到服务实例信息将请求发送到一台服务实例记录监控日志等信息
SpringCloud架构介绍
SpringCloud整个架构与Dubbo非常类似：
Eureka（注册中心）Gateway（服务网关）Provider（服务方）Consumer(消费方)Zipkin（监控）
不同的有如下几点：
SpringCloud是HttpRest接口，Dubbo不是。SpringCloud注册中心不使用Zookeeper，使用自研的Eureka。关于Zookeeper是否适合做注册中心，请参考文章：《Eureka!WhyYouShouldn’tUseZooKeeperforServiceDiscovery》、《阿里巴巴为什么不用ZooKeeper做服务发现》SpringCloud提供了Gateway网关组件。与Spring生态兼容，生态链丰富，自定义Filter、拦截器，来加强功能,如：权限校验、日志打印等；SpringCloudNetflix提供了熔断、限流等组件。
综合以上几点，考虑到架构统一，未来发展趋势，我们选择了SpringCloud。
SpringCloud主要帮助我们做系统内部服务化，REST接口形式，不会破坏现有服务，前端服务调用无需做任何调整。
选择SpringCloud还有一个重要原因是Dubbo与苏宁RSF服务框架高度重合，在对外服务接口上，我们还是以RSF接口为主。
基于SpringCloud的服务化实践
整体架构介绍
整体有几个组件：注册中心、服务网关、服务监控、负载均衡器。注册中心使用SpringCloud提供的Eureka，服务网关使用SpringCloud提供的Zuul组件，负载均衡器使用Ribbon组件。
服务网关的负载均衡策略选择的是：WeightedResponseTimeRule，根据服务器响应时间来决定路由到哪个节点。
服务监控组件，用来监控服务性能、调用情况，最重要的一点，是将整个服务链路能串联起来。
服务监控设计
监控是一个系统的眼睛，是断然不可缺少的一部分，Zipkin提供了很好的服务链路监控，结合我们自身的使用场景，最终我们没有选择Zipkin，为什么？
首先了解下Zipkin整体架构：
数据采集（Brave、Sleuth）Tranport数据传输（支持Kafka、直接发送Collector）Collector（数据收集）Storage（存储：ES）Search+Webui（监控展示）
整体架构如下图所示，Zipkin监控数据格式如下：
Zipkin有如下缺点：
我们不止是监控SpringCloud服务调用，如：苏宁RSF服务调用、SQL的执行时间、本地方法执行时间等。监控数据格式不满足业务需要。Collector节点容易出现性能瓶颈，ES聚合查询性能较差。跨线程，链路无法串联。
基于以上几点，我们决定自研服务链路监控系统，整个系统架构如下，我们利用Kafka、Druid，原则上提供了无限扩展性。
Druid对应Zipkin中的角色：Collector（数据收集）+Storage（存储：ES）。
我们结合业务的需要，设计了监控日志格式，如下图所示：
一条调用链路，有相同的根ID，服务名由三部分组成：
系统名一级名称二级名称
一级名称有7种值：
url：
转载请注明：http://www.0431gb208.com/sjsbszl/2648.html
