经过了十个城市的路演，华为HDG线下沙龙终于来到了首都。在北京，开发人员之多，关注的技术领域之广，讨论的话题之深入，堪称HDG历届参与讨论者之最。
赵阳是华为PaaS平台资深架构师，也是北京站***位发言的讲师。他本次演讲的题目是《华为PaaS公有云服务实战分享》，他告诉记者，他主要是想分享华为FusionStage团队在公有云上的实践，包括华为公有云交付的挑战、华为FusionStage团队在公有云上提供的容器服务Cloud Container Engine(CCE)，以及华为对容器技术、容器服务的理解。
以下是他的现场演讲实录：
容器云的简介。我不知道大家看完之后是什么感觉，我是觉得挺专业公司做出来的视频比自己做的好很多，这也是我们今年的感想，自己一定要做自己擅长的事，因为之前我们是自己做的，无论是自己看还是给别人看，大家都觉得比较low，我们就请了一个专业公司。如果大家觉得做视频很有趣，也是一个很有前途的行业。
今天我们主要的话题，我是***个话题，当然全天都是围绕华为的PaaS平台来展开的。我们为什么一上来先讲公有云呢，也是因为现在大家很多的工作已经在公有云上面使用了，大家除了使用国外的亚马逊，还是国内的阿里，还是其他的公有云，大家都有一些直观的感觉。所以我们先讲一个比较接地气的题目，逐渐再展现到技术细节。
我不知道大家有没有用过华为的公有云，如果用过的可以举一下手，说明我们还有很大的空间。华为的公有云已经做了好几年了，从开始我们并没有大幅的去推广，因为当时最早做的时候，主要是以一个技术验证和支持大型企业客户为目的。大家可以看到，2011年我们就开始搞，但实际那时候整个行业对于云的理解都是比较混合的，有人说虚拟化就是云，有人说把一些机器堆起来外服务器也是云。逐渐到了2014年、2015年大家真的切实使用的云，大家觉得概念无所谓，主要是用起来好不好。基本上我们认为针对云***的市场还是应用的开发者，其实对于企业来讲他们现在还有很大的疑虑，就是我到底放到云上有什么好处。我们总是说云是可以省钱的，但是对于很多土豪的企业来说不在乎这个点，或者他有很多的考虑，我的数据会不会被人偷走了，或者哪天宕机了，我会不会有业务损失，这些都是问题，这也是我们云要实际改进的。这个表格里面对于开发者来说，很多时候我们不会那么在乎，比如说我今天一个代码跑在上面，可能晚上12点机器停5分钟，对于大多数人来说都是不接受的。我们觉得这个市场对于开发者是很重要的。
我们这个里面做了很多的服务，这个服务很多也是对着亚马逊，因为亚马逊是行业的一个标杆，所以我们没有必要跟它搞的那么的不一样，所以我们还是对着它做的。我们做了云计算、存储、网络，上面的应用服务，还有一些附加的安全服务，这个基本是一个IaaS+PaaS的平台。我们可以看到现在华为主要想的是什么，我们首先要把国内的市场覆盖，所以我们一定要争取在各个省，或者是主干的节点上建数据中心。因为华为一直是做网络的公司，我们一定要保证网络的体验，不能让大家觉得布了几个点以后，时延那么大，这是最主要的考虑。所以我们现在一直在建设各种的数据中心。整个建设过程中提出了很多要求，对于数据中心的能源，还有对数据中心的可靠性，这些可能在成本上会提高，但是对于大家的业务也是有好处的。
PaaS是我们整个公有云的一部分，PaaS的定位是什么，就是服务应用开发者。应用开发者就是整个应用全生命周期的管理，就是应用的开发、测试、部署、上线、运维，还有在业务有些变化的时候做弹性伸缩、扩容等等。这个过程里面我们定义了一些服务，最开始的一个服务我们把它叫做云的应用引擎，这个比较像PaaS，就是我把代码扔上去，别的什么都不用管，我也不知道代码跑在哪儿，我也不知道它有没有一些共享之类的。但是我通过云服务保证你的代码可以被通过网络来访问的。所以我部署上面以后会有一个域名，我通过域名来访问。随着到去年的时候，由于docker的火热，整个容器市场被炒的很热。很多用户说我希望往下沉一点，不需要只是把代码扔上去，我还想操控我的容器，或者我想自己管理我的集群的可靠性、可用性，或者说我应该配它的网络存储等等。这个时候我们做了一个新的服务，叫做云的容器服务，这个基本也是跟其他厂商的PaaS服务去对应的。另外我们现在还在规划一个服务，叫做云的编排服务，这个服务对于应用来说，尤其对一些复杂的业务系统来说是比较有益的，我很难保证有一两个节点跑一个完整的系统。比如很典型的像电商的系统，从一个用户登录，到抢购，下订单，购物车，***的结算，物流等等，这里面可能会有十几个模块，这些模块之间的依赖关系是谁来管理，我们希望通过云的编排的服务来完成。当然这个服务现在还在做，大家现在到公有云是看不到，还在做内部的内测。
我们现在想强调的是什么呢?我们无论做多少个云服务，下面是一样的，这是我们华为的核心理念，就是我们一定要有一个公共的底座。这个底座既能服务私有云，也能服务公有云。大家可能会觉得有点不可思议，公有云和私有云的场景是有很多区别的，但是我们希望把这个公共的组件，包括我们下面讲的基础的框架，还有一些云上的中间键，和云上会用到的管理服务，把它们都抽象出来。抽象出来的好处是什么呢?就是我针对各种不同的场景，可以灵活的去组装，把它组装在一起以后，能够支撑我一个或者多个场景。大家知道华为同时还在做很多通信的行业，包括网络，包括物联网，包括无线通信等等。这些场景下我们也要用PaaS，这个大家在传统的认知上是不太理解的，就是为什么要有基站，要有网关，这些东西要用PaaS。这也是华为现在强调的理念，因为我们在做专有设备，无论从运营商的角度，还是从客户的角度，都是觉得不符合现在的潮流，所以我们要做一个全部软件化的、云化的平台。这个平台里面具体的细节我们到下午的时候，几位架构师都会详细的讲，所以这一块我只是强调整个的概念，就是同一个底座，去支撑上面各种场景和各种云服务。这种大家也会联想到阿里***的平台，其实也是很像的。
我们再转到云容器服务里面，云容器服务我们想做的就是一个PaaS和CaaS的混合体。大家应该都用过一些各种各样的容器服务，容器服务本质上讲就是想要用户很容易的把，比如说docker，Kuberentes，这些开源的东西用起来。这个用的过程中我们首先要保证用户不要自己再去捕捉抓这些东西，因为你从网上下载docker引擎，再找linux的机器装起来，再配网络啊，各种东西，再装Kuberentes，就算是熟练一点的老司机，估计也要搞一两天的时间。这个时候对于你应用开发的过程，这个过程是无效的，就是你学了那么多，你的应用代码不太能跑上去。我们希望的是通过一个封装好的服务，能够让用户不要关心这些东西，我只需要把我的容器镜像，或者我的源代码直接扔到上面就可以跑。这个对于用户的好处就是，还是像传统的PaaS那样去用容器，这是我们整个的理念。它的好处就是你同时享受到了容器的好处，比如快速部署、快速启动、快速扩容等等。
我们把这个服务打开看一看，大家可以看到也没有那么复杂，真的做一个容器的服务，其实核心不在于你用了什么***的技术，而在于你能够把它调养的比较好。这个有点像买一个车一样，你买一个300的引擎，轮子特别小，也没有用，我们主要是整合在一起。里面用了很多开源的组建，包括Kuberentes，包括docker的镜像仓库，包括一些开源运维的工具，像kafuka、ELK这些东西。我们主要做的包装一个是给用户一个界面，一个是图象化编排的，刚才视频也讲到了，还有我们在Kuberentes之上自己定义了一层所谓的容器编排或者是急性调度的一个封装层，这个封装层的目的是为了提高Kuberentes的应用性。我相信很多同事都看过Kuberentes的一些简介，它的模型对于我们比较学院的同学来说感觉是奇怪的，它定义的无论是名字还是概念都比较特别。所以在这个阶段我们是希望把它封起来，你不要再把pod，server，什么node的这些概念，你要的其实是资源池，我要部署容器，我要应用跑起来，我能够访问。在这上面我们也额外加了一些自己添加的特性，包括我们讲的怎么去支持多个Kuberentes集群的，怎么去做这种比较好的调度，怎么在这个平台上面通过一些策略，去实现灰度发布，应用升级等等。还有刚才一直在讲的图形化编排的工具，帮助用户组装自己的应用。还有整个平台，因为我们是放在公有云上，公有云上用户最关心的三个点，***是可用性，第二是用户体验，第三是安全。所以我们一定要把安全搞好。再有这上面会有很多网络相关的条约，现在容器本身已经比较成熟了，但是容器的存储和网络还是在不断演进的过程，所以我们会把各种新的开源的，或者结果调优的容器网络的内容都整合到这个服务里面。
展开来讲几个小点，我们跟标准社区的东西不太一样的东西。***我们做了一个镜像仓库，这个镜像仓库本质上也是基于标准dockerhad，但是我们主要做的是一个租户的隔离，就是保证不同租户之间的镜像是不能互访的。这个对公有云是很有意义的，因为很多人用公有云就是想把它当私有云池子用，这时候你要保证安全性。所以首要的***步是要隔离起来。后续我们还会加一些新的跟镜像相关的，基于开源社区的一些特性，比如说基于docker我们做镜像的签名，还有基于OS的另外一个项目进行镜像的扫描，这些都是为了保证安全性。对于用户来说，对于他上传的每一个镜像生成一个报告，***你的镜像有没有被钻该，第二你的镜像里面有没有含有一些安全漏洞或者威胁，这样对于他的应用是很关键的一点。
第二个就是刚才讲到的我们怎么去做大规模的部署，因为在公有云上面很典型的场景，电商啊或者网站，这里面都会有一个对于量的要求。所以我们不能说只用比较少的资源，能满足所有的场景。所以在这个场景下我们需要做很多的调优，比如现在基于社区版的Kuberentes，对它做一些规模和性能上的调整。当然这个调整最终还是要回归到社区，当然可以在我们的服务上先用起来，但是最终我们会在Kuberentes里面看到这些新的特性。再一块就是我们讲的，你在部署容器的时候，如果大家用过默认的docker，你在部署的时候需要添很多环境变量啊，端口啊，还有依赖管理。这些东西我们做一个简单的封装，我们管它叫一个部署的模板，这个模板里面签了很多用户常用的配置项和参数，用户可以基于这个模块，可以快速的、批量的部署它的容器，而不需要一个一个的管。这个大家可能觉得docker也是类似的，其实从理念上确实是这样。
这个图形编排我们也讲到了，我们希望通过一个界面，可能对程序员来说，很多程序员是厌恶界面的，但是对于应用的开发者或者是上层的系统设计的人员来说，他希望能够很直观的看到我整个系统的关系，所以我们认为还是必要的。我们的愿景是在整个的视图上能够看到很多别的云的服务，比如我现在只是容器服务，未来可以用容器去对接数据库，去容器去对接负载均衡，对接大数据等等，这样我的容器服务就变成一个应用总的入口，大家可以在上面组装出自己的应用系统。
还有一个很重要的就是应用的运维层面，大家都知道我这个应用跑起来以后，整个应用的生命周期里面部署是一次性的活动，部署以后可能会长期的运行。长期的运行过程中其实有很多的指标是需要关注的，比如说我的资源使用率，我的系统有没有异常的事件，有没有告警，还有各种应用程序输出的日志。这些东西我们都是借助于docker和Kuberentes已经定型的一些通道，比如说它的监控的代理，它的docker后台的API，把它们集中的导出出来，放在我们基于ELK和一些改进的统一的运维系统里面。基于这个系统我们可以做到，***用户可以实时的看到自己应用的健康状况，资源使用情况，日志告警。再一个就是基于这个数据，我们可以做弹性伸缩，可以做扩容。这个就可以应对很多典型的电商，或者是网站的场景。
另外一个我们一直在强调的，也是今天开发者社区一直想跟大家强调的一个理念，我们一定是基于开源的。这个东西现在的趋势很明显，你再自己搞的话，就算你公司有几万人，也搞不过全世界的开源力量。所以我们现在整个策略一定是源于开源社区，把我们做的一些改进回馈到里面。当然这个是动态变化的，如果大家去网站上找，可能有些顺序不太一致，但是基本上我们可以说我们现在国内的贡献度是一样的，就是对于docker社区和Kuberentes社区。这两个社区大家可以看到里面有很多熟悉的面孔，像谷歌，(18：59)，docker公司，还有IBM等等，所以这些公司我们也可以认为，其实大家都有活干，虽然我们在某些客户的时候，大家是去抢钱的，但是从技术整体的愿景上，大家都认可我一定要搞一个公共的平台，一定要搞一个所有人不会再重复建设的平台。这个应该是一个生产力上的提升，大家不要盖一样的房子养活自己，这个对整个社会没有太大的效益可言。
我们也可以基于现有的服务分享几个案例，当然这个案例大家应该都比较熟悉这种典型的场景，就是电商的场景，无论是京东也好，阿里也好，或者是很多网站，唯品会，美丽说，大家都会有这种场景。就是双十一或者某一天来了，我今天就要搞促销，搞促销的时候，跟平常的业务量是有几十倍、上百倍的变化。也时候怎么办呢?传统的情况下我会提前两三天把资源准备好，当然这样肯定是最保险的。当然其中也有一些我认为没有那么关键的业务，在整个电商系统里面抢购至少不会死人，不会造成用户的钱被不正常的透掉，或者是数据库的内容不一致。我们觉得这个系统可以作为容器改造的试点，所以我们拿它做了一个尝试。这个尝试在前两天双十一的时候已经产生效果了，就是我们做了一个手机的预约抢购的模块，这个模块大概在两三天之内服务了几十万的抢购的请求。在这个请求来的时候，我们会通过容器服务实时的创建事例，一旦这个请求没有了，我们就把这个事例删掉。这样首先保证了业务的敏捷性，保证几分钟之内扩出很多的节点。再一个对于研发的人员来说，这也是一个很大的好处，我不需要再去准备各种各样不同的环境。我们一直在讲DevOps，其实DevOps大概在上个世纪就开始有人讲了，但是真正能够落地，容器是很关键的要素，它保证了我真的可以实现一次代码处处运行。所以通过这个，我们也改变整个研发的流程，最终的效果也是不断的改进电商网站，或者追求新的特性的时候，可以做到非常快的周期，这应该也是从业务上直接的好处。
另外还有一个也是我们测试的客户，他们做的是一个有点像租车管理，有点像滴滴或者神州这样的，大家会做一些基于手机的APP。以前的场景下是说我做一个大的应用，这个应用里面把所有的组件都绑在一起。现在因为从手机APP里面，两三天就会下一个新版本。这时候如果你天天打一个大包的话，效率是很低下的。客户主导做了一个微服务的改造，这个改造把APP里面切出很多很碎的功能点，每个点是一个独立的微服务。这个情况下如果我还用原来的虚机的形式去部署，就是我拿一个很大的资源跑了这么多的服务，其实是达不到微服务资源隔离的要求的。这个场景下很自然的也会切换到容器，通过容器首先保证系列路的隔离，再一个保证快速的升级和部署。这个我相信大家也都能理解，作为容器应该是很典型的场景。
讲了这些场景之后，大家应该会有一些问题，你做了一个云服务上好像也没有什么奇怪的，把docker、Kuberentes自己加点代码，包一包，发上去就完了。在这个里面公有云从我们的角度看来，或者从我们的经验看来，困难并不在于你写代码，困难在于整个运维的过程。因为公有云大家都知道，竞争很激烈，任何一个厂商基本上像赛马一样，一会你超过去了，一会我超过去了。这个场景下你怎么能够保证你的服务持续的会有人用呢，这个服务本身就是一个DevOps的方式。所以我们现在基本定的是每个季度就会有一个大的发布版本，这个版本里面会加很多的东西，这些东西基本上都是一个逐渐去叠加的过程。这个叠加的过程我们发现，我可能改系统，我可能改了一些后台的东西，或者加了一些用户可见的特性。这些东西一步一步的堆上去，对于整个工程来说是很大的一个挑战。这个挑战是内部的。还有一个问题是外部的，大家都知道华为只在国内运营了自己的云，在国外我们的策略是帮助运营商客户去建立云。所以大家假如出国或者看到一些新闻报道会发现，现在很多运营商在搞云，可能很多传统的我们以前的知识是，这些互联网的新贵，像亚马逊、谷歌他们在搞云。实际从华为的理解，他们是面向一类场景，但是从传统的客户，或者是一些成熟市场，像欧洲或者拉美，大家都觉得最可靠的人还是运营商。***运营商从来不会乱扣大家的钱，第二运营商过两天就倒闭了。所以运营商建云的话，对于很多人来说是一个可以理解的事情。所以我们现在是帮着大家一起建，大家会看到我们一方面在自己不停的做东西的情况下，还要不停的跑到外面去部署，我们会跑到欧洲，跑到拉美。这些每一个版本，我们都要去升级，都要去保证在业务不终端的情况下升上来。所以这是一个非常大的挑战。
这对我们整个团队和工程能力是很大的要求，在这个要求之下，我们也是首先自己在做DevOps，就是我们不再是一个口号。DevOps可以从天上一直做到地上，我们觉得真正从搞一个公有云的场景下，一定要搭建一个完整的，基本可以做到全自动化的流程。当然这个过程是很痛苦的，就是我们怎么去建这些环境，怎么打通之间的网络，怎么保证它们的一致性，怎么去构建一个全自动的流程。这个结果是什么呢，结果就是我们能够做到发布一个新版本，在一周之内能够发送到全球的各个节点去，通过一些自动化的脚本，或者运维的工具，做到无损的升级。这是公有云后来大家去比拼的一个关键点，就是你的软实力是什么，而不是你的特性点比别人多多少，你的功能比别人强多少，或者你的版本里面有多少版本。所以这是我们现在还在运营建设的一个过程。这个里面我们也发现了很多问题，把它再沉淀到刚才讲到的版本里面，再不断的滚动式的改进。所以这个也是我们很多华为部署到的一个新的世界，比如以前我们做电信的，基本上可以半年或者一年一个版本，版本出去了，就稳定运行，没有太多的回馈或者是迭代的过程。但是在云的时代里，大家都是在一个起点上。
好，今天我讲的内容主要是这些。
(结束)
