[转]Spring Cloud在国内中小型公司能用起来吗？

原文地址：http://www.cnblogs.com/ityouknow/p/7508306.html

原文地址：https://www.zhihu.com/question/61403505

今天吃完饭休息的时候瞎逛知乎，忽然看到这个一个问题Spring Cloud在国内中小型公司能用起来吗？，吸引了个人注意。仔细的看了题主的问题，发现这是一个好问题，题主通过了一番思考，而且用图形全面的将本身的疑问表达了出来，做为一个研究并使用Spring Boot和Spring Cloud近两年的程序员，看的我手痒痒不答不快呀。

好问题

好问题必须配认真的回答，仔细的看了题主的问题，发现这个问题很是具备表明性，多是广大网友想使用Spring Cloud却又对Spring Cloud不太了解的共同想法，题主对Spring Cloud使用的方方面面都进行过了思考，包括市场，学习、先后端、测试、配置、部署、开发以及运维，下面就是题主本来的问题：

想在公司推广Spring Cloud，但我对这项技术还缺少了解,画了一张脑图，总结了种种问题。

微服务是这样一个结构吗?

前端或二方 - > ng集群 -> zuul集群 -> eureka-server集群 -> service provider集群

（二方指其余业务部门）

想要明白这个问题，首先须要知道什么是Spring Boot，什么是Spring Cloud，以及二者之间有什么关系？

什么是Spring Boot

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

Spring Boot是由Pivotal团队提供的全新框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员再也不须要定义样板化的配置。用个人话来理解，就是Spring Boot其实不是什么新的框架，它默认配置了不少框架的使用方式，就像maven整合了全部的jar包，Spring Boot整合了全部的框架（不知道这样比喻是否合适）。

Spring Boot的核心思想就是约定大于配置，一切自动完成。采用Spring Boot能够大大的简化你的开发模式，全部你想集成的经常使用框架，它都有对应的组件支持。若是你对Spring Boot彻底不了解，能够参考个人这篇文章：Springboot(一)：入门篇

什么是Spring Cloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，均可以用Spring Boot的开发风格作到一键启动和部署。Spring并无重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，经过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

微服务是能够独立部署、水平扩展、独立访问（或者有独立的数据库）的服务单元，Spring Cloud就是这些微服务的大管家，采用了微服务这种架构以后，项目的数量会很是多，Spring Cloud作为大管家就须要提供各类方案来维护整个生态。

Spring Cloud就是一套分布式服务治理的框架，既然它是一套服务治理的框架，那么它自己不会提供具体功能性的操做，更专一于服务之间的通信、熔断、监控等。所以就须要不少的组件来支持一套功能，若是你对Spring Cloud组件不是特别了解的话，能够参考个人这篇文章：springcloud(一)：大话Spring Cloud

Spring Boot和Spring Cloud的关系

Spring Boot 是 Spring 的一套快速配置脚手架，能够基于Spring Boot 快速开发单个微服务，Spring Cloud是一个基于Spring Boot实现的云应用开发工具；Spring Boot专一于快速、方便集成的单个微服务个体，Spring Cloud关注全局的服务治理框架；Spring Boot使用了默认大于配置的理念，不少集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring Boot来实现，能够不基于Spring Boot吗？不能够。

Spring Boot能够离开Spring Cloud独立使用开发项目，可是Spring Cloud离不开Spring Boot，属于依赖的关系。

Spring -> Spring Boot > Spring Cloud 这样的关系。

回答

如下为我在知乎的回答。

首先楼主问的这些问题都挺好的，算是通过了本身的一番思考，我刚好经历了你所说的中小公司，且都使用Spring Cloud而且已经投产上线。第一家公司技术开发人员15人左右，项目实例 30多，第二家公司开发人员100人左右，项目实例达160多。

实话说Spring Boot、Spring Cloud仍在高速发展，技术生态不断的完善和扩张，难免也会有一些小的bug，但对于中小公司的使用来将，彻底能够忽略，基本均可以找到解决方案，接下来回到你的问题。

一、市场

据我所知有不少知名互联网公司都已经使用了Spring Cloud，好比阿里、美团但都是小规模，没有像我经历的这俩家公司，业务线所有拥抱Spring Cloud；另外Spring Cloud并非一套高深的技术，普通的Java程序员通过一到俩个月彻底就能够上手，但前期须要一个比较精通人的来带队。

二、学习

有不少种方式，如今Spring Cloud愈来愈火的状况下，各类资源也愈来愈丰富，查看官方文档和示例，如今不少优秀的博客在写spirng cloud的相关教程，我这里收集了一些Spring Boot和Spring Cloud的相关资源能够参考，找到博客也就找到人和组织了。

• Spring Boot学习资料汇总：
• Spring Cloud学习资料汇总 ：

三、先后职责划分

其实这个问题是每一个系统架构都应该考虑的问题，Spring Cloud只是后端服务治理的一套框架，惟一和前端有关系的是thymeleaf，Spring推荐使用它作模板引擎。通常状况下，前端app或者网页经过zuul来调用后端的服务，若是包含静态资源也可使用nginx作一下代理转发。

四、测试

Spring-boot-starter-test支持项目中各层方法的测试，也支持controller层的各类属性。因此通常测试的步奏是这样，首先开发人员覆盖本身的全部方法，而后测试微服务内全部对外接口保证微服务内的正确性，再进行微服务之间集成测试，最后交付测试。

五、配置

session共享有不少种方式，好比使用tomcat sesion共享机制，但我比较推荐使用redis缓存来作session共享。彻底能够分批引入，我在上一家公司就是分批过渡上线，新旧项目经过zuul进行交互，分批引入的时候，最好是新业务线先使用Spring Cloud，老业务作过渡，当彻底掌握以后在所有替换。若是只是请求转发，zuul的性能不必定比nginx低，可是若是涉及到静态资源，仍是建议在前端使用nginx作一下代理。另外Spring Cloud有配置中心，能够很是灵活的作全部配置的事情。

六、部署

多环境不一样配置，Spring Boot最擅长作这个事情了，使用不一样的配置文件来配置不一样环境的参数，在服务启动的时候指明某个配置文件便可，例如：java -jar app.jar --spring.profiles.active=dev就是启动测试环境的配置文件；Spring Cloud 没有提供发布平台，由于jenkins已经足够完善了，推荐使用jenkins来部署Spring Boot项目，会省很是多的事情；灰度暂时不支持，可能须要本身来作，若是有多个实例，能够一个一个来更新；支持混合部署，一台机子部署多个是常见的事情。

七、开发

你说的包含html接口就是前端页面吧，Spring Boot能够支持，但其实也是Spring Mvc在作这个事情，Spring Cloud只作服务治理，其它具体的功能都是集成了各类框架来解决而已；excel报表能够，其实除过swing项目外，其它Java项目均可以想象；Spring Cloud和老项目能够混合使用，经过zuul来支持。是否支持callback，能够经过MQ来实现，仍是强调Spring Cloud只是服务治理。

八、运维

Turbine、zipkin能够用来作熔断和性能监控；动态上下线某个节点能够经过jenkins来实现；provider下线后，会有其它相同的实例来提供服务，Eureka会间隔一段时间来检测服务的可用性；不一样节点配置不一样的流量权值目前还不支持。注册中心必须作高可用集群，注册中心挂掉以后，服务实例会所有中止。

总结，中小企业是否能用的起来Spring Cloud，彻底取决于本身公司的环境，若是是一个技术活跃型的团队就大胆的去尝试吧，目前Spring Cloud是全部微服务治理中最优秀的方案，也是一个趋势，将来一两年可能就会像Spring同样流行，早接触早学习岂不更好。

但愿能解答了你的疑问。

Spring Cloud 架构

咱们从总体来看一下Spring Cloud主要的组件，以及它的访问流程

• 一、外部或者内部的非Spring Cloud项目都统一经过API网关（Zuul）来访问内部服务.
• 二、网关接收到请求后，从注册中心（Eureka）获取可用服务
• 三、由Ribbon进行均衡负载后，分发到后端的具体实例
• 四、微服务之间经过Feign进行通讯处理业务
• 五、Hystrix负责处理服务超时熔断
• 六、Turbine监控服务间的调用和熔断相关指标

图中没有画出配置中心，配置中心管理各微服务不一样环境下的配置文件。

以上就是一个完整的Spring Cloud生态图。

最后送一个完整示例的Spirng Cloud开源项目等你去spring-cloud-examples

 

----------------------------------------------分割线-----------------------------------------------------

----------------------------------------------分割线-----------------------------------------------------

----------------------------------------------分割线-----------------------------------------------------

 

做者：Harry Huang
连接：https://www.zhihu.com/question/61403505/answer/188118355
来源：知乎
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

踩过一段时间Spring Cloud的坑，来强答一下。

结论：确定能用起来，可是要根据实际状况判断用的程度。

---

我基本尝试架构了全套的Spring Cloud服务，包括和Spring Cloud深度关联的Cloud Foundry。可是最终决策并无采起全套部署Spring Cloud方案。

其中几点缘由说明一下：

1. 微服务

与Spring Cloud相关联的，很核心的一个概念就是微服务。

微服务不适合解决企业类应用的架构问题，而是针对互联网服务特别有效的解决方案。

互联网业务的特性是模式简单，服务量巨大。部分业务能够深度解耦，在这种状况下，微服务是一种行而有效的解决方案。

而企业业务深度耦合，不少业务都是事务性处理，任何单路微服务挂掉均可能致使整个事务的丢弃回转。在这种状况下，事务性业务须要考虑如何在微服务架构上，将每一个微服务的业务都丢弃。

我在微服务概念普及以前，已经尝试过几回将服务微服务化（移动互联网应用和游戏服务以及企业业务），针对互联网应用确实颇有效，可是针对游戏和流程性很强的企业业务，并不成功（由于粒度没法控制，最终结果是在微服务的粒度上，构建不少复合业务，数据分离存储后，又有不少冗余数据要重复存储，避免过多的业务互相访问）。

所以，我认为采用微服务架构必需要根据实际问题具体考虑。有个核心点是Context is king。在Java里面Context实例化采用的也不少，所以这点考虑相对容易。若是你的服务粒度之间能够抛弃Context，实现彻底的无状态访问，那么能够考虑采用微服务结构。

2. Spring Cloud自己技术的有效性

最近Docker推出了内置的Docker Swarm Mode，能够将若干机器联合起来进行快速扩展访问，而且自带快捷的流量自动分发，在这点上，Zuul的做用就不明显了，被缩减到主要是服务监控的做用。若是是将Zuul联合Docker Swarm Mode以及前面再加一层Nginx或F5作SSL和流量分发，意义就更不明显了。

Spring Cloud提出了一套技术解决方案（主要是基于Netflix的解决方案），可是这套技术并不必定是惟一的最佳解决方案。当新的服务提出时，Spring Cloud里面的部分解决方案，可能就是过期的了。

另外，Spring Cloud的入门门槛，我认为仍是很是高的，由于英文文档写的十分复杂，并且结构组织并很差。我从找到Tutorial开始一点一点常识部署，到最终对整个架构有一点比较完整的认识，前先后后大概花了半年的时间，而且其中大多数时候都是搞明白工做模式后，发现并不适合本身的业务模式使用，从而丢弃（传说中的踩坑）。

回归本源，Spring Boot自己是神同样的解决方案。但Spring Cloud还没达到Spring Boot这个级别。举个例子，Spring Cloud OAuth我认为就是很不成熟的解决方案。我照着Spring Cloud OAuth本身写了一套基于JPA的OAuth流程，发现本来的实现，很是受局限（若是要使用自带的数据库那套代码）；并且OAuth自己，虽然很适合作针对客户的业务，但并不适合作企业内部的系统认证处理（这个是我我的的偏见，由于个人全部服务都是提供的REST API，并不指望在服务中嵌入任何H5代码，可是这样必然不符合OAuth第三方认证的模式）。

3. Spring Cloud与Cloud Foundry的联系

Cloud Foundry是一套很复杂的云系统，运行在VMware或其余云虚拟服务上。而Spring Cloud官方提供的一些服务，包括Sagan项目案例，AB部署（官方叫蓝绿部署）等，都是基于Cloud Foundry的。

我特地购买了128G内存，安装VMware虚拟机后尝试部署了这套方案。由于若是这套方案可行，那么给客户部署CF的私有云对我而言也是能够接受的方案。

可是最终我并无成功的部署Cloud Foundry的服务，由于，它是在对硬件要求过高了（不加内存跑不起来，即便是测试部署，它也模式你是部署在公网环境，必需要有一套公网认证的Wildcard域名-几万一年。同时，Spring部署上去还必须对Java的运行包进行修改，以支持SSL访问）。

评估下来，可能必需要组建一套真正的私有云机房，才可以正常的部署Cloud Foundry服务。（涉及到的多是百万级别的VMware购买费用，或者是组织团队作一套OpenStack的解决方案）。而无论从哪一个方面考虑，若是针对中小企业私有云的话，我我的评估不出它带来的超额的价值。

另一点，真的要部署到开放服务的话，我我的感受对比自建机房，选择阿里云等云服务对绝大多数企业是更好的选择（我是阿里云脑残粉）。

若是抛弃Cloud Foundry，我我的认为Docker是很是好的替代方案。固然，不少功能须要本身来完成了，包括部署、AB部署等。

4. 目前个人方案

我目前彻底抛弃了Spring Cloud，只使用了Spring Boot。这样最终服务是直接打成惟一的一个包。

部署的时候，采用Docker Swarm Mode，直接用Service模式，这样能够手动控制节点数量。

即便是小型私有云服务，在VMware机器上，虚拟出若干台虚拟机，而后每台虚拟机跑一个服务就足够了。

这里面要考虑的主要是存储和数据库服务。数据库免费的能够考虑Percona数据库（也有一些坑，由于我本身制做的DockerFile，让存储文件挂载到NAS上）。不过业务量不大，单台MySql也能够。收费的，上Oracle这个就不说了。

另一个问题就是文件存储和访问的问题，在多台机器下，NAS存储几乎是必选方案（若是你愿意，虚拟一台机器安装NAS操做系统也能够）。

其余里面你提到的一些问题：

1. Spring Cloud人才是否好招聘？

公司本身内部培养一我的便可，这个技术不须要太多人掌握。维护人员知道如何维护就能够了。

2. Spring Cloud资料

网上主要是教程和官方文档，更多的，目前主要靠本身踩坑。

3. Spring Cloud先后端划分

这个跟自己的业务模式相关，我一直是先后端分离的，这样便于移动端访问。网页端直接部署阿里云OSS上，而后经过Api访问服务器，极大下降了服务器的带宽成本。

4. Spring Cloud微服务碎片化

微服务的粒度是本身控制的，并且这个控制很是难（这也是我采起微服务失败以及再也不在企业项目中采起微服务架构的核心缘由）。记住一点，Context is king。

固然，若是人力充足，微服务也是能够选择的，靠人力完成服务解构，这样极大便于以后的维护。

项目是能够无限次重构的，只要有需求，在合适时机招聘人员来完成便可。

5. Session共享

个人模式是访问Token来控制，有一个惟一的微服务来存储和控制Token，其余服务获取访问以后进行验证和获取用户ID等信息。本身作的缘由是由于没有采起Spring Cloud的服务，并且这项服务设计实现起来很是简单，本身作自由度也很高。

这样也能够强行将全部服务RESTful化，便于服务的横向扩展。

6. 多环境不一样配置

Spring Boot只须要你有Java便可，别的都自带。最好是跑在Docker里面了，我本身维护了一套Docker的Image。

Spring Cloud发布平台，这个自带的和Cloud Foundry深度相关，建议仍是看Docker，固然部署靠本身写代码了。若是基于Gradle或者Maven，自带Docker插件，能够和项目深度绑定。

7. Docker搞不定？

强行指派搞定，这个真没那么难

8. 混合部署

Docker自然支持

9. HTML代码和UI接口

这个是Spring Boot的功能，Spring Cloud无论这块

10. 和老系统整合

这个与Spring无关，若是你以前系统是REST的HTTP服务，那天然简单得多。若是是特殊接口，那就要本身实现了。

11. 异步Callback

上MQ系统吧，和Spring Cloud也不要紧，和你本身实现相关。

运维

与Spring Cloud自然无关，和你选择的部署模式相关。

Zuul和Nginx等技术对流量控制稍好一点，Docker Swarm Mode不少地方都仍是空白。