|
以下是演讲实录： 首先，push是什么? 第二，极光推送原理。 第三，C2000K的问题。 第四，敏捷开发实践。 我们做移动应用面临一个问题就是如何把数据更新到你的应用里面去，大家知道在PC年代的时候，你的应用实际上没有说休眠之后还要去同步数据的问题。但是移动时代，目前大家都在说，限值移动平台发展的瓶颈可能就是电池，电池是最致命，带宽的问题已经解决了。我们在移动平台上更新应用的数据常用的方式，一个是所谓的push，还有一个是所谓的polling，这两种方法可能很多人用过polling的方式，我们常用的就是开一个RPC，到时去问一下，有没有最新数据，有就拉下来。实现起来相对来说polling比较简单，但是polling有一个问题就是假如5分钟查询一次，数据最大延迟是5分钟，平均延迟是2—3分钟。整个延迟还有流量和电量的消耗，polling都是表现不怎么好的。但是polling有唯一的优点就是实现非常简单。 push在延迟方面表现非常好，如果能有效维持的话，push平均延迟大概是在几十毫秒，流量和电量这个比较主要是看你polling的时间间隔。我不知道有多少人在用android的新浪微博，里面有一个很有趣的，我经常讲，大家看android里面有一个push项，就是你去设置多长时间去查询一下数据，他有三个选项，一个是30秒，一个是1分钟，还有一个是2分钟，这个很有趣，大家可以看一下。如果是30秒的话，基本你的手机也就能干半天的活，实现复杂度相对来说push的复杂对会大很多，特别是用户量在千万级以上的时候，不是简单可以搞定的。 这是我比较的手机耗电的情况，这是理论模型。我所说的待机7天多，就是在1400的手机上，如果什么都不做，仅仅让你的机去维持，如果你开一个5分钟的polling会变到有4天多的时间，如果5分钟的时间去做polling的话，这个时间会到五天，就是不打电话、不发短信的话。push只需要去维持一个运营商的网络，整个间隔时间比较长，还有就是我们可以让多个应用共享一个push通道，这个时候如果开push的话，待机时间相对来说比较理想。 这是我们极光推送现在用的android SDK的原理，我们可以用其中一个维持长连接，只需要在后台跑一个活跃的。你的数据不是跟你的终端用户直接建立联系。 我们现在用的一个服务器的基本架构，首先我们前端会有一个所谓的SS的服务，会让你的手机查询你应该去哪边接入，跟哪一台服务器做长链接。因为我们考虑整个全球移动网络的环境比较复杂，中国是大家都知道，有几个巨头，他们都是三足鼎立。比如说在上海用上海移动的，你去接上海移动本地的机房最佳选择，延迟是10—20毫秒，但是如果一不小心跑到西藏的某一太服务器上，延迟可能在300毫秒以上。所以我们前端有一个去让你选择真正的接入服务器，根据你来的地方跟你来的运营商你去去接最正确的服务器。还有一个如果说，因为大家知道中国移动互联网的网络状况确实不太好，机房也是参差不齐，所以我们做了这样一个简单的所谓的SIS，实际上类似于一个DNS的服务。建立长链接之后，通过我们这边叫MQ的机制，进到其他的IDC做处理，这样我们可以把各接收机房数据汇集到一起，集中处理。这个是Session Manager，我们对API从这边下来，因为push Center这边整个架构不一样，相对来说会更重，我们单独放到一个机房，好几个机房做。我们也是把数据汇聚之后，通过MQ转到后台逻辑和接入上面去。 这边我有两点想要着重强调的，就是我们用的两个中间键一个是Cache， 一个是Message MQ，我们正常一个Cache服务器维持30G的数据大概需要90—120G的物理内存，我们规划这么大的物理内存存放这些Cache数据，以保证他的命中率是达到百分之百。因为大家知道一个Cache系统独命中率低于90%，会大大影响整个系统的性能。然后我们用到一个Message MQ，我这边之所以把这个拿出来讲，因为我觉得国内用这个并不是特别多， 一个是稳定性比较好，另外是他的整个管理能力不是别的原来的Message MQ所能比的。 我们经常在社区里面有一些朋友问我这个问题，就是所谓的C2000K，所谓的C2000K的问题，实际上就是如何维持大量的长连接。业界有一个很有名的就是说C10K，后来慢慢变成C100K，C500K。这是什么意思?最早是早期的FTP的服务器，很多的FTP服务器只能维持1万的用户，超过1万之后其他的人很难接入，并且速度非常慢。大家知道我们做push面临最大的问题就是我们有大量的长连接，我们每天活跃的用户有好几千万，如何处理大量的用户是一个很现实的问题。我们做了各种尝试，我们做下来得到这么一个设计，我们接入服务器的模型是用事件驱动，异步、非阻塞。内存的管理，其他早期用的是静态的内存分配和回收。这种方式会浪费大量的内存，并且会影响，因为内存的瓶颈会限制这台及其能够接入的用户数。后面改成一个Memory Pool的模型，因为他有一个优点就是跟我们静态分配比起来本身是比较省内存。跟动态分配比起来，他的分配和回收速度快非常多。所以Memory pool是非常好的解决方案。还有一个是多核，服务器基本没有单核，好几年前都是16核以上。充分利用多核也是非常重要的。假如说我这个机器有16个核我就开16个进程，这16个进程共享监听一个Socket，所以上你socket上停留的数据非常短。每一个进程都有自己的Event look和 Mempool，不需要去共享其他的资源，也可以大幅度的避免出现(锁)。整个我们服务器里面没有出现锁。 这是我抓的我们服务器监控上面的在线用户的曲线，我们的命名是C2000K，实际上在峰值的时候能够维持的用户数是330万左右，为什么上不去?是因为内存的原因。我们如果再想提高就只能优化TCP协议站，我们现在暂时没有这个精力。 目前为止业界最大单机维持连接数，我看到一个单机同时维持在线的有50万。 其实之前的内容，我在eoe前面两场讲了很多，我今天特别想分享的是我们团队实现的敏捷开发。敏捷开发在业界已经火了一二十年，大家各有各的做法，有的人说敏捷开发要快，所有流程简化，团队每天站在一起开五分钟的会，我理解的敏捷开发，从我的角度来说我觉得敏捷开发最大的精华就是持续集成，特别是对比较大的规模系统来说。如果我们几个人在一起做一个项目，大家都从一个里面去写代码，比如我们写了一个月合起来，我不知道有多少人做过这样的事情，你会发现合并的时候真的是一场灾难，可能写一个月的代码需要用一个星期的时间合并，并且发现合并的时候很多人做的事情根本做不进去，最后发现他做的东西没有意义，要么重写，要么这个东西不要了。持续集成里面一个理念就是，我们提交的时间间隔越短越好，持续集成里面，我们尽量鼓励大家尽早提交，提交时间越早越短，就是永远每一个人永远都在最新的代码上去工作。这里面有一个很重要的点是每次提交之后要做集成，集成之后要做完整的回归测试，不要说没有做回归测试，然后每天提交代码，这是更大的一场灾难。 持续集成，我们用到的工具，代码管理工具目前是用的GIT。任务管理用的是Pivotal Tracker，不知道现场有没有朋友用过。他是一个非常轻量级的，可以什么都不干，甚至连状态都不提交就可以放在那里，并且他小到什么程度?就是说，如果我们做一个网站，我觉得那个LOGO颜色不太好看我就写一个放在那里，我觉得LOGO颜色不太好看，谁应该去处理谁就自己去拿。代码Review，我们用的是Review Board的工具，还有自动编译，Buildbot，还有自动测试是Unit Test，还有自动部署是用的Xen，Yum。我不知道大家有没有尝试过做一个，从中间件，到测试的Unit Test整个流程跑一遍，这是非常有挑战的。特别是这个部署，你部署一个可能比较简单，但是要部署50个，还要部署中间件，还有部署整个模块，让整个集成跑起来，这是很有挑战的。我们这边自动部署里面，我这边写到的这些，不只这些，这是一个虚拟化的平台，有一个特别大的优点就是说你的OS在你的电脑上看起来就是一个文件，你这个文件可以跑起来就变成一个操作系统，因为整个系统不需要重启，整个过程可以通过命令、自动化、我可以在这个操作系统上部署一些RPM包，或者做一些配制，跑成一个什么节点。我这边提到的这些工具，远远不只这些，特别是自动部署这块我们自己写了大量的脚本还有用到的相关工具。 简单看一下整个持续集成提交的流程。一个开发人员写了一些代码当然这个代码越小越好，实现一个很小的点就可以提交，提交到我们Git代码服务器上去，这个时候他会自动出发两个事情，一个就是提交一个Reviewer和Unit test，我们用的是叫先提交后检视，因为我们提交之后会自动做测试。提交之后会马上出发一个Unit Test，没有通过就会被打回去。如果你的Unit Test通过了会自动部署到测试环境，这就说到我刚才提到的那些东西，会自动部署到一个测试环境。自动部署到测试环境之后我们会去跑一套测试环境的整个集成测试的脚本，然后会把集成测试的结果反馈给做正式提交的开发人员，还有他的leader。我们做这样一个过程基本上时间是在20分钟左右，每一次提交完之后，就可以知道这次提交是否能够被放下去用，这样可以保证大家每天都知道你写的代码是不是真的能在生产环节上去用的。 我体会到持续集成的代价和优点。代价就是你要能达到持续集成的能力要做一些什么事情，首先是前期系统搭建的工作量，就是你要把我刚才说的一整套的流程可以跑通的话，需要很熟悉，你知道怎么去对接，你知道怎么去生成，怎么把报表生成之后，又去自动部署到测试环境，所以前期工作量非常大。需要写大量的优质单元测试用例，还有集成测试的用例，好处就可以及早发现问题，你会一直有一个可用版本，因为我们验证一次提交成本时间很低，我刚才说的20分钟到半个小时的时间，这次提交如果有问题的话，我们马上做回滚，上一个版本可用，如果没有问题，马上可以形成一个可用新版本。这些工具建好之后，开发人员关注的就是实现自己的代码，只要他的代码放上去之后整个测试通过就不用再担心，因为我们整个测试保证基本功能可以用的。 持续的持续集成是什么意思?大家知道持续集成本身是一个迭代国家，因为 像Test Case的积累，是需要不停的积累，自动化的工具优化，实际上就像我们最开使用的代码管理工具我觉得不好，马上就切到Git，还有管理方法的优化。 最后一句话，持续的自我优化是一个团队的核心竞争能力，特别是对于开发团队来说。这个持续集成实际上讲究的是持续迭代和持续的提高。【完】 |
|
|
