append 这个风格是因为可能会触发底层数组扩容，重新分配数组，所以设计成这个样子。

我要向楼主学习提问的技巧

整体架构：如果存在一种捷径，那就是难路。
这个深有体会，如果架构设计上存在偷懒的话，后期非常痛苦。
感谢分享。

容器重启是遇到问题重启了，发出告警，但重启动作很快，重启完成后，显示已恢复 的话会让用户觉得恢复了，没有问题了。

要真正 code review 的话，至少懂别人的代码的业务。国内很多公司都是一个人干两个人的活，根本没这个精力管别人。

第二点就是指告警抑制，不是告警静默

大家能举个实际的例子吗，就是真正在用到的例子。

a 和 b 是开源的第三方的 模块。

嗯，确实是 yaml ，感谢 @fantastM

```
type Config struct {
ServerConfigs []ServerConfig
}
```

如果 先赋默认值，再反序列化的话。针对这个情况咋搞？

了解了，close 之后的 channel 依然可读

stopCh 的触发是外部 close(stopCh)

现在遇到的问题是，如果服务端是个 k8s pod 的话，veth pair 好像对于大于 mtu 的包丢弃，导致图上哪个 1538 大小的包丢了。

补充：不同机器的硬件是不同，每台机器都是固定的顺序，操作系统都是 linux ，但是内核版本不一致

补充一下：我是在发送端用 tcpdump 抓包查看的。

@elegantu @Maboroshii 方便做单元测试怎么理解？能举个例子吗？

验证 JSON 这个结构体是否实现了 Render 这个接口。如果没有实现的话，在编译的时候会报错。

创建两个 deployment 和 service 。

```
deploymentA:
replicas: 2
label:
app: app1
my-app: app1
deploymentB:
replicas: 1
label:
app: app1

serviceA:
label:
app: app1

serviceX
label:
my-app: app1
```

serviceA 可以管理 deploymentA 和 deploymentB 的 3 个 pod ，serviceX 管理 deploymentA 的两个 pod

fu'wu https://i.imgur.com/SvBiSNw.png 服务端