同款，当时五千左右就能买到金属机身的轻薄笔记本感觉挺值的，性能对用笔记本编程来说完全够用，也是特意选的 32G ，缺点就是自带的无线网卡不行，今年网卡彻底坏了之后换了 ax120 ，自带的固态也很一般，到手就换了。
其他的缺点就是相比现在的新款，没有网线接口，不能加内存条。

不是，改成 map 不也是这样一大坨么，只不过变成了 map 一大坨，换个地方变成一大坨而已。

@laminux29
对对对，你是中肯的，仔细的，认真的，做技术的，会阅读的，会评论的。

@bthulu 对的，这才是真实的世界。

@laminux29 #13 银行 app 和云闪付 app 里的信用卡账单都能做到实时，而短信的账单就会延迟就是为了省成本，发短信是要钱的，银行有几块钱包月实时短信通知的业务。所以这和分布式事务有啥关系？

@laminux29 #11
银行账单延迟和看不到详情单纯就是为了降本省成本，和分布式事务有啥关系？

@dengkj #117 合着女的是雌雄同体能自己生孩子？

@sagaxu #16 方案是好的，但是执行起来变数太多了。

首先别看天府大道那么宽，实际上上下班也堵的厉害，要选挨着地铁的才能缩短通勤时间，另外考虑娃上学，天府新区的教育资源肯定不如老区。

@xuelang #1 这个科普写的真好。

@shadowyue #88
这就有点过了吧，怎么大家都是草包了？
你那个帖子说明你对跨域停留在简单理解上，并没有太多实际业务中的跨域边界问题实践经验。

@dongzhuo777 #69
主要是单体的话，靠日志在本地或者测试环境复现的难度小很多。
如果不是微服务，而是某个模块，那我可以直接 debug 一步一步调试就可以，也可以做各种 mock 方便我复现。
但是微服务的话，拿着各种服务的日志做对一堆服务做排查，还会碰到某个服务是完全不同的语言写的，这一下子时间成本就上来了。
单体就像是独立开发，微服务就像是多人合作，上下文切换和沟通成本变大了。
确实你说的没错，日志的问题换成单体也会碰到，只是单体相比起来排查起来更容易些。

前面有人说加上链路追踪，日志搜索平台就可以，然后你会发现：
1. 这个全链路追踪的性能消耗为啥比线上所有服务的资源消耗还要大，最后只能改成只用 traceID 做记录，那种有详细记录的链路追踪就算了吧。
2. 服务太多，排查基本全靠日志，要是出现一个问题没有被日志覆盖到位，改代码，加日志，上线，诶，好像还不行，还得加日志，来来回回整半天，而且有的问题只有等加日志后复现，不然你永远也不知道为啥会有问题。
3. 日志加多了之后，每天的日志量很大的，一天 1TB 的日志都不是问题，日志越多，日志平台的性能消耗就越大，这时候用 ELK 的成本可能比你当前线上服务器的成本还要大。
4. 服务太多，本地调试困难，别说有测试环境，真实情况下微服务那测试环境每天都是缝缝补补，谁用到的时候谁去修，修复测试环境的时间比你开发需求的时间还要多的多，想想几十上百个服务的部署，启动顺序，数据库数据，业务依赖，这测试环境的部署和维护就足够麻烦了。

你看上面这些问题，除非是大公司有钱玩的动，小公司还在天天计算如何优化服务器配置减少成本。
最后，定位一个问题两天一夜其实也说明不了啥，有些问题工单一两年都查不到原因，但是查不到也没关系，可以用别的方式想办法规避开。

没太看明白，意思是说个人最优解是进入一个其他同事都比较全能的团队，自己或者同事会不会都不是问题，只要团队里能有人会就行？

@whoosy #13
兼容的话，不管是新增错误码，还是用子错误码还是别的方案，要做兼容都是搞一套新的或者加新的，旧的不动，继续留着。