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

Posted 2020-10-06 wlzjdm

原文地址：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，但对于中小公司的使用来将，完全可以忽略，基本都可以找到解决方案，接下来回到你的问题。

1、市场

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

2、学习

有很多种方式，现在Spring Cloud越来越火的情况下，各种资源也越来越丰富，查看官方文档和示例，现在很多优秀的博客在写spirng cloud的相关教程，我这里收集了一些Spring Boot和Spring Cloud的相关资源可以参考，找到博客也就找到人和组织了。

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

3、前后职责划分

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

4、测试

Spring-boot-starter-test支持项目中各层方法的测试，也支持controller层的各种属性。所以一般测试的步奏是这样，首先开发人员覆盖自己的所有方法，然后测试微服务内所有对外接口保证微服务内的正确性，再进行微服务之间集成测试，最后交付测试。

5、配置

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

6、部署

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

7、开发

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

8、运维

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

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

希望能解答了你的疑问。

Spring Cloud 架构

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

• 1、外部或者内部的非Spring Cloud项目都统一通过API网关（Zuul）来访问内部服务.
• 2、网关接收到请求后，从注册中心（Eureka）获取可用服务
• 3、由Ribbon进行均衡负载后，分发到后端的具体实例
• 4、微服务之间通过Feign进行通信处理业务
• 5、Hystrix负责处理服务超时熔断
• 6、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很多地方都还是空白。