@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

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

好东西。不过我不用 golang...

@irisdev Go 现在基本都是大厂跟外企用的多。做 DevOps 跟底层组件。小厂 Go 的岗位数量跟.net 没多大区别。

@zeal7s 都不学。离开软件行业吧。原来几年好歹做软件/互联网的还能挣个两三万一个月的工资，现在基本上一个月一万都算高的了。好多人一个月只有几千。跟其他行业并没有多大区别。开个火锅店一个月都能赚几千，干嘛非要在软件这边卷。

或者深入研究一下数学，然后投身金融领域。虽然风险高，但是收益也高得离谱。