转载

Spring Cloud Alibaba，中国 Javaer 的福音，为微服务续上 18 年

Java 界最近发生了一件大事，Spring Cloud 官方宣布阿里开源 Spring Cloud Alibaba ，并推出首个预览版。

据介绍，Spring Cloud Alibaba 由阿里开源组件和阿里云产品组件两部分组成，其致力于提供微服务一站式解决方案，方便开发者通过 Spring Cloud 编程模型轻松开发微服务应用。

开源的消息引起了巨大的反响，Spring Cloud Alibaba 的到来，不仅引起了 Java 开发者的高度关注，也让人们将目光聚集到了项目背后当下最炙手可热的微服务架构领域。

目前使用 Spring Cloud 的第一选择是 Spring Cloud Netflix，它的领先地位不可撼动，而此次阿里开源的“原生国产”环境下的这一项目，是不是会对此带来变革？而随着越来越多的落地实践，微服务架构的弊端已逐渐显露，此时阿里加码该领域的这一大动作，背后有什么考量呢？

此外还有开发者关注度相当高的项目后期维护、Dubbo 是否又一次被抛弃等问题……我们第一时间采访了阿里巴巴中间件高级技术专家姬望，希望能让大家对 Spring Cloud Alibaba 这个项目、对相关领域的发展与趋势有更多的了解。

本文内容较长，这里先提取几个要点：

再也不会不明白 Spring XXXXXX 到底是什么
中国 Java 开发者的福音
微服务架构领域变天
Dubbo 没有被抛弃
下一代架构不是流式架构，而是 Serverless
云计算终将统治整个服务端架构
明年 2 月 GA

Spring？Spring Boot？Spring Framework？Spring Cloud？Spring Cloud Alibaba？Spring 全家桶在 Java 开发中是不得不提的，虽然知名度很高、使用度高，但是其实许多人就只是使用着框架，甚至对于什么是 Spring Cloud 都不甚了解，对上边这些术语傻傻分不清楚。借这个机会，请您给大家仔细地介绍一下吧。

在国内 Javaer 界，单说 Spring 这个词，其实并不具体指什么，它只是一个代号，具体代表的含义，是要看语境的。比如我说 Spring 那帮大神，那这时候 Spring 指的就是 Spring 公司 ；再比如我说你们平时开发用 Spring 吗，这时 Spring 一般指的其实是 Spring IOC ，而且大部分情况下，我们说 Spring 指的都是 Spring IOC。

Spring IOC 是什么这里就不多解释了，相信大家都不陌生，而且，这应该是最火的面试题之一吧。 Spring Framework 围绕着 Spring IOC 与核心的 Spring AOP 功能，还实现了与诸多 J2EE 开发框架的整合，大大降低了企业级应用开发的难度，提高了效率。

几年前很火的 SSH 框架就是一个典型的 Spring Framework 整合 Hibernate 和 Struts2 的例子。当时，学会 SSH 整合，那可是一门手艺，那复杂的配置文件、层出不穷的 Jar 包，绝对可以让你眼花缭乱、欲罢不能。所以，现在的 Javaer 是幸福的，因为 Spring Boot 解决了这个问题。

Spring Boot 让你可以引入一个 POM 依赖就实现所有 Jar 包的管理，也可以让你一个配置文件、几行简单的配置就解决所有复杂的配置问题。Spring Boot 的宗旨就是让用户可以更简单地开发基于 Spring Framework 搭建的应用，不得不说，Spring Boot 完美地实现了它的宗旨。

至于 Spring Cloud ，它是在 Spring Boot 的基础上，增加了一堆微服务相关的规范，并对应用上下文（Application Context）进行了功能增强。

既然 Spring Cloud 是规范，那么就需要去实现， Spring Cloud Alibaba 就是 Spring Cloud 微服务规范的一套实现。

总结起来就是：

Spring 通常指 Spring IOC。
Spring Framework 包含了 Spring IOC，同时包含了 Spring AOP，并实现与其它 J2EE 框架的整合。
Spring Boot 是对 Spring Framework 的补充，让框架的集成变得更简单，致力于快速开发独立的 Spring 应用。
Spring Cloud 是基于 Spring Boot 设计的一套微服务规范，并增强了应用上下文。
Spring Cloud Alibaba 采用阿里中间件作为原料，实现了 Spring Cloud 的微服务规范。

目前 Spring Cloud 规范已有 Spring Cloud Netflix 等实现，那 Alibaba 这一套的主要区别与优势是什么？

Spring Cloud Alibaba 的组件孵化自阿里巴巴内部自用的中间件产品，这些中间件经历过多次双 11 的考验（双 11 是目前世界上最大最复杂的电商交易场景），具备超强的抗压能力这点毋庸置疑。此外，Spring Cloud Alibaba 完整的原生中文文档和本地化的开源服务将大大降低开发者的学习成本，提高接入速率，并降低后续的运维难度。

具体到其中的各个组件来看：

Nacos

Nacos 基于阿里内部 配置管理 和 服务发现 组件开源，经历过多次双 11 检验，支持超大规模集群，稳定性和性能上值得信赖。后续我们还会基于这套成熟的业务模型，建设灰度发布、环境隔离、全链路压测这些更高级的特性，将更多阿里在微服务实践方面的大杀器输出。

Nacos Discovery

Nacos Discovery、Spring Cloud Netflix Eureka、ZooKeeper 和 Consul 都遵循了 Spring Cloud 服务发现的标准实现，也很好地适配了 Ribbon。相比之下，Nacos Discovery 有如下特点：

支持实时推送，达到秒级服务发现。
多层容灾机制，尽量保证服务发现中心宕机不影响应用调用。

Nacos Config

Nacos Config 和 Spring Cloud Config、ZooKeeper 与 Consul 一样，都遵循了 Spring Cloud 配置标准实现，但是依赖组件更少，使用更加简单，功能更加强大。

例如它无需 Spring Cloud Bus、MQ，直接就可以实现配置的实时推送，而且推送状态可查。支持数据回滚、支持多种数据格式、完美支持中文，最后还依赖多重容灾机制确保配置服务端的故障不影响应用本身。

RocketMQ

Spring Cloud 官方的 Spring Cloud Stream 框架屏蔽了底层消息中间件的处理，使用统一的编程模型进行编程。目前官方只有 Kafka 和 RabbitMQ 的 Binder 实现。阿里巴巴的 RocketMQ 消息中间件 ，已经成为了 Apache 的顶级项目，社区上也有很多人在咨询什么时候能出 RocketMQ 的 Binder，而我们也认为这是非常有必要的。

Sentinel

目前 Spring Cloud 官方推荐的断路器是 Hystrix。Sentinel 是阿里中间件团队开源的，面向分布式服务架构的轻量级高可用 流量控制组件 ，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。Sentinel 与 Hystrix 两者具有一些共同特性，但底层的实现方式不一致。

相比之下 Sentinel 有以下特性：

轻量级、高性能
多样化的流量控制策略
系统负载保护和实时监控与控制面板等尘烛写 OSS 、SchedulerX 与 ARMS 的优势

SchedulerX

SchedulerX 是一套高可靠的 分布式任务调度系统 ，支持海量任务秒级别调度，支持 Java、脚本、http 等多种任务类型，提供分布式编程模型可以进行大数据跑批，接入简单易用。

ARMS

ARMS 是一款 APM 类的监控产品，用户可基于 ARMS 的前端监控、应用监控或者自定义监控，快速构建实时的应用性能和业务监控能力。

OSS

OSS 是阿里云提供的 云存储服务 ，它具有与平台无关的 RESTful API 接口，能够提供 99.999999999%（11 个 9）的数据可靠性和 99.99% 的服务可用性。

Spring Cloud Alibaba 入驻了 Spring Cloud 孵化器，这个消息可以说是比较突然的，能不能介绍一下从最开始到今天进入孵化器的整个过程，以及背后的心路历程。

去年年末的时候，我们看到 Spring Cloud 子项目中有 spring-cloud-aws 和 spring-cloud-gcp 这些组件，它们可以提升 AWS 和 GCP 用户在使用 Spring Boot 编程时的效率。

那时候我们想如果把阿里云的产品也集成到 Spring Cloud 生态中，那肯定也能增加阿里云上 Java 用户的幸福感，所以我们着手做了相关工作，最开始项目叫 spring-cloud-alibabacloud。

但是后来，随着阿里中间件全面拥抱开源，服务发现和配置管理组件 Nacos、流量保护 Sentinel 这些重量级的中间件陆续开源出来，同时我们也发现开源社区在使用 Spring Cloud 已有实现的时候遇到这样那样的问题。这个时候，我们觉得将这些经过多次双 11 检验的生产级别中间件接入到 Spring Cloud 生态会是一件更酷的事情。于是我们将 Spring Cloud Alibaba 单独成项，提交到了 Spring Cloud 官方。

目前我们发布了第一个版本，包含了 Nacos 和 Sentinel，以及阿里云的 OSS、ACM 和 ANS。随着阿里开源的力度不断加大，后续会有更多组件加入。

Spring Cloud Alibaba 成为官方认证的新一套 Spring Cloud 规范的实现，从多方面来讲这意味着什么呢？

我从以下几个方面来讲一讲吧。

首先是弥补 Spring Cloud 原生实现在大规模集群场景上的局限性。Spring Cloud 规范的实现目前有很多，比如 Netflix 有自己的一整套体系，Consul 支持服务注册和配置管理，ZK 支持服务注册等。每套实现或多或少都有各自的优缺点，或许大多数 Spring Cloud 用户很难体会到原生实现的局限性，无论是服务发现、分布式配置，还是服务调用和熔断都不太适合大规模集群场景，比如我们内部也遇到 Eureka 性能问题。因此，阿里将自身的超大规模集群经验与强大的 Spring Cloud 生态整合，实现强强联合，相信对业界会产生积极的化学变化。

另一个影响是我们觉得这可以 造福中国的 Javaer 。我们发现目前 Spring Cloud 的第一选择 Spring Cloud Netflix 在国内并不是有特别多的人精通，而且它们的文档都是英文的，出问题后排查也比较困难。

Spring Cloud Alibaba 是一套国产开源产品集合，后续我们会提供中文 reference 和一些原理分析文章，这对于国内的开发者是非常棒的一件事。

阿里巴巴的宗旨是“让天下没有难做的生意”，其实阿里的众多 Javaer 一直以来也有一个宗旨，那就是“造福中国的 Javaer”。不论是之前的 Dubbo 也好，还是前段时间的 Java 开发手册也好，都很好地体现了我们的宗旨，如今，我们拿出 Spring Cloud Alibaba，继续贯彻我们的宗旨。

还有一个方面是对于 微服务架构领域 来说的。随着微服务架构日益普及，这方面的知识储备也越来越重要，越来越迫切，Spring Cloud Alibaba 的出现，可以说是恰逢其时。而对于微服务这个领域来说，Spring Cloud Alibaba 的出现，也会让这个圈子产生不小的化学反应。前段时间，有文章表示阿里有这么强劲的技术实力，而且又是中文环境，后续 Spring Cloud Alibaba 可能会替代掉 Spring Cloud Netflix，微服务领域要变天，我觉得这非常有可能。

有人要问，阿里这样搞，那同样深耕微服务领域的 Dubbo 算什么？前阵子才为它的复出欢呼雀跃啊，扔了吗？

其实很多人都有一个误解，认为 Dubbo 和 Spring Cloud 是二选一，甚至对立的关系，这里我们需要着重澄清一下。

联系前边讲到的内容，Spring Cloud 并不是等同于 Spring Cloud Netflix 的 Ribbon、Feign、Eureka、Hystrix 这一套组件。而是抽象了一套通用的开发模式，它的目的是通过抽象出这套通用的模式，让开发者更快更好地开发业务。

但是这套开发模式运行时的实际载体，还是依赖于 RPC、网关、服务发现、配置管理、限流熔断、分布式链路跟踪等组件的具体实现。

Dubbo 与 Spring Cloud 并不是竞争关系，Dubbo 作为成熟的 RPC 框架，其易用性、扩展性和健壮性已得到业界的认可。未来 Dubbo 将会作为 Spring Cloud Alibaba 的 RPC 组件，并与 Spring Cloud 原生的 Feign 以及 RestTemplate 进行无缝整合，实现“零”成本迁移。

在阿里巴巴的微服务解决方案中，Dubbo、Nacos 和 Sentinel，以及后续将开源的微服务组件， 都是 Dubbo EcoSystem 的一部分 。我们后续也会将 Dubbo EcoSystem 集成到 Spring Cloud 的生态中。

所以总结一下就是： Spring Cloud 抽象了微服务编程通用模式，而 Dubbo EcoSystem 是微服务的最佳实践。

微服务架构特别火，但是其实它也存在一些问题，最近有人就因此指出微服务架构要完蛋了，并且否定了“Service Mesh 作为下一代微服务架构”的观点，同时说明像 Flink 这样的流式架构将成为新主流。阿里此次通过 Spring Cloud Alibaba 加码微服务，想必是不认同微服务架构要结束的观点。类比一下单体、SOA、Serverless 等架构，您觉得微服务架构已经发展到了一个什么样的阶段呢？请您具体分享一下。

【文章详见： https://zhuanlan.zhihu.com/p/48036811 】

我觉得微服务目前处在蓬勃发展的阶段，Service Mesh、Serverless 其实都隶属微服务架构的范畴。Service Mesh 是提供微服务的一种多语言、无依赖的解决方案。Serverless 是提供微服务的一种简化开发、自动化运维、资源分时复用的解决方案。

Service Mesh 和流式编程架构都是很好的方向，阿里集团里也有其它团队在做这方面事情。

但是站在我们团队的角度来看，这些都是尚未经过大规模生产集群验证的架构，而 Spring Cloud Alibaba 里面集成的这些组件都是在阿里内部经过多年双 11 检验的。

说到底， 技术还是要为业务服务 的，所以我们将这套技术集成到 Spring Cloud 生态，方便开发者更好更快地开发业务，业务永远是最重要的。这是我们的想法。

具体到那篇文章中的观点，我是这么看的：

微服务是 SOA 的一种实现

SOA 是面向服务的架构，微服务也是面向服务架构的一种实现。如果引用微服务领域的先驱 Martin Fowler 的话，那么“ 我们应该把 SOA 看作微服务的超集 ”。微服务是 SOA 的一种敏捷实现，之前 ESB 是 IBM 对 SOA 一种不太完美的实现，在微服务这个概念被 Martin Fowler 大神创造出来之前，阿里巴巴使用 Dubbo、HSF 实现了自己的微服务体系，其实也是 SOA 的一种实现。

微服务解决的本质问题是团队分工

SOA 也好、微服务也好，解决的根本问题是团队分工问题，详见康威定律，这是大型软件发展的必然，不因为人的喜好而改变。当你读懂康威定律，就会发现“ 服务拆分粒度难以准确把握 ”根本 不是本质问题 。

你有几个 2 pizza 团队，最好就拆成几个微服务。举一个现实的例子：只有一个开发人员时，尽量就做单体应用，不要没事找刺激拆成 10 个微服务，最终这个开发人员还会把他合成一个。微服务要求纵向的 2 pizza 团队（无数个小团队，包含开发、测试、运维），当然我们也实施过一些传统大型企业，但团队还是处在横向结构的场景下（开发、运维、测试各是一个团队），拆分微服务让他们很痛苦，尤其是运维团队。

微服务带来挑战是分布式下开发、测试与运维的复杂性

永远不会有银弹，但是我们要接受历史的潮流，并且适应它。微服务的出现解决了团队分工问题，同时也会引入新的问题，但是 并不是“基础设施的庞大复杂”。

EDAS 其实已经提供了大部分“基础设施”。微服务跟开车一样，车（基础设施）我们可以不去造，但是学会开车（微服务理念）是对单体应用开发、测试与运维最大的挑战。例如：单体应用开发者从来不会去想方法调用会失败、会重试、要幂等；单体应用测试人员不会去想几十个应用我怎么一起集成测试；单体运维人员不会去想下游应用挂了对我有什么影响。意识到分布式下开发、测试与运维的复杂性，并掌握解决这些复杂问题的方法，才是更主要的。

微服务至少还能活 18 年

当然不能因为微服务存在问题，我们就说它将死。很多人说 Java 将死，从 2000 年就听说过这个论调，18 年过去了 Java 还活着，而且最近还搞得风生水起。

谈到微服务将死，那么这里联系一下 Java，我认为微服务至少还要活 18 年，并且它也值得我做一辈子，我们会提供完善的基础设施（车），提供完善的最佳实践（教练），帮助开发者享受微服务（开车）带来的好处。

下一代架构是 Serverless

此处提到的 Serverless != FaaS，Serverless 包含底层中间件的 Serverless 及服务本身 Serverless，而 FaaS 只是其中一种比较简单的实现。那篇文章中提到的 Flink 跟 FaaS 实际上并无本质区别，但是本身商业化比 FaaS 差得比较大。

针对文中各个“ 流式架构优势 ”论证点的具体分析如下：

原文：服务端开发人员无需再关注系统性能，Slink 集群可以用容器动态扩容，Slink 集群也可以动态调整某个业务的节点数量。

性能是开发人员必须关注的指标，开发人员只是不需要关注节点扩缩，FaaS 做得更好，甚至可以做到无流量时节点不驻留。

原文：服务端开发人员无需再关注系统可靠性，Slink 集群管理每个节点，包括调度、重启、状态管理等。

FaaS 节点的自动故障转移。

原文：服务端开发人员无需再考虑系统拆分，因为系统已经拆分到单条业务的粒度了，业务发展和变化，不会导致架构变化，只需要调整业务处理流图就可以了。

理想很丰满，现实很骨感，阿里有个团队尝试了 FaaS 之后，马上退回去了，复杂业务逻辑不是拖拽那么简单就可以解决。单体应用的代码理论上也可以写成无数个小方法，拖拽一下就可以了，目前小部分银行系统小部分逻辑是这样实现的，但是为什么不能大规模推广？这是业务复杂性或多变性导致的，所以 FaaS 也很难成功。FaaS 所谓的方法级别的拆分，本质跟微服务接口 API 定义无本质区别，所谓的编排，目前看只适合于简单业务逻辑的控制。

原文：Slink 可以支持多个业务运行，资源可以做到最大程度的共享。

FaaS 可以做到不运行的逻辑不加载，做到分时复用，Flink（Slink）做不到。

原文：几乎大部分中间件，例如消息队列、全链路跟踪、配置中心、降级系统等都可以去掉，Slink 平台可以内置这些功能。

AWS FaaS 底层已经提供了 Serverless 的各种服务，目前看 Flink 并未提供。

原文：运维基本上维护 Slink 平台即可，业务无需运维维护。

AWS FaaS 不需要维护，AWS 会帮你维护。

原文：Slink 可以支持多语言，不再要求服务端开发统一技术栈。

FaaS 可以是任意语言，已经商业化。

总结一下，实际上 Serverless 解决的本质问题是以下几个方面：