中小型公司对于Spring Cloud的选择与思考

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

技术背景

什么是微服务

微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”。

微服务架构是一种架构模式，它提倡将单一应用程序划分红一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每一个服务运行在其独立的进程中，服务与服务间采用轻量级的通讯机制互相沟通（一般是基于HTTP的RESTful API）。每一个服务都围绕着具体业务进行构建，而且可以被独立地部署到生产环境、类生产环境等。另外，应尽可能避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

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

微服务架构优点

复杂度可控：在将应用分解的同时，规避了本来复杂度无止境的积累。每个微服务专一于单一功能，并经过定义良好的接口清晰表述服务边界。因为体积小、复杂度低，每一个微服务可由一个小规模开发团队彻底掌控，易于保持高可维护性和开发效率。

独立部署：因为微服务具有独立的运行进程，因此每一个微服务也能够独立部署。当某个微服务发生变动时无需编译、部署整个应用。由微服务组成的应用至关于具有一系列可并行的发布流程，使得发布更加高效，同时下降对生产环境所形成的风险，最终缩短应用交付周期。

技术选型灵活：微服务架构下，技术选型是去中心化的。每一个团队能够根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。因为每一个微服务相对简单，故须要对技术栈进行升级时所面临的风险就较低，甚至彻底重构一个微服务也是可行的。

容错：当某一组件发生故障时，在单一进程的传统架构下，故障颇有可能在进程内扩散，造成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其余服务可经过重试、平稳退化等机制实现应用层面的容错。

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

什么是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风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

微服务是能够独立部署、水平扩展、独立访问（或者有独立的数据库）的服务单元，springcloud就是这些微服务的大管家，采用了微服务这种架构以后，项目的数量会很是多，springcloud作为大管家须要管理好这些微服务，天然须要不少小弟来帮忙。

主要的小弟有：Spring Cloud Config、Spring Cloud Netflix（Eureka、Hystrix、Zuul、Archaius…）、Spring Cloud Bus、Spring Cloud for Cloud Foundry、Spring Cloud Cluster、Spring Cloud Consul、Spring Cloud Security、Spring Cloud Sleuth、Spring Cloud Data Flow、Spring Cloud Stream、Spring Cloud Task、Spring Cloud Zookeeper、Spring Cloud Connectors、Spring Cloud Starters、Spring Cloud CLI，每一个小弟身怀独门绝技、武功高强，在这里不作详细解释，具体的能够看我另一篇文章。

Spring Cloud都作了哪些事

如下为Spring Cloud的核心功能：

分布式/版本化配置

服务注册和发现

路由

服务和服务之间的调用

负载均衡

断路器

分布式消息传递

咱们再来看一张图：

经过这张图，咱们来了解一下各组件配置使用运行流程：

一、请求统一经过API网关（Zuul）来访问内部服务.

二、网关接收到请求后，从注册中心（Eureka）获取可用服务

三、由Ribbon进行均衡负载后，分发到后端具体实例

四、微服务之间经过Feign进行通讯处理业务

五、Hystrix负责处理服务超时熔断

六、Turbine监控服务间的调用和熔断相关指标

Spring Cloud体系介绍

上图只是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 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 SpringCloud应用的分布式追踪系统，和Zipkin，HTrace，ELK兼容。

十、Spring Cloud Data Flow 一个云本地程序和操做模型，组成数据微服务在一个结构化的平台上。

十一、Spring Cloud Stream 基于Redis,Rabbit,Kafka实现的消息微服务，简单声明模型用以在Spring Cloud应用中收发消息。

十二、Spring Cloud Stream App Starters 基于Spring Boot为外部系统提供spring的集成

1三、Spring Cloud Task 短生命周期的微服务，为SpringBooot应用简单声明添加功能和非功能特性。

1四、Spring Cloud Task App Starters

1五、Spring Cloud Zookeeper 服务发现和配置管理基于Apache Zookeeper。

1六、Spring Cloud for Amazon Web Services 快速和亚马逊网络服务集成。

1七、Spring Cloud Connectors 便于PaaS应用在各类平台上链接到后端像数据库和消息经纪服务。

1八、Spring Cloud Starters （项目已经终止而且在Angel.SR2后的版本和其余项目合并）

1九、Spring Cloud CLI 插件用Groovy快速的建立Spring Cloud组件应用。

固然这个数量还在一直增长…

三者之间的关系

微服务是一种架构的理念，提出了微服务的设计原则，从理论为具体的技术落地提供了指导思想。Spring Boot是一套快速配置脚手架，能够基于Spring Boot快速开发单个微服务；Spring Cloud是一个基于Spring Boot实现的服务治理工具包；Spring Boot专一于快速、方便集成的单个微服务个体，Spring Cloud关注全局的服务治理框架。

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

实战经历

遇到问题，寻找方案

2015年初的时候，由于公司业务的大量发展，咱们开始对原有的业务进行拆分，新上的业务线也所有使用独立的项目来开发，项目和项目之间经过http接口进行访问。15年的业务发展很是迅速，项目数量也就相应急剧扩大，到了15底的时候项目达60多个，当项目数达到30几个的时候，其实咱们就遇到了问题，常常某个项目由于扩展增长了新的IP地址，咱们就须要被动的更新好几个相关的项目。服务愈来愈多，服务之间的调用关系也愈来愈复杂，有时候想画一张图来表示项目和项目之间的依赖关系，线条密密麻麻没法看清。网上有一张图能够表达咱们的心情。

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

其实刚开始咱们是走了一些弯路的。这两款框架咱们当时都不熟悉，当时国内使用Spring Cloud进行开发的企业很是的少，我在网上也几乎没找到太多应用的案例。可是Dubbo当时在国内的使用仍是挺广泛的，相关的资料各方面都比较完善。所以在公司扩展新业务线众筹平台的时候，技术选型就先定了Dubbo，由于也是全新的业务没有什么负担，这个项目咱们大概开发了六个月投产，上线之初也遇到了一些问题，但最终还比较顺利。

在新业务线选型使用Dubbo的同时，咱们也没有彻底放弃Spring Cloud，咱们抽出了一两名开发人员学习Spring Boot我也参与其中，为了验证Spring Boot是否能够到达实战的标准，咱们在业余的时间使用Spring Boot开发了一款开源软件云收藏，通过这个项目的实战验证咱们对Spring Boot就有了信心。最重要的是你们体会到使用Spring Boot的各类便利以后，就不再想使用传统的方式来进行开发了。

可是还有一个问题，在选择了Spring Boot进行新业务开发的同时，并无解决咱们上面的那个问题，服务于服务直接调用仍然比较复杂和传统，这时候咱们就开始研究Spring Cloud。由于你们在前期对Spring Boot有了足够的了解，所以学习Sprig Cloud就显得顺风顺水了。因此在使用Dubbo半年以后，咱们又全面开始拥抱Spring Cloud。

微服务技术是程序员绕不开的话题，想要了解更多微服务架构知识点的，能够关注我一下，我后续也会整理更多关于微服务架构这一块的知识点分享出来，另外顺便给你们推荐一个交流学习群：650385180，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。目前受益良多，如下的课程体系图也是在群里获取。

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

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

1）从两个公司的背景来谈：Dubbo，是阿里巴巴服务化治理的核心框架，并被普遍应用于中国各互联网公司；Spring Cloud是大名鼎鼎的Spring家族的产品。阿里巴巴是一个商业公司，虽然也开源了不少的顶级的项目，但从总体战略上来说，仍然是服务于自身的业务为主。Spring专一于企业级开源框架的研发，不管是在中国仍是在世界上使用都很是普遍，开发出通用、开源、稳健的开源框架就是他们的主业。

2）从社区活跃度这个角度来对比，Dubbo虽然也是一个很是优秀的服务治理框架，而且在服务治理、灰度发布、流量分发这方面作的比Spring Cloud还好，除过当当网在基础上增长了rest支持外，已有两年多的时间几乎都没有任何更新了。在使用过程当中出现问题，提交到github的Issue也少有回复。

相反Spring Cloud自从发展到如今，仍然在不断的高速发展，从github上提交代码的频度和发布版本的时间间隔就能够看出，如今Spring Cloud即将发布2.0版本，到了后期会更加完善和稳定。

3) 从整个大的平台架构来说，dubbo框架只是专一于服务之间的治理，若是咱们须要使用配置中心、分布式跟踪这些内容都须要本身去集成，这样无形中使用dubbo的难度就会增长。Spring Cloud几乎考虑了服务治理的方方面面，更有Spring Boot这个大将的支持，开发起来很是的便利和简单。

4）从技术发展的角度来说，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项目，到如今公司绝大部分的项目都是在Spring Cloud这个架构体系中。

微服务技术是程序员绕不开的话题，想要了解更多微服务架构知识点的，能够关注我一下，我后续也会整理更多关于微服务架构这一块的知识点分享出来，另外顺便给你们推荐一个交流学习群：650385180，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。如下的学习路线图也是在群里获取。

经验和教训

架构演化的步骤

在肯定使用Spring Boot/Cloud这套技术栈进行微服务改造以前，先梳理平台的服务，对不一样的服务进行分类，以确认演化的节奏。

先让团队熟悉Spring Boot技术，而且优先在基础服务上进行技术改造，推进改动后的项目投产上线

当团队熟悉Spring Boot以后，再推动使用Spring Cloud对原有的项目进行改造。

在进行微服务改造过程当中，优先应用于新业务系统，前期能够只是少许的项目进行了微服务化改造，随着你们对技术的熟悉度增长，能够加快加大微服务改造的范围

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

服务拆分原则

服务拆分有如下几个原则和你们分享

横向拆分。按照不一样的业务域进行拆分，例如订单、营销、风控、积分资源等。造成独立的业务领域微服务集群。

纵向拆分。把一个业务功能里的不一样模块或者组件进行拆分。例如把公共组件拆分红独立的原子服务，下沉到底层，造成相对独立的原子服务层。这样一纵一横，就能够实现业务的服务化拆分。

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

服务拆分是越小越好吗？微服务的大与小是相对的。好比在初期，咱们把交易拆分为一个微服务，可是随着业务量的增大，可能一个交易系统已经慢慢变得很大，而且并发流量也不小，为了支撑更多的交易量，我会把交易系统，拆分为订单服务、投标服务、转让服务等。所以微服务的拆分力度需与具体业务相结合，总的原则是服务内部高内聚，服务之间低耦合。

微服务vs传统开发

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

分工不一样，之前咱们多是一个一个模块，如今多是一人一个系统。

架构不一样，服务的拆分是一个技术含量很高的问题，拆分是否合理对之后发展影响巨大。

部署方式不一样，若是还像之前同样部署估计累死了，自动化运维不可不上。

容灾不一样，好的微服务能够隔离故障避免服务总体down掉，坏的微服务设计仍然能够由于一个子服务出现问题致使连锁反应。

给数据库带来的挑战

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

1）严格按照微服务的划分来作，微服务相互独立，各微服务数据库也独立，后台须要展现数据时，调用各微服务的接口来获取对应的数据，再进行数据处理后展现出来，这是标准的用法，也是最麻烦的用法。

2) 将业务高度相关的表放到一个库中，将业务关系不是很紧密的表严格按照微服务模式来拆分，这样既可使用微服务，也避免了数据库分散致使后台系通通计功能难以实现，是一个折中的方案。

3）数据库严格按照微服务的要求来切分，以知足业务高并发，实时或者准实时将各微服务数据库数据同步到NoSQL数据库中，在同步的过程当中进行数据清洗，用来知足后台业务系统的使用，推荐使用MongoDB、HBase等。

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

微服务的经验和建议

一、建议尽可能不要使用Jsp，页面开发推荐使用Thymeleaf。Web项目建议独立部署Tomcat，不要使用内嵌的Tomcat，内嵌Tomcat部署Jsp项目会偶现龟速访问的状况。

二、服务编排是个好东西，主要的做用是减小项目中的相互依赖。好比如今有项目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来作主控。之后项目部署的时候，只须要最后启动服务编排项目便可。

三、不要为了追求技术而追求技术，肯定进行微服务架构改造以前，须要考虑如下几方面的因素：

1）团队的技术人员是否已经具有相关技术基础。

2）公司业务是否适合进行微服务化改造，并非全部的平台都适合进行微服务化改造，好比：传统行业有不少复杂垂直的业务系统。

3）Spring Cloud生态的技术有不少，并非每一种技术方案都须要用上，适合本身的才是最好的。

总结

Spring Cloud对于中小型互联网公司来讲是一种福音，由于这类公司每每没有实力或者没有足够的资金投入去开发本身的分布式系统基础设施，使用Spring Cloud一站式解决方案能在从容应对业务发展的同时大大减小开发成本。同时，随着近几年微服务架构和Docker容器概念的火爆，也会让Spring Cloud在将来愈来愈“云”化的软件开发风格中立有一席之地，尤为是在目前五花八门的分布式解决方案中提供了标准化的、全站式的技术方案，意义可能会堪比当前Servlet规范的诞生，有效推动服务端软件系统技术水平的进步。