@XTTX 其实你可以看看源码的，随便找了两个常用的 pkg：
https://github.com/golang/go/blob/master/src/bytes/buffer.go#L180
https://github.com/golang/go/blob/master/src/bytes/buffer.go#L199
https://github.com/golang/go/blob/master/src/bytes/buffer.go#L236

https://github.com/golang/go/blob/master/src/bufio/bufio.go#L169
https://github.com/golang/go/blob/master/src/bufio/bufio.go#L207
https://github.com/golang/go/blob/master/src/bufio/bufio.go#L295

我没看过你发的那个，平时习惯了源码。

@darrh00 你要考虑，如果是 c/cpp 那些，要自己写信号量 /条件量+queue，虽然也是简单的玩意，但对于逻辑程序员占 80%的程序员群体中的这大部分人，已经是一道天堑鸿沟了，chan 可以让你直接拿来就用了。

稍微复杂点的功能都可能需要去处理并发相关的事情，真的不算事。所以你说的缺点，可能对于长期做 web 接口开发 CURD 人员来说，确实是难了点。如果都是按照 CURD 的标准来要求开发者，那很多基础设施类的东西都没几个人能做了。即使是其他语言很方便，但承担造轮子任务的人仍然要面对大量的复杂。

chan 的这点复杂，应该是自己级别飞升时必须克服的一道基本功修炼流程，而不是被这么点复杂把自己逼在舒适区里只靠业务经验提高履历含金量。

@XTTX #9 go 源码里这种还是挺常见的

不要归咎内卷于普通员工级或者小领导级的个人头上，首先应该主要归咎于资本，其次归咎于爬到高处的领导级个人。

有的人是出于兴趣：因为写代码和学习相关知识确实很有意思、让人着迷，很多编程思想、知识都是带有艺术性的，新技能 get 时或者自己实现一些好的事物时会产生愉悦和满足；
有的人是出于责任：工作任务在肩上，出于责任心事业心去努力是优秀人才的基本素养，普通员工和小领导这种级别的，通常还没到非常恶心地大面积杀伤队友的程度，最多也就是受到资本和更高层领导胁迫锁做出的内卷行为，面对要么卷要么走的艰难境地，他们也是无奈之举、也是受害者；
有的人是出于贫穷：城市家庭的孩子，通常条件不至于太差，这里不是说父母给买房买车那种才不算太差，而是真正贫困的那种，比如偏僻地区的农村，那真的是交学费都要耗尽父辈的洪荒之力、真的是家里多个孩子只能供其中的部分孩子完成学业梦想、真的是要靠助学贷款馒头就咸菜勤工俭学之类的才能完成学业，当然现在这种会越来越少。比如某 500 强，招聘偏爱农村出身的，为啥？因为这部分小伙伴为了翻身真的能够坚韧、吃苦耐操。如果换个城里的小伙伴，八成干不了多久就跑路了，对于企业人才养成成本不友好。

资本天生趋利避害追逐利益最大化，高级一点的领导也都有股票期权分红之类的了、属于资本的帮凶了。

如果去归咎于普通员工、小领导，这本身就是底层人民的内耗，反倒帮助资本转移了矛盾，就像很多人喷外卖员、快递员不送货上门，换位思考下，如果资本不各种算法压榨得他们喘不过气来，大家自然都愿意服务周到客客气气皆大欢喜。

所以，仍然摸爬滚打在底层的话，就彼此放过吧，顺应国家整治 996 趋势，团结起来去让资本减少作恶吧！

@shoaly @pzzrudlf
开了个 slack 频道，欢迎来交流：
https://join.slack.com/t/arpcnbio/shared_invite/zt-vh3g1z2v-qqoDp1hQ45fJZqwPrSz4~Q

Shutdown 只是减少了停服的短暂过程的抖动数量，对于当时 qps/tps 非常高的服务效果好点。但仍可能存在在途请求（网络链路、尚未被读取的内核缓冲区中的数据）被放弃、请求方失败、超时的情况。

所以虽然冠以了 graceful 之名，只是 part of graceful，仍然需要业务层来保证需求的实现，以及集群架构层面的高可用性部署、调度等相关支持，业务逻辑相关的重试、幂等保证是必需品。

即使不是程序本身的导致的抖动，也存在其他网络链路抖动的影响比如 ISP 线路故障，仍然是需要集群架构层面的高可用性部署、调度等做相关的强支持，而这些支持能够同时从更高层面照顾到程序引起的抖动造成的影响。（ ISP 、程序抖抖可能造成请求方重试、累积踩踏雪崩之类的，都是需要网络、运维、高可用部署相关的这些保障）

有了业务和运维层面的保证，对于绝大多数业务量级而言，程序引起的短暂抖动其实影响很小。而对于中小厂的流量，抖那么一下，受影响的请求数也是极小的。

所以其实 graceful Shutdown，虽然照样用，但实际发挥的用处不大。

顺便蹭蹭，欢迎关注我的两个框架，高性能、海量并发相关：
https://www.v2ex.com/t/794435#reply3

lz 女朋友是时候考虑下退掉楼主、继续考察另外两个谁留下了。

捡芝麻丢西瓜。

网络层可以用我这个：
https://github.com/lesismal/arpc

微服务就是多个服务，他们之间怎么管理，自己设计实现接口就行了。

@vicence 我#7 少打了个 T，没法编辑

@vicence 就是 linus 那句名言：Read The Fucking Source Code

https://sites.google.com/site/shopexts/trading/php/read-the-fucking-source-code

1.《 LINUX 设备驱动程序》，多数嵌入式开发的人是做驱动，如果楼主不是，可以看《 Linux 内核模块编程指南》
2.《深入理解 LINUX 内核》
3. linus: RFSC

1，对模块机制、驱动开发有足够的了解
2，对 linux 内核比较全面的了解
3，前两本能拿下，剩下的就是啃源码了
其他的书没什么必要看，浪费时间，尤其 200 多页那本，看上去啥都讲了，实际相当于啥都没讲，就跟《七周七语言》《七周七并发》那些书类似，连鸡肋都不如：食之无味、弃之不可惜

@shujun 感谢支持！

golang，你值得拥有

@marceliu323 嗯嗯，如果是 pos 机里面已经使用了某种序列化，那是没法换 pb 之类的了，如果 c/s 端都是自家可控的，可以选择 pb 之类的。

一些老 c/cpp 项目是直接把不涉及深拷贝的 struct 的 sizeof 内存段拷贝过来用于序列化的，另一端 c/cpp 也是直接 struct X *p = (struct X *)buf，这种确实比较酸爽。唯有重构，能得结果 :joy:

关于序列化，protobuf/json 足够用了，并且还有其他一大堆知名的序列化方案可选。

另外，是否支持完备的嵌套，比如是否支持 struct 内的 struct 成员、数组成员、数组成员的元素是 struct 等。如果支持，算是相对完善，剩下的要看性能，如果不支持，对业务太不友好了。对于性能，主要是两个方面考量，一是速度，二是生成的数据长度。因为是用注释的方式，也就意味着要反射，性能可能不会比 protobuf 这些生成代码的快、长度也不会比 protobuf 能省，因为没有按照固定的 proto 生成固定的代码，所以传输给对方解码时仍需要带上 key 信息，相比 json 倒是可以把一些引号冒号省了，但可能又跟 MessagePack 差不多了。

单就序列化，对简化 tcp 服务消息封装和解析帮助不大。楼主应该是指这个 Header 做包长相关的流到包的解析。这个对于 go 也比较简单，单独协程读的方案，有 ReadFull 这些方便的方法，不需要像 c/c++ 那些异步解析稍微费神（但是异步解析费神也不算太多）。所以，整体看，tcp 服务也没必要用这种序列化方案。实现这种序列化，对学习和提高编解码能力是好事情，但建议使用更成熟优秀的方案。

@nannanziyu 对，很多不必要的争论都源自误解的分歧，所以没必要。回头望跟跳出圈外看事情是一个道理，往往旁观者清。