从单体程序到微服务，再到当下流行的服务网格概念，Spring 连接起了这两个时代。它曾是单体程序的代名词，但是却在微服务时代浴火重生，给我们带来了 Spring Cloud。

借助于 Spring Cloud，苏宁大数据中心完成了微服务架构转型，在实践中并不是一帆风顺，有思索、有迷茫，更有解决问题的乐趣。

苏宁数据中台后端是传统的开发架构， VIP 负载均衡 + Nginx +SpringMVC，代码以单体程序为主。

正常情况下一个项目使用统一域名，在苏宁现有开发架构下，统一域名导致后端只能有一个 war 包，程序变成单体程序变成必然。

如下图所示是典型的旧式项目代码目录：

项目名称-web：对外 war 包模块

项目名称-interface：统一定义接口

项目名称-service：统一定义接口实现

整个项目管理、开发思路，围绕单体程序开发模型设计，带来的弊端很明显：

代码职责不清晰，每个人都在同一模块下提交代码

首先微服务化思路，并不高大上，我们为什么选择微服务化，首要原因是管理问题。

结合苏宁现有开发架构，整个微服务架构如图：域名解析 + VIP 负载均衡 + Nginx + 服务网关 + 各个服务。

下图是某个项目采用微服务化后的工程代码目录：

整个代码目录更清晰，利于模块拆分、人员职责安排。

苏宁数据中台是一个大项目群：

百川是指标平台层，让用户建模、定义指标，对外提供指标查询服务。百川主要支持的建模方式是：星型模型。

数据建模自然离不开维表维度，UDMS 系统就是来定义、管理所有维度、维表，目前收录了整个集团近 200 多个维度，对外提供维度、维表信息服务。

天工是类似 Tableau、Superset 的可视化报表设计平台，与这些 BI 软件最大的不同点是，天工基于百川的指标、UDMS的维度来制作报表，数据来源已经高度标准化、归一化。

目前商业报告分析工具：Cognos、阿里 QuickBI 等，是将数据建模、可视化设计能力放到一起，这是天工与它们的最大区别。

慧眼，是统一报表门户，所有的报表统一发布到慧眼面向业务。慧眼最大的挑战在于报表权限管控与自动匹配，总共 4000 多张报表，用户 2w 多，一张报表开放给8000+人员是很常见的。

所有这一切靠人工维护，既容易出错又不利于数据安全，也不能及时响应用户需求，这些都是慧眼系统要解决的问题。

Dubbo 主要有四个模块：

整个服务调用流程如下：

消费方在本地发起服务调用

将请求发送到一台服务实例

与 Spring 生态兼容，生态链丰富，自定义 Filter、拦截器，来加强功能, 如：权限校验、日志打印等；Spring Cloud Netflix 提供了熔断、限流等组件。

综合以上几点，考虑到架构统一，未来发展趋势，我们选择了 Spring Cloud。

Spring Cloud 主要帮助我们做系统内部服务化，REST 接口形式，不会破坏现有服务，前端服务调用无需做任何调整。

选择 Spring Cloud 还有一个重要原因是 Dubbo 与苏宁 RSF 服务框架高度重合，在对外服务接口上，我们还是以 RSF 接口为主。

整体有几个组件：注册中心、服务网关、服务监控、负载均衡器。注册中心使用 Spring Cloud 提供的 Eureka，服务网关使用 Spring Cloud 提供的 Zuul 组件，负载均衡器使用 Ribbon 组件。

服务网关的负载均衡策略选择的是：WeightedResponseTimeRule，根据服务器响应时间来决定路由到哪个节点。

服务监控组件，用来监控服务性能、调用情况，最重要的一点，是将整个服务链路能串联起来。

监控是一个系统的眼睛，是断然不可缺少的一部分，Zipkin 提供了很好的服务链路监控，结合我们自身的使用场景，最终我们没有选择 Zipkin，为什么？

首先了解下 Zipkin 整体架构：

整体架构如下图所示，Zipkin 监控数据格式如下：

我们不止是监控 Spring Cloud 服务调用，如：苏宁 RSF 服务调用、SQL 的执行时间、本地方法执行时间等。

监控数据格式不满足业务需要。

Collector 节点容易出现性能瓶颈，ES 聚合查询性能较差。

跨线程，链路无法串联。

基于以上几点，我们决定自研服务链路监控系统，整个系统架构如下，我们利用 Kafka、Druid，原则上提供了无限扩展性。

我们结合业务的需要，设计了监控日志格式，如下图所示：

一条调用链路，有相同的根 ID，服务名由三部分组成：

一级名称有 7 种值：

你可能会问，没有存储父 ID，如何判断一条链路中的父子关系？这里我们设计一个特殊的事务 ID 生成规则，通过事务 ID 本身即能判断父子关系，如下图所示：

下图监控系统的链路展示页面：

Hystrix 对应的中文名字是“豪猪”，豪猪周身长满了刺，能保护自己不受天敌的伤害，代表了一种防御机制，这与 Hystrix 本身的功能不谋而合。

因此 Netflix 团队将该框架命名为 Hystrix，并使用了对应的卡通形象作为 Logo。

在一个分布式系统里，许多依赖会不可避免的调用失败，比如超时、异常等。

如何能够保证在一个依赖出问题的情况下，不会导致整体服务失败，这个就是 Hystrix 需要做的事情。

Hystrix 提供了熔断、隔离、Fallback、Cache、监控等功能，它能够在一个、或多个依赖同时出现问题时保证系统依然可用。

使用 Hystrix 很简单，只需要添加相应依赖即可，最方便的方式是使用注解 HystrixCommand：

threadPoolProperties：指定线程池参数（线程池大小、最大队列排队数量）

一篇文章快速理解微服务架构下的数据设计

百万在线直播互动平台基于Docker的微服务架构实践

腾讯IT老兵：云端微服务架构下的运维思考

特别声明：本文为网易自媒体平台“网易号”作者上传并发布，仅代表该作者观点。网易仅提供信息发布平台。

共享类库是整个服务运行过程中最需要的部分；另一方面，这些类库总的来说也可以被认为是“一种平台”。包括像Spring、Guava和那些通常被用在路由消息和日志记录里的类库。在最后，一个系统的性能优劣取决于是否具备100+类库的组合。如果一个服务不能和系统进行互动的话，只能说明这些类库的可用性有问题，Christensen称这种情况为分布式单体架构。

本质上来讲，你所做的那些将成本花在分布式系统上的事情，其实只是在网络上推广单体架构，但是并没有从微服务架构里面获得任何好处。至于丢失的这些好处就包括多语言特点，也就意味着你所开发的这个服务错过了利用最好的技术来解决特殊问题的可能性，包含组织上和技术解藕方面的问题。解决处理了这些问题有助于团队进行技术升级，而不需要在第一时间去获得授权。

Christensen谈到说，共享类库是整个服务运行过程中最需要的部分；另一方面，这些类库总的来说也可以被认为是“一种平台”。包括像Spring、Guava和那些通常被用在路由消息和日志记录里的类库。在最后，一个系统的性能优劣取决于是否具备100+类库的组合。如果一个服务不能和系统进行互动的话，只能说明这些类库的可用性有问题，Christensen称这种情况为分布式单体架构。

本质上来讲，你所做的那些将成本花在分布式系统上的事情，其实只是在网络上推广单体架构，但是并没有从微服务架构里面获得任何好处。至于丢失的这些好处就包括多语言特点，也就意味着你所开发的这个服务错过了利用最好的技术来解决特殊问题的可能性，包含组织上和技术解藕方面的问题。解决处理了这些问题有助于团队进行技术升级，而不需要在第一时间去获得授权。

不妨在这里简单介绍一下单体架构应用（Monolith），网上对微服务进行介绍的文章常常以单体架构开始。这里也不例外，只有在知道了单体架构的不便之后才能更容易地理解微服务架构模式所具备的各种优点。

开发出来的服务应该是什么样子呢？通常情况下，这个服务所对应的代码是由多个项目所组成，各个项目会根据自身所提供功能的不同具有一个明确的边界。在编译时，这些项目会被打包成为一个个JAR包，并最终合并在一起形成一个WAR包。

接下来，开发者需要将该WAR包上传到Web容器中进行解压，并重新启动服务器。在执行完这一系列操作之后，对服务的编译及部署流程也就完成了。如果按照单体架构组织的代码来运行的话，会生成一个包含了所有功能的WAR包，因此在对服务的容量进行扩展的时候，我们只能选择重复部署这些WAR包来扩展服务能力，而不是仅仅扩展系统瓶颈的组成。

但是这种扩展方式极大地浪费了资源。比如（上图）：在一个服务中，某个组成的负载已经达到了90%，也就是到了不得不对服务能力进行扩容的时候了。而同一服务的其它三个组成的负载还没有到其处理能力的20%。

由于单体架构服务中的各个组成是打包在同一个WAR包中的，因此通过添加一个额外的服务实例，可以将需要扩容的负载降低到45%，但是也使得其它各组成的利用率更为低下。可以说，所有的不便都是由于单体架构服务中一个WAR包包含了该服务的所有功能所导致的。而解决该问题的方法就是微服务架构模式。

Don’t Repeat Yourself的字母缩写DRY对很多人来说都不陌生，意即不要重复造轮子。在共享代码的业务逻辑中，孤立的去部署变化条件的方式正在被摒弃，因为这种做法会直接影响服务执行代码的效果。Christensen强调共享代码在服务边界里面是相当完美的，可是一旦泄漏的话，就会有潜在的耦合可能性。Sam

服务之间太多的耦合所带来的弊端，远比简简单单复制代码所带来的问题还要严重很多倍。

Christensen认为可替代的解决方案就是采用稳定的协议，隐藏所有的实现细节，只将数据契约和网络协议暴露出来，在不依赖服务实现的前提下，用户都能够使用任何技术和编程语言，这才是网络该做的事情。Christensen还指出，虽然在如日志记录、分布式跟踪、路由等领域没有强制的标准化需求，但还是应该启用独立的类库，这样用户才有权选择是否使用这些网络服务。

Christensen认为，这样的低级错误是很容易经常性犯的，因为我们都知道如何使用共享类库，我们也常常在短期内进行优化来达到更高效率。他还说，虽然推迟解藕的成本较高，可是解决方案也是有的，努力在刚开始的时候就把合适的工具用在合适的地方，物尽所用才能发挥最大效果。

在最后的问答过程中他提到，使用一个大的框架无可厚非，只要这个框架被当作内部一个独立的服务使用就行，但如果整个系统的架构不采用这个大的框架也并无大碍，因为这会避免出现长期耦合。微架构或者SOA架构真正发挥所长的地方在于，根据彼此独立部署的逻辑服务，这些逻辑服务可以独立于其他服务进行扩展，而且能够实现独立的故障切换。

红帽公司中间件部门工程副总裁Mark Little博士也曾说过：“我在微服务架构方面担心的问题之一就是，你有一个整体式单体架构应用，假设你随意把它分解成多个服务，到头来就会分解得过细，最后会有10个、100个甚至1000个微服务。但是这些微服务又彼此高度依赖，以至于如果某一个服务出现故障，其余服务很有可能也会出现故障。这种情况下，你将一无所获。你有999个服务就在那里干等着另一个服务恢复正常运行之后才能工作。”

拉勾网「50家好公司带你嗨翻天」

3月19日梦想者市集北京站落地中关村创业大街，

InfoQ和极客邦各业务线的小伙伴也会出现在那里，

欢迎大家来面基、玩耍、拿奖品！

更有百万福利！等你来领！