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

[drymonfidelia]

[kneo]

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

[povsister]

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

[lujiaxing]

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

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

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

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


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










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

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

[Int100]

说明你的规模还不够大

[wuyiccc]

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

[RightHand]

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

[spiffing]

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

[chendy]

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

[houshuu]

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

[cookii]

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

[beginor]

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

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

[kzfile]

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

[Configuration]

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

[uiosun]

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

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

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

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

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

[wujianhua22]

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

[kaneg]

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

[abcbuzhiming]

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

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

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

微服务不是灵丹妙药。

[vikaptain]

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

[dddd1919]

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

[249239432]

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