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

364 天前
 drymonfidelia
17908 次点击
所在节点    程序员
87 条回复
lvlongxiang199
364 天前
@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 折磨过
Pdk5a8759cbeD6CH
364 天前
@abcbuzhiming @abcbuzhiming 可能咱俩说的大不是一个大的意思吧。这个项目算是国内最顶级公司里最火行业的支撑项目,服务的用户数量绝对是顶尖了。
不是现在考虑转微服务,是已经这么做好多年了,我也是维护之前的东西而已。
Pdk5a8759cbeD6CH
364 天前
@Cloud9527 不这么弄怎么提现技术总监的牛逼之处呢,有些总经理不知道在哪里听了微服务/大数据这些词,没几个用户也要硬上这些。
tt67wq
364 天前
。。。。微服务本质上是让人好安排并行工作,你一个人头整这么多服务????
grzhan
364 天前
不光是运维成本,微服务间调用本身也是开销(还要引入分布式追踪来保障可观测性),且如果拆分服务粒度有问题还会引入分布式事务等可能本不必要的复杂度。

IT 圈一直会一阵一阵过热地吹捧某个技术,但很多场景只有最合适的,没有最好的。
LIMITob
364 天前
一次发布要动这么多服务, 功能耦合这么重度,为啥要拆开呢
akorn
364 天前
@abcbuzhiming #17 按北美的食量,一盒披萨一个人都吃不饱。哈哈哈。

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

感觉微服务比较好的是动态阔缩容,负载均衡,因为服务负载了,业务可以做分布式,比如运算密集型或者大数据量的业务,可以拆分业务域。还有利于灰度发布。单体服务,做灰度发布,由于灰度是完整服务,流量得把恢复上业务全跑通了,才能确定没问题,微服务的话,只要灰度功能自己没问题就行。
runlongyao2
364 天前
@lvlongxiang199 你说的这个是代码管理工具干得事情...
lvlongxiang199
364 天前
@runlongyao2 我反驳的是 "单体架构下往往本身就是面条代码, 一条业务从入口开始就串联一大堆模块, 你不可能说这段代码你写那段代码他写吧?"
nicebird
364 天前
微服务是一个披萨团队维护自己的服务,整个公司有很多这样的团队。
youyouzi
364 天前
要耦合性不强的才有用吧,强行为了微服务而微服务真是
v2Geeker
363 天前
在讨论微服务的时候肯定离不开的一个词,叫「微服务治理」,这可是一堆基建组成的「微服务底座」呀。没有「底座」的话,你所谓的微服务部署简直是地狱,可维护性肯定差。
xuanbg
363 天前
@lujiaxing 你会建设还能不会维护?维护也就维护业务服务,很少需要维护基础设施和基础服务的。业务服务本来就简单到不能更简单,这都维护不了,单体的不是更维护不来了?
lvlongxiang199
363 天前
为楼主独立思考, 没有盲从微服务点个赞

按我的理解, 微服务为了解决单体搭便车上线翻车的问题.
单体的时代, 所有人的代码都跑在一个进程里, 你要上线的功能可能跟别人上线的功能跑在一个进程里头, 一般情况下上线完后, 如果出现异常情况, 运维会选择直接回滚, 如果别人的改动导致了回滚, 也可能会使你的那部分功能回滚. 不搭便车的话, 那就得一个功能一个功能的上线.
切分了微服务, 如果你跟别人改的服务没有相交, 可以同时上线, 即使他翻车了, 也只会回滚他的服务, 不会影响到你

当然在单体里头加 feature flag 也能避免搭便车翻车的情况, 有异常情况, 就直接禁用掉那部分功能

业务复杂并不是拆分微服务的充分条件, gitlab 业务也算复杂(工单管理, code review) 至今也就因为性能问题, 把 git 操作相关的从 rails 单体里头拆出来, 用 go 重写了 https://about.gitlab.com/blog/2022/07/06/why-were-sticking-with-ruby-on-rails/
memcache
363 天前
人多了好协作
lujiaxing
363 天前
@lvlongxiang199 你跟我说的场景根本就不一样. 我说的是业务系统, 你说的是底层组件. 底层组件本来就各模块相对独立. 业务系统逻辑往往是交织在一起, 宛如一张大网一般. 像我们公司的产品, 使用说明都可以写成一本书了. 基本上改哪块都是牵扯一大片. 所以必然是某个人负责一个功能就一杆子捅到底. 即便是抽象出接口, 也不可能分开写. 你接口实现好了, 别人没实现好呢! 一大堆 throw new NotImplementedException() 怎么搞? 调啥都是 NotImplementedException. 总不能调别人接口的地方都写成 mock 吧? 而且万一是 A 依赖 B 的功能, B 依赖 C 的功能呢? 测都没法测. 只能是等别人把功能做完了你才能动手. 要么就是全你自己搞.

至于单体架构的链路追踪, 你说的问题直接给记录入口参数, 时间, 返回内容, 调用堆栈就足够了. 你都知道调用堆栈了还看不出来问题么? 比如说有些竟态导致的 BUG, 其实模拟一下就能复现. 不行拿脚本跑. 游戏测试怎么做的你就怎么做呗. 游戏的逻辑更复杂, 你说的这种难以复现的问题更多. 你看哪个游戏还整链路追踪的? 搞复杂了兄弟. 哪怕实在不行到处埋点都比你直接上一套链路追踪好. 对于单体的链路追踪本质上就是 AOP. 多少会影响性能的.


"一个服务把其他服务串联起来算是面条代码吗 ?" 必然不是. 微服务中每一个服务都是状态无关的. 一个服务处理过程结束之后可以直接广播动作, 其他服务接收到广播就完成各自相应的动作. 中间没有调用关系, 互相不依赖. 而单体架构下往往是一个函数调另一个函数, 另一个函数再调另一个函数. 上下文一大堆. 所以为啥叫面条代码, 面条不就是挑一筷子一长溜一米多长么, 代码也是. 光调用链就几十层, 那可不跟面条一样!
lujiaxing
363 天前
@xuanbg 那我问你. 微服务生产环境发生了一个报错. 导致一个订单的附加订单错误结算. 请问你要怎么排查? 你是准备捋着代码挨个微服务去查是么? 是不是要部署 Skywalking? Skywalking 挂了又要怎么办? 日志分散在各子系统上, 日志收集分析是不是要上 ELK? Kibana 出问题了你知道怎么解决么?
xuanbg
362 天前
@lujiaxing 用得着挨个微服务去查吗?你都不能确定结算错误是产生于业务链的哪个环节的么,这也太搞笑。日志肯定要上 ELK ,Kibana 出了问题还不好办,一条 docker 命令重新创建容器就解决了啊。你咋不说 ES 挂了怎么办呢。。。
lujiaxing
362 天前
@xuanbg 问题就是你只能看到结果是这样的。入参是这样的,中间流转不清楚是哪个环节出的问题。复现不了,又没法跟单体结构一样到处打 log ,没链路追踪你怎么排查?靠蒙是吧?那问题来了,不管是业务网关组件, ES, Skywalking, 还是 Kibana, K8s, 无论怎么说都是增加了系统的复杂度没错吧? 增加复杂度一定会增加出问题的概率你总不可能否认吧? 出问题了怎么解决? 你说重新创建容器就能解决, 看来你也就会这一招了啊. 如果重新创建容器都起不来了呢? 如果某一块核心子系统一直在报错呢? 搞不好就是因为子系统过多, 某个子系统的配置文件里少写了一个逗号导致各种报错呢? 你能在多长时间内发现并解决问题? 生产环境不等人, 一分钟的失效都是真金白银的损失. 你是准备拿你的年终奖赌这些周边系统以及业务子系统绝不可能发生这些事情?
ciki
362 天前
多团队多开发语言的情况下用挺好,其他还是单体梭哈吧

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1082359

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX