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

[drymonfidelia]

[jenson47]

自动化部署，软件包与配置分离，这样子接入微服务会简单点。
我看有些 java 包都是拖家带口，配置都打在里面

[jorneyr]

对于中小型公司来说，微服务的开发成本、运维成本至少增加一倍。

[guiyumin]

微服务首先说从 amazon 开始
jeff bezos 要求所有团队用 api 和其他服务交互
于是就出现了微服务这个模式
然后就大行其道了

[faceair]

项目大到一个人只维护一个微服务里面的部分功能的时候就合适了，你这还是不够大

[guiyumin]

实际上，github 是 ruby on rails 单体的

微服务本质上是为了快速迭代，运维上的好处是一个服务挂了，不至于让其他服务也挂，尤其是服务之间的重要程度不一样的情况下

但显然增加了复杂度

[ytmsdy]

个人觉得微服务的主要目的就是为了方便扩容。比如一个登录模块顶不住了，我就多加 10 倍的量进去，流量没了就撤掉。如果都放在一个大程序包里面，那扩容就会比较麻烦。
第二个其实就是为了开发方便，不说其他的，服务拆出来以后，你往 main 分支合并代码的时候都能轻松不少。

[ncbdwss]

团队大的才有价值。几个人的小团队搞这个就是作死，自找麻烦。

[cominghome]

微服务和 K8S 有点像，小型团队用起来会很痛苦，但是过了那条规模线，好处是显著地多过坏处的

[carytseng]

规模不够就没必要上微服务

[chloerei]

Monolith First https://martinfowler.com/bliki/MonolithFirst.html

> 当我听到有关团队使用微服务架构的故事时，我注意到了一个常见的模式。
>
> 1. 几乎所有成功的微服务故事都是从一个变得太大而后被拆分的整体开始的
> 2. 我听说过的几乎所有从头开始构建为微服务系统的系统最终都陷入了严重的麻烦。
>
> 这种模式导致我的许多同事认为你不应该用微服务启动一个新项目，即使你确信你的应用程序足够大，值得这样做 。

[wangxin13g]

除非有千人以上的研发团队，不然用微服务拆分纯属没事找罪受。

[dylanqqt]

@wangxin13g 微服务并不是人多才用吧，是业务规模大，业务逻辑复杂才会用吧，我们十多个人负责几十个服务。

[Geekerstar]

只有我一个后端的项目也上微服务，还有一堆运维监控中间件，访问用户只有几个，问就是客户要求微服务

[hhacker]

我觉得微服务贵...

[lvlongxiang199]

@lujiaxing
1. 微服务边界拆分不合理, 也会出现一个功能改多个微服务的情况. 我不明白你是咋得出"这时候微服务可以很好的让团队成员聚焦于某一个具体的模块"这个结论的. 如果把模块拆好, 一个功能只改一个模块, 就算是跑在一个进程里, 又有啥问题 ?

2. 放 docker 里

"链路追踪" 不是微服务特有的问题. 微服务比单体更容易实现 trace. 如果都在一个进程内, trace 只能靠手动埋点. 拆了微服务, 一般通过 rpc 调用, 可以用中间件的形式来统一实现 trace

[mightybruce]

你要是 2016 年来提这个问题，我还有点兴趣，那时候微服务治理发展阶段才开始不久。

这个问题现在还不知道怎么解决，我只能说你们上微服务就是错误的选择。

[pangdundun996]

微服务跟业务团队架构挂钩的

[KP45]

好的质量是设计出来的，微服务可以让生命周期不同的服务独立开来，也可以让核心服务和其他不重要的服务采用不一样的质量标准和做到质量隔离，如果你的业务也要引用类似认证或者短信这样的服务，你对它们的期望就是稳定可靠别影响自己，看问题要先脱离屁股决定脑袋

[sampeng]

已经是月经帖了。没为什么。就是因为 team leader 要。刷简历有东西可以说啊。

微服务再好，我就没见过微服务划分合理的，一发布还是跟个大单体一样。

[wxw752]

微服务要解决高并发情况下部分服务用量大，动态扩容的问题啊。没有并发别搞微服务