经过了十个城市的路演，华为HDG线下沙龙终于来到了首都。在北京，开发人员之多，关注的技术领域之广，讨论的话题之深入，堪称HDG历届参与讨论者之最。
虽然同样谈PaaS，但是华为PaaS平台资深架构师张龙春则是另辟了一个角度。他来自中央软件院PaaS架设部，所以他主要谈谈华为设计这个系统的时候到底是怎么考虑初始架构的，从这个角度看PaaS核心组建高效灵活的应用调度和资源管理。
以下是他的现场演讲实录：
既然前面的专题我们基本上都已经过一过了，我们就讲一讲这些问题背后的思想到底是什么。我是来自中央软件院PaaS架设部的，我们平时设计这个系统的时候到底是怎么考虑这个问题的，大概从这个角度我们继续来看一下PaaS的核心组建的高效灵活的应用调度和资源管理。
我们上一个讲题讲的是DevOps，我就接着DevOps这个话题往下讲。我们回顾一下刚才马大师说的DevOps有什么收获，就是他提到三点，他的一个理解，其实我也感受颇深的。他提到的***点是DevOps我们期望的是把所有的东西都组建化，第二个东西所有的组建是可流程化，第三个是所有的流程可自动化。是不是通过这个就把整个从Dev到Ops的所有过程都管理起来了。我们知道在一个开发过程之中，除了开发程序的研发要做的事情就是写程序，我接到一个需求我要分析，我写我的需求设计文档，落到我具体的开发代码的编写制作之中，***我编译成一个ese文件，可以执行的文件。通常我们的工作就做完了。交给另一波人，另一波人就去装机器，装完机器做网络设计。装机器的过程，做网络设计的过程，具体做安装部署的工作是不是很多都是手工的工作，这个工作就是我们所谓的去部署上线的过程，部署完之后我们就去运维这个东西，运营这个东西。运维这个东西的时候，我们不断的看这个东西的情况是怎么样的，如果有问题，比如一天早晨起来机器宕掉了，是不是再装一台机器，把这个再重新部署一下。
这个过程里面背后我们可以看到很多都是手工的，或者是跨不同组的这种工作。这种工作一旦手工工作很多的时候，我们不能把它流程化的时候，这个工作的可复制性就会比较差，大家会很辛苦。我相信一个事情做一遍不难，难的是你不停的做，这个道理同样应用于整个研发领域。我们装一遍机器不难，难的是你天天装机器，我安装一次程序不难，难的是每次都安装这个程序。而且你改一次参数可以，改10个、20个我可以做，你改100遍的时候，是不是难免有一次疏忽了。特别是越熟悉的人，越觉得这个东西容易疏忽，这时候越容易产生错误，这是人的因素。
所以DevOps的精髓就是，我***件事情就是把所有的东西都自动化，所有的东西都可操作。可操作之后就可以流程化和编程了，所以这是它的本质。只有这样子我所有的过程从Dev到Ops的所有过程都可以做到自动化，这是一脉相承的三个阶段。
接着刚才说DevOps，我以前经常说DevOps是管一个应用系统的前半生的。什么叫前半生的?就是从调研接需求，到开发，一直到这个程序写出来，整个镜像打开了，开始编译部署，这是前半生。什么叫后半生呢?我部署上去了，我要运营，我要监控监管，日常出报表，定期看结果，***到经过五年十年这个程序下线了，这是它的后半生。我以前提过这样一个话题，DevOps是管前半生的，而我们的PaaS运营平台是管后半生的。但是我一节课仔细听了马大师的演讲，我新的感觉是其实DevOps是管一个应用一生的，只不过它的后半生还用了DevOps的思想，把它放到了PaaS去管了它的后半生。所以我现在的观点是DevOps是管整个应用的一生，后半生是靠PaaS帮它一起实现的。我们站在这个思想上来想。
回过头来看一下，***一个话题很多内容，前面每一个话题里面都提到了，所以这个形式并不很重要，关键是你理清什么内容，所以我们不一定非得看片子本身的内容，包括挑战啊，包括发展趋势啊，大家都很了解了，我们就讲讲DevOps的后半生，PaaS是怎么帮它实现的。
我们想一个应用程序，我们作为一个开发人员做一个应用程序，一个应用系统的时候，我们期望一个什么模式是大家比较理想的模式。我们一直说附用，能够把以前任的结果沿袭下来，不要发明文字。其实说这些东西的背后我们都希望，我作为一个开发者可能希望的是，***是不是有现成的代码，现成的应用，现有的功能，我可以拿来就用，不需要自己再做一遍了。第二现有的安装，现有的调试，现有的部署，是不是都是现成的，我拿来就可以用了。我要做的事情就是把业务逻辑开发往上一部署就OK了。包括将来运维的时候，现在很多应用会碰到波峰波谷的情况，双十一的秒杀啊，或者是有些时候特殊的公关事件，或者是公共事件出现时候的流量的冲击。类似在这种情况下，我的系统也可以很灵活的处理这种背后的对于资源的需求，如果这些东西都可以有一个现有的系统帮我们承载，我们的工作只做应用逻辑、业务逻辑就可以了。当然这是很理想的，我相信理想的情结还是要有的，虽然实际上不一定完全能做到这一步。
在这种理想的情况下，我们期望能够让一个平台帮我们把编译、测试、运维的东西都实现掉，这就是一个比较理想的场景了。所以我们期望PaaS核心的模块也能达到这一步，才能达到我们理想中的目的。这就是我们设计PaaS，或者是PaaS存在的一个意义。经常有人会问这么一个问题，你们做PaaS的，PaaS到底是干什么的，能给我带来 好处呢。我通常会这样想，得看问的这个人是谁。问的这个人如果是一个偏研发的同事，我通常会这么说，PaaS里面有很多服务，你写程序的时候，这些东西都是现成的，而且都是很好的，你点一点，布一布就可以了，这些功能都是现成的。
但是如果是偏运维的同事，我们可以这么说，PaaS可以把你日常的工作都涵盖掉。举个例子，你部署的时候安装机器，还要调操作系统，还要装程序，还要配参数，环境变量，各种变量的东西。现在的做法是，有一个表述包，把你所有的事情开发人员都帮你表述好了，你要做的事情就是看一下机器的总量够不够，物理总量是够的，一台机器有了，你把这个包放上去，点一下安装，等一下喝杯水，回来这个东西做完了。你再看看日常的工作，会给你发一个报告，你看一看结果，你可能要做的事情是根据业务的需要，制定一定自动化的策略，比如说弹性伸缩的策略等等。你告诉系统，当我的负载到什么程度的时候，你是不是帮我破一点节点，当负载到什么程度的时候你是不是把节点降下来，这种状态是不是比较理想。
如果一个客户问我的时候，大概会有这样一个回答。客户说你们PaaS到底能做什么，特别是像企业的客户。PaaS通常能做到这一块，***这个PaaS里面有现成的很多现有的服务，你的应用开发就非常的简单。而部署和维护的成本会非常的低，能够减少你的应用开发，就是你来了新需求，到最终上线的这个时间会减少很多，这是***个。第二个是过去你作为一个个的很独立的开发的系统，都是独立采购硬件资源的，在这种情况下你就会发现每一个资源池可能都不饱满，但是你每一个资源池又得考虑峰值情况，肯定得把提前的余量预留好。这时候你整个机器的管理、运维，包括资源的平均利用率都不会高。所以有这个PaaS，除了刚才说的你的业务沟通市场的时间缩短以外，还可以把资源重新的利用起来。你可以把一组的应用部署到一套的平台里面去，这样你整个资源利用率提高了，你的运营运维的效果也好了。这是站在业务的角度看待问题。
所以我们站在不同的维度看PaaS，就能看到不同的PaaS。所以PaaS就是有不同的面，我们这么来看，这就是我们看PaaS的来源，从每一个角度来看PaaS。
docker大家都知道这个概念，docker里有一个很重要的概念，叫打包概念。打包的意思，就是把所有的东西都打在一起。不要小看打包这个概念，有时候量变会引起质变，当你把所有的依赖都压缩在一个包里的时候，当你所有应用的启停都简单到一个机器的启和停的时候，一个东西才会发生变化。举个例子，我们过去部署应用程序的时候，我们知道通常部署一个应用程序需要把一个应用程序安装到一个目录上去，需要去配各种各样的配置文件，是不是有时候还需要看环境变量，有时候我们的应用程序还会写一些start up或者start stop的脚本，或者(16：54)的脚本，这些脚本还要和其他的应用程序交互。这些东西虽然看起来不是很复杂，但是往往都是每一个应用程序很个性化的东西。当这种个性化的东西没有形成一个标准的时候，这个应用程序的启和停就变成个性化的事情了。
所以我们知道为什么过去那些PaaS平台会定一系列的标准，我需要一个什么东西，把程序的启停封装起来，来达到我对外提供统一的启停和应用管理的目的。但是容器化之后就不一样了，容器化之后你所有的东西都放在了容器里面，这个时候所有的启停都被认为是容器的启停，所以整个应用的启停简单的就变成一个程序的启停，就是容器的启停。这样一下子就把应用程序对外的接口变得非常干净。
我们刚才最早的时候也提到一个观点，我们期望我们应用后半生的管理都变成，***是组件化的，第二是可编排的，第三所有的编排都是自动化的。如果按照这个角度来看，***件事情就是要求我们写出来的应用程序，至少有一个很合适的界面给我们提供出来，让它可以很容易的被编排，被使用。因为PaaS这个概念出来的并不是刚刚这一年、两年才有的，很多年前都有。但是有了容器化之后，就是docker只是容器的一种标准，有了容器化之后，才发展的更快起来，这也是有一定的相辅相成的作用。容器化之后，就是我们应用程序的管理有了一个标准，这是***个。
第二个sefe，就是交付。过去的交付也有通过集中的或者软件仓库的方式交付，但是以容器化的角度的交付，现在是正式的把这个问题变成一个业界的常态了。过去可能是有些应用做，有些应用不做。但是你有了容器化的概念以后，交付就是基本上大家都会选用这种集中的注册中心交付的模式，或者是集中的软件交付的模式。这种模式使我们的交付也变得标准和单一了。再加上我们说的所谓的隔离，针对这个事情我也谈谈一个理解。
我们做PaaS的时候，一方面做PaaS平台本身，另外我们也在研究另外一个话题，到底传统的应用是怎么能够搬到PaaS上来的。一般我们说***件事情我要建云，第二件事情是要迁云，就是把东西迁上来。当我们建一个PaaS平台，没有人来用的时候，那就只是技术上的一个先进性而已，我说来说去没有人用。但是又有多少应用是新建的呢，很多是从传统的应用迁移到云上来的。迁移到云上来的时候，我们知道传统的应用，我们过去看到的很多应用在前几年，在容器化发展之前，那些应用基本都是以虚机化的应用比较多。我们知道虚机化的应用，那时候通常是以虚拟机为单位进行隔离。所以它的隔离性只能体现在虚拟机上，应用如果享用隔离，就必须建不同的虚拟机。所以通常的做法就是一个应用会启一个虚拟机，或者一个集中的应用启一个虚拟机。
但是我们知道虚拟机的启停和容器的启停级别肯定不在一个级别上的，容器其实就是一个启一个进程，容器如果还能提供隔离机制的话，我们就能产生***个好处，我们可以在一台机器上布很多的容器。而每一个容器之间是互相隔离的，因为这个技术大家都很了解，我只是谈谈能给大家带来的好处，传统应用的不同组件就可以核设到一台机器上去。核设到一台机器上的好处就是，我不需要很多很小的虚拟机。举个例子，我现在的物理机规模都很大，48核，128的，256内存的机器。过去画10个虚拟机或者20个虚拟机。但是一旦画完虚拟机之后，虚拟化本身的消耗也很牛，而且这个管理也很麻烦。在这种情况下，如果我们可以把一个应用的不同组件核设到一台机器，同时又能够做到一定的隔离性，这样我应用的部署是不是也会变得相对的简单起来了，这也是一个站在虚拟化和容器化角度来看应用部署革新性的变化。就是我程序的核设部署变得非常简单，而虚拟机的用度可以不需要画的非常的小，这样我应用的管理也会变得非常的容易。所以从这些角度来看的话，应用这个层面，将来的管理就会有新的不同的理解和突破。
刚才提到应用本身的变革之后，回到刚才这个话题上我们可以简单的说一下。容器化来了之后，让我们的应用程序的启停变得非常的简单，它对外的接口变成单一化、容易化去处理。第二它整个的递送变得非常简单，我们不需要手工做各种各样的拷贝。第三它在一台机器上可以核设很多的应用程序，让我们的程序管理变得简单。
在这种情况下我们再想PaaS再往上的能力，我们刚才说了有了容器化的特点之外，是不是离我们刚才最早说的理想的模式到底还差多远呢。刚才说了一个应用的后半生我们希望***做到的是，***个它的安装、部署、管理、弹性伸缩全变成自动化了，全是可编排的，我的应用写什么，应用程序运用什么功能，也都是平台自己给我提供的，这是一个理想的模式。要达到这个理想的模式，是不是刚才说的docker的那三个特征，就能满足我们所有的需求了呢，现在看还是差一些。
会差哪些呢?我们做一个应用的时候，分析一个应用的时候，往往一个应用并不都是一个简单的应用，一个应用并不是简单的，甚至连最简单的应用，我要做一个高可用的外部的BBS的应用，或者一个blood的应用，是不是都有一个前端，一个缓存，一个数据库，再加一个什么东西，都是相对复杂的几个节点或者几类东西组成的。这几个节点，几类东西，我们单独拿一个节点，或者一类程序，拿docker来做，好像都能够提升部署的效率或者效果。
但是作为一个整体的应用，我是不是还得把这几个东西单独手工的弄一遍呢?还有一个机制能够把一个应用不同的组件，或者是不同的部分，能够把它编串起来，形成一个整体。我们以这个整体为单位，来看应用，是不是这样就会比较理想一些。所以我们就希望另外一个概念，有一个机制是跨不同的，每一个应用程序，组成一个虚拟整体的应用的角度。这个时候我们通常会说，当然这个调度的核心有很多，我们可能会选Kuberentes，因为今天上午其他的专题也都提到了我们有Kuberentes，有很多很多的平台做这件事情。不管是哪个平台都要解决这些问题。
举个例子，一个应用的不同节点它的关系是什么，它启停的顺序有没有要求。上一个应用的不同节点之间要不要理解对方的存在，这个应用程序给外部提供服务的时候，别人怎么能找得到它。这个应用如果做扩缩容的时候，到底是整个应用做扩缩容，还是某个节点是瓶颈的时候做扩缩容。这些东西怎么做，如果这些东西都不能组件化或者做好的话，我们只看docker自身是没有意义的。所以我们总需要这些东西，把这些东西都做掉。所以我们就希望有另外一个更全面的系统来覆盖这些内容。仅仅是单机的容器往往是不够的，所以一个生态环境里面还需要很多其他的内容。
我们提到了Kuberentes，这是编排方案的一种，我们其实在这上面做了一些扩展和扩充，也会把这些回馈到社区去，希望这个东西能够做的更好，业界有其他的。只不过Kuberentes现在看，在社区的发展上这一块发展的比较红火。我们知道技术上没有绝对的先进和落后性，这是***。第二开源的世界里面大家都能互相看到对方技术的实现，就算我今天比你差一点，不代表我明天会比你差，所以绝对的好和差我认为是在一个瞬间存在的，但是长时间看是不存在的。但是一个东西是不是能发展的好，得看社区的红火程度。如果说人多，众人拾柴火焰高，只有人多了，这个事情才能发展的起来。所以我们可以看Kuberentes社区的热度还是非常高的。
我们往下看，基本概念就不说了，说了很多遍了，而且大家到网上随便一搜都能知道这些基本的概念。这是它整体的架构，我也不怎么说了。这是一个典型应用创建的流程，这是调度器的分析过程。我就提到一个调度器的算法，刚才我们也提到了一个应用不是被拆解成很多单一的应用组件，一个大的应用会看成是很多组件的一个组合。一个应用布下之后，我们过去的做法是说，我要布一个应用，部署在哪台机器上去，通常我们过去的想法都是这样操作这件事情。我布一个应用到这台机器上去，这个机器的IP假设是192 168.1.1的节点，我要把这个应用部署到这个节点。请注意，我说的我要把应用部署到这个节点。因为这个节点是我知道的，它能够满足用户的或者这个应用需求的。这种做法，当然做肯定是没有问题，这叫命令式的一种做法，就是我做这件事情。
倒过来我们可以看，是不是还有另一种不同的做法。另外一种做法就是，我要布一个应用，我希望有一个CPU，2G内存的机器布它就够了，我有这样一个需求。我把这个需求下下去，反正你这个系统帮我能找到这样一个东西，你能按照我的需求提供这样一个资源，就把我的应用给部好了，这是不是也是一个做法。
这个做法和刚才那个做法的区别是什么呢?刚才那个做法是命令式的，我要做这件事情。第二个做法是我有这个需求，请你帮我做这件事。这两个是有区别的，对于我们一个理想的模式而言，我们应用程序的将来运营和运维理想的模式，***种和第二种最终结果并没有什么区别。但是好处在什么地方呢?当我提出是一个需求的时候，这个需求的满足是有系统帮我去想怎么去做的，就有一定的主动性。当它有了主动性的时候，它的主动性是不是可以复制。我现在告诉它我需要部署一个1C2G的资源就够了。当这个1C2G的资源出错了，这台机器坏掉了。因为它知道我的需求，还可以再找一个1C2G的资源，是不是它有了主动性之后，可以帮我做更多的事情。如果我告诉他部署在192.168.1.1的机器上，如果这台机器坏掉了，平台能帮我们干什么呢。它只能说抱歉这台机器坏掉了，我还有一个1.2的能不能用，我还得告诉它1.2的我看看能用，你再用。就是当我指定到动作本身的时候，这个时候系统的主动性就降低了。我们期望的是我们只提需求，让平台帮我们做决策和调度。这时候当系统出问题，或者系统没有出问题，将来压力变大的时候，我需要做扩缩容的时候，这个时候它的主动性就可以继续发挥作用，这就是我们调度系统需要做的事情。
调度系统就是把过去命令式的调度算法，变成我是需求，让它主动帮我调度算法的过程。这就是很多调度器底层需要做的事情，我们来提要求，它来提实现。它来提实现的话有很多方法，一般我们会讲一个例子，基本的调度器。***它得把排他性的元素给去掉。举个例子，我不希望部在一个网络很差的节点上，我不希望和那个应用程序部一起，我不希望怎么怎么着，就是一些排他性的条件一定要先去执行掉。因为这个排他性的条件一旦发挥作用，所有涉及到的可能的资源都要排他性的去掉。第二个阶段如果所有排他性的都去掉了，所有剩下的都是侯选的了，都是可用的了。在都是可用的情况下我选一个***的，更合适的节点做这件事情。所以整个系统调度核心就是从这两个角度看问题，***个是先做排他性的，第二再做***性的。所以在KBS里面也是有这套调度器的过程和不同的算法组成的，不同的算法我们都可以配的。这些算法都是我们可以插进去的，当然了它提供了一些默认的基本的算法，可以让我们使用预定义的算法做资源的调度，这是一个基本的调度的过程。
其实亲和性和反亲和性的也是调度的一个过程而已，亲和性和反亲和性就是刚才算法的一些特例，但是为什么单独提出来呢?因为在很多算法里面，在很多的实际场景里面，亲和性和反亲和性的作用还是非常大的。举个例子，我们在做应用的，刚才说我们过去是命令式的，现在是需求式的，提需求，去定义的方式去做的。我的需求定于的方式去做的时候，其实我真的不知道底层到底能给我调度到什么地方去，因为不是我指定的节点。因为把排他性条件去掉之后，合适的节点可能还有几十个，这种情况下我们有时候为了应用的特别的需要，特别是高可用的需要，或者是一些其他的需要，会有一些特别的要求。这种特别的要求就要求有些应用程序是希望离的越远越好，或者说它不希望在一个物理机器上存在。这样就导致这一台物理机器如果出了故障，它所有的节点都宕掉了。如果它在不同数据中心，你换一个，它的数据中心还在。这就有点类似于反亲和的战略。
亲和性策略是什么意思呢?刚好这两个应用，一个应用是白天忙的，一个应用就是晚上忙的。本来它俩之间对资源的需求就是交叉的，它俩如果亲和在一起是不是比较理想。如果我们指令性的告诉它，这两个应用***能放在一起。当然我们所谓说的无论是亲和性还是反亲和性，都是一个建议，就是我对它的一个要求。它如果在满足的情况下，尽量会帮我们铺在一起。当两个应用程序刚好对资源的需求有波峰、波谷差异的时候，我们如果给它一个亲和性需求的话，就会尽量的把这两个应用铺在一起，这就是亲和性和反亲和性。其实亲和性和反亲和性也是上一页说的这些调度算法的一类，只不过我单独拎出来的意思是，这些东西其实是我们真正业务使用之后需要着重考虑的算法。
有了这些之后，我们应用的部署过程就变成了我只需要告诉你，我要部一个应用了，需要什么样的资源，你大概按照我的标准部就可以了，是不是把部的过程交给了一个平台了。交给这个平台之后，刚才我们也提到这个应用真正部的过程，就是它选到这个节点，真正部的过程也变成了。过去是我要把程序拷上来，还要安装，还要执行它的安装脚本，启动的时候要执行启动脚本。重启的时候压执行重启脚本。这样一系列过程就变成一个容器的启和停，是不是这个启停的过程也标准化了。所以通过这两层的概念，把我们应用部署的过程就统一起来了。是不是离我们刚才说理想的模式又进了一步。
我们再回过头看一下，我们刚才说一个应用后半生的理想模式大概是什么样的，我再简单重复一下。我们期望***我的应用要使用的这些功能，现成的如果有，我拿现成的就OK了，这是***个我希望的模式。第二个我的程序只关心我的业务逻辑，我写完之后我的应用的部署、管理，生命周期所有的东西，是不是今天帮我们自动就完成了，这就是我理想的一个模式。所以如果做到刚才说的这两点之后，是不是离我们理想的模式又近了一步。刚才说到理想模式的前一个问题，我希望是不是现有的这些应用，现有的功能如果有，我直接利用就可以了，我不需要再开发了，我不需要把这个东西再发明一遍了。
这件事情是怎么帮它做的呢?平台希望提供一整套的服务目录这个概念。我们知道在整个PaaS平台里面会管两大类的东西，其实两大类的东西本质是一类东西，都是应用。但是我们还给这两大类应用稍微做了一下扩展分类。一类东西叫做纯的应用程序，叫应用，还有一类叫服务，其实服务也是一类应用。但是服务和应用稍微有一点点区别。这个服务是可以被自动化使用的应用，叫服务。我们的应用可以给人用，当然也可以给外部用。而服务主要是给另一个应用，或者另一个服务用的，这种东西其实也是一种应用，只是我们把它给稍微的做了一下归类。所有的服务系统都会有一个服务的目录，目录里面有我系统里面现存的，大家通常知道的redis服务，SEQ的服务，DDS的服务，有很多这种服务，这种都是大家都会用到的通用的服务。
这种服务应用程序开发的时候我们用就行了，甚至我们过去说，我拿一个轮子的话，可能会编译到我的代码里面去，这是一种使用方法。再往后的使用方法，既然大家都耦合了，是不是说我要想用个redis，我就从平台里面订购一个事例就可以了。平台只需要告诉我说你访问的redis的地址是什么，你的用户名密码是什么，是不是就够了。我们告诉系统说我需要一个redis服务，我需要10G的空间，我希望它高可用，我就是提这些要求。类似于刚才我部一个应用的时候，我提一个要求，我需要1个CPU，2个G的内存，或者我需要一个实际的网卡，或者我需要一个1G的网卡，或者我需要一个本地盘是什么，我需要一个远程盘是什么，你提要求就行了。
服务也是一样的概念，你的应用程序提一个要求，系统就会把服务给你找到这个服务，给你生成你需要的实例，然后把访问信息给你，你就可以使用这个服务了。这个时候是不是离我们刚才的理想又近了一步。
我现在想用服务，系统也给我提供了，服务的在哪儿我不用管，服务的容量我只要提就行了，要求只要提就可以了。它就会告诉我访问的地址和用户名和密码。而我的应用，我只需要写程序就可以了，我部署的时候只需要提要求，我需要什么CPU，什么内存就可以了。到底这个机器的IP，部在哪儿，我都不需要case。是不是我们应用程序离这个项目又近了一步，我们***只关注业务逻辑本身这件事情更理想化一点了。
实现刚才这个过程，我们PaaS里面完成了两大件事情，一个就是整个应用生命周期的管理，第二个就是与服务有关的管理。我们希望离理想模式再近一步，我们过去可能写了很多的应用程序，可能我写很多的组件。如果我只写一个简单的应用程序，就是web的，中间一个redis，下面就是一个mySQL，一个很简单的应用大概是这样的模式构成的。
所以我们PaaS还会提供另外一种能力，就是我现在已经开发的应用组件，我有一种编排的能力，我把这种已有的组件可以通过一种描述，把它编排起来。这个编排里面写哪些信息呢?一个信息是我一个大的应用，编排一个大的应用，里面有多少个小的应用组成，这些应用之间的关系是什么，它们启停的优先顺序是什么。如果这个东西都可以用一种描述语言描述出来之后，我们把这个描述语言打成包，是不是我以后部署直接把这个描述语言部下去就可以了。系统可以根据我的描述语言对它提供的要求，执行我们描述性的一些语句，***能够负责把整个应用启起来的目的。如果这个东西有的话，以后如果这个应用架构发生变化之后，我是不是简单的改改描述语言就可以了。朝这个方向走的话，我们通常说PaaS还会提供一个能力，就是整个上面跨应用的编排能力。这个编排能力有的话，就使我们应用的部署和将来的变化，变得非常的容易。这个编排能力有的时候，就是一种描述语言，描述语言的好处是说，我写完之后可以管理版本，每一次变化直接调调那个描述的东西就可以了。
对于这个描述语言再增强的需求是什么呢，有没有一个可视化的方法，把这个描述语言给展示出来。我们很清楚的看到，过去从脑子里看到我有一个应用，前面有一个web的应用，中间一个redis或者什么，我都在嘴上说。是不是我可以画出来，上面一个这个，这里一个，中间连一根线，这根线就描述了它的依赖关系。这根线的关系可能是代表了我依赖于一个redis的服务，这个服务我再讲细一点，服务也算很多类型。这个服务可能因为你这个应用程序存在而部的一个服务，也可能是应用公共的一个服务。
所以框到这儿之后，我们再回过头看看我们的理想能实现到什么程度了。我们有这样一个平台，***是我们所有的应用，我先不讲前半生，前半生里可能含的是我先写代码，我写一个代码。假设我一个应用有很多微服务组成，我先定义了微服务的IDL，上个话题。我写了IDL，就把一个应用拆成很多很多的部件组成。把IDL编译成一个组件，每一个组件装代码，我在每个组件里面写我自己的应用程序，业务逻辑。写完业务逻辑，提交到源代码的仓库上去。这个应用后面编译和部署的流程，通过上个讲期我们说的DevOps拖拉拽的环节，我给它制订了一些标标准的拖拉拽的过程。***一个节点如果所有的编译都OK，那么就是上镜像，然后去部署。部署的时候，因为我们提前会设计好一个应用有多少组件组成的，这些组件之间的关系我就用一个图形化的工具，假定我这些应用的镜像都已经OK了，我就提前把这个自动化的工具，把应用各个的关系和部署的组件的关系画成一个部署的图，画完之后存在系统里面作为一个模板放在那儿就可以了。
之后我就开始去开发，开发之后我只要一提交我的源代码，是不是它的整个DevOps流程就开始往下走。走到***一步，是不是生成了各种各样的镜像。生成镜像之后，又会触发部署的过程，这个部署的过程就是我们刚刚说的用图形化工具编排的那个应用的整个部署的关系描述。然后靠那个关系描述，因为那个关系描述里面并不规定我一定要部署在哪些机器上，我只需要资源需求就可以了。我下面只要有了足够的资源，有系统帮我们去把每一个节点都挑一个很合适的资源，分配给它。分配给它之后，同时把它部下去。部下去之后，就完成了我们整个应用的代码编写，到***整个上线的过程。
刚才我们也提到了因为我们在设计那个图的时候，会除了做部署上的策略以外，还会有一些其他策略。举个例子，像弹性伸缩策略，灰度发布策略，这些策略都可以在那个图里面描述出来。这些策略最终会结合什么呢，因为PaaS底层有一定的兼并性。基本上这样离我们期望的目标就比较接近了，最终我们监控的部分配合到弹性伸缩的策略，和我们灰度发布的策略，使我们的整个应用，在将来运营的过程之中，举个例子，比如负荷很高的时候，可以增加一些节点，负荷很低的时候，在我的空档的周期之后会把节点降下来。大概这样整个的过程就OK了。
刚才我是站在研发角度去看PaaS给我们开发的过程带来的好处，我再稍微总结一下，我们期望做到的是什么呢。***我们DevOps能够把我整个应用的生命周期前半生和后半生都管起来。第二我后半生管的时候，我只提一些要求，由平台主动的帮我们进行各种各样的调度。第三我们运维过程里面的这些东西，都是根据我们的调度策略和算法自动的帮我们完成，而不是我们手工要做的。能够把这些东西都实现，我们的service可以提供让我们能够把现有应用的能力整合起来，能够把这些点都实现了之后，我们就希望关注于写业务逻辑，使我们整个应用的管理变得更加的简单。这就是我们期望在做PaaS设计的过程里面，要做的这一点。所以我们所有的组件都是围绕这些点去做的。刚才也提到一些问题，我们去做调度的时候会有哪些问题，我的部分基本到这里就结束了。
(结束)
