微信号:archtime

介绍:在这里煮酒聊架构.

我对PaaS云的思考以及关键技术点的论述

2016-06-22 20:20 李东

这一章是本文最后一个话题,我们从2012年开始研发PaaS,当时对PaaS的定义是应用的开发、运行、运维监控一体化的自动化平台。在采用Docker技术之前,我们的策略是通过适配来部署和连接各种不同的应用。后来随着Docker技术的迅速兴起,业界对PaaS的定位似乎也有了改变,PaaS更偏向于应用的运行和运维管理平台。由于篇幅所限,很多问题不能详细展开,所以本章只侧重核心部分。

运维型PaaS

运维型PaaS的特点是,通过Docker技术实现存量应用的封装和部署,不改变应用对外的通讯方式,不改变应用之间的架构。运行时,通过很薄的一层代理层解耦应用之间的直接通讯耦合,并在代理层实现应用的负载均衡。除数据库外,任何不依赖于本地存储的应用都可以进行自动化的扩展,当应用的CPU、内存或IO等超出给定的额度上限时,PaaS控制器自动的运行新的Docker,并将其挂接到相应的负载均衡器上;当给定的指标低于下限时,从负载均衡器上隔离应用,然后关闭相应的Docker。

运维型PaaS的优缺点是:

  1. 几乎可以适应一切传统的应用,包括已经SOA化的应用,除了那些使用客户端负载均衡方案的应用(例如某些微服务架构的实现)。

  2. 可以降低存量系统迁移、复制以及部署的难度。但是无法改善组织的应用架构,也无法通过架构改造改善组织的开发流程以及业务敏捷度。

  3. 可以实现一定的自动伸缩能力,部分的降低运维过程中面对业务突发冲击带来的人工成本。但由于没有一种科学的方法能够实现负载精确调整,所以面对真正的大型负载冲击,还是要人来干预。

  4. 无法实现传统数据库的伸缩,由于负载均衡层不对报文进行解释,所以也无法实现传统应用的分库。

本文重点不是运维型PaaS,所以在此不做过多的论述。下面我们来谈谈支撑型PaaS。

软件到底是什么?

从有社会以来,我们主流的商业模式只有一种,那就是产品,这是任何一种基于交换的价值基础。我们所做的一切商业行为包括市场、生产、销售、服务、管理等等,都是围绕着这个基础在运转。所有的产品,最终必须在终端用户(也就是个体)的消费行为中体现价值,所以抽象的来看商业=人+产品,这个加号代表消费。而产品=人+商业,这个加号代表一切和产品相关的行为,这里的商业代表为提供产品所需的商业。

这是一个递归的定义,这个过程意味着每个人都在为其他人提供产品,直到最终的消费者终止(如果没法到达最终消费者,那么实际整个过程并没有产生商业价值)。整个递归过程中的产品只有两种:工具和材料,算上最终被消费的产品,抽象的看产品只有三种形态:消费品、工具和材料。就此,我们也就知道了软件是什么,不外乎这三种形态而已。

传统的工业化消费品,受益于科学技术的进步和社会化大分工,已经将整个商业递归链条运转到令人叹为观止的地步。为了充分利用这两个公式获得价值最大化,也就是增加消费,降低成本。那么第一个公式演变为商业=人+产品+…+产品,也就是让人消费更多的产品;如果通过减少第二个公式中的商品来降低成本的话,就会违背第一个公式从而导致整个递归链条的断裂,所以第二个公式演化为产品=人+商业-人-…-人,也就是利用工具尽可能的替代人(即更高的自动化水平),当然这里随着工具的进化所需要的人也必须具备更高的科学知识。

与传统工业对比,依赖软件作为工具和材料的商业链条离充分递归还相距甚远。曾经,传统的软件工业试图复制传统工业的经验,建立规范标准的软件工厂,但是最终软件工厂还是通过增加“蓝领工人”规模的方式来因对快速变化的需求,我认为这种方式基本上算是失败了。在我看来,未来任何一种严重依赖于软件的商业,如果不能朝着第二公式的方向演化,那么最终还是会失败的。

支撑型PaaS的核心定位

商业链一定是先从最靠近终端用户的企业开始的,任何工具和原材料的需求都开始于此,支撑型PaaS提供了一个高度自动化的软件工具,这个高度自动化的工具可以帮助终端企业降低对大量人力的依赖。那么IT企业能够为终端用户提供什么产品呢?与传统工业相比,IT工业提供的是虚拟化的商品,这些虚拟化的商品以数字、文字、图片、视频等形式被终端消费,并与此同时可能还会有对应的实体商品被消费。可以预见,IT消费的便捷性最终会使得所有的终端消费模式都会与之趋同,这是工业互联网化的趋势。

如果我们依然把IT企业业务过程抽象成通过工具对原材料进行加工的工业过程的化,那么IT企业的原材料就是业务系统提供的业务服务,而加工工具就是各种不同的流程工具。支撑型PaaS平台,就是提供工业生产车间,在车间中可以依照需求选用不同的工具和原材料,自动化的生产所需的虚拟商品,同时自动的完成终端消费者消费虚拟产品的流程。这就如同一个面向个人的手机生产厂,终端消费者直接向工厂下订单,选择手机的功能和式样,并且立等可取。

所以,支撑型PaaS的核心是要解决如下问题:

  1. 建立工业标准化系统,为工具和材料提供标准(可以内置通用的工具和材料)。

  2. 建立自动化的可伸缩生产体系,利用有限得而工具和材料,最大限度的满足客户的动态需求。

  3. 为业务人员甚至终端用户提供定制虚拟产品的流程工具。

同时要能解决,系统的治理、管理、监控和自产的标准件(服务)开发流程管理等要求。

关键自动化技术

PaaS最核心的需求是解决应用运行时刻动态伸缩问题,最初是以虚拟机为伸缩的原子单位,但虚拟机过于庞大资源的消耗过多,所以PaaS的发展过程中出现过以应用容器(比如Web容器)为最小单位的(我们最初就是这么做的),随着Docker技术的迅速兴起,目前更经济的原子单位是Docker。

那么什么样的应用是PaaS最擅长管理的呢?是不是所有应用都可以利用PaaS进行动态伸缩呢?这我们要分析一下PaaS的伸缩策略,首先要建立一个简单的数学模型:

首先我们要确定动态伸缩的依据是什么,传统的依据是根据CPU、内存或IO来判断,但针对不同的应用并不一定适用。而且一个多变量的数学模型过于复杂,所以我们将多变量综合成单一变量,一个最简化的单一变量模型就是基于服务质量进行伸缩控制,也就是说基于服务的平均响应时间来判断服务是否需要扩容或收缩。

简单说,这个模型中输入就是服务的并发量,输出就是服务的响应时间,整个系统可以规约为一个信号处理系统。通过这样的规约,我们可以看到PaaS系统其实是一个工业自动化控制系统,这是我们第一次将应用软件用传统工业控制的理论进行自动化运维的一种尝试。

单一服务业务系统建模

建模的第一步是要确立PaaS系统的几个基本物理量之间的关系,也就是输入和输出之间的关系。实验可得,在系统资源充足的情况下,应用响应时间随并发量的变化是很小的,但是随着并发量的进一步增大,系统资源逐渐不足,响应时间会急剧上升,直到系统资源耗尽后并发与响应时间成线性增长关系。

设输入并发量为U(同时有U个请求报文),输出响应时间为T,则:



  1. 当并发量U<N时,系统处于闲置状态,响应时间可以约等于单并发请求的响应时间T0。

  2. 当并发量U>M时,系统处于过载状态,任何新的请求都处于阻塞状态。

所以,PaaS的应用工作区应选取在N<U<M之间,也就是说应该在T0~Tm之间选择最佳的工作点。实际上,由于响应时间受CPU、内存、IO以及数据库事务等诸多因素影响,所以在工作区的函数并非线性的,但是为方便起见我们可以将之近似的用线性函数拟合。

理想可控制的PaaS模型

我们假定用户可以容忍的响应时间为Tu,我们可以设Q=Tu/Tm。Q的物理含义其实就是业务系统的品质,我们称Q为品质因数,相对应的业务系统可以接受的并发上限为Q*M。我们讨论的这些参数,在PaaS系统运行过程中都是可以动态测量的,因此PaaS可以基于这些参数进行业务系统的控制。

定义理想单服务的目的是为了简化问题,便于分析。下面先解释一下要求的含义:

第三条要求应用内部无队列缓存,是为了扩展的时候能够把负载转移到新的实例中,如果负载全部缓存在老的实例内部,那么扩展就没意义了。

第四条对环境的“无知”,是指的应用不需要知道自己是运行在一个PaaS环境中还是自己独立的运行。这样的要求是因为应用不具备也不应该具备全局视野,否则应用换一个环境将无法工作。这要求应用对外提供一对同步或异步的通讯接口,除此之外不应该对外部环境有任何感知和要求。

第五条服务必须是本征的,因为如果服务对外有请求,那么其Q值就不能作为应用的真实能力体现,PaaS控制器无法依据Q值和并发进行有效的计算,从而无法完成扩展(当然还有其他原因,前几章节有论述,此处不再详细解释)。

第六条是为分析方便做的假设。

PaaS控制器的作用根据应用集群所能承受的并发与输入并发的差值,来调整集群的数量。假设集群中现有应用数量为n,那么其中差值:


考虑到应用伸缩的最小颗粒度是一个应用,所以我们用差值除以单一应用的并发上限Q*M,就可以得到需要增加的应用数量:

网络时域分析:零状态冲击响应

对于上述模型,我们来研究一下其随输入信号变化,输出信号在时域上的变化。典型的时域分析是给定一个输入脉冲,看输出如何随时间变化。我们假设当前集群中有n个实例:


上图为系统在静态(无伸缩)情况下的零状态冲击响应,其物理含义是系统对输入脉冲进行缓存(内部队列)。

然后在一定时间内以每经过一个Tu长得时间处理n*Q*M笔请求,直到缓冲的请求全部处理完成。响应曲线公式为:

在系统动态情况下,如下图:
假设PaaS控制器在检测到冲击u以后,动态加入新的实例(见式2.2)。由于新的实例需要一段时间的延时才能够发挥效用(应用需要启动),所以在延时R之后,并发的斜率发生变化:


由3.2可知,如果延迟R使得 Ur大于等于u,则PaaS控制器无需对冲击做出任何响应。

网络时域分析:阶跃响应

零状态阶跃响应


静态模式:
左图代表系统总的品质低于输入负载压力,右图代表品质高于负载压力。

动态模式:
非零状态阶跃响应


静态模式:
动态模式:

环路控制建模

对于随时间变化的Uin(t),PaaS控制系统会产生一个输出Uout(t)。由于业务系统受控反应有一定的延迟,假设增加实例的延迟为R,减少实例的延迟为r,则PaaS在此服务上的固有调整频率为


对于PaaS控制器而言,统计服务队列中的消息数量可得Uin(t),统计上下文中未返回的消息数量可得Uout(t)。

反馈控制

由于我们无法预测请求的变化,所以通常我们会先考虑系统的反馈控制。对于PaaS系统而言,输入的并发Uin,经由正向传递函数G(s)在业务系统中产生Uout的并发压力,再经由反馈控制系统动作并由反向传递函数H(s)将反馈量反馈给输入端,经由加法器运算产生新的输入,如此循环直至达到系统的稳态动平衡。(其中G(s)和H(s)是对应时域的传递函数,进行拉普拉斯变换后获得的频域函数)。


根据这个模型得出公式:


式4.2就称之为系统的闭环传递函数T(s)。下面我们来看一个简化的PaaS控制器的逻辑视图:
这个控制器的基本逻辑是当定时器脉冲上升沿来临时,比较输入和输出信号。如果输入信号大于输出信号,意味着PaaS系统不能及时的处理输入请求,于是增加集群实例数量;如果输入信号小于输出信号,意味着PaaS系统存在一定的余量,于是减少集群实例。等到定时器下一个周期来临再次重复上述动作。

PaaS控制器的核心在于比较器的算法、反馈网络以及伸缩算法设计,为防止系统发生频繁的调整,需要采用迟滞比较器;反馈网络和伸缩算法选取的好坏会直接影响系统的阻尼,我们希望系统尽可能少的震荡。
上图为红线为输出欠阻尼震荡,输出信号快速达到下一个稳态值并过冲,随后围绕稳态值震荡。黑线为欠阻尼,从前一个稳态值缓慢变化到下一个稳态值。过阻尼和欠阻尼都会导致控制器频繁的做出调整动作。

为达到系统较快的动态响应,需要合理的选择比较策略和控制策略。根据选择的策略计算得出正向传递函数和反向传递函数,进行拉氏变换后代入式4.2获得系统的传递函数,然后根据传递函数分析系统的极点和零点以及穿越频率等等。限于篇幅原因,在此不做过多的分析和计算了。此处给出原理,感兴趣的读者可以继续推导。

前馈控制

前馈控制是指可预测的输入波动,一般用于节假日的可预期事件,比如双十一等。但前馈控制需要人工设置,管理复杂容易出错,如果系统反馈控制灵敏度足够好,其实可以不采用。

本文不详细论述前馈控制。

关键技术—与技术无关的流程编排

如果想实现IT企业工业化的生产,那么对技术人员的严重依赖不解决是永远做不到的。即便是现代自动化的制造业,一线的工人虽然科学知识很丰富,但是想让他去制造一台生产设备那根本是不可能的,不要说制造就是复杂点儿的维修都不现实。

所以,支撑型PaaS平台的一个关键工具就是,不依赖于技术人员的流程编排工具。传统的业务提需求,技术来设计实现这样的生产模式,是无法工业化的。当然,这个理想历代的技术人员都在追求,很多人也无奈的放弃了。我认为,这个目标符合社会发展的规律,肯定是对的,我们不该放弃。S++的理论就是一种新的尝试,解决了业务与技术彻底分离,多态性解决了业务分支,那么完全不依赖技术的流程工具是可以实现的。

PaaS平台的架构

支撑型PaaS系统,是一个分布式多中心的微服务架构。微服务是无知和本征的,微服务之间不存在任何耦合调用。微服务的前端系统,通过各自不同的微服务中心与相关的微服务交互,形成一个区域中心自治,全局统一管理的分布式系统。

但是,我们前面分析的都是理想系统模型,那么真实系统还存在如下问题需要解决:

1、单服务应用

这个实际是基本做不到的,当然强行去做也不是不行,就是要浪费资源。实际上一个业务系统中实现多个服务,对于PaaS控制器来说只要其中任意一个服务质量下降超过阀值就可以扩展;任意一个服务的服务质量上升超过阀值就可以收缩。

当然,如果随着未来的容器技术的发展,一个服务一个应用可能会成为现实,那企业在IT领域全面工业化将成为可能。

2、存量业务系统如何云化?

存量的传统业务系统上云面临几个问题。第一个问题是由于体量太大导致启动时间过慢,固有调整频率为f0太低,导致系统控制反应过慢,往往冲击信号已经过去,还没有反应过来。第二个问题是,系统对外耦合度高,无法做到“无知”,直接上云平台是无法运行的。所以,存量系统首先要SOA化来去耦合才能勉强上云。

SOA化的传统应用上云后,就可以着手进行S++化,可以先在应用内部建立本征服务进行服务治理,之后再将业务流程剥离出来形成组合服务,最后再一个个的将本征服务分离出来形成微应用。

3、传统微服务架构如何云化?

传统微服务架构中,由于服务之间相互依赖,所以也不能做到“无知”。所以第一步也要先S++化,通过微服务的本征化进行服务治理,再通过组合服务完成去耦合的业务流程。传统的去中心化的注册服务注册机制,在PaaS云中无法使用了,所以应能设置开关屏蔽注册代码。

关于微服务有个探讨,认为微服务架构本身是要自治,个体要足够的智能,显然一个“无知”的微服务是不符合微服务架构初衷的。我认为,智能是有代价的,系统越大智能的代价占比越低,一台电脑中可以有一个CPU成为“智能”的设备,但是组成电脑的其他元件(比如电容器)都是智能的,成本就太高了。同样的道理,微服务太小了,让每个微服务智能化,不如让一群微服务有一个智能中心。所以,微服务越小就应该越“无知”。

4、RDBMS如何云化?

前面我们曾假设RDBMS的Q值无限大,实际是不可能的。所以RDMS上云可以有3种形式。第一种,直接上云不做伸缩控制。针对于业务压力较小的服务,单一的数据库可以满足要求,就可以认为Q值足够大。第二种,将数据库按某个甚至某几个业务要素分区。这种需要PaaS控制器能够按内容进行负载均衡,但依然无法做到数据库动态扩展。第三种,期待未来有一种能够在云中扩展的RDBMS。

5、前端应用如何云化?

对于传统的存量前端,由于大部分很难改造,所以无需通过PaaS控制器实现动态扩展,只需要根据传统的CPU、内存及网络IO的负载情况进行扩展即可,但其云化的先决条件也是SOA化。

微服务的前端,需要将输入输出全面异步化,才可以很好的用PaaS控制器进行动态伸缩。

小结

在一章中去完成对PaaS的思考,对我来说还是要些取舍的。本文的基本思想,IT企业依然需要靠社会化大分工来实现自己的业务。工业化是个老旧的东西,但是社会的任何进步都是建立在已经被证明是科学方法的传统之上的,彻底的革命是没有先例的,也是不科学的。我认为,未来工业必然会互联网化(或IT化),但是难道IT企业就不要继承优秀的传统方法吗?我认为,IT企业工业化是必须要补的课,工业化大生产高效、稳定、低成本以及自动化,都是IT企业不具备的,我们到现在还是靠人堆的生产方式。

作者介绍

李东,14岁开始学习计算机语言,作为课外兴趣自学了BASIC和汇编,利用放假期间编写了贪吃蛇、打飞碟等游戏。高中、大学期间继续自学软件编程,曾将C和汇编结合使得从高级语言中能够调用绘图功能,并模仿Borland C++开发了一套适合学校机器的图形化开发环境的原型。

93年大学毕业后在西门子合资公司作为交换机软件安装人员工作两年,然后来到JInfonet公司先后参与4GL的研发和JReport的研发。作为JReport的第一代主要研发人员,编写了从原型一直到3.0版本的核心引擎部分。2000年与合伙人一起创建了Bi-Soft公司,主营业务是商业智能软件Bi-Pilot,负责整个产品的研发及管理工作,从最基本的查询一直到多维分析模型和引擎都是产品的涵盖范围。

2007年Bi-Pilot被神州信息收购合并,李东开始在神州信息研发SmartESB产品,用SOA的方法论为客户提供底层产品服务。

马化腾怎么看云计算?

2016年7月5日,诚邀您参与腾讯·“云+未来”生态峰会,与腾讯董事会主席马化腾先生及各界顶级企业家,国际专家共探产业与互联网融合发展之道,推动互联网+生态圈发展。详情请点击阅读原文链接。

 
聊聊架构 更多文章 反思 | 你是个软件架构师吗? 首发 | 实时股票分析系统的架构与算法 研究Airbnb架构,我学到了什么? 五年Skype架构师之路的感言 思考 | 为什么企业架构如此重要?
猜您喜欢 软件测试:通用测试用例写作 深度 | 微软人工智能首席科学家邓力:深度强化学习如何助力聊天机器人 [技术] 谈谈编程思想 【第2章第179回】JSON 读书笔记 Python鲜为人知的16个“魔法”