golang的优化

最近对自己写的golang服务器做优化，遇到不少坑，这里聊一下所遇到的坑。

跑了一些机器人，主要看cpu跟内存的占用了。首先是做压测，cpu至少要2核，1核是不行的。会发现1核占用率100%，到2核上就仅仅只有10%左右了。据说golang是默认多核的。所以，就算是压测至少也得2核。

接下来说一下，golang的一个巨坑。。。golang原生库带了定时器相关的，我觉得它那定时器用起来不方便，就简单封装一下，结果，一压测，cpu，内存占用暴涨。。。当时，我还不知道是定时器问题，结果弄了看了代码，看了很多资料，才定位到定时器。但服务器肯定要用到定时器的啊，难道不用吗？其实也不是不能用，就是不能大量使用。但如果一定要大量的使用定时器的话，怎么办呢？个人建议就是用time.Sleep。。。这东西跟定时器不是一个实现原理的，估计（没时间深究它们的差异）。。。反正，我就用了这方法，cpu，内存明显的降了一大截。。。

然后，说说golang的第二个坑，那就是rpc。网上看到有个哥们说测了一下，原生rpc可以用在工业上什么的。然而我实际测试了一下，当数据量及其大的时候，这个东西就会不停的让内存，cpu暴涨。这东西甚至比定时器还严重，直接让操作系统把那进程kill掉。。。

看来原生的rpc是不能用了，原生rpc的问题在于反序列化上面。不知为何，序列化倒是没啥，反序列化极其耗内存，而且还迟迟不释放。。。导致被系统杀掉。接着我试了其它两个RPC第三方库。我是尽量避免使用大量第三方库的，因为部署起来很麻烦（懒得用docker），但原生库是不能用了，就只能用第三方的了（自己撸一个也不是不行，就是浪费时间）。

我先后用了两个rpc库，一个是rpcx，一个是gRPC。前者是个人开发？还是一个组织？反正他的网页上吹嘘，拳打阿里（Dubbo），脚踢微博（Motan），头撞fb（Thrift），完虐Google（gRPC，对这里介绍一下gRPC，就是Google出品，谷歌出品不是精品就是残废品。这个确实是精品）。还说性能是gRPC的2倍。列了几张图表，并且很简单易用。

说实在rpcx，确实挺简单的，不用生成一些东西，直接调用。只是安装有点麻烦，特别是在国内。安装需要用到golang两个x下面的库。但这东西在国内是装不了的，你懂得。然后我提了issue，说这东西有些库装不了啊。结果作者说 out of China。我还差点没吐血。。。勉强装好了那些依赖库（感谢golangtc.com提供下载方式)，花了一天时间，接好了，开始压测。结果，刚开始的时候表现的比原生的好，我有点喜出望外。然后，当过了一段时间，cpu，内存仍然一直暴涨。。。看来这东西也是不能用了。。。

狠下心，继续换，换成gRPC。其实一开始我是想用它的，但安装的时候，出了点问题，就放弃了，用rpcx了。但这回没辙了，只能硬着头皮上。还好装rpcx的时候，一些依赖库，grpc也依赖，这个没问题（再次感谢golangtc.com提供下载方式)。但本体却有问题了，因为Google把库都搬github了，但居然安装方式没改，用它文档的就会安装不上。于是搜了一下，找到方法，折腾了很久，终于装上了。

网上grpc的教程都用proto3的，挺误导新手的，官方教程也是用proto3。其实proto2也是可以的，我就是用proto2。编译没问题，然后又花了一天时间，改成gRPC。压测一下，cpu，内存占用竟然维持在比较低的水平。看来RPC库也就只能gRPC能用了。

另外，刚刚开始压测时候，发现有些请求居然服务器没响应，查了一下cpu，内存并不高，再查了代码，也没报错，最后才发现带宽不足，导致完全没响应了。这也是一个坑，但不是golang的错。逻辑上的问题。于是乎又百度，Google，得出的结论就是限流。我采用令牌桶算法，限制一定时间内的数据包发送量，结果奏效了，带宽占用降低50%

以上就是我在压测优化的一些看法吧，说不是很具体，仅仅大概说一下罢了。