正在工 epyc 和 7d12 做一样的事情，32 核 64 线程基本满足所有需求。主板是 atx 的。
以前也用过 2680v4 ，只要 80 一片。在我看来搞这个破事最大的问题还是国内墙搞，配置稍微麻烦，硬件没有很多要求。。4c16g 的电脑也一直在跑

@mrgeneral mesh 层如何将 in & out 的流量进行关联呢？
例如我是服务 B ，收到了一个服务 A 的请求，处理，然后向服务 C 发一个请求，mesh 的基础设施如何保证发给 C 的请求携带的 TraceID 与 A 发给我的 TraceID 一样呢？

@crysislinux 五楼这个是不好的解决方案，视角很局限，我们想解决的是业务间传递的问题，而对于单一的服务，如果它自己有这样的需求，它肯定有办法独立解决，向上抛错误也好，补齐 ctx 也罢。

而在跨团队协作里面推动所有人完成一件事是比较困难的，一个单元没解决好，大家都没办法拿到最好的结果。

另外回归到方案本身，它是不太有实践价值的，试想你现在只在 request log 显示了 trace id ，其他所有日志都没 trace id ，你如何串联所有日志？那，这个 trace id 只出现在 request log 的意义又是什么，岂不是跟没有 id 一样了。

@odirus
@kkhaike
谢谢两位朋友的建议，是个可以实施并且可以慢慢推的方式，可能落地起来还需要搭配一些宣讲一点点改善

@JustSong 这个东西就跟你和刚用 Redis 的人讨论可不可以使用 `KEYS` 一样的，不可能要求所有人立刻就知道这个东西重要不重要，可行与否，以及是否强制要传。等发现问题要改的时候往往是很难改得动，所以才会有很强的需求寻找如何优雅解决，而不是反推他们 “全部做对”（当然，全部做对肯定是最好最好的，不能因为难就否认）。

@danbai 记下魔法了，跟 1 楼其实是一样的。让我们猜猜业务方愿不愿意改 orz

@Nazz 不是，哥们，那你这个 trace id 如何传递给下一个调用方呢？

@juzzle 我想了一下，这种方案可以在流量进来和流量出去的时候为（可能是空白的） ctx 补充 trace id ，但是印象中：
1. goroutine 没有唯一 ID ，之前了解到是故意这样设计的，不知道这种情况后来有没有改进
2. goroutine 之间的 trace id （可能）不容易传递

其实更想了解有没有一些无侵入，业务不感知的方案，能够达到同 goroutine 内补全 trace id 的效果（也就是可以不考虑问题 2 ）

@OnlyShimmer 不是这个真不是重点，我朋友圈有好几个深圳，广州的移动业务员，我看他们发的消息基本都是要 60 元 300m 这档的，不管什么时期都有。但是与之相对，电信 60 元应该是不管 100m 还是 1000m 都不可能买到，它压根就没有这个档位的套餐，这是我想强调的，而不是说移动转网多划算。

重点是电信没有给入门用户的套餐，就算砍到 50m 100m 我也能接受，毕竟低延迟，但是事实上他们压根没有这档位。

@OnlyShimmer 移动携号转网还有更便宜的，基本上算下来 60 元（包含所有费用，月租、额外的宽带费可能每个月 10 元，都算在内）给的是千兆，需要合约保证用满 2 年。

我觉得三大运营商争资源再正常不过了，不过这其中电信的力度是最小最小最小的，基本上就没有每月 60 元这个档位的（含宽带）的套装，所以导致长期都没法选他们家，实在是太贵了。

至于网络质量，我在广深用了大约 1 年电信 100M 、4 年移动 600M/1000M （多处，不同区不同楼栋），电信网游延迟基本 10ms ，非常理想；移动延迟基本 30ms ，也属于是能正常玩的那档，个人体验下来这个费用差异确实是没有什么性价比，基本是花额外的钱去做一些比较极限的提升（ 30ms->10ms ），见仁见智

10 代雅阁锐智车主，当时落地 24w 整。看需求觉得选思域，便宜一点通勤好，看人数也不那么迫切需要 B 级车。

不过如果选雅阁的话，有一个好处可能是开 10 多年不用换，家里有一辆 14 年的雅阁，当时 26w 落地的，开到现在依然新净，2.4L 动力可以，而且非常宽敞、耐用，没出过什么毛病。

虽然但是）

其实我觉得适合写在简历上的项目可以考虑爬虫项目，TL;DR：
1. 海量数据，你爬下来上亿条数据（这个对于爬虫来说很正常），就能做亿级数据的 DB 优化、异构数据库、离线数仓等等；
2. 可以强调并发量，TPS 高爬虫才有效率，又是一大技术难点，如何压榨机器的资源
3. 以上两点在做正常的新手 Demo 项目（传统的商城、xx 管理系统）都是非常难做到的，或者说你可能需要自行生成这么大的数据量，但是在爬虫项目里很容易就能遇见

如果你想在爬虫项目里做一些服务化的事情，可以考虑按模块拆几个服务试试，例如
1. 实际发起调用的服务
2. 调度服务（例如有些数据想要实时更新点赞数、阅读数，那总得有一套规则，何时爬第一次，何时爬第二次，下发给哪个调用服务去爬取）
------------------------------------
3. 管理系统，或者用于展示的 Web UI 前后端

感觉不实用，但仍然很有意思哈哈哈，只看了一眼 README 就觉得太太太想试试了

@Jayice

@lvxiaomao 看起来好像以前投递过的不能重复投递了 :(

可观测性职位招什么经验的可以帮忙问下 HR 吗谢谢

@djoiwhud 井底之蛙....已 block

@djoiwhud 抱歉你的理由我认为非常奇怪。为什么数字精确是要怀疑合理性，如果你是我的面试官我首先会认为贵司没有任何 cicd 的流程，平时也不做测试，很可能代码是屎山。所有的这些数字都是在测试报告里面第一眼看到的，每次 commit 或者 merge 都必须展示在代码管理工具中的。

你说质疑数字价值和合理性，那不是搞笑吗，说明你没用过 gitlab 还是说没跑过单测呢😂

@dummynode 个人建议是不要乱换的，有的面试官不理解测试的价值，可能在生产里面根本就没做过测试，更不要说做什么 TDD