技术平台分层体系-PaaS层浅析

IaaS层的定位资源层提供按需所取的弹性资源服务，当然资源前面重点只介绍了计算资源，实际上按照计算机的构成和协同工作的原理，IaaS层的资源分为“计算”、“存储”、“网络”这三大领域。每个领域的虚拟化都在有条不紊的构建体系，向上层提供资源服务，最终在类似openstack这样的虚拟化资源管理平台统一纳管提供资源服务能力。

如果IaaS层定位资源领域通过虚拟化技术统一抽象了不同的底层资源的话，那么PaaS层就可以理解为架设了应用开发者、使用者等最终用户的应用程序和资源以及技术平台之间的桥梁。

PaaS层基于IaaS资源层，通过抽象应用在服务器集群之上的分布式runtime，管理应用程序的生命周期，为应用程序构建了一套统一的自动化协调的分布式运行环境，以服务化的方式支撑上层的应用的快速创新。

这里我们从一名开发者的角度来看看应用和资源之间的关系变化，以此来理解PaaS。

第一阶段：手工+脚本管理时期（开发者需要关注服务器和应用）

想象下在06年我们开发者大概是怎么处理应用程序和资源之间的关系的。

假设我们需要在几台服务器上面部署开发的应用程序，可能是对外提供服务的web程序，或者纯粹在后端批量计算处理数据的任务程序等。

首先，我们肯定会将开发完成，具备上线条件的应用程序进行构建打包；
程序构建打包，不管java类的程序还是类似c++等程序，都可以在服务器环境下统一的编译构建，当然也可以在本地环境下构建，不过c++/c这类程序因为跟环境强相关，一般都会在相同的环境服务器上构建程序包。
构建完的程序包一般会存放在某台专门用于部署发布的服务器上，通过脚本维护统一管理。
根据需要选择生产环境服务器节点，指定发布相应的版本程序包，并且通过远程脚本执行命令启动相应的应用程序运行。

这阶段不管哪些类型的应用，都采用类似的管理方式来处理应用程序和资源之间的关系，基于半手工的模式来构建和运行应用程序。

第二阶段：分布式框架平台化管理时期（资源层在开发者种逐渐下沉）

1.数据计算领域

首先突破的是数据计算处理域，为什么呢？大概有两个原因可能：

因为随着数据计算处理量越来越大，面对服务器集群的资源，被分而治之的任务应用越来越多。尤其在实时系统还没有大规模的被普及应用的时期，批量的离线计算一般是相对保守、稳妥的解决问题的手段。
离线计算多为周期型应用，具有应用频繁的被启停运行等特性，同时因为涉及的服务器数量巨大，进而在问题领域出现了分布式协调的算法，用来协调多台服务器协调工作。比如后来被大规模应用的zookeeper这样的分布式协调服务的组件技术的出现，促进了分布式集群化管理应用的进步。（当然交易处理领域分布式服务化也因为类似zookeeper技术的出现，得到大规模的落地。）

举个简单的场景：

假设某一个省份的运营商系统，每天需要周期的常规处理某批数据，那么由于数据的量巨大，一个个问题域就需要被抽象成多个切片去并发处理，充分的利用服务器多核，多集群的计算能力。

这种场景下，应用的部署和发布的形态出现演变，逐步的由原先的推的模式，改为集中化拉取的调度模式。这种调度模式的演变也成为现在容器化、镜像化的核心实现方式。这里以13年主导设计的某个任务调度平台的设计思路来阐述下这个过程。

13年在为crm的后台批量应用程序迁移x86服务器集群构建一套分布式集群管理平台，该平台主要解决x86化服务器，因数量指数级增加，人工维护的部署发布、运行环境的成本问题，另外也为了更好的提升集群的资源共享和利用率。

分布式任务集群管理平台中，重点关注各类并发计算的任务如何在众多的服务器集群环境下构建一套统一的runtime环境。
通过定义统一的任务应用模板，配置化支持任务应用的定义配置管理，同时也支持可视化的方式来管理任务的部署、发布。
后端通过调度器+执行器的主从模式，通过分布式协调服务zookeeper来确保任务在分布式的环境下的状态一致性管控。
其中任务应用程序可以采用远程ftp发布或者本地文件系统、分布式共享文件系统方式来发布加载。

在该平台上，一个任务应用的具体生命周期如下：

使用者通过平台定义任务应用模板，配置具体带业务属性的任务模板，生成任务配置数据入库；
任务调度器根据任务模板配置数据的扫描确定任务具体的调度方式，包括任务周期性调度属性的计算；
调度器会根据到期的任务属性，发起具体任务的计算调度，将其生成任务流水设置在zookeeper定义的节点中。
预先部署在各个服务器节点的执行器节点启动后会通过zookeeper完成计算节点注册，同时watch任务节点获取任务调度的请求；
一旦调度器触发的任务实例根据调度算法，分发任务信息进入zookeeper节点，相应的执行器节点就会获取到该任务信息；
执行器加载该任务对用的程序包，完成指定的任务业务逻辑的计算，大多数分为加载分片数据，多线程派生并发计算处理的模型；
执行器启动后会保持与调度器之间的心态，周期的任务一旦处理完成，执行器会释放加载的业务计算任务，等待新的计算任务到达。

2.web服务领域

随着交易领域的越来越普及，交易量不断的增长，交易领域计算框面向资源层也演变出相应的分布式计算管理平台。

强力依赖网络能力提供服务的web类应用，随着服务器集群化以及业务量负载的增长也迫切的需要构建一套能够动态的管理这些常驻应用的平台，帮助提升web类应用的并发、弹性计算能力。

回望下这之前web类应用部署使用情况，手工维护主机列表，通过有限的脚本部署发布相应的服务，通过手工维护负载均衡器的后端应用地址来实现服务的对外上架服务。这种人肉的模式存在缺点也很明显：

应用越来越多，服务器集群规模越来越大，脚本和人工维护的成本越来越高；
面对高度不确定性的处理量的web应用，不能够快速灵活的提供弹性的机制来上下架服务以及扩缩容等操作，基本上是人工经验调整。

具备分布式管理能力的微服务架构通过一套订阅/注册机制，灵活的将服务端的能力通过注册中心统一自动发布，服务使用者通过注册中心订阅相应的服务处理能力。

这其中也得益于数据计算领域的技术进步，zookeeper这样封装了分布式协调算法的技术组件的普及应用，为构建这套体系提供很好的技术基础。（这里就不详细阐述微服务框架，后续可以单独展开来说）

这个阶段，在开源的领域主要都是各个问题域的计算框架以及各个公司私有框架在分布式化的过程中沉淀了各式各样的平台能力，比如大数据领域hadoop，包括后来的spark、storm、flink等，服务领域的dubbo等框架，这些应用框架都自带了对分布式应用在资源层之上的统一管理和调度的工具。

第三阶段：PaaS平台化阶段（开发者无需关注资源层）

随着服务器集群化，各个应用框架在各自的问题域里面构建各自的分布式框架，并且逐步向平台化管理方式演变，但是企业面临的实际情况是，包含了不同问题域的业务，那么就需要各自管理好各自领域的分布式应用平台，站在企业角度考虑这样缺乏统一体系化的管理考虑，直到PaaS标准概念的出现。

PaaS是站在企业角度，构建一套以应用、技术平台为中心的一站式平台体系，让不同的应用、技术平台都能够在这样的体系下面以相同抽象的方式统一对外提供服务。

PaaS平台化时期主要考虑解决两类核心问题：

1.应用在IaaS层之上需要构建怎样的分布式统一标准的runtime，支撑应用统一的运行环境，类似基于异构的硬件服务器+linux操作系统之上构建分布式时期的操作系统；

2.应用集成中需要使用到数据库、各种各样的中间件、开发框架等技术，如何面向使用者提供统一一站式管控的技术平台化能力的体系，也是核心之一。（平台即服务重点体现的就是技术平台的服务化能力抽象）

下面通过一个简单概要的架构图来体现下PaaS平台的核心思路，在实际落地过程中有商用、有开源、有自研的模式，但是对于一家企业来讲选择和构建PaaS的体系是相对统一的。

可见PaaS层是构建在IaaS层之上的，核心通过应用管控引擎和服务化的标准管理来统一管理平台上的应用和技术平台。

这里应用和技术平台本质上都是应用程序，只不过技术平台是具有技术特性的，普通的应用是具有业务特性抽象的。

围绕着应用的生命周期，构建了一整套应用从代码的开发管控、构建、测试和部署发布、应用运行调度、运维一体的平台。在这套平台里面几个特点：

通过一个统一的门户对外提供平台的服务化能力，考虑开发者、应用使用者、运维者等不同的角色，围绕不同类的用户构建统一的权限管控体系；
通过构建开发管理域的体系，为开发者提供从代码管控、代码构建、测试到部署发布的体系化的能力；
通过为应用程序构建应用模型，构建应用管控引擎连接应用和资源的部署调度实现应用在平台的生命周期管理；
所有的应用和各类中间件等技术平台都可以通过标准的service broker的协议实现在PaaS门户的上下架统一管理和服务提供。

大概初略的总结下PaaS层领域的演进的思路：

1.IaaS层注重资源层面虚拟化服务化的能力的构建，PaaS层围绕应用为中心提供一整套应用管控的体系，以服务化的方式对外提供；

2.早期应用的整套管理都是人工+脚本的方式构建的，在这种模式下基本上可以管控的服务器规模、应用规模都是可控的；

3.随着服务器集群化，尤其是x86化带来的改变，服务器集群的规模成倍增长，应用的管控人工+脚本方式落后的缺点凸显，催生了PaaS这样的体系化的抽象模型。

4.PaaS围绕应用，应用包括普通应用和技术平台应用，因此PaaS平台真正的将应用统一的抽象，通过构建应用管控的引擎，统一对接IaaS资源层；通过类似service borker这样服务化的标准协议实现这些普通应用和普通应用面向使用者的统一开放管理。

到这里，有必要说明下容器技术的普及以及容器编排技术的普及对PaaS带来的影响。

首先，容器个人认为是资源层面虚拟化的进一步提升；还记得在之前的篇幅说过，对于开发者来讲，在服务器上部署应用资源的单元是以虚拟机为单位的。这样的使用资源方式存在缺点：

资源在服务器操作系统是以竞争的方式占用和切换的；
应用程序部署在虚拟化的服务器上，互性竞争使用计算资源，但是虚拟机上应用部署需要提前规划，类似电信行业7*24小时的服务要求，会要求服务器资源占比控制在比较低的占比上，浪费资源，部署运行凸显人工经验化。
容器技术的出现和普及，一方面计算资源的分域管控达到应用级别，应用的部署交给了容器编排的平台采用算法自动化的分配管理，无需人工经验参考和调整。另一方面，镜像技术的出现也极大的统一的应用运行环境，以及应用发布的模式，解决了多语言、多环境以及部署发包不完整等一系列的问题。

所以容器和容器编排技术的普及使用，本质上并没有改变PaaS平台的初衷，只是在应用和资源的结合层面，应用管控的调度层有标准化统一的抽象处理方式。

大的企业，考虑到存量的平台建设情况，在引入容器、容器编排技术的同时，都在构建基于虚拟机和容器化异构的技术栈的PaaS平台，同时兼顾到不同技术使用形态的情况，持续为企业构建统一的应用运行环境。

技术平台分层体系-PaaS层浅析相关推荐

技术平台分层体系-应用开发者看待容器技术带来的变化
基本概述不管IT领域如何的分层抽象,应用的开发者始终是面向终端用户提供真正业务服务的主体,尽管现阶段云计算的进步是希望通过分层抽象的能力,尽量转移和减少开发者聚焦点,让其专注到提供业务服务上来,但是 ...
千万级到10亿+的疯涨，搜狗商业平台服务化体系实践之路
挑战搜狗商业平台为打造搜狗一站式营销服务平台提供基础架构支撑,支持跨平台的广告主及代理商的接入.广告投放.效果评估.策略优化以及资金管理等.近年来搜狗业务飞速发展,在线广告物料实现了千万级到10亿+ ...
致远项目管理SPM系统五大技术平台层-CTP能力概述
卷首语:协同技术平台(CTP)为致远项目管理SPM系统提供了运行框架和技术支撑. CTP平台概述 CTP平台在语言方面基于Spring开发框架,遵循JavaEE的标准规范,主要采用JAVA语言设计开发 ...
金秋“论道”分享——《IPTV直播+技术平台浅析》
10月14日下午,在以"智屏·互联,大'视'所趋"为主题的流媒体网第十二届电视新媒体高峰论坛--"大视频时代的运营商转型探索"分论坛上,观止云老雷为大家带来了一 ...
太美医疗搭建临床研究机构信息化体系，助力新药专项临床评价技术平台建设
2017年10月,卫健委为落实中办.国办下发的<关于深化审评审批制度改革鼓励药品医疗器械创新的意见>(厅字[2017]42号),加强重大新药创制科技重大专项(以下简称新药专项)临床评价技术 ...
数字经济核心科技深度报告：AI+5G是数字时代通用技术平台
核心层:数字经济发展的底层建筑核心层的范畴及其经济含义从宏观视角看,核心层是支撑数字经济发展的底层建筑.这个基座主要包括(1)体. (2)信息技术(IT).(3)通信技术.(4)智能硬件四个领域. ...
B端运营级视频服务技术平台搭建
正文字数:4119 阅读时长:6分钟本次LiveVideoStackCon 2020北京线下峰会我们邀请到了北京二六三企业通信有限公司技术总监李志涛来做分享.经过多年的打造,263云视频平台已经支 ...
用友iuap技术平台：赋能企业业务快速创新，实现云原生自由
伴随着数字化.智能化转型的深化,企业对云原生的需要,不仅是采用以容器.服务网格.微服务.声明式API等云原生技术,而且要回到"云原生"定义的初衷上,让应用在云架构上构建,生于云. ...
技术平台应用开发专题月 | 国产化替代的本质是价值替代
在数字经济时代,软件自主创新和国产化替代已经不仅只是把ERP.CRM等软件换成国产软件,而是要以新的思路.新的应用将数智化与信创化相结合,形成中国企业真正的国产化价值替代. 国产化替代的本质是价值替代 ...

技术平台分层体系-PaaS层浅析

技术平台分层体系-PaaS层浅析相关推荐

最新文章

热门文章