微服务到底在哪个方面让开发、维护简单了？怎么看都是变复杂了，原本配置一次数据库就能跑，现在要配置八九个容器和数据库，更新一次要配置好几个服务

[drymonfidelia]

[lvlongxiang199]

@lujiaxing "单体架构下往往本身就是面条代码, 一条业务从入口开始就串联一大堆模块, 你不可能说这段代码你写那段代码他写吧?" 为啥不可以 ? 我可以给不同的模块划分不同的维护者. 比如 tidb 进程内的每个模块都有不同的 owner: https://github.com/pingcap/tidb/blob/master/pkg/expression/OWNERS https://github.com/pingcap/tidb/blob/master/pkg/ddl/OWNERS

"难不成要变成 "你等他的模块写好, 他等另外的人的模块写好"" 为啥不能同时进行 ? 我可以抽象成接口进行 mock. 我可以约定好你这个模块产生什么样的输入, 然后两边并行开发

"还是说你先写好了结果顶着编译器报错提交代码" 微服务将接口改起来得小心翼翼, 避免变得不兼容. 单体改完接口还有编译器检查错误

"你负责订单你就一直负责订单, 订单完成后的事情, 什么加积分, 客户升星级, 结算分佣这些" 我可以在单体内划分出不同的模块, 每个人专注于不同的模块


"至于链路追踪就更搞笑了. 单体项目还需要什么链路追踪? " 为啥不需要呢 ? 比如 https://github.com/prestodb/presto, 一个 sql 打进了, 我想看到产生的逻辑/物理计划啥样, 切分成了哪些 fragment, 每个 fragment 有几个 task 打到了哪些节点上, 这不值得上个链路追踪吗 ?



"单体架构下往往本身就是面条代码, 一条业务从入口开始就串联一大堆模块," 一个服务把其他服务串联起来算是面条代码吗 ?

"生产环境哪里报错了有完整的调用堆栈. 甚至可以在错误日志里打上下文. 你拿着数据自己去调试就好了. " 你这是没被跑几百次才出现的 bug 折磨过

[dylanqqt]

@abcbuzhiming @abcbuzhiming 可能咱俩说的大不是一个大的意思吧。这个项目算是国内最顶级公司里最火行业的支撑项目，服务的用户数量绝对是顶尖了。
不是现在考虑转微服务，是已经这么做好多年了，我也是维护之前的东西而已。

[dylanqqt]

@Cloud9527 不这么弄怎么提现技术总监的牛逼之处呢，有些总经理不知道在哪里听了微服务/大数据这些词，没几个用户也要硬上这些。

[tt67wq]

。。。。微服务本质上是让人好安排并行工作，你一个人头整这么多服务？？？？

[grzhan]

不光是运维成本，微服务间调用本身也是开销（还要引入分布式追踪来保障可观测性），且如果拆分服务粒度有问题还会引入分布式事务等可能本不必要的复杂度。

IT 圈一直会一阵一阵过热地吹捧某个技术，但很多场景只有最合适的，没有最好的。

[LIMITob]

一次发布要动这么多服务， 功能耦合这么重度，为啥要拆开呢

[acorngyl]

@abcbuzhiming #17 按北美的食量，一盒披萨一个人都吃不饱。哈哈哈。

最近见了不少小公司，用户量几万不到，本来一台 pc server 搞定的事情，非要上微服务，多想不开啊。人家用微服务的公司，光运维团队，比小公司开发人都多。

感觉微服务比较好的是动态阔缩容，负载均衡，因为服务负载了，业务可以做分布式，比如运算密集型或者大数据量的业务，可以拆分业务域。还有利于灰度发布。单体服务，做灰度发布，由于灰度是完整服务，流量得把恢复上业务全跑通了，才能确定没问题，微服务的话，只要灰度功能自己没问题就行。

[runlongyao2]

@lvlongxiang199 你说的这个是代码管理工具干得事情...

[lvlongxiang199]

@runlongyao2 我反驳的是 "单体架构下往往本身就是面条代码, 一条业务从入口开始就串联一大堆模块, 你不可能说这段代码你写那段代码他写吧?"

[nicebird]

微服务是一个披萨团队维护自己的服务，整个公司有很多这样的团队。

[youyouzi]

要耦合性不强的才有用吧，强行为了微服务而微服务真是

[v2Geeker]

在讨论微服务的时候肯定离不开的一个词，叫「微服务治理」，这可是一堆基建组成的「微服务底座」呀。没有「底座」的话，你所谓的微服务部署简直是地狱，可维护性肯定差。