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

[IamUNICODE]

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

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

[fkdtz]

查问题困难问题出在没有统一规范吧，如果各服务有统一的输入输出标准和监控项，加上链路追踪，起码可以快速定位到是哪一个服务的哪一个接口出问题

[sagaxu]

2015 年开始搞微服务，全套自研，大概有一两百个独立服务，然后哦业务数据还不错，冲击上市。2019 年开始搞中台，然后迅速下坡路，2024 年还剩不到 10%的员工。

以上只是时间上有耦合，无因果关系。

[GooMS]

可以有效解决大家没事做的问题

[momo2789]

人菜草台班子跟微服务没关系啊

[miscnote]

微服务不止是搞搞研发，通常 sre 也要跟上。所以大公司喜欢弄这个，小型公司就没必要为了这个名词而去跟风了。

[idblife]

@IamUNICODE 50 个不算多，我们有一千个左右

[opengps]

你要说中台还行，属于业务层面；微服务纯技术架构，背不了这锅

[skyworker]

@bronyakaka 其实最重要的一点是, 没有微服务经验, 下一份简历不好写

[murmur]

我们是搞了微服务没有做容器化，还是用商业版的虚拟机

[IamUNICODE]

@idblife 6

[IamUNICODE]

@sagaxu 2019 年迅速走下坡路是因为经济形势吧

[yunpeng2015]

微服务会带来运维等方面的困难，如果设计的不好，没有很好监控 追踪管理，那么问题会更严重

[hangszhang]

组织架构决定系统架构，微服务又不是让一个人维护所有的子系统

[wlm201219]

接触过两个公司
一个从其它语言转过来的，项目组总共就十来个人，上来就要上微服务，结果半年的工期拖成了一年，老板贴钱给员工发工资，最后幸好上线了，也是不幸中的万幸

另一个更搞笑，总共二十来个人，硬是拆出了 50 多个微服务，平均两张表一个微服务，无法理解。后续就没关注了，大概已经没了吧。

[lvsshuttao]

就算没有链路追踪，请求其它接口返回的数据也会打一下日志的吧😅

[sagaxu]

@IamUNICODE DAU 早在 2017 就到顶了，DAU 开始下坡路的时候，如果不能挽救，那就只剩赚钱套现一个思路了，一切向钱看的时候，死的更快。很多 App 都这样，广告位越来越多，黑五类广告来者不拒的时候，结局就注定了。

[gitrebase]

@IamUNICODE #11 你们一个组的微服务有 10 个吗我靠

[ClericPy]

十年前的微服务，和十年后今天的云原生一样，好好学几个月再上，又快又稳定

一点都不学闭着眼百度搜个 CSDN 就上，写出来的跟屎一样然后加薪跑路，这锅甩的一点都不优雅

两句话深以为然：软件工程没有银弹；人和人的差距比人和狗的差距都大。水平不够的反而感觉写点小脚本上 serverless 更不耽误下班时间

[diagnostics]

你要是说无脑拆微服务，那确实有问题。

哪个大型项目不拆分服务？举例：B 站历史记录和评论系统分别崩溃过一次，但是其他播放等功能完全不受影响。（你单体试试？）美团的优惠券券查询页面崩溃过一次，但是下单、浏览，甚至使用优惠券都不受影响（你微服务试试？）

阿里云去年崩溃过一次，整个淘宝几乎不能访问了。

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

菜就多练。我们排查问题，虽然部署了 skywalking ，但是没权限，但是我们日志里也会记录一下 traceID ，用集中式日志检索平台一搜索（ splunk ），看哪个系统没打这个记录（我们这一个请求最多跨 5 、6 个），再去这个系统去看具体的日志。

[IamUNICODE]

@diagnostics 按照功能拆不难理解，之前我们也是这样拆的，但是这么分散，还是很难理解的。
你说的这些这边都有，但是最后发现是某个包没升级造成字段缺失，这个排查有什么优化方案么——我是不怎么懂哈，毕竟我没有做过这种微服务，所以你是觉得这边人很菜吗？