@justdoit123
粗略意义上正确，不过各家有各家的做法，rpc 的错误机制设计是要和可观测+trace+SLO 大盘联合起来考虑的。

业务错误不代表监控不需要关心，简单来说：
如果你只需要拒绝服务+返回错误，并且需要有一个自定义的 errcode 去表示这是什么类型的错误，同时附带一个简短的 readable 的说明（可以理解为 errcode 作为程序使用的描述，可以依赖 errcode 进一步执行某些程序化步骤，readable 的描述作为程序员阅读使用，方便快速识别问题），除此之外不需要向调用方传递更多的错误内容，那么就适合用 rpc error 来表示。
如果你要向调用方提供更多的关于错误的具体信息，深入绑定业务场景，那么就不适合当做 err 来处理，应该作为一个正常的 rpc 响应，此时的观测方案设计应该交由调用方手动填写 metric/log ，作为业务指标监控来看。

更深一步来说，还可以细分为业务错误（入参不合法，执行条件不满足，业务逻辑错误等等），框架及中间件错误（ token 无效，malformed request ，调用超时，BBR 自适应限流，熔断错误等等），以 int64 作为 errcode 的取值范围的话，常见的方案是 0 为正常响应，errcode>0 的部分作为业务错误（ eg：10001=余额不足），errcode<0 的部分作为框架及通用错误（ eg：-400=请求错误/参数错误，-504=调用超时，-429=BBR 限流）

rpc error 本身已经有一套错误码了，这个通常称为大码，含义可以简单认为和 http code 相同，通常作为 transport 层的可观测手段，适用对象 API 网关，SLB 等基础 L3-L7 设施
业务 errcode 通常是选择 rpc error 中的 unknown error （例如 GRPC 为 status 2 ）作为可扩展对象，这个称为小码，其作用就是，在 rpc 的底层 transport 没有问题的时候，用于传递业务+业务框架的错误，主要目的用于微服务治理和更细粒度的 SLO 观测

通常对于 rpc 来说，其框架已经定义过了错误，并且提供了错误的扩展（描述、details 等），就不要再把“业务错误”包装成正常响应返回了，否则你在可观测上会遇到不小麻烦。

而且，看你的设计，你在异常里，又返回了 data ，并且还描述了业务相关数据（ out of stock ids ），那么你本质就不是想返回错误，而是告诉请求方你提交的哪些数据不合法。
这时候你就要反思你的设计：你究竟是想交互，还是想抛出错误？对于一个错误来说你返回的信息里包含了太多业务场景相关信息，没有通用性。应该考虑这是一次正常交互。

错误描述的扩展，应该是描述错误本身，首先，应该提供一个统一注册管理的 bizErrorCode ，这个是可观测的基础，同时应该提供 description ，这个是对错误的描述，提供一些场景、debug 信息，而且仅应该用于 localization 或者程序员调试使用。

rb5009+1

中间件，工具，各种基础底座。
rust 不适合敏捷业务开发。
楼上说的也很对，rust 缺少 k8s 云原生这样的杀手锏。

家里一大堆服务的按理说你该懂组网的啊。
有公网 ip 不涉及过墙就经典方案 l2tp ipsec 或者 ovpn ，推荐 l2tp ipsec 基本现在是个设备都自带支持也不用额外装软件，不推荐 pptp 没加密，公网裸奔登个账号容易出事

mmo 那堆东西现在老古董很多啊，随便配台二奶机，内网隔离下随便造

某种意义上说的也没问题。不过他见识还是少啦，真正的有钱人是不屑于也不需要去挤高考独木桥的。

从你拓扑上看没啥问题，抓包看到底是啥问题吧

@mongoose
真有快照需求自建上 ZFS ，群晖私有 SHR+btrfs 个人认为是无法信任的。
目前策略是数据分层+rsync 备份，有需要的自动定期 zstd 打压缩包 rotate ，重要数据 iCloud 会再存一份。

先不吐槽标题了。
你这个问题很简单，因为卡死的不是“主线程”。
main 能不能 exit 和其他线程又没关系，只要主线程退出就行，操作系统会负责给你擦屁股的。

@Shoukaku
做了，两块 R1 ，另外两块当 Basic 用。fs 都是 ext4

@rssf
4x18T 银河带两块致态，DS923 目前一年了没有问题。
企业盘峰值功耗体现在启动那一下，平时氦气盘甚至是比机械盘省电的。
群晖启动时是 2 块 2 块错峰启动的，所以应该也不会有问题。

掉盘之前 hung 了一堆 kernel task ，看起来有点奇怪，我的建议是，远离 SHR 和 btrfs ，单独挂载这块 20T 做存储试试

放几年前我会说彩云天气，但现在我不知道了。。

体验了一下，反馈几个问题
1. non-Root docker 支持非常不好，entrypoint 起手就是 chown /app 然后一堆 permission denied
2. chrome 插件设置 kubespider 的服务器地址时，填写 addr 和 token 后，点击报错 SaveError ，无任何提示，无法保存
3. 文档滞后且缺乏条理性，默认的 3080 端口访问报 404 ，建议至少放个简单的浏览器配置示意，或者做成 web 配置管理。目前手动编辑繁杂的配置文件体验是很差的
4. 安装脚本过于傻瓜化，而且完全没有提供手动部署的流程文档。安装脚本默认用户是 All in one 部署形式，但我的网络拓扑中，NAS 和 AIO 是区分部署的，AIO 只挂载存储。所以仅需在 NAS docker 中部署 kubespider ，所有的 download provider 是安装在 AIO 中的。目前我只能人工阅读安装脚本然后手动操作

@testonly
想起了古早的 VR 设备，背包里塞一台笔记本主板。。
另外目前的透明屏幕显示技术还是无法实用，所以你看强如苹果也选了 Camera Passthrough 的方案。
而选了透明屏幕的 Google Glass 和微软 Hololens 已经死啦。

七宝啊，回想起了住星中路时，被早高峰 9 号线支配的恐怖