【SDCC 2016】华为PaaS首席系统工程师俞岳：新一代华为PaaS平台助力企业IT全云化转型...

【CSDN现场报道】2016年11月18日-20日，由CSDN重磅打造的年终技术盛会 —— “2016中国软件开发者大会”（Software Developer Conference China 2016，简称SDCC 2016）在北京京都信苑饭店隆重举行。本届大会云集了100多位国内外顶尖专家和技术大牛，共设新趋势和新实践2大主题会场，14个技术专题。面向国内外的中高端技术人员，聚焦最前沿技术及一线的实践经验，助力企业的技术升级和改造、全面提升技术人员的综合实力。

在11月18日上午的Keynote上，华为PaaS首席系统工程师俞岳带来了“新一代华为PaaS平台助力企业IT全云化转型”主题演讲，通过回顾云化挑战、技术发展趋势，以及华为PaaS平台的架构设计，全面分享了华为公司在云计算领域的思考和实践。企业转型素来说易行难，阻碍这一进程的三大山分别是组织流程、应用架构，和系统平台建设。他指出了“部门墙”烟囱式设计以及单体应用架构带来的升级时间窗等问题。同时分析了企业应用架构由单体应用到松耦合的SOA再到Micro Service一步步细粒度拆分的云化进程。此外，PaaS平台现在在企业内部显示出碎片化的形式，而未来的PaaS平台一定是一个统一架构的开发平台。最近的容器技术在PaaS平台的演进历程中扮演着重要的角色，Docker的出现给PaaS平台带来了新的技术和发展，“Docker是进程，PaaS是机器”。（PPT下载）

华为PaaS首席系统工程师 俞岳

以下为演讲整理：

各位来宾大家上午好，欢迎大家来参加中国软件开发者大会，我是俞岳，来自华为，现在担任PaaS平台的首席系统工程师。非常高兴能在这里跟大家一起探讨一下我们华为公司在云计算领域的一些相应思考和实践。

我将从三个角度来阐述我们的PaaS平台：首先同大家回顾一下我们华为公司在和企业探讨云化转型中遇到的问题和挑战，以及PaaS最近的一些技术发展趋势。最后分析华为PaaS平台系统架构的构建，以及如何解决这个问题。

企业转型三大挑战

烟囱式应用系统

常言道“江山易改，本性难移”，企业转型说来很容易，但在企业真正转型的过程中，遇到了很多困难的问题和挑战。我们通过和客户的调查，总结出来大概有3个非常大的挑战。第一个挑战是，现在企业内部在做系统架构时，应用架构设计采用烟囱式构造，不同的业务部门根据自己的需求采购，从底层的云平台到操作系统，到中间到上层的应用系统都是独立完成的，各分散的业务部门之间缺乏一定的共享，而且他们在构建应用系统的过程中，往往都按照资源最大利用率的情况来生产。比如说我们为了应对双十一，会按照资源利用率最高的工作负荷预留一个资源，这就会造成系统大多情况下都是闲置的。据统计，在一般的企业数据中心里，资源利用率只有10-20%，而一些大的互联网企业，比如谷歌、脸书，他们的资源利用率达到30-50%，这意味着巨大的资源浪费。

此外，企业在构建应用系统时，技术架构、中间件有各业务部门（合作ISV）独立选型、采购，OS、中间件选择并没有完全统一，类型众多，我们称之为“七国八制”，而且革命应用系统根据他们业务的需求，采购的操作系统数据库也不相同，因此在企业的数据中心里，这种业务系统会非常繁杂，很难统一管理——这个第一个挑战造成了企业内部资源服务难以共享。

单体应用架构

随着业务部门的开发产品不断叠代，中间的代码变得越来越臃肿，传统的架构模式都是CS或者BS的结构，会把大多数的应用逻辑放到应用程序中间，就造成了应用程序的逻辑不断膨胀，使整个应用系统变成一个非常庞大的单体式应用。在我们内部的IT系统建设，最早也是基于这种模式。日积月累后发现，这种单体应用架构完全缺乏敏捷和弹性，部署扩容慢，产品升级尤其困难，往往需要通过业务中断的方式进行。

开发与运维割裂

企业端到端的开发流程由来已久，由产品需求方——开发——测试——运维的流程尤为漫长，而且各个职能部门承担不同的工作，部门之间存在“部门墙”。有一句话，如果大家熟悉康危定律，就是“组织架构决定了产品架构”，由于组织的构建方式，造成产品整个开发流程非常长，而且每个环节都会有自己相应的环境，自己的系统。整个的开发流程中，开发环境的不一致，以及部门墙中间的隔阂，造成了整个企业IT的应用就无法做到非常敏捷。

发展趋势

应用向CloudNative演进

现在先进的互联网公司他们都是怎么做的？首先看一下应用架构的转型，现在都讲究向CloudNative转型，CloudNative是一整套的理论方法工具的实践的结合，它强调的是应用的敏捷、应用的良好架构以及完善的治理方式，如果向这个方面转型，其中微服务一定是它的方向。回顾企业应用架构几个不同的阶段，最早我们叫做“单体应用”，就是传统企业IT基于CS、BS的构建，集中在应用服务器这一端，变得非常臃肿，都采用纵向的伸缩方式，横向非常难，只能通过传统的维度叠加，不能做更细粒度的拆分。

后来通过解耦发展为松耦合SOA，对应用颗粒度做了一些拆分，把原来的单体应用拆散，按照不同的独立的功能，把它拆成不同的服务，每个服务对外有一个清晰的接口，通过一个企业的应用总线把这些服务串在一起，完成高级的服务逻辑。这是服务化架构的一个构建方式，好的地方在于让你做服务化结偶，职能单一，但是在系统和系统之间偶合的时候，强调引入这个ESB的方式，我们发现在很多企业的实践过程中，ESB成了一个新的瓶颈，而且它是偏集中的一个架构方式，整个的总线的好坏就变成了企业应用好坏的一个最关键的问题。它的敏捷性做了提高，应用的颗粒度做了一些拆分，但是还是不能满足云化的敏捷的要求。

之后随着云化理念引入，在SOA的基础上最先提出来的就是微服务架构，它的理念也是进行服务化解，但在实践过程中更加强调的是点对点，完全分布，更强调的是服务之间的治理、容错，需要在不可靠的服务基础上，构建一个可靠的业务系统，这也是微服务的核心理念。方式是通过微服务之间的治理、容错、隔离这些相应的技术来实现这种能力，使应用从业务的角度看变得非常稳定。还强调了扩展高可用等，每个服务都是由一个小团队来开发，服务和服务之间通过松耦合的点对点方式组合在一起，变成小的网状式结构。

PaaS平台演进

PaaS平台的历史至少有十几年了，现在PaaS平台在企业内部呈现出一个碎片化的形式。在企业内部会发现，每个云化的平台上都或多或少有一些工具搭建的Erlang平台。这种碎片化的PaaS会在企业内部造成一个混乱，会造成开发流程的断裂，应用无法从一个PaaS平台到另外一个PaaS平台。最新一代的相应的技术，能够帮助我们有效规避这些问题。我们认为未来的PaaS平台一定是一个统一架构的PaaS平台，最重要的使命是能够让企业真正聚焦于自己应用的开发，开发出真正敏捷、具有弹性的高可靠应用。这个PaaS平台上的那些基础服务，一定标准化的。还也一些服务是专业化领域服务，由在某一个行业、领域有非常多经验积累的厂商来提供专业化的领域服务。由这个核心PaaS平台，加上外面堆加的统一PaaS平台，才能真正解决企业的问题。

容器技术给PaaS带来新的机会

看一下容器技术，为什么说PaaS平台发展这么多年，真正的容器技术发展出来了以后，才有一个真正的进展。其实最早也说了，现在看PaaS是机器，就说明PaaS平台随着容器技术的引入，才能给企业的数据中枢带来一个真正统一的架构，它可以作为这个企业的数据操作系统。我们面对这个平台都是从上往下看的，以应用的视角看，才能满足应用敏捷性的需要。

容器技术是操作系统子代技术，基与Linux构建而成，它只是这个技术的一个实现，并不是代表所有的容器技术，因为无论是谷歌还是其他的厂商，他们都有自己相应的容器技术。Docker，这样的才能真正做到一次构建，多次运行，只要你有一个镜像，找到可以支持Docker的平台你就可以开跑。

容器打包，更希望容器系统是开放的，并不是只有Docker一家来垄断。最近基金会也出现了这个标准，就是为了更加开放，让不同的容器技术能够在同一个标准下互相进行良性竞争。Docker技术和原来的虚拟化技术相比，有很大的优势，它可以让应用直接访问内核和硬件。由此带来的无论是扩容还是安装速度，都比以前的裸机有一个数量级的飞跃，非常敏捷、高效。

华为FusionStage架构

说了很多企业的问题和一些新的趋势，如果要做一个新的PaaS平台，应该怎么做？这是我们新的PaaS所考虑的问题，我们基于以上的思考，认为这个PaaS平台应该采用分层的架构，分成两层，底下叫做PaaS内核，就相当于数据中心的操作系统，面向应用的敏捷系统，内核里面有很多标准服务，和业务没有关系，比如缓存、数据类的数据库、大数据、消息类的管理等都可以使用这个中间服务。再下一层是PaaS平台核心框架，要满足企业应用的开发、部署、治理的共同要求。对开发态，我们希望有一个开发流水线的框架，能够把整个流程打通。运行态需要一个强大的“心脏”，我们叫做调度和资源的引擎。还有微服务的治理框架，微服务开发稍微复杂一点，但是最难的是治理，因为微服务把应用拆散成很多小的部分，互相之间的借用非常复杂。

除了PaaS底层的内核以外，上面这层希望与我们的合作伙伴来构建，叫做领域的服务，希望由每个行业比较资深的，或是行业里面耕耘多年的，对行业的业务非常了解的人来帮我们构建，通过这种分层，我们就可以清晰地定位出平台来做什么，业务做什么，通过这两方面的结合，希望给企业一个统一架构的完整平台，能够满足应用敏捷开发、运行、运维的需要。

开发流水线框架是用以解决端到端的流程打通问题。我们认为在企业内部，开发流水线可以分成两个层次，上层叫做流程编排，下层则是流水线的编排。流水线编排是什么意思？我们觉得当企业内部去完成一个特定能力的业务功能时，可能需要一个流水线。举一个例子，我持续构建，代码开发完之后就打成一个包，我们称之为“持续构建的流水线”，测试部门有一个持续测试流水线，就是拿到开发提供的包之后，立刻部署，去跑持续测试。还有持续部署的，就是拿到这个包后不断地部署。这些小的流水线的框架组合在一起，可以完成一个大的业务功能，我们叫它“DevOps”的流程。流水线引擎的核心就是基于容器的相关技术构建起来的。这个流程引擎还需要让它具备一些灵活性，可以对接企业已有的工具，包括构建工具，或者其它部署。重要的是，除了能够对接已有组建，还有一个比较强大的能力——一个自定义组建，包装成一个容器来跑，然后把它插到流水线里组成一个完整的流程。

最后介绍一下微服务的框架，刚才徐昊也说了，微服务是未来的必经之路，我们认为一个好的微服务框架首先要对不同的开发语言、框架做一些适配，都要有一些开发方向来支撑，让你的编程变得更简单，只要有一些定义的模式就可以了。中间有一个多性能的通讯总线，保证了微服务之间可以互通。最下面核心的就是微服务的运行和治理能力。首先是有一个微服务的目录，启动的时候都会注册，这个服务目录就会放到注册中心。还有一个配置中心，每个微服务互相之间的调用，或者互相之间的通用都需要配置中心的统一管理。配置中心要管设备的一致性，在互联网企业，考虑得更多的是用最终一致性来解决，实际上在企业内部，还有很多需要强一致性的场景，比如说要保证跨数据库或者是跨服务的交易要全部成功或者是全部失败。还有一点就是容错。微服务拆散了之后，在云的环境中会被视作不可靠的，每时每刻都会有东西挂掉。这个就需要微服务有一个强大的容错能力，或者快速失败，这个都属于容错的范畴。此外，要做隔离舱，要做熔断，都是在这里统一管理。

最后，微服务里还需要一个链条，因为微服务运行起来之后，端到端很难保证，把微服务拆散后，就是把实验加长了，端到端的实验和故障难以定位，此处需要一个微服务的分析，把整个业务连在一起，出了问题之后，可以定位到不同的微服务的点上。

【总结】

三个框架定位解决企业内部不同的问题，一个是开发流程一体化的问题，还有应用架构的问题，以及平台构建的问题。

更多精彩内容，请关注图文直播专题：SDCC 2016中国软件开发者大会，微博：@CSDN，订阅CSDN官方微信公众号（ID：CSDNnews），即时获取大会动态。