@javaisthebest 丰富完善能罩得住业务，但是太丑陋了，让人作呕是因为太丑不是它不丰富不完善。另外，好多阿里同学自己吐槽他们内部框架臃肿不堪、性能低下。
我不知道兄弟你是不是阿里的或者是哪个部门的，或许你见过的阿里的东西比较好？能否推荐个我去学习下，免得我也被各种阿里同学或者非阿里同学整天骂阿里的 KPI 开源误导了（不过我看过一些阿里的开源，确实挺让人作呕的）。就是因为听说了这么多，所以阿里的哥们想内推挖我都直接拒绝了，审美取向不合。。。

很多人怕是不知道某些大厂内部的 java 基础设施有多么让人作呕。
没错，我说的就是阿里之流

在新业务没有历史包袱、并且能够实现人力招聘的前提下，大厂都在拥抱 go ，只剩下半桶水程序员还在吵吵不适合

按一线薪资标准，简单：
初级：1w 以内
中级：1-2w
高级：2w 以上

这光景，先狗住再说吧

如果润，devops 是好方向，就业容易、薪资可能比纯开发还高一点，坚持目前方向是好事情，国内 devops 待遇一般。

如果不润：
1. 既然 3D 图形不是一开始就在做，以后转通常成就也不会太大、竞争力不如别人专业领域一直从事的，薪资天花板可能相对低些，但如果是因为真爱想做自己喜欢的，那请随意。
2. 区块链，要动就早点动，要么就别动。只是做一些链上的功能开发不难，自学一两周个把月就能熟悉很多基础，然后找个工作就是了。如果是想做区块链本身的核心架构算法之类的开发，需要的基本功就比较多了，不是短期能成的事情

@iosyyy #10 好的

拿得起、放得下，自古两难全，做到一样也可。

另外，有时候 v 站的人戾气太重了，希望少点阴阳怪气，莫欺少年穷。
OP 在这研究这些是很值得鼓励的事情，总比很多人玩半辈子 CURD 要强多了

OP 别看这图，改看状态转换图吧，比这清晰多了

有没有一种可能，OP 你对精品的定义有所误解？

@gam2046 不同的服务类型和框架对优雅的定义、代码的封装都不太一样，分类展开了说有点多。。给个详细点的业务类型？

一起睡过的妹子照片

@wangyu17455 这样做是 Read 能得到 err 了，但是 socket 如果本身还是活跃的，这就是误杀了

还是我来做课代表吧！

@ppolanwind 正确的做法：
1. 不要通过调用判断是否断开的方法去判断是否断开（比如 IsClosed ）
2. 正常使用 Conn ，根据使用的返回值判断，比如 Read/Write 时返回了 err ，就是断开了

以上两条只是说怎么处理，实际实现 Conn 封装时通常要做的：
1. 单独一个协程处理读
2. 如果需要广播功能，单独一个协程处理写，否则可以不用单独协程、直接写就行

前面已经有人提到 keepalive ，但不够全面，仍需注意：
1. TCP 的 keepalive （传输层，4 层）只是检测连接健康状态，但不能用于判断连接的活跃状态。比如链路通顺、4 层 keepalive 是健康的，但 7 层应用层没有数据交互，这种属于僵尸连接了，对于正常的服务器，是应该踢掉这种长时间不活跃的僵尸连接的。所以 TCP 的 keepalive 选项不能解决僵尸连接的问题
2. 7 层应该自己进行 keepalive 协议包的收发比如 websocket 的 ping/pong ，来相互判断。业务协议活跃时可以节约掉 ping/pong 、一段时间没有业务协议交互再 ping/pong ，但 keepalive 间隔本来也比较大所以即使不节约这点也没关系。
3. 既然 7 层应该有自己的 keepalive ，其实 4 层的 keepalive 就没必要了

@DrX 我这没激动啊兄弟

@eason1874 #8
印象里我公司用过的 CDN ，回源流量峰值大于资源总量，比如资源总量 500M ，回源流量峰值可能 1G+，回源时间间隔远大于 1 天。

我是开发，运维相关懂得不多，只是猜测：
可能各个厂商实现策略不同，比如跟在线量有关？如果 CDN 都是单点回源然后 CDN 厂内部同步的话，尤其大厂、用户多，很容易赶上大量用户回源高峰期，这样如果大量节点之间同时迅速同步就也可能会有 CDN 厂内部网络风暴的问题，所以调度策略应该不是这种简单的方式，说不定是默认单节点回源后慢慢同步给其他节点，但是节点越多时间越久，这时候如果某些节点收到了请求、但自己节点还没收到回源节点同步来的数据，可能就直接源站了，然后也作为同步节点给其他节点发散？

如果是良心云增加了很多 CDN 节点导致回源流量暴增，那说明它的服务质量是提升了。。
但是我不太相信是这个原因。