4月17日晚22:51，伴随着D7次动车缓缓驶入沈阳北站，拖着疲惫的身体和些许兴奋的我，结束了两天的GopherChina 2016之旅。

一、GopherChina大会

GopherChina大会是中国大陆地区Golang语言推广第一品牌。2015年在上海成功了举办了第一届大会；2016年，大会发起人astaxie为充分照顾帝都（及周边）Gophers们的情绪^_^，将GopherChina 2016搬到了北京举行。

这是我第一次参加GopherChina大会，也是由于“第一次”，心里有种莫名的小兴奋。

第一天会议，8:30来到亚洲大酒店。虽然酒店外面人员密度稀疏，但主会场入口处却是接踵摩肩，人山人海：注册、领“Gopher战斗服”、收集卡片印章，场面好不热闹，不过主会场内部倒是一片井然有序之气象。会场内主屏幕上循环播放着这次大会几大赞助商的宣传视频：七牛、Daocloud和Grabtaxi等。作为Gopher，首先应该感谢这些金主，没有他们的”金元”，谢大也难为无米之炊不是。

二、Topic主观短评

大会的日程很紧张，Topic较多，能全神贯注的聆听每个Topic基本很难。开始还好，后来只能重点听听自己感兴趣的了，第二天的时光尤甚。相信坚持听完两天的topic的Gopher们都或多或少有疲惫之感。下面就自己的感受，用短短一两句话，主观短评一下各个Topic：

第一天

陈辉的“Go 人工智能”：
话题挺“唬人”^_^，实质则是陈总个人的opensource project show，从“悟空”到“弥勒佛”一应俱全。并且鉴于陈总的Facebook、Google和Alibaba的从业经历，他的开源项目应该值得学习一番。

刘奇的“Go在分布式数据库中的应用”：
刘总依旧幽默风趣，这次除了带来了TiDB外，还带来了砸场子的用Rust实现的TiKv，为晚上在技术Party上撕逼打下了伏笔^_^。

李炳毅的“Go在百度BFE的应用”：
“车轮大战、车轮大战、车轮大战”，重要的事情说三遍！不过这仅是go在baidu特定场景应用下的tradeoff。个人倒是不建议关掉默认GC。

毛剑的“Go在数据存储上面的应用”：
基于FaceBook的Haystack paper，为B站造的一个轮子，细致入微。其中的设计考量值得同样在做分布式文件系统的朋友们借鉴和参考。

Marcel van Lohuizen的”I18n and L10n for Go using x/text”：
Marcel也是今年GopherCon2016的speaker，这次来到GopherChina讲解x/text也是让我们先睹为快了。Marcel 对x/text进行了详尽的分类讲解，以及给出当前状态、todo 以及 plan。内容结构很有外国speaker共同具备的那些特点。

米嘉 的”Go build web”：
对Go web dev进行了庖丁解牛，Go味儿十足。现场的很多web dev都反映很有赶脚。

邓洪超 的“Go在分布式系统的性能调试和优化”：
来自CoreOS的邓洪超很萌，演讲很有激情。但也许是外语说惯了，中文反倒不那么利落了。不过整体效果依旧不错。

沈晟的”Golang在移动客户端开发中的应用”：
心动网络(前verycd)的沈总讲解了心动网络将gomobile 用于游戏客户端client library的例子。记不得沈总是否说过心动网络已经在正式产品中使用gomobile了，不过无论这样，这种“敢为天下先”的气魄还是值得赞颂的^_^。

技术Party

晚上大约80多人聚集在二楼会议厅举行GopherChina技术Party，Party上，PingCAP的刘奇引发Rust vs. Golang的重度pk。由于高铁晚点而迟到的七牛CEO许式伟也再次站出来成为golang的捍卫者。pk从语言特性延伸到社区文化，“民主集中制”的精英文化主导的Golang社区与纯粹美式民主的Rust社区到底孰好孰坏，大家也是众说纷纭，见仁见智。外国友人“马尾辫”(Marcel)和大胡子(Dave Cheney)也参与了论战，不过他们自然是站在Golang一方。之后大家在Docker话题上又燃战火，人们就Docker究竟能给企业和开发者带来何种好处进行了深入PK。

第二天

Dave Cheney的”Writing High Performance Go”：
Dave Cheney不愧为Go语言的知名布道师，这个topic“编程哲学”与实践并存，干货满满，估计事后消化也需要很长时间。值得一提的是本次大会只有Dave的slide是采用Go team常用的.slide格式文件制作的，赶脚非常go native。

吴小伟的“Go在阿里云CDN系统的应用”：
围绕Go在阿里CDN的应用，看得出Go用的还是蛮多的。印象深刻的一个观点：老板决定语言！

许式伟的“谈谈服务治理”：
大家似乎都想知道国内第一家采用golang技术栈实现的七牛，内部到底是如何使用go的，但许总就是不能让我们如愿哈。

孙宏亮的”Go在分布式docker里面的应用”：
赞助商Daocloud的技术和产品展示，可以看到Daocloud内部的一些架构设计和实现，值得参考。

高步双的“Go在小米商城运维平台的应用与实践”：
由于困了，听这个speak时很迷糊，无感。

赵畅的“Golang项目的测试，持续集成以及部署策略”：
我也是第一次听说Grab这家公司。不过赵畅这个speak我很喜欢，把公司技术栈的变迁讲的很生动，关于golang的实践和一些数据正是我们需要的。

孙建良的“Go在网易广域网上传加速系统中的应用”：
不知为何，slide的首页标题居然是：Go&网易云对象存储服务。原以为标题发生了切换，但没过几页，又回到了“广域网上传加速系统”，这两者似乎也没啥联系啊。也许是我没听完提前离场赶火车的缘故吧。

三、会后

谢大组织的这次GopherChina2016非常成功，表现为几点：

• 参会者众多，会场爆满，还有不辞辛苦，站着聆听的gopher。
• 多数Speaker表现优异，达到了Gopher传道的目的。
• 技术Party气氛热烈，论战持久，让Gopher收获满满。
• 硬件以及组织到位，会场井然有序。
• 这次Gopher战斗服非常棒，材质很好。
• 会场的水、水果、奖品、party前自助餐也很给力。

这里对谢大也表示大大的感谢！

个人也有一些小建议：

• 多些场上互动，尤其是下午场，易困倦。如果此次能将daocloud的抽奖环节挪到主会场，全员参与，想必更能活跃气氛，为大家提神^_^。
• 从GopherChina大会品牌角度出发，如果能统一讲师slide模板会更好，如果都能使用go team那种native的.slide文件格式就更Go味道十足了。
• 希望类似GopherCon大会那样，增加open keynote(语言历史，当前，未来plan)和close keynote(社区文化推广)两个环节。

另外我觉得应该对讲师slide内容做一些审核，考虑像gopherchina这样的围绕一门编程语言的conference，到底什么话题才是最佳的呢？当前借着Go之名，实则讲解某一行业领域系统架构的内容似乎多了一些。针对语言本身、语言标准库、语言工具和语言最佳实践的内容略少了一些。

如果要谈语言应用，那个人认为至少如下几个方面应该提及：

• 使用什么go版本
• 版本切换时的差异（内存、cpu、GC延迟、吞吐）和坑
• 用Go开发了哪些服务？为何？为何其他服务不用Go开发，理由。
• 遇到问题/坑，如何解决
• 组织内Go的最佳实践

各位讲师的slide后续还得慢慢消化，另外感谢极客学院展台工作人员的拍照服务^_^：

一切没有目标的努力，都是瞎忙活儿。
                                                    - Tony Bai

刚实施回来，就又投入到新工作中，到今天才有那么一点点时间写写这件事儿。

* 缘起

我们的遗留系统性能一直不高，导致这一局面的因素有很多，比如最初设计和实现的“考虑不足”、后续维护人员的“随波逐流”甚至缺少勇气对影响性能的关 键代码进行重构等等。技术债务就这样一直积累着。直到两年前，我们终见其导致的巨大的影响了。

由于客户方成本压缩，单节点性能低意味着需要更多的硬件投入，并连带着报价升高，导致我们的产品市场竞争力下降。而竞争对手产品的性能是我们的 3-5倍，这终于引起了领导的重视，并下达了开发高性能版本的任务命令。

* 抉择

遗留系统的问题有很多，性能差仅仅是表象之一。可维护性差更让人印象深刻。遗留系统就像一件打满补丁的旧衣裳，虽然依旧能穿着遮体御寒，但却让我 们时刻战战兢兢，生怕一个动作会导致它解体，变得支离破碎。

对于我们这样一个mission-critical的系统来说，开发周期显然是不会短的。在性能达标的同时，更为重要的是保证产品的质量，确保上 线后运行稳定。因此摆在我们面前有两条路：
    1、在遗留系统上做“大修” – 大规模重构；
    2、重写，把构成系统的骨架重新设计和实现，使它能够足够坚固，满足在“高速公路”上驰骋的要求。

我们最终选择了重写，也就是风险较大的那条路。在我们的理解中，重写软件就好比汽车升级平台，就像大众将传统的PQ25、PQ35等统统升级为 MQB平台那样。平台的升级，不光影响技术，还会影响方方面面，比如团队的能力、思维方式、合作模式以及团队过程改善等等。做 得好的话，会使整个团队迈上一个新台阶，这是原地修补所不能够带来的。

对于我个人来说，这也是我期望中的实验田，我将把之前研究的诸多实践落地，帮助团队提升能力。

自私地说，重写系统也是我的一个小理想，能遇到这样一个从无到有构建一个系统的机会是不多的，因此很是希望能看到一个系统一点一点的在自己的呵护 下“成长”起来。虽然我也清楚完成这样一个系统需要很长时间，而这期间我可能需要时刻紧绷着神经，直到系统正式上线后，才能感受到那一抹释然。

* 建立“骨架(skeleton)”

我们将项目分成两个阶段：建立系统“骨架”和为系统“添肉”，即添加业务逻辑。

系统的性能目标是原遗留系统的10倍，这样我们建立的骨架的性能至少要高于原遗留系统的10倍。在“添肉”之前我们要充分证明骨架的设计是合理、 有效、稳定和高性能的。

遗留系统性能低，并非因为当初的设计者能力有什么问题，更多是局限于当初的设计目标。系统初期业务量不大，接入的外部网元不多，因此系统大量使用 了链表这种简单但低效的数据结构；为了easy coding，当初的设计者选择了全局大锁；在客户端-服务器处理模型上，选择了一个连接一个进程的“高耗能”模式。最初这样的设计应对当年的业务量也是 绰绰有余的，但应付今天的业务规模就显得颇为捉襟见肘了，以至于我们不得不通过罗列机器来满足业务增长的状况。服务器增多，却导致了我们维护 和监控难度的增加。

为了应付现有业务量规模以及未来若干年的业务量增长，我们的新系统的骨架在设计时显然要扬长避短：
    – 我们重新设计了通用的服务端框架和客户端框架，使得系统各个业务模块采用相同的通信处理机制；
    – 我们没有选择线程，而是依旧采用成熟的进程（资源隔离式） + IO多路复用（linux下epoll机制）的服务器-客户端模型，与以往不同的是，我们在每个进程中处理多个链接，设定进程数量在合理水平，避免大量上下文切换带来的性能损耗；
    – 将传统的全局big lock更换成了细粒度锁；
    – 采用高效的数据结构和算法，比如用hash和array替代掉list等；
    – 用简单队列替换掉原先复杂的队列调度结构，降低代码理解难度和后续维护门槛。
    – … …

我们要求对骨架代码进行严格的单元测试，通过lcut为骨架代码建立起单元测试集，并结合持续集成对骨架代码进行持续的单元测试验证。

骨架完成后，我们对其进行了全面的压力测试，确保其性能水平达到我们设计要求，这是我们进入下一阶段的前提条件。

* 添肉(business logic)

有了稳定、可靠、高效的骨架，我们在”添肉“阶段就更加有信心了。用C写纯业务逻辑是苦逼了一些，但还好我们没有全部将以前遗留代码扔掉，我们为了保证功 能Feature不丢失，我们会尽量复用之前的业务逻辑，当然是“规范地”搬到新系统中的，尽可能地去除原有代码中的Bad smell。

与骨架相比，业务逻辑相对复杂，且耦合较多，因此对这些业务逻辑做单元测试真是一件让人头疼的事情。不过这也和我们最初的估计相符，最初制定的策略就是对骨架代码做高覆盖，对业务代码则宽松些，尽量覆盖即可。

* 附加实践

就像前面所说的那样，围绕着这次重写系统，我策划了很多实践有了落脚之地，包括：
    – 试点知识管理 ：通过这次重写，建立起关于该系统的知识库；
    – 增加基于ReviewBoard的在线代码评审环节；
    – 引入基于Jenkins的持续集成；
    – 重新思考和设计构建环节，通过buildc提高构建效率；
    – 重新设计通用安装包；
    – 使用LCUT对骨架进行单元测试覆盖；
    – 规范commit log以及代码提交流程；
    – 应用代码风格检查工具，使得所有代码风格一致。

事实证明上述实践在这次系统重写的过程中产生了很好的效果，尤其在代码质量保证方面，系统上线后的结果也恰恰印证了这一点。

* 上线

“丑媳妇总要见公婆”。我们的新系统也到了该上线服务的时候了。为了这次上线，我们做了较为充分的实施准备，无论是人员还是时间，都有倾向性的向这个系统 投入。我们也提前做好了应对各种突发问题的预案。可实际情况出乎预料，与遗留系统的版本升级相比，这次全新系统上线显得十分顺利，系统的核心相当稳定，出 现的一些问题也都比较边缘，对这次成功上线已经不构成什么影响了。

* 那一抹释然

在实施人员庆贺上线成功时，在领导口头表扬时，我的内心却显得十分平静。对于新系统来说，这是一个好的开始。对我个人来说，我感受到了那一抹期望已久的释 然。在这个领域里这个方向上已经摸爬滾打了多年，虽然还有好多地方需要改进，好多实践需要完善，但我的内心告诉我：“够了”、“已经没什么牵挂了”、“是 时候换换方向、换换领域了”、“让其他人去做吧”。我已经在产品和团队中融入了我的思想，我相信他们都能很好的演化和发展。而我则为接受新思想、新领域做 好了准备。

的确也到了为自己设立新目标的时候了！