毕业工作五年的总结和感悟（中）-公有PAAS平台

上一篇文章介绍到云存储项目，下一个做的项目就是统一日志。这一个项目前前后后做了一年多，版本迭代更新了很多版本，架构升级都做了3次以上。做这一个项目是收获最大的，我在这一个项目中锻炼了大型分布式系统的架构设计能力，也从0开始完全自主研发和设计的一个分布式系统。里面涉及到了很多技术，例如日志实时抓取和采集技术、数据实时传输、数据压缩、软负载均衡、zookeeper等。统一日志项目从最开始的3个人到最多的时候19人，到最后又只剩下3个人。从每天除了几GB的数据到每天处理每天几百TB的数据，从每天处理几千条日志到每天处理上百亿条日志数据。可以说做统一日志项目的每一天都是快速成长的一天，刚开始求着别人使用我们的日志平台，到后面全部都主动要求接入、到最后成为日志的标配系统，所有系统都必须接入。当时我们的口号就是让日志触手可及，我们内部的项目名称叫做loghub。在做这个项目的过程中，大家一起经常加班到凌晨，但是精神都还是很好的，下班后大家还要一起去宵夜，一起吃烧烤喝啤酒，在一起聊聊工作和技术，聊聊人生和理想。久而久之大家都非常的熟悉了，就这样大家开始逐渐建立了深厚的友谊，虽然后面大家都散到各个项目或离开了，但是还是每年组织几次活动。做每一个项目都有不同的感受和经历，这个项目我逐渐的意识到技术创新和发明的重要性，在这一个项目中我也写了很多技术发明专利，并且专利局目前已经授权了2篇。如果做技术你就一定要做到行业最好，只有做到最好的时候你才有机会去创造更好的技术，不然你只有永远的跟随哪些做的比你好的技术。技术创新都是建立在以后的很多技术之上，如果你不能掌握目前最好的技术，就根本谈不上去创新。技术不是凭空一个想法就可以创造出来的，一个技术创新一定就是解决了某一个还没有被解决的问题或者是比以前更好的解决方案。这个项目让我印象太深刻了，不论是从技术本身还是团队本身。

大家都知道互联网公司变化很快，而唯一不变的就是变化。但是变化不一定好也不一定坏，事情都是有两方面的。作为一个积极向上的我，更愿意去接受变化，并且改变自己。很多人和我聊天以后都会问我一个问题，你是怎么成长这么快的。首先我不认为我自己成长够快，因为只有自己清楚自己想要的是什么，自己知道对自己的定位是什么。至于做技术的人怎么让自己更快速的成长，我觉得首先前面的文章中已经提到过，积极主动花更多的时间去学习更多和更深的相关技术，并且让自己有机会去实践这些技术。当然这里还有提到一点就是积极的迎接变化，因为变化意味着你又有新技术接触想的项目和技术了，那么你的另一个技术领域就有机会去实践和突破了。从我前面做的每一个项目都帮助我建立了一套技术体系，而且这些技术体系之间相互融会贯通，对于软件架构设计有极大的好处，因为软件架构师需要有足够多的技术才能选择最合适的技术去架构系统。这里谈了变化，因为变化让我有机会参与下面一个很重要的项目，而这个项目让开始真正接触云计算，并且这个项目让我的能力和价值发挥到了最大。下一个项目就是做一个公有的PAAS平台。

刚开始做公有PAAS平台的时候我还只是一个高级软件工程师，前面做很多项目甚至连高级软件工程师都还不是。但是已经是那些项目的技术负责人和架构师了，从这里可以看出，在互联网公司级别不一定是最重要的，最重要的是你有机会发挥你的价值和能力。不过话又说回来，很多事情没有级别可能也做不了，不是谁都像我这么幸运，有机会负责这么多NB的技术挑战的项目。现在继续谈谈做的这个公有的PAAS平台，这个项目最开始并不是在我们部门的，而是从其他部门移交过来的。移交过来的时候，部门的老大就在部门内部找人接手这个项目，当时这个项目主要是使用ruby和go语言开发的。部门老大就在部门邮件组里面发了一封邮件问，哪些人会ruby和go，作为一个从.net转型到java的技术体系公司，想找ruby和go语言的人才基本上是没有，何况go语言是一门比较新的语言。不过还好自己比较关注技术前沿和新技术，当我了解到go语言是Google推出并开源的一门语言以后就去深入了解了一下，深入了解以后我觉得这是一门比较有前途的语言，所以就开始买了一本书开始学习，每天晚上睡觉前看半个小时左右，然后在用半个小时把看过的内容实践一遍，就这样一个星期下来基本上掌握了go语言最基本的内容。所以收到这封邮件以后我就简单的回了一封我会go语言，当时自己也还没有想要去加入做公有PAAS平台的项目，结果部门老大就认为我要求主动去做这个项目了。结果现在这个项目的负责人（也就是前面说的统一日志平台，在简单说一下我只是技术负责人，不是团队的负责人，团队负责人一般是M线）就来问我怎么回事，不过还是误打误撞的去负责公有PAAS平台的技术和架构了。虽然以前做过好几个分布式系统了，但是之前的都是比较单一功能的系统，整体架构不是很复杂。但是自从我一开始接触公有PAAS平台，就被这个系统的复杂程度惊讶到了，光大大小小的子系统就有十几个，每一个子系统可能又有很多个小的系统模块组成。不过自己还是很高兴，有机会接触和架构这么复杂的系统了。我很快的把以前的统一日志平台交接给另外一个同事以后就开始正式开始进入公有PAAS的研究了，因为是从其他部门交接过来的，所以接受这个系统还是花了一个星期。他们团队过来了两个人进行交接。交接的时候这个平台要是需要邀请码才能使用的，也就只有几百个用户，活跃用户就十几个吧。但是交接的时候还是经常出现问题，而且还有两个很致命的缺陷，首先是所有用户入口的代理层经常假死，导致不能使用，只有重启代理层，第二个是这个平台完全依赖一个消息中间件，而且这个消息中间件是单点的而且ruby开发的性能很差。所以接手以后除了需要马上解决这两个问题，但是还要本身熟悉整个系统那么多，还要学习ruby。可想工作量很大，基本上刚开始接手的那几周天天都是需要强制加班的，一遍学习还要一遍排查问题。代理层假死那个问题是最急迫的，首先需要招到原因，代理层系统是使用go语言实现的，在线上是后台启动的进程，但是他们以前在启动的时候没有把输出日志重定向，以致于每次假死都时候都看不到异常日志。后面我登录上去查看各种服务器资源消耗的问题，其中网络连接数引起了我的注意，每次假死的时候一般都是1024左右连接处于timewaiting状态。后面我重新启动进程并且把日志重定向到一个文件，下次再次假死的时候我去看，果然是too many file....的错误日志。原因终于明白，由于这个进程没有进行特殊的资源设置又是普通账号，所以默认只有1024个文件句柄可以使用。找到问题就好办了，首先把限制调大一些，但是后面还是会假死，因为链接数会持续上涨。很明显是代码里面造成了链接资源的泄露，就是链接断开以后没有及时的释放，如果不重启链接资源一直不会释放。在没有找到具体原因之前需要有方案来避免这个问题导致的系统问题，那么我就写了一个shell脚本来统计链接数达到可能会导致假死的时候就去自动重启一下这个进程。这样问题基本上得到了缓解，能够给我更多时间去排查问题，因为那个时候我对代码一点都不熟悉。后面就开始从代码级别去排查问题了，经过几天代码的熟悉终于找到了没有正确释放链接资源的代码，经过改进完全解决了这个问题，首战告捷。大家终于可以放松一下心情继续学习PAAS平台的相关技术。

第二个问题就是消息中间件的单点和性能问题，这个问题必须要在大规模推广之前解决，不然一点消息中间件出现问题就会导致这个系统不可用。这个是一个极大的挑战，我就开始调研方案。最终的方案就是自己设计分布式的消息中间件，并且改用go语言实现，工作量很大，不仅仅需要实现服务器端，还是实现消息中间件的go客户端和ruby客户端。不过这些工作都是我自己完成，自己设计方案自己去实现，最后安排了一个测试协助我测试。当然我提交的测试版本基本他是测试不出什么问题的，这个很简单，因为在提交测试的时候我自己已经经过了充分的测试，而且我自己才知道怎么去测试一些异常场景和边界条件。我正在实现这个方案的过程中，新的问题又出现了，存储系统又出现问题，为了保证存储系统的可靠性以前是使用nfs进行同步的，但是nfs有一个问题就是单块磁盘，而且nfs经常出现性能问题和最后的磁盘容量问题。这个时候又需要我去解决，还记得我前面是做过云存储项目的，当时就是使用开源的分布式文件系统，所以对我来说很快就有了方案，并且很快的申请资源部署系统就搞定了。但是需要维护这个分布式文件系统还是比较复杂的，虽然第一次使用分布式文件系统以后解决了长期的容量问题，但是后面还是可能需要扩容。最后时间充裕以后我们就完全把存储放在云存储系统上去了，这个云存储有专门的团队维护的。等我把使用go语言开发的分布式消息中间件上线以后就开始大规模的推广了，经过几个月的推广我们的用户很快就达到10万级别了，主要是免费吸引了很多用户。当然整个过程中还做了很多架构升级和优化的工作，还在各大网站上发布过具体优化的文章：http://blog.csdn.net/wangdk789/article/details/23605403。

经过上面的改造平台基本上平台基本上稳定下来了。后面又做了很多改造和优化，例如整个平台的监控系统改造，资源利用率优化（提升资源利用率10倍以上）等，就不详细介绍了，我在很多技术分享会议上进行过比较详细的分享。整个项目对我技术能力的提升飞跃式的，让我熟悉了整个PAAS平台的技术体系，包括现在很流行的容器技术docker，后面由于这个积累又做了基于docker的内部私有云项目，不过这个又是后话了。这个项目不仅仅让我技术能力得到了提升，让我对云计算也有了更深入的认识，当然对我自己的价值也有成倍的提升。