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 都玩不了. 原神跟星铁只能云. 绝区零连云都没有.

来，我要玩原神，星穹铁道，绝区零，绝地求生，老头环，糖豆人。。。。。。

在 Mac 上启动一个我看看

@tdb11039gg 对. 像成都那边现在, 活跃网络 (环汇集团), Seismic, Audatex (翱特), 西门子, Intel 等都还在的.

@rick13 这种一般都是在成都、武汉、西安这类的地方。工资相对比较低。你以为这帮外企做慈善呢 2333

目前已知的是有在华业务的大部分都在清场撤离.
有些外企是只有研发团队/客服团队在中国大陆. 在华没有业务. 这种基本不受影响.

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

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

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




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

对于这个年纪的小朋友, 最重要的并不是锻炼什么所谓的编程能力, 而是他的逻辑思维、空间思维以及想象力. 这对未来的数学以及物理课程来说是相当有帮助的. 当他能在大脑里凭空想象出一个完整的逻辑链条的时候, 他的数学能力将会突飞猛进. 未来学几何会容易得多.

所以去花时间去让他研究什么语法, 什么原理其实屁用没有, 最好就是给他弄个开源的 scratch, 让他在拼图的过程中理解什么叫做逻辑. 这才是最重要的.

@fansmaster 怎么可能... 京东金融一度到了需要动用同行拆借来补窟窿的地步, 你觉得这次京东金融的亏损会小么? 这大窟窿不动用全公司的全年利润怎么补? 别想了今年你们年终没了.

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

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

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

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


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










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

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

推进去干啥啊？京东全员今年能不能拿到年终奖是个大问题你还推？？？？