lujiaxing

VLC 啊...

@xuanbg 本来就是这个意思.... 你这话表露出来的意思就是 "三脚猫的 DevOps 也可以 hold 住生产环境微服务架构"... 还 " 懂 '点', '会用' "...... 微服务那玩意没有个技术经验丰富的技术大牛把握的话根本就没法搞. 风险太大了. 而且 "因为公司一直没用使用过微服务架构, 所以从项目负责人到运维工程师到一线开发所有人对 DevOps 都不太了解" 这种事简直太常见了. 中厂小厂们基本都是这个样子. 而且就算是我们这种垃圾二线城市, DevOps 的工资都要 2.5W 以上, 普通 CURD 只要 1.5W~1.8W.... 团队负责人脑子抽了在没用微服务架构需求的情况下下这么大成本去招这么一号人?

@xuanbg 仅仅只是知道怎么部署, 怎么给各系统跑起来 知道个 kubectl run docker-compose up 就以为自己可以上微服务就敢往生产环境上上微服务的, 你的年终奖几天就扣光了.

@xuanbg 那就不是 "懂点运维，会用个 docker" 就行的. 想搞微服务, 起码要对整个一套微服务用到的所有组件全都要有相当丰富的运用经验. 知道报错之后大概要从哪里入手分析解决, 知道各组件的各种细节. 绝不是 "懂 '点' 运维" 就行的!!!

你以为 DevOps 工程师工资比 CURD 开发工资高出几倍是因为什么?????

原神. 希诺宁真好用!

@xuanbg 问题就是你只能看到结果是这样的。入参是这样的，中间流转不清楚是哪个环节出的问题。复现不了，又没法跟单体结构一样到处打 log ，没链路追踪你怎么排查？靠蒙是吧？那问题来了，不管是业务网关组件, ES, Skywalking, 还是 Kibana, K8s, 无论怎么说都是增加了系统的复杂度没错吧? 增加复杂度一定会增加出问题的概率你总不可能否认吧? 出问题了怎么解决? 你说重新创建容器就能解决, 看来你也就会这一招了啊. 如果重新创建容器都起不来了呢? 如果某一块核心子系统一直在报错呢? 搞不好就是因为子系统过多, 某个子系统的配置文件里少写了一个逗号导致各种报错呢? 你能在多长时间内发现并解决问题? 生产环境不等人, 一分钟的失效都是真金白银的损失. 你是准备拿你的年终奖赌这些周边系统以及业务子系统绝不可能发生这些事情?

@xuanbg 那我问你. 微服务生产环境发生了一个报错. 导致一个订单的附加订单错误结算. 请问你要怎么排查? 你是准备捋着代码挨个微服务去查是么? 是不是要部署 Skywalking? Skywalking 挂了又要怎么办? 日志分散在各子系统上, 日志收集分析是不是要上 ELK? Kibana 出问题了你知道怎么解决么?

@lvlongxiang199 你跟我说的场景根本就不一样. 我说的是业务系统, 你说的是底层组件. 底层组件本来就各模块相对独立. 业务系统逻辑往往是交织在一起, 宛如一张大网一般. 像我们公司的产品, 使用说明都可以写成一本书了. 基本上改哪块都是牵扯一大片. 所以必然是某个人负责一个功能就一杆子捅到底. 即便是抽象出接口, 也不可能分开写. 你接口实现好了, 别人没实现好呢! 一大堆 throw new NotImplementedException() 怎么搞? 调啥都是 NotImplementedException. 总不能调别人接口的地方都写成 mock 吧? 而且万一是 A 依赖 B 的功能, B 依赖 C 的功能呢? 测都没法测. 只能是等别人把功能做完了你才能动手. 要么就是全你自己搞.

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


"一个服务把其他服务串联起来算是面条代码吗 ?" 必然不是. 微服务中每一个服务都是状态无关的. 一个服务处理过程结束之后可以直接广播动作, 其他服务接收到广播就完成各自相应的动作. 中间没有调用关系, 互相不依赖. 而单体架构下往往是一个函数调另一个函数, 另一个函数再调另一个函数. 上下文一大堆. 所以为啥叫面条代码, 面条不就是挑一筷子一长溜一米多长么, 代码也是. 光调用链就几十层, 那可不跟面条一样!

@BruceFerrari 都玩不了. 原神跟星铁只能云. 绝区零连云都没有.