没有高并发的场景，整微服务、服务发现、集群啥的，是不是有点步子迈太大了？

[darknoll]

我司做制造业相关的软件，一般都是部署在公司内网，原先都是桌面程序，socket 通信，现在大势所趋需要转型到 web，领导提出的架构:要用微服务、服务发现、集群这些做，是不是有点杀鸡用牛刀了？

[zengming00]

公司会为此付出惨痛的教训

[dream4ever]

11 楼和 14 楼一看就是过来人，建议多听听这两位的意见。

[bzshow1]

直接用 bilibili 的架构

[darknoll]

@vandort 其他的研发同事的能力——只会 socket，HTTP 还没怎么用过，web 从没做过

[kkbblzq]

看你们公司有没有比较有经验的 devops 团队了。。。这玩意不只对研发有需求，对运维也有需求的，就算上云商也少不了这些的。。

[scofieldpeng]

楼上说什么带薪学习的省省吧,企业要求的是稳定,和 11 楼,14 楼说的,真要学习,自己云上买个主机玩玩,或者家里搞个破烂服务器都能玩,老实说,量没上去,业务没上去,别搞那些虚的,什么微服务,其他我就不说了,同样的东西,你微服务要多少时间?更不要说什么运维之类的成本了,别抱什么侥幸心理不会挂之类的,线上到时候真跪了你难道要给客户说我们上了一个很牛逼的东西,但是这东西我们还是在学习期?

[wangxiaoaer]

微服务可以考虑，但别像有些教程那样拆的太细。

服务发现啥的久别扯淡了，就你那几个服务一眼就看完，人工发现就 OK 了。

集群无所谓，看情况。

[young1lin]

要我，我偷着乐了，我可能年后去一个二线大厂打工还用不到微服务呢。

带薪学习，先干他个半年。简历上重构原有项目至微服务架构。

不过，这个看日志有点麻烦，除非你引入 ELK 这种，还有你还要做全链路测试，各种问题。没个半年以上，搞不定的。拆分项目根据业务来拆，不用根据 DDD 来。就 4 台机器，说真的，干不了什么。

如果你只是要实现功能的话，我劝你还是搞成多模块应用好，把通用模块拆出来（这就是通用域啊），之后再慢慢改成微服务都行。

[oneisall8955]

带薪学习？你公司这样的体系怎么感觉会学歪了

[KuoYu]

千万不要！血的教训，在一家初创公司刚开始的时候 leader 就提出微服务 集群等，就 4 个人做这些大坑一个接一个，最后交付期拖了又拖，到我离职都没完成。做个人吧，老老实实传统业务做好做精不好吗？

[tedzhou1221]

想起一个互金行业的上市公司的后台，看日志也是上终端看，麻烦死了。后来发现是有 ELK 的，然后他们说不会用。。。。

[optional]

3 台 k3s，不就啥都有了

[atonku]

把现在的代码复制一份，部署上去，告诉老板，微服务做好了

[Tarkky]

谁来给扫下忙，微服务到底适用的场景是啥？它的痛点又是啥？谢谢

[winglight2016]

个人看来，9 成 9 的软件是不需要微服务架构的，然而就业市场上吃香，lz 不妨抓住机会学习一下。毕竟这么一大坨技术栈，不在实际项目上应用是想象不出来有多么复杂。好在，你不需要严格划分“微”服务，只需要按子系统分一下，然后能够互相调用就好了，毕竟，能够容器化领导就已经直呼专业了。所以，这种项目真正考验你的不是学习能力，而是项目规划能力，加上服务注册 /发现，错误处理，不就是二期需求了吗？再来一些 k8s，热更新、灰度部署啥的，三期就来了。程序员最重要的能力就是给自己安排合适的工作。。。（🐶

[luzhh]

微服务没楼上说的那么恐怖，我当时也是一个人搞微服务项目，一波下来没啥复杂的，但是该有的确实得有，不然那就是挖坑，链路追踪+日志中心得搞好，要不然排查问题特别麻烦。

[abcbuzhiming]

@Tarkky 微服务本质是用空间换了复杂度，用体积膨胀，人员膨胀的方式把问题分而化之了。所以如果你的组织度跟不上的话，你解决不了问题，反而问题更多

[abcbuzhiming]

@luzhh 链路追踪和日志中心的成本真高，动不动就是几台服务器，或者要上 ELK 做查询。我其实很早就想把自己的服务拆分化，后来一看我才几台服务器啊。我要拆了得上链路中心和日志中心，搞不好在这上面的服务器比我的应用服务器都多，实在是尴尬。

[xuanbg]

@abcbuzhiming 1 台 4C16G 就够跑 20 来个服务了。。。微服务不一定要多少台服务器，而是适当拆分服务。拆分服务的好处是能够在局部(单个服务)有效降低业务复杂度，使每个服务都容易维护，且整个系统易于扩展，反正就是加个服务(一只羊是赶，一群羊也是放)。

[agagega]

https://ruby-china.org/topics/39735

巨石架构很香啊