@WithLin 大佬在 SCB 有趣吗以后去投奔哈哈，早几个月发过邮件给你

mark 一下这个挺有意思。

不过自建思路也挺简单的，现在 CI 上传了 html （或者其他形式东西），应该只需要解析展示就可以。

然后再补充一个付费的，我自己一直在使用： https://about.codecov.io/ 可以看看企业规模和成本支不支持

Alternatives: https://www.google.com/search?q=codecov+alternatives&oq=codecov+alter&aqs=chrome.0.0i512l2j69i57j0i22i30l2.4033j0j7&sourceid=chrome&ie=UTF-8

界面很好看，虽然从来不用 GUI （ FYI 身边很多同事都用 CLI 直接办事），但是还是觉得这样的项目会很有潜力。

Redis 过往做工具的问题，常常是跟不上官方迭代，新 Feature 难以支持（不可能有人能年年都跟着他们的迭代同步迭代，特别是靠爱发电的），而且 Redis 交社区维护之后，迭代频率策略也快了很多，在工具形成社区之前其实需要很多的努力。

不过换个角度想想，好像 Redis 很多公司也不随迭代更新吧，保持在 2.7 / 3.x / 5.x 的大有企业在，嘿嘿，不错，是个利好

@jzjjzj 我错了，是周年庆，我的锅

@julyclyde 但是感觉是个比较有需求的东西？总感觉很多人都需要

@littleYY 没事哥们 我们今天也算是加班

@so2back 跟 v 友们分享一下喜气

@54xavier 卧槽哥们快逃

@claylin 别的组不知道，我 975

@xianyv
@zapper 贱贱发出来恶心 v 友一手 哈哈 (^Д^) 家里人貌似很喜欢这个小饰品，我自己倒是不太感兴趣，但是确实还是值钱的。

如果是我本人的话，可能换成个主板硬盘路由器啥的也挺好

当年一加 1 从 14 年用到了 18 年还在服役，真的是神机。。。

@sss15 时间如果+8 的话哪天去美国了是不是又会骂他没有-8 hhhhhhhh

@wsszh 有趣的 repo ，关注一下，感谢

@yongzhenchen682 数据可以是提交数据，也可以是查询数据，你怎么去定义呢？

服务 A 向服务 B 查询了一堆数据，数据是从 B 流向 A ，所以你觉得 B 是上游，A 是下游；

服务 A 向服务 B 写入了一堆数据，数据从 A 流向 B ，所以说 A 是上游，B 是下游。

根本就没办法解释和通用地定义“流向”和“依赖”，文字游戏是没啥意思的

@v2nika 听起来没什么问题？一直都是这么用的。不需要强加自己的理解于别人之上，面试只需要表达清楚意思就可以了。

上下游的定义一直都有（至少）两类，

第一类: 按 action 的方向定义
上游: 指收到了哪里的请求 / 要响应给谁。
- 上游服务调用了我，我要响应给上游服务。
下游: 发请求给谁 / 从谁那接收它的响应。
- 我正在调用我的下游。

第二类：依赖关系
上游: 发请求给谁 / 从谁那接收它的响应。
- 我正在调用服务的上游
下游: 指收到了哪里的请求 / 要响应给谁。
- 下游服务调用了我。

面试里面结合语义这些东西并不值得纠结，而且既然不是个所有人都同意的东西，hh ，我也觉得会有人发帖：

```
为什么这么多后端开发上下游不分?
面试了不少于 100 个后端工程师, 初级到高级都有. 有相当一部分 (>70%) 的人, 都会说我做的服务调用上游服务如何如何.
为什么会这样? 只要认真思考一下, downstream 和 upstream 的概念不至于记不住吧?
```

@ye4tar 比较接近，但是想要个解决方案，至少能把数据报给 prometheus （或者别的也行），它应该是个 Linux 系统能跑的进程才对，类似 Node Exporter ，但是 export 出去的内容是“外部请求的黄金指标”

https://go.dev/play/p/8_2sAiXdrQ7

9L 的小 demo ，试了一下感觉应该挺好用的

type User struct {
Name string `json:"name" validate:"required"`
Age int64 `json:"age" validate:"required"`
}

testCase: {"name": "john", "age": 10}
result: <nil>

testCase: {"name": "john", "age": 10, "is_v2ex": false}
result: main.User.ReadObject: found unknown field: is_v2ex, error found in #10 byte of ...| "is_v2ex": false}|..., bigger context ...|{"name": "john", "age": 10, "is_v2ex": false}|...

testCase: {"name": "john"}
result: Key: 'User.Age' Error:Field validation for 'Age' failed on the 'required' tag

我出两个小建议，但是可能都需要对全局代码进行查找和替换。不过改动量还算可控的。

1. 如果只是针对 json 格式和 struct 定义不完全匹配，可以用 jsoniter 库，通过这个配置玩一下：jsoniter.Config{DisallowUnknownFields: true}
2. 如果需要在 struct 上自定义 tag ，例如：required ，那可以提供一套自定义的 json 方法，里面先使用 github.com/go-playground/validator/v10 进行检查（支持的 tag 应该足够用了），再执行原生的 json 方法，方法签名保持不变

对于方案 2 ，全局的代码应该可以通过修改 import ，把所有的 json 包都替换成自行实现的 json 包，提供 marshal / unmarshal 方法就可以了