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

优势是允许不同团队自己搞自己的。
宏观上效率肯定是降低了。
但是对负责特定服务的团队来说是简单了。
至于你说的嘛，对不起，运维自己想办法。

如果这些都要你自己配置，那你只是强行在用微服务。不用自己运维爽的一批好吗

微服务只在特定的情况下让开发、维护简单了.

1. 在项目功能极其繁多, 开发团队冗杂的情况下, 经常会出现若干个人改一个模块, 一个人改若干个模块的情况. 这时候微服务可以很好的让团队成员聚焦于某一个具体的模块, 而不是改一个功能, 又要考虑 A 模块, 又要考虑 B 模块, 又要考虑 C 模块的. 功能细分做详细了, 每个人做好自己的就行.

2. 微服务很适合 CI/CD 自动化部署. 反正交付的都是一堆 tar 包, 运维部署交给自动化脚本就行了. 运维只负责看服务器有没有啥问题没, 不用担心什么这儿又缺环境啊, 那儿又配置不对啊等等乱七八糟的事情. 上线自动灰度. 反正程序本身也会变成资产, 自动化运维程序只要把程序也当成资产处理就行了.

3. 微服务适合高访问量产品, 可以充分利用各云平台对不同的模块做自动伸缩. 比如明天我们要做双十一, 预计商品模块, 订单模块访问量都会很大, 那么微服务项目就可以充分的利用云平台自动伸缩的功能, 在服务访问量大的时候自动扩容, 同一个模块, 一个支撑不过来, 我拿十个顶. 等流量下去了之后, 再缩回来, 以节省服务器成本. 而这期间不用担心所谓上了一堆与其无关的模块而影响部署效率或者执行效率. 这点对于用 java 这类能效比极其差劲的东西来说非常重要. 试想如果你要应对大并发, 需要重复部署项目做 LB, 结果一部署好几十个 jar 包, 有用没用的都得上. 上完了一起来屁事没干 1g 内存没了. 微服务的模块只要上那么一个模块而且还是自动的, 只需要几个 jar 包, 无关的东西一律没有. 一起来只有 200m 内存占用... 那么服务器能效比高下立判.


但是微服务也不是万能的.
就像你说的, 微服务部署起来极其麻烦, 需要做包括但不限于内部网关, 链路追踪, 微服务治理等. 对于一些统计报表类功能极端不友好 (试想, 一个报表要跨订单、账单、用户、积分等等子系统, 你要怎么查?) 一般都还要上 ClickHouse 这类的鬼东西. 所以微服务一般只适用于团队规模特别庞大, 产品使用量特别大或者特别复杂的情况.










当然, 如果你一个人的话, 微服务当然也会让你的开发、维护变得简单.

就是你会微服务了你就可以在公司吹牛逼或者在面试时候吹牛逼, 然后得到一个 Technical Leader 或者 VP 的岗位. 开发、运维都不需要你亲自动手了, 只有动动嘴皮子让手下去头疼就好了. 那对你来说难道不就是开发和维护变得简单了么 23333

说明你的规模还不够大

等有人写的代码干停整个业务服务就老实了

增加了用人量，降低了失业率，容易晋升。至于什么规模化，自动化，这不是微服务特有的优点

各团队有自主权了，不能既要又要

原本配置一次数据库就能跑，现在要配置八九个容器和数据库
微服务场景下八九个容器有八九个人或者团队负责
什么只有一个人？那微服务个集贸啊

如何合理的分割整个业务逻辑到数个微服务也是个技术活，团队规模，更新频度都是要考虑的

想象一下，你写代码的时候，把代码全写到一个文件里简单，还是把代码写到多个文件里简单。

容器做好了，把配置和数据都放在容器外面挂载，灾备恢复的时候最爽了，直接 docker compose up 就启动。

要是独立部署的数据库你就慢慢装，慢慢配

规模/复杂度上去后才进入微服务舒适区

感受不到微服务的好处是因为你所接触到的系统太过简单

微服务是指：你负责一个庞大项目中的、一个切分出去的小服务，你会感觉“我只需要写好自己的一亩三分地，太快乐了！”

而不是让一个人去负责庞大项目——还要求你用微服务架构，运维成本加 N 倍、还需要考虑系统间 RPC ，更别提微服务很多都带跨服务调用测试的，写了吗，不写怎么保证可用性。

想想这些工作量，人都要哭了。

而且多数更新都需发布多数微服务，说明你们微服务的业务切分没做好。

@Configuration 兄弟你说啥呢哈哈哈，他是系统太简单嘛？怎么看都是一、俩人的迷你团队，还要上微服务，还没切好模块，搞得要死要活……

凭什么你几个人的小团队就敢用微服务

要为服务化，自动化是必不可少的，就是要用机器替代人做很繁琐的事。 如果做不到这自动化，人当机器，那不感觉繁琐才怪。

老外有个暴论：当你的团队人数用一盒披萨就能喂饱的时候，你根本不需要微服务这东西。

微服务一定要系统足够庞大，庞大到不拆分几乎无法维护的时候，才会有意义——相对微服务带来的那些问题：运维麻烦，各数据分散在不同的存储中，报表困难。

另外和大家想的不一样的是，不要觉得微服务上了，就真能各团队独立，这其实是个幻觉，现实是大概率你把你的服务改了，一个依赖你的服务挂了，这才是普遍现象。

微服务不是灵丹妙药。

上微服务起码得有几个人专门帮你搞定各种基础设施吧，你要是一共就几个人，那你还上啥微服务啊。

服务复杂到一定程度才能看到微服务的收益，如果项目中有大块的不相干功能模块，一次编译启动要若干分钟，那是个拆微服务的好时机

老子自己一个人的项目，jsp+servlet ，简单快乐

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

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

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

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

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

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

但显然增加了复杂度

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

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

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

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

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

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

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

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

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

我觉得微服务贵...

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

2. 放 docker 里

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

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

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

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

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

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

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

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

因为大部分人根本不知道微服务到底是干什么的
很多时候是以讹传讹

现在有些人是为了微服务而微服务

之前接手过一个项目, 一个 crm 也用微服务, 然后跑在一个服务器上....

@dylanqqt 虽然那位说上千人有点夸张了。但是你这十多个人维护的几十个服务，也能叫业务规模大？

微服务的本质就是软件开发流水线化，一部分人专注造发动机、一部分人专注造变速箱、还有一部分人去造轮胎，最后再将这些流水线产物组装起来。流水线化之后人工就变得不值钱了，每一个流水线上的工人都是螺丝钉，随时可以替换掉。同时带来的也是大规模生产上的效率提升。

尽量别用，单体实在解决不了再上，微服务维护起来比单体麻烦多了，大部分项目用不上。

@abcbuzhiming 还真挺大的，十几个人只是纯后端。

微服务是开发的福报 一定程度上 可以增加程序的复杂度 提升就业 建议多搞点这些
微服务 大数据 人工智能 分布式 区块链 我什么都加进去

@dylanqqt 朋友，十个人纯后端的项目真不能算大的，国外推荐开始考虑微服务的时间点，基本都是你已经有几十个不同功能开发小组的时候，而不是十几个人的时候。
当然，你这个时间点可以开始考虑转微服务，只是我觉得此时收益和付出的代价比还是不够。

微服务其实是一个“在到了一定条件下不得不选”的选择，而不是一个“更好的”选择。我觉得所有人在决定上微服务前，都得想清楚这个区别

你这么想，抖音 app 后端工程师加起来上千个，应该怎么做呢

@lujiaxing
@wujianhua22
@vikaptain

搞微服务，必须要懂点运维，至少要会用 docker 吧。而且要先搞定基础设施，如网关、注册中心、配置中心、统一日志收集这些。基础设施其实很容易搞定，譬如我在一个新的环境部署一套，也就 2 小时吧。你要是这些不会的话，那就别玩微服务了。

然后，你要先搞一些基础服务，譬如用户服务、身份认证、角色授权这些。基础服务由于和业务没有耦合，所以不管你有多少套业务系统，基础服务之需要开发一套就行。就用这一套代码到处部署，每次部署只要 3 分钟。基础服务有了，纯业务就真的很简单了。这个套路形成后，一个人就能玩转微服务。

微服务的建设过程对于生手来说主要难在前期，但这个对于熟手来说就一点都不难，甚至一个 shell 脚本就能搞定。不过进入后期大家喜闻乐见的狗都能行的 CRUD 环节，就真的毫无难度了。

@lvlongxiang199 你自己都说了是服务边界拆分不合理. 正常情况下都是每个人负责各自的功能, 你负责订单你就一直负责订单, 订单完成后的事情, 什么加积分, 客户升星级, 结算分佣这些, 不归你管你就不要管啊, 也用不着你管啊?? 所以自然就不可能去改别人的模块啊... 更何况微服务甚至还支持不同模块使用不同的开发语言来完成. 怎么别人用 C# 写的模块你也去改么? 你改得来不? 单体架构下往往本身就是面条代码, 一条业务从入口开始就串联一大堆模块, 你不可能说这段代码你写那段代码他写吧? 还不是你一个人从入口开始把所有逻辑开发完么? 难不成要变成 "你等他的模块写好, 他等另外的人的模块写好"? 还是说你先写好了结果顶着编译器报错提交代码?

微服务就没这问题. 大家都是走 RPC 接口, 接口定义好了我调就是了. 不是我的模块的接口单测也可以写 mock, 而不需要非要等别人的接口写完. 这就是我为什么说让团队成员聚焦于某一个具体的模块.




至于链路追踪就更搞笑了. 单体项目还需要什么链路追踪? 还埋锤子的点? 单体应用开发阶段可单步调试, 生产环境哪里报错了有完整的调用堆栈. 甚至可以在错误日志里打上下文. 你拿着数据自己去调试就好了. 埋什么点?

“原本配置一次数据库就能跑，现在要配置八九个容器和数据库”
我表示存疑 即使你是假上云 也不会这样吧

我们这用户小几千，日活不过百。领导生生弄出来十几个服务，简直无敌

康威定律

@Cloud9527 我也有同样的困惑啊！！！

@xuanbg 问题是不是说有多难, 而是没必要. 搭建这些没啥难度. 问题是怎么维护, 出了问题怎么解决. 环节越多, 出问题的概率越大. 这也就是为什么如非必要, 微服务是万万不可乱上的根本原因.

要结合一些其他服务，都要自己配就很烦，像我们所有的 pod 都托管在阿里云，然后节点自动扩容自动增加节点自动销毁节点，就很方便

说明你们只是为了用而用，没有分析这个东西：
对运维有什么好处和坏处？
对开发有什么好处？
对更新有什么好处？
对测试有什么好处？
任何东西都没有绝对的好与坏，都是相对的。
无论身处什么岗位，都需要思考得失，而不是别人说好用你就拿来用。

说好的是自己只负责其中一两个服务 不是把原来系统拆几个然后都自己负责🤣

@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 折磨过

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

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

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

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

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

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

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

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

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

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

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

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

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

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