可看此贴，管理员有提到。 https://ruby-china.org/topics/39520

Rails 的群体（在中国）本来就不算特别大。不过我觉得用的人多也不意味着它就是好技术，相反用的人不多也不意味着不行。先拿 JavaScript 来说，稍微有点规模的项目，如果还是大厂出的，不出一两年 github 上的 star 数量就有可能破几万。人们需求在那，加上大厂加持光环，“流量”就来了。然而你看Ruby的仓库，现在也就 1w 多颗星星，Ruby 已经维护了 20 多年了，配合 Rails 解放了多少生产力，你能说它差吗？

之前我吹捧过一阵子微服务，

拆了几十个小的服务，变成了一个伪微服务

之后

各种监控，各种部署，还有各种神烦的日志跟踪问题 数据库的一致性 还有该死的同步异步问题超时问题

可能是技术不够，让我深切的体会到了

啥叫搞服务发现，搞网关，搞流量控制，搞服务降级，搞异步部署

最后

我觉得我就是个弱智

OKR 有得写了

中大厂的大规模分布式系统，微服务、容器化是唯一的出路。一方面是为了复杂度分解，细化协作分工、提高整体研发效率和稳定性，必须要这么做。

微服务确实能解决很多问题，让很多东西更容易实施。但一旦拆分后，整体的复杂度会提升十倍以上，主要是分布式体系中网络复杂度和链路复杂度。这需要有相当强大的基础设施来降低这种复杂度，主要是强悍的框架和基础库、pass 能力、数据采集、基础服务、工具链。最难的是要让这些东西保持稳定性和迭代能力，这需要堆非常多的人，一个部件都需要一个团队。

估计你这边人力资源投入不够，这套东西又烧钱又耗人力。

人力资源不够的情况下微服务就是作死。。。

确实正如您说的，这套东西又烧钱又耗人力

主要是之前对技术难度预估不足，盲目自信，最后特别后悔

后来我自己的想法是，微服务这种搞法，估计运维 > 5 才能平衡吧

这里也可以麻烦大家统计下 大家上微服务，运维大概多少人，研发大概多少人

docker 化我倒是有一些使用 我们有一些后台任务挺烦挺长的，而且都是瞬时来，平时常备的两台 sidekiq 服务器不够，我是 将 sidekiq 进程做成了一个 docker 服务，同时检测 sidekiq 队列堆积情况 >1000 后 就在阿里开 docker 容器跑 效果还行

因为真的是老生常谈了，所以我决定长篇大论一番，观点完全主观，慎看。

微服务本身可能有两个不同角度的理解。一方面是商业，另一方面是技术

商业上其实跟初创差不多。我认为大多数老板都只是想要快速地将想法实现而已。这种情况下他们谈微服务，只是侧重于这个东西：

• 首先，不会导致原来的东西坏掉
• 其次，能用最小工时和运维代价快速上线
• 最重要的是，这个东西能随时跟其他服务组合一起卖。做多了以后还能自由组合，分别按量计费。这样子就很方便做组合销售。

举个例子，你在给大客户推自己的老服务，结果他说这里头连起步版都很多功能不用的，你却非要我买它。而且你这里头还有一个我需要的核心功能没有实现，别家说他们可以做。但是你这边工程师说耦合很大，难以实现。

所以总结起来，商业角度侧重于销售上的灵活性。

但是老板叫技术负责人做微服务，这时候技术负责人未必就能理解到这个销售的需要了。

接下来我就得谈谈技术方面对微服务的理解。

微服务虽然他是微的，本质却是服务。所以你不得不先了解下 SOA 是什么。

SOA 本质是给复杂的体系编程的架构。

这个复杂可以复杂在数据的存放和集成上，例如大公司用的是很多年前的 Oracle 数据库+asp，又跟购买的各种乱七八糟的系统【例如防伪系统】等有集成。这种情况下，如何通过重新整理系统来更高效地接入新的大需求——比如引进大数据分析，新的产品线。

这个复杂也可以体现在规模上。一方面是访问的并发甚至跨广地域上，例如社交网站等 C 端应用。除了多地高频访问带来的压力以外，还有开发测试运维客服团队规模变大带来的复杂性。入职到上手要多久？能自信地修改代码增加功能【而不会有严重回归】吗？怎么协调那么多人开发和维护产品。

从实际选型上，你可以发现 SOA 基本都是基于事件编程，并且进出流量都是通过分布式系统来承载。由此可以看出 SOA 的较好实践离不开这俩。

那回到一开始讨论的东西微服务，它微在哪里？大家应该都听说过重复发明轮子这句话。其实微服务只是代表在敏捷时代下新的技术栈里实现 SOA。 毕竟之前 SOA 的实现真的老了，更多的在 B 端应用，很多具体实现细节的差异让他们不能很好地适应一些现代的需求。当然另外一方面，我认为有能力开发的团队也不会买东拼西凑的 legacy 产品。

那为什么要说成微服务呢？这个我真的没有考究。猜测一方面是跟商业有关。例如你要给一家大公司推销你利用新技术的 SOA 方案，怎么样才能凸显优越性呢？取个名字“微”服务。微小负担的先进 SOA 听着就不错。另一方面没准搞技术的人也想让新轮子能区别于过去的旧轮子。

最后回到楼主的问题，初创搞 rails 老一套多舒服，为啥要劳民伤财地搞微服务，还要纠结这个坑爹的需求在啥都没有的微服务下要怎么绕圈做。哪怕预期的并发是 rails 无法满足的，开源社区上也有很多其他的语言和其他的框架。如果实在招不到人，那么也可以根据市场的语言偏好用跟 rails 类似的框架搞。例如 spring boot。.

正如 matz 所言，ruby 依然很适合很多初创公司搞。毕竟一开始没有多少人会有钱搞那么大的团队，也没有多少人能对自己公司实际在线的业务规模增长有自信。但是不管怎样，反应一定要敏捷。

所以结论，工具很多，根据实际情况出发，爱用啥就用啥。任何一门语言，只要还有人用，社区还有人贡献代码，它就能活着。不用操心。 我只需要担心自己会不会学不来，会不会找不到想要的工作。

早期拆分肯定坑，盲目拆分也是坑。 我们的项目从开始拆分微服务到现在正常迭代两年多，业务也足够复杂，拆分出来的服务也就二十个左右吧。几十个？有点夸张，大厂就另当别论了

用 Spring Cloud 这套也挺不错的，以前总觉 Rails 开发效率甩 Java 十条街，但真的用起来也还好，各有各的好，喜欢 Rails 的快速迭代，有问题了还能线上开个 console 去调一把。但 Spring Cloud 基本上可以替代掉 Rails，尤其在大团队协作开发的情况下，如果还是在一个或几个大项目里层层迭代，恐怕代码堆积起来后来人维护都会手抖。

现在如果不追求微服务的话感觉团队还是不够一定规模把，大团队拆分出高内聚低耦合的微服务各自治理，质量上还是很有保证的。至于用 Java 还是 Ruby，敲代码的说了不算

写了很多还是删掉了。

几个我自己观察的结论：

1. 应用的拆分和部分应用的服务化/中台化不可避免，有康威定律的原因，也有技术同学追求复用的努力。
2. Java 在中大型公司的 Web 业务处于统治地位，小众语言 ( Ruby, JavaScript, Python ) 积极拥抱 Java 生态才有发展壮大的可能。
3. 管理层不在乎技术，业务负责人对技术只有个模糊的概念，产品负责人对技术一知半解，充满偏见; 而以上三者对技术选型 ( Java or Ruby or Python) 有着很大的影响力，所以舆论阵地还是要去占领，Rails 的声音这两年太小了。
4. 编写代码在复杂业务的交付周期中，占比不大。产研测阶段，需求的明确，技术设计的讨论，测试用例和方案的梳理会占用很多时间.. 这确实导致编程语言/框架所带来的的生产力的提升，对于整个项目生产力的提升，效用不明显
5. 工程师的心气儿，素质和技术视野，我极目所见，同等水平 Ruby 同学秒杀 Java 同学。这是 Ruby 社区最宝贵的财富。
6. 砸一个亿，招五百个工程师，快速试错，扩张业务，国内业务驱动的独角兽目前是这么玩的。Ruby 同学还是太少了，社区应该多多努力。

你的 5 和 6 本身就是矛盾的，团队大了必然有英雄有炮灰，Ruby 程序员都想当英雄让别人当炮灰，团队根本大不起来

首先 Java 微服务并不当道，所以楼主的前提条件已经错了，而且微服务并不等于每个服务都要一队人做，Monorepo != Monolith，Rails 也可以搞 Engine 微服务，JS 也有大而全的新兴框架 redwoodjs。

我记得 2012 年的时候，突然 Oracle 类的培训，书籍，博客非常多，因为那时候阿里实际上在去 IOE，可能有一群 DBA 闲下来了吧，现在 Java 微服务我看也是这个趋势。

英雄 vs 炮灰，有必要这么腹黑么？ -_-||

水平有高低吧，我倾向于这么看问题。水平高的负责重要的事儿，做骨干，做核心; 水平一般的做做辅助。

PS: 五百多新同学的话，按 10% 的比例，需要五十多个所谓的"英雄".

看来我不是 ruby 程序员，没想过当英雄，就是混口饭吃而已。

Java 微服务横行的一个重要原因是很多决策者和掌权者根本没看清自我团队的现状，纯是被营销过度洗脑或者追逐所谓的“前沿技术”一意孤行。另外，还有一大部分都是为了 ppt 好看。

不要问我为什么知道，我都被逼得开始搞所谓的微前端了。。。F**k！

我也在前端岗位，想追问一下何为微前端？

从我个人的视角来看是借微服务蹭一波热度的概念炒作。目前开源可用的轮子也是局限性很强，落地轻飘飘。非超大型团队、超长期项目基本上不适用，而且要尽量保证各个团队业务独立自治度高。

至于比较正经的介绍，请看这里喽～ https://micro-frontends.org/

啊～补充一下，据说微前端这个概念曾在 twitter 上引发过激烈的辩论，无奈梯子挂了，没看到。dev.to 上有个帖子下面的争论也值得一看 https://dev.to/dabit3/building-micro-frontends-with-react-vue-and-single-spa-52op。

OK 感谢分享，我先收藏一下。稍后有时间慢慢看。 估计也只是看看，我一直觉得前端太过于工程化了，操作起来着实让人心累。人们总说术业有专攻，但对我们这种小团队来说，前端没空，还得后端上，简单为妙。

为了微服务而微服务吗？

在拆分微服务，不过仍然是 ruby，用的 grpc 那套自己搭