刘军卫：各位好，今天很高兴能在这个会上跟大家分享一下中国移动PaaS的技术选型和实践经验。
我们这个产品部主要提供云计算相关的标准化和定制化产品和解决方案，构建云计算资源池的软硬件集成服务和技术支撑服务，提供云计算咨询、应用云化迁移和容器化迁移服务。苏研其实除了在中国移动内部以外做一些产品化还有一些项目之外，其实在社区里苏研还是小有名气的，OpenStack社区贡献国内前10，全球荒原会员，中国首个OpenStack SuperUser，Ceph社区贡献社区第4，Linux基金会银牌会员，国内贡献第5。
进入今天的主题，PaaS。好多年之前就在提PaaS，PaaS这个概念不断在变化，尤其是PaaS，可能大部分人，尤其是做技术的人，感觉PaaS特别鸡肋。在前几年在底层被IaaS挤压得很严重，在上层被SaaS挤压得很严重。PaaS明显在前几年显得特别积累，但是近几年有一个可以说在某几类PaaS的细分领域中有一个很大的提升，比如像现在比较流行的iPaaS，还有像一些传统的CRM、社交软件，这类PaaS可能还是比较火的。我们把它做了一个定义，在中国移动内部我们怎么理解PaaS，肯定都是大家都在说的，PaaS以应用为中心，为应用提供开发、集成、部署、运维，也就是现在咱们一再提的研发运维一体化，作为一个平台，将一些共性的业务和技术能力抽象出来，形成一个统一的、标准化的、开放的能力服务平台，这个是运营商比较喜欢的，因为只有标准化了、开放了，我才能把厂家的东西解耦。目前市场份额发展比较快的主要是这些类，根据我们移动自身的业务，我们也提取出来我们比较关心的，主要是这几类，一类叫aPaaS，是发展最早的一类，也是最激烈的一类，一开始像谷歌的，像新浪的SAE，大部分是这种aPaaS，但是为什么aPaaS完全没有用户群体，真正的PaaS平台给你提供了开发环境，基本上没人在用，主要是因为这一类PaaS面向一个非常特殊的群体，开发者。开发者的口味比较难满足，基本上导致了aPaaS这一类比较难在市场上获得成功。但是像运营商这个角色他做aPaaS还是有一定优势的，比方说我可以给我的合作伙伴提供一些标准的开发平台，所以说我们把这一类PaaS也作为一个考虑放进来了。另外还有大数据类的PaaS，主要包括现在比较火的Hadoop、Spark、QUVE、HBASE、Storm，这一类的有可能把它封装成PaaS应用来用，这一类也是我们关注的。还有一类PaaS是iPaaS，框架类的，这类PaaS主要有一些像数据库、消息队列、缓存，这一类的使用方式和没有PaaS的时候区别不大。还有一类PaaS，是通用中间件，有一个能力开放平台，放在这个平台里。另外是架构的选型，前几年讲PaaS的时候，大家都不太敢讲，像国内来看，基于Cloud Foundry来做的不是太多，大部分的创业公司基本上没有再基于这个来做，不是说不好，其实做PaaS做业务做得好的我认为是Cloud Foundry，但是不太符合现在这种互联网的思维或者开发者思维，所以导致它不太适合拿来做一个创业项目或者是基于它来做一个产品，除非有能力比较强的公司，像IBM、华为，他完全有能力来掌握这个东西。对应用管理，为了完善生态圈，也搞了好多，应用管理的框架，叫应用也好，叫Marathon，像推特搞的叫Aurora，像Swan，这个需要用户定制化程度还是比较高的，它的功能是非常简单的，比较适合于互联网公司的运维人员，我自己来用，不适合作为一个产品交付给第三方来用。另外Marathon这一点，它的功能还是比较单一的，举个例子，像咱们一再说PaaS的好处或者容器的好处，自动化的扩缩容秒级的，Marathon扩缩容非常简单，随机的，这对于一些企业级的应用是非常不好的，比如我要求你按时间顺序扩出来了，你就再按时间顺序缩回去，这个Marathon是完全做不到的。另外比方说Marathon稳定性确实有些问题，这是通过我们的一些实践总结的，比如在1.1版本的时候，健康检查是非常有问题的。另外社区也不是太活跃，解决问题的成本是非常高的，比如Marathon上去了，你在客户那一旦出了问题，那马上给我解决，解决的成本是非常高的。这个系列里对用户带来的困难就是，这个生态，因为每一个组件只解决一类的问题，它会通过几十个组件来构成这个完整的解决方案，而且这几十个组件各种各样的语言，C++、Mesos、Marathon、Python，成本非常高。介绍一下它的优点，它确实比较旁边，和Mesos来比确实比较庞大，因为它功能特别完善，它打得口号是开箱即用，所有功能都整合进来了。但是这个对比其实是不太合理的。kubernetes这边与OpenStack结合得还是比较好的，生态环境也比较好，尤其是国内的创业公司。
PaaS要解决什么问题，像移动的省公司，他们作为一线，他们是理解得比较深的。我要解决一个应用运行环境问题，托管环境的问题，解决运行环境的问题，对运维人员来说哪个更好。这一类更体现运维人员的需求。另外是提供统一应用开发环境，DevOps首先解决的是给你提供一个开发的环境，后面再解决运行环境的问题。另外还有一个自动化运维现在提得也比较多，自动化狭隘一点说，在很短的时间能做一个事情，那你物理机虚拟机可能时间比较长。另外还有能力开放服务的平台和资源管理与调度。
这个是我们规划的一个PaaS的功能架构图，技术架构不讲了，主要讲一下功能架构。在我们省公司来说，它的技术发展程度不太一样，有的省公司现在还是小机，但是大部分是是X86，大部分省公司停留在基于VM的虚拟化，有些公司是OpenStack。上面是一个能力层，基本上是我们基于以前做的DCOS 1.0，还有只提供一些能力，像镜像管理、存储管理、用户管理、资源管理、服务管理等，这里面做得比较差的是用汇管理，现在好多人提容器、虚拟机、物理机统一管理，第一个需要统一的就是用户管理，要不然是页面嵌页面，没有意义。另外存储这块做得也比较弱。镜像管理还是可以的，应用管理也是可以的，服务管理、资源管理也还行。具体功能不讲了，大家可以看一下。再往上层叫PaaS服务层，你也可以理解成是一个业务层，主要是面向几类PaaS来提供相应的服务。
现在你光做一个平台不行，你还需要有一些概念，现在PaaS里面好的一个概念，大家都在热炒的，研发运营一体化DevOps，我们也做了一些概念的抽象，把研发过程的每一个环节抽象成一个插件，好处是第一方面做了标准化，第二个方面我可以拖拉拽，这条线连起来就是从代码到最后的托管运行。这里面我们已经做完了，主要做了一个，把刚才我讲的每个节点做一个节点化，第二个做一个工作流，把这些插件端到端的串起来。再一个是多种交付方式，另外像环境管理，把资源进行隔离，做成一个域，测试域、集成域、生产域。上线之后运维人员很头疼的问题是配置，出了问题怎么追查，是不是配置的问题。还有表单管理。
另外一个亮点，kubernetes作为所有云计算产品的基础，是统一的分发与运行平台。现在OpenStack也在做，我把OpenStack整个跑在kubernetes上，所有的云计算的产品它的控制平面全部容器化，由kubernetes统一管理起来。比方说我的OpenStack可以跑上来，我的PaaS可以跑上来。
最后给大家介绍一个案例，江苏的，这个案例和浙江的有点像，主要有几个应用迁上来的，像冲浪、网厅，他的日均调用两达2000万，高峰日均4000万。这个系统跑到现在还没有出故障，是因为你容器化了之后，一个网厅的应用其实有一百个实例，挂个十台八台的物理机影响还不是太大。这两幅图是一段时间内峰值调度的图，它的压力还是非常大的。目前整个系统有不到一百个节点，七十六的节点，整个环境能两千多个容器，目前已经上了474个。大部分的前端被容器化了，要改一些参数，在容器来改参数不生效，主要原因是因为，我们用的内核都是4.9.0的，已经非常高了，但是你在容器能改了几个参数的时候它是不生效的，主要原因是内核还不支持在容器里去修改这个参数。像容器被kill掉之后，里面跑的应用变成了孤儿进程，可以找一些社区里面写好的tinyint和dumb-init，来替换那个init。另外还有kubernetes bug，像Haproxy参数也好，改一些大连接数和晋进程数的参数。还有一个，业务调用延迟小于50ms完成。由于你引入了Dockerbridge，它怎么能降低这些延迟，是非常重要的。
我的分享就到这，谢谢大家!
热门专题
