从毕业至今，已经待过四家公司，算上实习期间三月游的公司差不多已经快十家了，时常会碰到一些有意思的言论。
在某司的时候就经常听到人说，“我们在 T 姓巨头的时候”，“我们在 A 姓巨头的时候”，“我们在 B
姓巨头的时候”，以任意一家巨头公司作为观点的前缀，显得观点就特别有分量。仔细想想，实习期间我也是在这些所谓的巨头公司待过的，我怎么就没有想到可以在自己编的故事前面加上这是
X 家的事情，所以还是他们比较机智。
大公司里的平均水平高，牛人多，并不代表进去的就一定是牛人，还有不少认不清是自己强还是公司机制强的混子。
即使是在大公司，也会有很多垃圾系统，他们内部没有限流，没有熔断，没有降级，也没有过载保护。但是他们却不会崩溃，
这次去 Gopher China 和不少老朋友见了个面，还有不少在微信上认识已久，一直没见过面的网友。同时也和各个公司的一线开发们聊了聊，互相交流了彼此使用
Go 时的一些心得和痛点。
综合近期了解的一些相关分享，我把到目前为止见到的，不那么常见的，各方对 Go 的优化和 hack
集中在这篇文章里。因为考虑到一些公司情况比较特殊，所以本文中列出的点就不标记是哪个公司做的了。未来他们觉得时机成熟应该也会自己出来做一些分享。
网络方面
当前 Go 的网络抽象在效率上有些低，每一个连接至少要有一个 goroutine 来维护，有些协议实现可能有两个。因此 goroutine 总数 = 连接数
前置知识在这里 [https://github.com/cch123/golang-notes/blob/master/memory_barrier.md]。
在 stackoverflow 上有这么
[https://stackoverflow.com/questions/50307693/does-an-x86-cpu-reorder-instructions]
一个问题，问题的答案中有这么几段：
> At the same time, x86 defines quite a strict memory model,
有一个观点已经被说烂了：使用 MQ 可以帮助业务系统解耦。
想法很简单，在业务状态流转时，如果没有 MQ，那么其它系统想要知道状态变了，那就需要核心流程系统去主动做通知。
比如电商系统里订单从创建到处理中状态切换了，客服系统需要知道，风控系统需要知道，用户系统也需要知道。
这里的通知通过 RPC 来进行，下游系统需要的数据可以在这次 RPC 里携带上，也可以在请求的时候让下游系统自己去查。
下游系统增加的时候，核心业务的代码也需要修改，比如新做了一个积分系统，现在订单状态流转积分系统也想知道。
核心系统需要不停地增加调用关系来迎合下游新增的业务方需求。这些边边角角的计算逻辑和订单系统本身没啥关系，但是因为下游需要拿到这些数据，我们就需要自己用 RPC
去调用下游的接口。这确实不太合理。
当下游系统发生事故时，
