微服务架构-选择Spring Cloud，放弃Dubbo

Spring Cloud 在国内中小型公司能用起来吗?从 2016 年初一直到如今，咱们在这条路上已经走了一年多。

在使用 Spring Cloud 以前，咱们对微服务实践是没有太多的体会和经验的。从最初的开源软件云收藏来熟悉 Spring Boot，到项目中的慢慢使用，再到最后全面拥抱 Spring Cloud。

这篇文章给你们介绍咱们使用 Spring Boot / Cloud 一年多的经验总结。

在开始以前咱们先介绍几个概念，什么是微服务，它的特色是什么? Spring Boot / Cloud 都作了那些事情?他们三者之间又有什么关系?

什么是微服务

微服务的概念源于 2014 年 3 月 Martin Fowler 所写的一篇文章“Microservices”。文中内容提到：微服务架构是一种架构模式，它提倡将单一应用程序划分红一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

每一个服务运行在其独立的进程中，服务与服务间采用轻量级的通讯机制互相沟通(一般是基于 HTTP 的 RESTful API)。每一个服务都围绕着具体业务进行构建，而且可以被独立地部署到生产环境、类生产环境等。

另外，应尽可能避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每一个微服务仅关注于完成一件任务并很好地完成该任务。在全部状况下，每一个任务表明着一个小的业务能力。

微服务架构优点

01复杂度可控

在将应用分解的同时，规避了本来复杂度无止境的积累。每个微服务专一于单一功能，并经过定义良好的接口清晰表述服务边界。

因为体积小、复杂度低，每一个微服务可由一个小规模开发团队彻底掌控，易于保持高可维护性和开发效率。

02独立部署

因为微服务具有独立的运行进程，因此每一个微服务也能够独立部署。当某个微服务发生变动时无需编译、部署整个应用。

由微服务组成的应用至关于具有一系列可并行的发布流程，使得发布更加高效，同时下降对生产环境所形成的风险，最终缩短应用交付周期。

03技术选型灵活

微服务架构下，技术选型是去中心化的。每一个团队能够根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。

因为每一个微服务相对简单，因此须要对技术栈进行升级时所面临的风险就较低，甚至彻底重构一个微服务也是可行的。

04容错

当某一组件发生故障时，在单一进程的传统架构下，故障颇有可能在进程内扩散，造成应用全局性的不可用。

在微服务架构下，故障会被隔离在单个服务中。若设计良好，其余服务可经过重试、平稳退化等机制实现应用层面的容错。

05扩展

单块架构应用也能够实现横向扩展，就是将整个应用完整的复制到不一样的节点。当应用的不一样组件在扩展需求上存在差别时，微服务架构便体现出其灵活性，由于每一个服务能够根据实际需求独立进行扩展。

什么是 Spring Boot

Spring Boot 是由 Pivotal 团队提供的全新框架，其设计目的是用来简化新 Spring 应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员再也不须要定义样板化的配置。

用个人话来理解，就是 Spring Boot 不是什么新的框架，它默认配置了不少框架的使用方式，就像 maven 整合了全部的 jar 包，Spring Boot 整合了全部的框架(不知道这样比喻是否合适)。

Spring Boot 简化了基于 Spring 的应用开发，经过少许的代码就能建立一个独立的、产品级别的 Spring 应用。Spring Boot 为 Spring 平台及第三方库提供开箱即用的设置，这样你就能够有条不紊地开始。

Spring Boot 的核心思想就是约定大于配置，多数 Spring Boot 应用只须要不多的 Spring 配置。采用 Spring Boot 能够大大的简化你的开发模式，全部你想集成的经常使用框架，它都有对应的组件支持。

Spring Cloud 都作了哪些事

Spring Cloud 是一系列框架的有序集合，它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，均可以用 Spring Boot 的开发风格作到一键启动和部署。

Spring 并无重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，经过 Spring Boot 风格进行再封装、屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

如下为 Spring Cloud 的核心功能：

• 分布式/版本化配置。
• 服务注册和发现。
• 路由。
• 服务和服务之间的调用。
• 负载均衡。
• 断路器。
• 分布式消息传递。

咱们再来看一张图：

解释一下这张图中各组件的运行流程：

• 全部请求都统一经过 API 网关(Zuul)来访问内部服务。
• 网关接收到请求后，从注册中心(Eureka)获取可用服务。
• 由 Ribbon 进行均衡负载后，分发到后端的具体实例。
• 微服务之间经过 Feign 进行通讯处理业务。
• Hystrix 负责处理服务超时熔断。
• Turbine 监控服务间的调用和熔断相关指标。

固然上面只是 Spring Cloud 体系的一部分，Spring Cloud 共集成了 19 个子项目，里面都包含一个或者多个第三方的组件或者框架!

Spring Cloud 工具框架：

• Spring Cloud Config，配置中心，利用 git 集中管理程序的配置。
• Spring Cloud Netflix，集成众多 Netflix 的开源软件。
• Spring Cloud Bus，消息总线，利用分布式消息将服务和服务实例链接在一块儿，用于在一个集群中传播状态的变化 。
• Spring Cloud for Cloud Foundry，利用 Pivotal Cloudfoundry 集成你的应用程序。
• Spring Cloud Foundry Service Broker，为创建管理云托管服务的服务代理提供了一个起点。
• Spring Cloud Cluster，基于 Zookeeper、Redis、Hazelcast、Consul 实现的领导选举和平民状态模式的抽象和实现。
• Spring Cloud Consul，基于 Hashicorp Consul 实现的服务发现和配置管理。
• Spring Cloud Security，在 Zuul 代理中为 OAuth2 rest 客户端和认证头转发提供负载均衡。
• Spring Cloud Sleuth Spring Cloud，应用的分布式追踪系统和 Zipkin、HTrace、ELK 兼容。
• Spring Cloud Data Flow，一个云本地程序和操做模型，组成数据微服务在一个结构化的平台上。
• Spring Cloud Stream，基于 Redis、Rabbit、Kafka 实现的消息微服务，简单声明模型用以在 Spring Cloud 应用中收发消息。
• Spring Cloud Stream App Starters，基于 Spring Boot 为外部系统提供 Spring 的集成。
• Spring Cloud Task，短生命周期的微服务，为 Spring Boot 应用简单声明添加功能和非功能特性。
• Spring Cloud Task App Starters。
• Spring Cloud Zookeeper，服务发现和配置管理基于 Apache Zookeeper。
• Spring Cloud for Amazon Web Services，快速和亚马逊网络服务集成。
• Spring Cloud Connectors，便于 PaaS 应用在各类平台上链接到后端像数据库和消息经纪服务。
• Spring Cloud Starters，项目已经终止而且在 Angel.SR2 后的版本和其余项目合并。
• Spring Cloud CLI，插件用 Groovy 快速的建立 Spring Cloud 组件应用。

这个数量还在一直增长...

三者之间的关系

微服务是一种架构的理念，提出了微服务的设计原则，从理论为具体的技术落地提供了指导思想。

Spring Boot 是一套快速配置脚手架，能够基于 Spring Boot 快速开发单个微服务。

Spring Cloud 是一个基于 Spring Boot 实现的服务治理工具包;Spring Boot 专一于快速、方便集成的单个微服务个体;Spring Cloud 关注全局的服务治理框架。

Spring Boot / Cloud 是微服务实践的最佳落地方案。

Spring Boot / Cloud 微服务实践背景

2015 年初的时候，由于公司业务的大量发展，咱们开始对原有的业务进行拆分，新上的业务线也所有使用独立的项目来开发，项目和项目之间经过 http 接口进行访问。

2015 年的业务发展很是迅速，项目数量也就相应急剧扩大，到了年末的时候项目达 60 多个，当项目数达到 30 几个的时候，咱们就遇到了问题，常常某个项目由于扩展增长了新的 IP 地址，就须要被动的更新好几个相关的项目。

服务愈来愈多，服务之间的调用关系也愈来愈复杂，有时候想画一张图来表示项目和项目之间的依赖关系，线条密密麻麻没法看清。下面有一张图能够表达咱们的心情：

这个时候咱们就想找一种方案，能够将咱们这么多分布式的服务给管理起来，到网上进行了技术调研咱们发现有两款开源软件比较适合咱们，一个是 Dubbo，另外一个是 Spring Cloud。

刚开始咱们是走了一些弯路的，这两款框架咱们都不熟悉，当时国内使用 Spring Cloud 进行开发的企业很是的少，我在网上也几乎没找到太多应用的案例。可是 Dubbo 在国内的使用仍是挺广泛的，相关的资料各方面都比较完善。

所以在公司扩展新业务线众筹平台的时候，技术选型就先定了 Dubbo，由于也是全新的业务没有什么负担，这个项目咱们大概开发了 6 个月投产，上线之初也遇到了一些问题，但最终还比较顺利。

在新业务线选型使用 Dubbo 的同时，咱们也没有彻底放弃 Spring Cloud，咱们抽出了一两名开发人员学习 Spring Boot，我也参与其中。

为了验证 Spring Boot 是否能够到达实战的标准，咱们在业余的时间使用 Spring Boot 开发了一款开源软件云收藏，通过这个项目的实战验证咱们对 Spring Boot 就有了信心。

最重要的是你们体会到使用 Spring Boot 的各类便利以后，就不再想使用传统的方式来进行开发了。

可是还有一个问题，在选择了 Spring Boot 进行新业务开发的同时，并无解决咱们上面的那个问题，服务与服务直接调用仍然比较复杂和传统，这时候咱们就开始研究 Spring Cloud。

由于你们在前期对 Spring Boot 有了足够的了解，所以学习 Spring Cloud 就显得顺风顺水了。因此在使用 Dubbo 半年以后，咱们又全面开始拥抱 Spring Cloud。

为何选择使用 Spring Cloud 而放弃了 Dubbo

可能你们会问，为何选择了使用 Dubbo 以后，又选择全面使用 Spring Cloud 呢?其中有以下四个缘由：

01从两个公司的背景来谈

Dubbo，是阿里巴巴服务化治理的核心框架，并被普遍应用于中国各互联网公司;Spring Cloud 是大名鼎鼎的 Spring 家族的产品。

阿里巴巴是一个商业公司，虽然也开源了不少的顶级的项目，但从总体战略上来说，仍然是服务于自身的业务为主。

Spring 专一于企业级开源框架的研发，不管是在中国仍是在世界上使用都很是普遍，开发出通用、开源、稳健的开源框架是他们的主业。

02从社区活跃度这个角度来对比

Dubbo 虽然也是一个很是优秀的服务治理框架，而且在服务治理、灰度发布、流量分发这方面作的比 Spring Cloud 还好，除过当当网在此基础上增长了 rest 支持外，已有两年多的时间几乎没有任何更新了。

在使用过程当中出现问题，开发者提交到 GitHub 的 Issue 也少有回复。相反 Spring Cloud 自从发展到如今，仍然在不断的高速发展。

从 GitHub 上提交代码的频度和发布版本的时间间隔就能够看出，如今 Spring Cloud 即将发布 2.0 版本，到了后期会更加完善和稳定。

03从整个大的平台架构来说

Dubbo 框架只是专一于服务之间的治理，若是咱们须要使用配置中心、分布式跟踪这些内容都须要本身去集成，这样无形中增长了使用 Dubbo 的难度。

Spring Cloud 几乎考虑了服务治理的方方面面，更有 Spring Boot 这个大将的支持，开发起来很是的便利和简单。

04从技术发展的角度来说

Dubbo 刚出来的那会技术理念仍是很是先进，解决了各大互联网公司服务治理的问题，中国的各中小公司也从中受益很多。

通过了这么多年的发展，互联网行业也是涌现了更多先进的技术和理念，Dubbo 一直停滞不前，天然有些掉队，有时候我我的也会感到有点惋惜，若是 Dubbo 一直沿着当初的那个路线发展，而且延伸到周边，今天可能又是另外一番景象了。

Spring 推出Spring Boot / Cloud 也是由于自身的不少缘由。Spring 最初推崇的轻量级框架，随着不断的发展也愈来愈庞大，随着集成项目愈来愈多，配置文件也愈来愈混乱，慢慢的背离最初的理念。

随着这么多年的发展，微服务、分布式链路跟踪等更多新的技术理念的出现，Spring 急需一款框架来改善之前的开发模式，所以才会出现 Spring Boot / Cloud 项目。

咱们如今访问 Spring 官网，会发现 Spring Boot 和 Spring Cloud 已经放到首页最重点突出的三个项目中的前两个，可见 Spring 对这两个框架的重视程度。

所以 Dubbo 曾经确实很牛逼，可是 Spring Cloud 是站在近些年技术发展之上进行的开发，所以更具技术表明性。

如何进行微服务架构演进

当咱们将全部的新业务都使用 Spring Cloud 这套架构以后，就会出现这样一个现象：公司的系统被分红了两部分，一部分是传统架构的项目;另外一部分是微服务架构的项目，如何让这两套配合起来使用就成为了关键。

这时候 Spring Cloud 里面的一个关键组件解决了咱们的问题，就是 Zuul。在 Spring Cloud 架构体系内的全部微服务都经过 Zuul 来对外提供统一的访问入口，全部须要和微服务架构内部服务进行通信的请求都走统一网关。以下图：

从上图能够看出咱们对服务进行了四种分类，不一样服务迁移的优先级不一样：

• 基础服务，是一些基础组件，与具体的业务无关。好比：短信服务、邮件服务。这里的服务最容易摘出来作微服务，也是咱们第一优先级分离出来的服务。
• 业务服务，是一些垂直的业务系统，只处理单一的业务类型，好比：风控系统、积分系统、合同系统。
• 这类服务职责比较单一，根据业务状况来选择是否迁移，好比：若是忽然有需求对积分系统进行大优化，咱们就趁机将积分系统进行改造，是咱们的第二优先级分离出来的服务。
• 前置服务，前置服务通常为服务的接入或者输出服务，好比网站的前端服务、app 的服务接口这类，这是咱们第三优先级分离出来的服务。

组合服务，组合服务就是涉及到了具体的业务，好比买标过程，须要调用不少垂直的业务服务，这类的服务咱们通常放到最后再进行微服务化架构来改造，由于这类服务最为复杂，除非涉及到大的业务逻辑变动，咱们是不会轻易进行迁移。

在这四类服务以外，新上线的业务所有使用 Sprng Boot / Cloud 这套技术栈。

架构演化的步骤

架构演化的步骤以下：

• 在肯定使用Spring Boot / Cloud 这套技术栈进行微服务改造以前，请先梳理平台的服务，对不一样的服务进行分类，以确认演化的节奏。
• 先让团队熟悉 Spring Boot 技术，而且优先在基础服务上进行技术改造，推进改动后的项目投产上线。
• 当团队熟悉 Spring Boot 以后，再推动使用 Spring Cloud 对原有的项目进行改造。
• 在进行微服务改造过程当中，优先应用于新业务系统，前期能够只是少许的项目进行了微服务化改造，随着你们对技术的熟悉度增长，能够加快加大微服务改造的范围。

传统项目和微服务项目共存是一个很常见的状况，除非公司业务有大的变化，不建议直接迁移核心项目。

服务拆分

服务拆分的两个原则：

• 横向拆分。按照不一样的业务域进行拆分，例如订单、营销、风控、积分资源等，造成独立的业务领域微服务集群。
• 纵向拆分。把一个业务功能里的不一样模块或者组件进行拆分。例如把公共组件拆分红独立的原子服务，下沉到底层，造成相对独立的原子服务层。这样一纵一横，就能够实现业务的服务化拆分。

要作好微服务的分层：梳理和抽取核心应用、公共应用，做为独立的服务下沉到核心和公共能力层，逐渐造成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。

服务拆分是越小越好吗?微服务的大与小是相对的。好比在初期，咱们把交易拆分为一个微服务，可是随着业务量的增大，可能一个交易系统已经慢慢变得很大，而且并发流量也不小。

为了支撑更多的交易量，我会把交易系统，拆分为订单服务、投标服务、转让服务等。所以微服务的拆分力度需与具体业务相结合，总的原则是服务内部高内聚，服务之间低耦合。

微服务 vs 传统开发

使用微服务有一段时间了，这种开发模式和传统的开发模式对比，有很大的不一样，以下面几点：

• 分工不一样，之前咱们多是一个一个模块，如今多是一人一个系统。
• 架构不一样，服务的拆分是一个技术含量很高的问题，拆分是否合理对之后发展影响巨大。
• 部署方式不一样，若是还像之前同样部署估计累死了，自动化运维不可不上。
• 容灾不一样，好的微服务能够隔离故障避免服务总体 down 掉，坏的微服务设计仍然能够由于一个子服务出现问题致使连锁反应。

给数据库带来的挑战

每一个微服务都有本身独立的数据库，那么后台管理的联合查询怎么处理?这是你们广泛遇到的一个问题。

有以下三种处理方案：

• 严格按照微服务的划分来作，微服务相互独立，各微服务数据库也独立，后台须要展现数据时，调用各微服务的接口来获取对应的数据，再进行数据处理后展现出来，这是标准的用法，也是最麻烦的用法。
• 将业务相关的表放到一个库中，将业务无关的表严格按照微服务模式来拆分，这样既可使用微服务，也避免了数据库各类切换致使后台统计难以实现，是一个折中的方案。
• 数据库严格按照微服务的要求来切分，以知足业务高并发，实时或者准实时将各微服务数据库数据同步到 NoSQL 数据库中，在同步的过程当中进行数据清洗，用来知足后台业务系统的使用，推荐使用 Mongodb、Hbase 等。

三种方案在不一样的公司我都使用过，第一种方案适合业务较为简单的小公司;第二种方案，适合想在原有系统之上，慢慢演化为微服务架构的公司;第三种适合大型高并发的互联网公司。

微服务的经验和建议

01建议尽可能不要使用 Jsp，页面开发推荐使用 Thymeleaf

Web 项目建议独立部署 Tomcat，不要使用内嵌的 Tomcat，内嵌 Tomcat 部署 Jsp 项目会偶现龟速访问的状况。

02服务编排是个好东西，主要的做用是减小项目中的相互依赖

好比如今有项目 a 调用项目 b，项目 b 调用项目 c...一直到 h，是一个调用链，那么项目上线的时候须要先更新最底层的 h 再更新 g...更新 c 更新 b 最后是更新项目 a。

这只是一个调用链，在复杂的业务中有很是多的调用，若是要记住每个调用链对开发运维人员来讲就是灾难。

有一个好办法能够尽可能的减小项目间的相互依赖，就是服务编排，一个核心的业务处理项目，负责和各个微服务打交道。

好比以前是 a 调用 b，b 掉用 c，c 调用 d，如今统一在一个核心项目 W 中来处理，W 服务使用 a 的时候去调用 b，使用 b 的时候W去调用 c。

举个例子：在第三方支付业务中，有一个核心支付项目是服务编排，负责处理支付的业务逻辑，W 项目使用商户信息的时候就去调用“商户系统”，须要校验设备的时候就去调用“终端系统”，须要风控的时候就调用“风控系统”，各个项目须要的依赖参数都由W来作主控。之后项目部署的时候，只须要最后启动服务编排项目便可。

03不要为了追求技术而追求技术

须要考虑如下几方面的因素：

• 团队的技术人员是否已经具有相关技术基础。
• 公司业务是否适合进行微服务化改造，并非全部的平台都适合进行微服务化改造，好比：传统行业有不少复杂垂直的业务系统。
• Spring Cloud 生态的技术有不少，并非每一种技术方案都须要用上，适合本身的才是最好的。

总结

Spring Cloud 对于中小型互联网公司来讲是一种福音，由于这类公司每每没有实力或者没有足够的资金投入去开发本身的分布式系统基础设施，使用 Spring Cloud 一站式解决方案能在从容应对业务发展的同时大大减小开发成本。

同时，随着近几年微服务架构和 Docker 容器概念的火爆，也会让 Spring Cloud 在将来愈来愈“云”化的软件开发风格中立有一席之地。

尤为是在目前五花八门的分布式解决方案中提供了标准化的、全站式的技术方案，意义可能堪比当前 Servlet 规范的诞生，有效推动服务端软件系统技术水平的进步。