2024 年了，之前搞微服务的公司你们还好么

[IamUNICODE]

新加入一个团队，应该是两年前开始搞微服务架构，组件大概有近 50 个，两个月我只看和改了其中五六个，数据流向交互完全不明白，大概是 grpc+emqx 通信，数据库有云端主库和每个用户自己的文件数据库，部署是妙云一把抓，我以为我只是项目不熟，结果上周有个小伙子，是全程跟了项目，应该对项目一草一木都熟悉吧，结果定位一个问题用了两天一夜，老实说之前参加过的最乱最复杂的项目都没有这么久才能定位问题，这是微服务通病还是只是这里没设计好？

这种搞法有点看不懂啊，现在看起来唯一的好处是整个项目对研发的依赖相当高，什么都要研发参与才进行的下去，所以之前搞微服务的你们还好吗？

[pegasusz]

@yuanmomo 说得很中肯

[Features]

我也想问一下，有人用 PHP 的 hyperf 搞微服务吗？
前几年进一家公司，技术主管非要跟风搞这个
一大堆坑，传统的 PHP 库没几个能正常用的，搞了几天我跑路了

我私下问主管，都用 hyperf 为啥不用 springboot
主管说的很直白，反正都是打工，给自己增加一点资历

[me1onsoda]

微服务搞起来得整配套措施，链路追踪是标配。你那小伙子也是之前负责项目的一部分，搞不清楚很正常，一个人能把整个搞清楚的项目一般不用上微服务，不会太复杂。

[bronyakaka]

@diagnostics 单体又不是只部署一个实例，前面有负载均衡 机器挂了也有别的服务接收流量，微服务本质上没有解决任何技术问题，只是方便大公司人去开发，别上来说人菜就多练，你也好不到哪去

[diagnostics]

@bronyakaka #43 你理解的服务挂就只是一个节点挂掉？我没根据一个一个点，说别人菜就多练？

> 排查问题，写出你们的排查路径，最后发给大伙看看有没有可优化点，然后你也再复盘，而不是一味得怪这怪那

我不想说脏话，这句话你看不到吗？

[diagnostics]

@bronyakaka #43 哦，原来是上个 webp 转 jpg 的人，并发编程都不懂的人，Blocked 了。

[diagnostics]

@IamUNICODE #39 定位工具都有，那排查问题还要 2 天，不就是经验问题吗？多在 dev 环境练，没问题吧？

另外，遇到问题，能反思的点很多，上来对架构做出质疑的，你别在 V2 发帖子，怼你领导，怼你 CTO 啊，你又没胆子，有胆识说服老板让你当 CTO/架构师，改为单例。

上面的话说的不好听了点，但良言难劝该死鬼，你这不是技术能力问题，而是态度问题了。

冯诺依曼架构在现代计算机上还有性能问题呢，人家也是混合哈佛架构去优化了才是我们现代处理器的模型，难道你要设计师推倒重来？回到我的论证：你觉得在这个 path 下微服务架构不好用：

1. 优化流程，减少微服务的拆分（不是无脑拆，而是有必要的拆分），至于有个哥们回复我负载均衡网关+单体，我都不想搭理他（这难道没拆服务？说白了他就是学艺不精，别人上个帖子也是写了并发的软件，并发都没吃透，培训班水平）
2. 构建组织的优化：你的问题其实是这个，library 没升级和微服务压根不搭边好吧
3. 升级流程的优化：上线没人审核评审变动，需求开发前没评估升级风险

这些点都可以是问题的优化，对于你的问题，压根不在微服务，你这是 Structuring Projects 的问题，但你觉得为什么部分包要单独抽出来外部引用？就是为了一个 schema 升级时，上下游都可以同步开发，不依赖这个 schema ，如果一旦 schema 升级，是需要上下游找到对应的人的。（你可以参考今天的帖子： https://v2ex.com/t/1057143 ）

另外升级检查，也可以写个 maven 插件来搞定（假设你是 java 项目）

八杆子打不到微服务架构上。。。。

[xuld]

这个问题本身存在一些观念上的误区。

任何一个问题的出现都是多方面引发的，绝不能简单地认为就因为一个点导致的。

这也是争论的来源，每个人说的观点从某一角度看都是正确的，但放在一起就是会出问题。

现在的问题是：出现了维护困难，一个熟悉代码的人都需要很久才可以定位问题。

所以你的期望的解决问题的方案是什么呢？

A：就是微服务导致的，微服务是个垃圾？
那请问全球所有做微服务的项目都维护困难了吗？
为啥有人没问题，而你的出问题了。

B：如果不用微服务，问题就解决了？
那请问全球所有没用使用微服务的项目都维护简单了吗？
显然不是。

那回过头来说，到底要不要用微服务？

这问题本身是一个非常傻的问题，就像我问你出门会不会开车一样，你一定会回答“看情况”一样。

微服务是一种工具，而人才是关键。

如果你认为这东西用的溜，符合你思维逻辑，而你又需要对项目负责，你可以用。
如果你认为这东西用的太累，不用的更快，那就不用。

没有绝对的这东西“好”或“不好”

[bronyakaka]

@diagnostics 并发编程都不懂的人？你这么懂并发咱们可以讨论下，口气不用这么嚣张

[IamUNICODE]

@xuld 看下来就你一个人能心平气和讨论利弊，谢谢了大佬🤣

[GeekGao]

不要试图从结果否定一个理念哈，有的时候可能只是你们搞叉劈了。
项目管理混乱，显然不是技术架构的锅。

[GeekGao]

就我们的感悟而言，微服务确实加速了线上迭代效率，任务部署更容易、开发人员的心智也会得到一定的解脱。

[cinlen]

可以肯定的是和微服务本身没啥关系。

我觉得你可以问问那个小伙子是怎么定位问题的，然后研究研究怎么让下一次 "定位问题” 变得简单。

[Linxing]

微服务是搞了 对应的 infra 没跟上吧？

[kk2syc]

@IamUNICODE 你对团队和谐的理解有错误。不是说不吵架就叫和谐。表面上每个人和和气气，背地里互相使坏就和谐了吗？真正的和谐是公平的环境，合理的制度，没有小心思的同事，不搞斗争的领导，公事公办的老板

[Vegetable]

不少人上来就是菜就多练，挺搞笑的。
微服务其本身的会引入什么问题已经被讨论烂了，op 说这些也都没有离开这个范畴。
这些都是客观存在的问题，上马微服务就是要谨慎，要权衡，不是什么万金油方案，无论人的水平如何。

[IamUNICODE]

@kk2syc 啊这，有前者不代表后者会少吧，尤其是人多的地方，基本上没办法避免了——尤其是定位问题困难的时候，笑死

[tyrone2333]

你头像好像朱元璋😂

[skuuhui]

东施效颦

[tairan2006]

50 多个微服务，你们团队有多少人啊……

一般小团队，微服务拆分要很谨慎，太多了就没法维护