服务器C++转Go的感受

服务器C++转Go的感受

过往经历

• 之前长期从事游戏服务器开发，基本上所使用的框架主要开发语言都是C++/Lua为主，如果涉及其他服务需要首先会考虑使用Python进行便捷开发。Python做一些简单服务不仅比较方便快捷，而且对接第三方都会提供Python的demo示例，也会事半功倍。
• 对于服务器开发来说，服务器的稳定性都是考虑的重中之重，毕竟一般的性能压力可以通过扩展机器设备来实现，只有服务器的稳定才是实打实的。一般来说，进程的主业务都是单线程，也避免了出现多线程造成的异常。另外会额外有写线程池专门去处理异步事务，对于一个多个步骤的事务操作来说也有专门的事务管理器去按步骤完成处理。通过线上项目的验证，基本上框架的稳定性自不必说，即使出现的coredump也一定是简单易查的，基本上通过测试过程中就能发现问题了。所以即使有新人来适应也不至于搞出一些幺蛾子。

对Go的兴趣

• Go语言作为一门很火的新兴语言，语义层面就已经是实现了一个并行，并且社区发展的火热，基本各种第三方的库支持都还算比较及时，有一种编译型Python的即视感。对于服务器开发者来说，自然对这个开发很感兴趣，就会去了解一些Go的机制以及使用，主要就是替代那些以前使用Python的服务试试水。而且包管理器Go Module的存在，简直是C++程序员的福音，只有用过C++才知道有多痛，更不用说一些老的C++框架可能还会有些对标准库的实现，但性能已经完全比不上现在的标准库了，另外现代C++11之后的版本，语法特性也不少，但整体用的不多基本也能把问题解决。

对Go的掌控度

• 作为一个服务器而言，用守正出奇可能有点恰当，对我来说还是比较求稳的，再新潮的东西抵不过上线稳定来的直接。对于C++框架而言，对机器资源的使用非常直接，无论是io还是cpu与内存，大体都能做到心里有底，如果出现问题怎么处理和解决。
• 但是对于Go来说，无论是GMP还是GC都是语言层面机制提供的，这一块虽然大体知道机制，但是内心还是认为不太可控的，举一个简单的例子，Goroutine到底用什么样的实践比较合适，是多开可以让每个独立用户的请求和逻辑处理任意的阻塞，还是说业务单Groutinue，网络io独立goroutine合适，一方面没有公认的最佳实践，一方面自己去测试这样的数据时干扰太大，时间上与项目上都不太支持。终归来说就是对Go的把控性不够。再一点就是对于Go线上项目出现异常的处理上，也没有一个完善的解法，目前大多数都是捕获panic的堆栈再结合日志来做。

Go项目

• 在公司的推广下，明确了使用Go作为新项目的主体开发，心里很爽，确实一直很想使用Go，但作为项目的服务器负责人来说，其实也很虚，开发一时爽，线上火葬场，一个基础项目已经基本完成了开发，经过压测和基本测试也都还好，甚至于因为天然的并发，如果不是跨机器部署进程的节点的话，一组服务里的每个服务甚至只需要一个进程就可以了，都不需要像以前一样去考虑横向部署扩展。后续项目上线后碰到什么问题和情况再来记录。

转Go过程的一些感悟

• 语法层面的话基本上都还好，毕竟我早起C/C++开发的对，对于Go的一些编程习惯也还好，只是少了一个Class对象的封装，代码的零散度还需要一些适应，尤其是接口和对象之间的松耦合关系。
• 我觉得转Go基本上把语法稍微看一看，然后如果时间充裕就可以看看官方的Effective Go，如果想更快速的话就可以网上随便搜一个语法体系，主要也就是知道代码怎么写，然后非常强烈建议看一看Uber的Go规范，规范不仅有些小技巧，也是一个对语法知识点的巩固，然后就可以开干了。
• 在我看来，Go有几点比较重要，GMP、GC、Goroutine、Chan，应该说整个go的优越性都体现在这几点，对于在架构的设计和实践上都很重要，需要不停的理解和思考，结合测试案例和社区的实践来评估与衡量。

尾声

• Go只是一个带有某些特性的语言工具，对于服务器而言在架构设计和实践上起到的是辅助作用，不神话也不迷信一个语言，关键还是能在业务实践中比较恰当的承担起应有的作用。目前也有新的小伙伴加入团队，有比我Go用的久的，也有新转Go的，语言始终不是一个瓶颈，关键还是在于是否有自己的思考，以及想用它来做成什么样的效果。
• 总的来说，写Go比写C++爽多了，希望项目上线也还能继续爽。