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

[drymonfidelia]

[codegenerator]

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

[CoderLife]

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

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

[abcbuzhiming]

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

[zzsong]

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

[gejun123456]

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

[dylanqqt]

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

[aino]

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

[abcbuzhiming]

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

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

[rahuahua]

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

[xuanbg]

@lujiaxing
@wujianhua22
@vikaptain

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

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

[xuanbg]

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

[lujiaxing]

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

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




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

[iyaozhen]

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

[Cloud9527]

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

[zypy333]

康威定律

[jeristiano]

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

[lujiaxing]

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

[vacuitym]

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

[q958951326]

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

[yor1g]

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