就分布式微服务架构来说， Spring Cloud 的未来在哪里？

确实迷茫，SpringCloud 跟多的是一种标准，会有越来越多的实现，但是还都是时间问题。

反观国内的环境，我更倾向于 dubbo 生态，dubbo 重启维护以后已经转正，一线大厂用 dubbo 的也不少，首先他早，其次是 rpc 性能更好。然后就是往远看 ali 的 cloud 生态可能以 dubbo 作为 springcloud alibaba 的 rpc 解决方案，我记得在阿里中间件技术博客中看过。至于最后会不会太监掉很难说。（不是 dubbo 吹）

然后就是接触过一些公司，在使用 cloud 的现有实现，不更新不维护的都换掉，比如 Eureka 换 Consul，zuul 换 gateway 等等。

最后就是，现阶段感觉选哪个都是在不断的踩坑中前行。。

封在史中

小白有点儿不懂，就算 spring cloud 不再更新维护，以现有版本的各个组件不能满足项目的需要嘛？就跟 springboot 2 出了，1 也很稳定，照样有人用似的，不可以吗？

一站式的解决方案，现在的 spring cloud 不能满足吗？

@leonme 你指的是 Spring Cloud 的哪个实现？ Netflix ？ Netflix 不再更新了，之后就会不维护，谁还敢用？这就意味着业界很多新出的技术，没办法被包含在框架内部，bug 之后可能也无人 fix，公司基础架构的演进意味着基本不可能，而这还是在微服务兴起的头几年。

@liujianwei

@liujianwei 新出的技术没办法被包含在框架内部？ 你难道没在 spring 中引入其他开源组件吗？哪个组件不维护了，想体验新技术就直接引入啊～另外开源组件哪有没有 bug 的

我认为没有前途，像中小企业用 dubbo 就好。大型企业用 go 上微服务，微服务太占用资源，cloud 性价比太低了。

oracle 又割韭菜，个人觉得 java 慢慢会凉，spring cloud 也好不到哪里去。

中小企业的开发团队有多大，要用微服务不嫌麻烦吗？

领导非要微服务 现在我们组的服务数量已经是开发人数的二倍了 就这还有好多服务可以再拆却没拆

@CFO 最烦这种建模都建不好还非要上微服务的。

@CFO 拆那么细不觉得花钱多么？

istio 为什么会有这问题

@artandlol 才了解微服务，就看见 service mesh 的风头..

很多人不明白，spring cloud 在 k8s 和 service mesh 时代已经没有必要存在，更多人没有搞清楚 spring cloud 当初为什么出现，以及为什么需要，所以现在更加搞不懂它为什么不再需要了

另外，像 dubbo 这种的存在完全是为了阿里云商业利益，和技术无关，rpc 不如 grpc 和 thrift，大部分 rpc 场景需要的是更高的性能，跨语言调用是很需要的，张口闭口 dubbo 完全连自己的需求都不清楚。

@troywinter 大佬讲讲 cloud 出现的原因？

不是深耕 java 系（ SOA 微服务 分布式 dubbo spring cloud ）体系
去了解 k8s docker istio （不限语言）
另外不要太依赖语言

这个不仅仅是你需要理解概念的问题 你要有场景 去了解 去实际操作

@CFO #10 服务数比开发人数多倒是正常，主要问题在于运维能不能跟上，运维跟不上强上微服务只能说自讨苦吃

现在国内不管大公司还是小公司，张口闭口都是微服务，实际上 99%的公司根本就不需要微服务化，大多数中小公司的技术团队也没那个能力支撑微服务化。
这几年见过不少这类情况：1、公司的半桶水总监平时喜欢到处看所谓的科技文章，然后看到热炒的微服务和大数据概念，然后要求自己公司也要上马，完全不管自己公司有没有必要上就直接强上。2、一些不负责任的技术人员总是喜欢在公司项目中实验新技术，也不管自己对这些新技术掌握到什么程度了。我见过团队中没有运维，就一个后端开发的情况下，后端开发用 spring cloud 把项目给重构了，你敢相信？
其实现在小型公司对技术滥用非常厉害，从上到下言必称你看阿里怎么怎么样，腾讯用什么技术，实际上这些顶级公司的架构和技术和你一个芝麻小公司有半毛钱的关系么？大公司的架构和技术可以学习，可以借鉴，但是一定不能照搬。

那小公司还是 PHP 到底算了。

我们公司在三年前的时候就非常喜欢用微服务，后来我发现微服务有时候太繁琐，会增加服务之间的交互逻辑。而且对于小公司而言，维护微服务成本也太高。不如先合理设计架构，等到满足不了需求需要拆分服务的时候再拆分也不迟，不能为了拆而拆

首先 dubbo 类似于 Spring Cloud 的一个子集，springcloud 是一整套的微服务治理解决方案，二者没有可比性。微服务强调是 “服务”，独立性，方便跨部门跨语言工作，都是用 http 协议。服务之间应该减少调用，最好不调用。是一个个独立服务的系统。

soa 服务化提了起码 10 几年了吧，不喜欢微服务也不用退的那么深啊，没微服务的时候不也有 esb 吗，非要退回傻大粗的单体时代吗

@wesnow 我同意你的观点, 目前很多小公司未来微服务而微服务 , 因为我目前在的就是只有搞得

现在真有那么多企业需要微服务吗，需要做前中后台吗。

不过是在企业转型的幌子和拉投资的战略里吧。

特别是为了微服务而微服务，把业务系统拆分到开发和运维根本都跟不上的情况下，美其名曰长远规划。

我是匿名的，你们看不见我。（ò ó）

使用微服务的目的就是为了快速上线。使用 spring 脚手架可以快速搭建一套服务。对于 java 体系来说，现成的脚手架就 spring 最成熟了，所以很多创业公司在招募开发的时候，就会考虑能找到廉价又好用的技术栈。一个能写代码的 java 开发，也就是 1 万左右，这个成本很低了。加上很多小公司的业务并不是技术决定的，所以，只要能用就可以。谈不上要长远规划。一旦业务起来了，花钱找架构师重新写也是一样的块。没有任何问题。

kong （ api Gateway ）后面随便用啥替换，反正前端看不见。

@xds2000 正解，同样的微服务框架里基于 rest 接口的 跨语言跨和环境最方便，dubbo 基于 rpc 的，又循环依赖的问题很麻烦。然后拥有成熟微服务和公共 api 的企业在开发新应用的上的效率是非常高的。

其实没啥未来~稍微大点的公司一般都有一套成熟的 RPC 方案, 一般自研或者基于 thrift/grpc 这种~, 然后跟各种容器编排深度绑定, 一般而言, 如果业务复杂度没有到达那个级别~真没必要为了微服务而微服务, 没靠谱 SRE 还是放弃吧

Spring Cloud is dead