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

[IamUNICODE]

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

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

[boboaiya3]

凤凰架构

[azhong123]

@idblife 老板只需要考虑裁员,CTO 要考虑的就多了

[runninghipp]

非常不好

[Richared]

我已经参与过两次微服务改单体了。做的算法模型平台，压力根本不在业务测，都在 hadoop ，spark ，flink 上。现在没钱招那么多人，也不招工资高的，根本维护不了。

[wqhui]

定位问题耗时长
一、bug 原因确实复杂，需要特定条件才能触发，可能涉及硬件或者非自己系统代码问题
二、监控、日志没做到位，关键日志丢失或者不好找，比如没做微服务日志收集管理
三、研发人员太菜没经验

[Navee]

很不错的
行情好的时候拆微服务 kpi
行情不好了合并微服务又是 kpi

[jeesk]

@Navee 当年上云， 成本减少 50%。 这几年下云， 成本有减少 50%。 双赢。

[shadowyue]

😅还微服务呢，看我之前发的那个跨域问题的帖子，有多少个收藏，吵架了多少个跟帖，你就知道大家水平都是草包。
怎么简单怎么来才是最好的。真的遇到瓶颈了再去想办法。

[ilvsxk]

@shadowyue #88
这就有点过了吧，怎么大家都是草包了？
你那个帖子说明你对跨域停留在简单理解上，并没有太多实际业务中的跨域边界问题实践经验。

[shadowyue]

@ilvsxk 世界上百分之 99 的人都是草包，我也是草包，草台班子才是世界的常态。

[lasuar]

小公司搞不定微服务，80%的问题都是水平问题。

[1252603486]

控制项目复杂度是最难的，一个项目复杂度上去之后，什么框架都没用，直到最后彻底无法维护，公司决定重写一个，毕竟公司可不关心项目是不是一坨屎，只要能赚钱就可以了。

[dongzhuo777]

@sujin190 我司这也这样乱过一阵子，后面复盘出现的很大一部分原因是 组织架构的调整，微服务的架构设计如果只是根据业务来划分，没有按照公司实际的物理组织架构去划分 后期一定会出现这种灾难的。

[adgad2]

微服务是这样的，项目复杂度至少比单机高一个级别

[dongzhuo777]

@adgad2 但是需要上微服务的项目复杂度本身就很高，有些项目系统都有几十个 要做集成不用微服务用单体 压根打包都做不到

[sujin190]

@dongzhuo777 #93 我司这个是既不按业务边界划分也不按组织架构划分，通过各种接口各种 mq 消息相互调，接口消息感觉就是想改就改，前向后向兼容几乎不咋考虑，也就是流量实在太低，各种人工改数据修正搞得定，客户不会分分钟打爆客服电话，否则感觉就是分分钟崩溃的节奏，都无语死了。。

[adgad2]

@dongzhuo777 不知道，之前我们做社交的上了微服务，复杂程度高了不少，挺考验技术的，本地开发也麻烦，docker 都要起好几个

[noyidoit]

@Richared 请问当年改成单体的过程中有没有遇到什么坑？可以简单讲讲吗

[pushback]

包升级跟微服务没太大关系，有些 leader 喜欢乱拆，多拆，才是最大的问题。

[JiRouWaZi]

微服务难道不爽吗？你们只是缺一个优秀的 devops ，如果整套工作流都走通了，爽爆