Spring boot&Spring cloud部署在C
作者：Harry Huang
链接：https://www.zhihu.com/question/61403505/answer/188118355
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
######
知乎上看到这位同学的经验，写的很好，撸下来mark下
——————
踩过一段时间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很多地方都还是空白。
