不买

6 万亿？？？吓死我了，现在央行放水也通过微信转账了吗？

一般我遇到无法保存的时候，都取消掉不保存，然后全选一下复制到一个新文件里面试试看能不能保存。总之不能慌，一慌就容易出错。

很简单啊，不买！

有多少国企改制，又有多少职工下岗。干着干着就改制了，改制了就不是国企了呀。更惨的是干着干着就下岗了，下岗了你和国企也就没啥关系了。

你说你能在国企能干一辈子吗？

@putaozhenhaochi 不过医生的知识体系里面关于诊断的知识基本上不太需要更新，而且占比较大，自然积累比较多。而程序员的知识体系里绝大部分都是需要更新，自然积累比较少。这一点造成医生在知识积累上面比程序员占优。

特殊情况下可以这样搞没问题。

不要相信装修公司

刚退租，看楼上各位，我估计我两千来块的提现也悬了啊。

@yulon C 艹在他们手里就更离谱了🐶

这不是和在一个循环里面把一个对象属性改改放进去 list，然后发现整个 list 里面的对象属性全都和最后一个一样一回事嘛。

@acmore 不存在是否需要微服务，只存在是不是会搞微服务。不会搞瞎搞微服务，就会显著增加开发和维护成本。会搞微服务的，是显著减少开发和维护成本。因为基础设施的建设是前期一次性投入，后期只需要开发和维护纯粹的应用服务。单个应用服务相对于庞大的单体架构，只需要实现业务逻辑，复杂度会大大降低。

@xylophone21

单体服务：要死一起死。一个模块挂掉导致整个服务挂掉
微服务：死道友不死贫道。一个服务挂掉不影响非依赖服务
单体服务：要上一起上。搞点小改动，整个系统都升级
微服务：你上你的，我上我的。改哪个升级哪个
单体服务：搬来一大家子新邻居。每个系统都有一大堆基础功能模块
微服务：欢迎小朋友加入大家庭。多个系统可以共享基础设施

这个参数验证怎么能优雅得起来呢？你这个接口接收的参数被设计成绝对的灵活，没有丝毫的规则可言。这种设计本身就不优雅，你让参数校验怎么去优雅！

因为 C 环境并不常见，所以 B 模块没有预见 C 环境的特殊问题导致崩溃是正常的，测试用例不可能做到 100%覆盖的嘛。

A 业务为啥要选择使用 B 模块？有没有考虑 C 环境的特殊问题？反正，得负主要责任。至于网关 D，我不知道楼主说的切走是怎么个切法？路由策略还是服务降级？如果是需要配置但没有配置的话，也有责任。

拆分不合理不代表没有拆分的必要，只是拆分得不对而已。微服务的拆分，业界公认原则是按领域来进行拆分。

微服务的好处是一次建设终身受益。因为你在建设微服务体系的时候，会把业务无关的东西都拆分出来，变成整个系统所有业务共享的基础设施。这样一来，下一个业务就不需要重复建设这些基础设施，只需要关注业务本身就可以了，开发效率自然就大大提高。

提高下飞机驾驶技术的话，会维护静态路由就足够了。路由器的作用就是根据路由表转发 IP 包给下一跳的网络设备而已。

jenkins 可以为每个项目的每个环境分别建立一个 job 。job 里面可以选择执行不同的脚本来复制对应环境的配置到打包目录进行打包和发布。

结构！结构！！还是结构！！！

结构设计对了，你会发现所有的功能都早就有合适的坑位在那里，就等着你去把这些细枝末节拼装上去。结构没设计对，总有些功能只能很不优雅地强行拼凑上去。这个时候，就该重新分析问题解决问题了。如果有时间，最好进行一次重构。