PAAS的架构设计与应用实践(一)

CloudSpace是一个平台即服务(PaaS),它提供给开发者自由的去选择云平台、开发框架和应用服务,使得开发者能够更快更容易的开发、测试、部署和扩展应用,让开发人员专注于编写应用程序,而无需为中间件和基础设施分心。团队在使用自助式高生产力的框架和应用服务的同时,开发人员可以快速在自己的环境上开发和测试自己的下一代应用,并能部署到云上而无需做任何更改,大大提升持续快速,高质量地交付价值的能力。

一、 PaaS解决了什么问题?

     PaaS为开发者提供应用全生命周期的服务能力,主要有两方面:

  • 是提供了资源资源和服务集成的平台,如  存储、数据库、缓存和搜索等;

  • 服务端应用程序的运行环境,如  Web应用和Work应用等;

PaaS架构设计要提供多租户的应用平台,多租户间的隔离机制(Nodes、Network、IO、Runtime、Services等)非常重要,对于隔离要关注以下方面:

  • 资源隔离和约束

       指应用间的容器配额cpu、io、内存等资源要相互不受影响。

  • 访问控制

       包括应用间的网络访问控制和本地IO访问控制。

  • 数据和数据服务

       Container只挂在归属应用自身的UnionFS 

       OVS针对服务实例实施白名单策略

       类似S3等块存储天然隔离

 

PaaS平台主要支持了通用应用架构应用运维两方面能力:

  1. 支持应用架构能力

  

      随着应用架构迭代,平台最终将应用抽象为两种类型web和work。区分两种类型, 就是看应用提供的是http能力,还是socket能力。对于通用应用架构,与框架无关,具有无状态、分布式、通用性三个特性。

  • 对于无状态

       一个应用通常有多个实例集,单实例失去服务能力不影响应用的服务。应用开发时,不要将状态与实例耦合,通常采用实例之外通用存储来保证状态一致性。

  • 对于分布式

       一个应用通常要进行集群部署,而不是单个应用部署。具体这样的特性,必须在应用开发时,注意扩展性,不要将配置与实例耦合,通常采用实例之外通用配置中心来保证应用独立性。

  • 对于通用性

       更多是从应用和服务角度来做定义,对于应用来讲,从调用关系来看,可分为对外或对内调用,应用间通信抽象为同步(常用Http)或异步(常用Message);对于服务来讲,从中间件角度来看,都应该具有分布式能力(分布式cache、分布式db等),并且提供数据的安全访问机制,屏蔽应用交互差异,做到通用模型。

 

2. 支持应用运维的能力

       运维通常划分为基础运维和应用运维。对于基础运维,主要负责物理设备及网络等基础建设,更偏底层。对于应用维护,主要围绕应用构建全方位服务,如 虚拟资源,网络规划,软件预装、应用,安全、日志等管理服务,一直以来都在推动运维工作的自动化、规范化和简约化,但仍然面对不同应用团队个性化的挑战,这些都应该有PaaS平台统一解决。

 

二、PaaS架构设计

 

  

  

CloudSpace围绕AppEngine核心采用了容器级的PaaS模型来设计,其设计目标为: 

#可用性,利用组件冗余的设计,满足应用7*24的服务。

#伸缩性,利用规则引擎的设计,满足应用所属实例的动态调度。

#安全性,利用软控制策略,实现了应用与服务的网络隔离和流量控制。

#省成本,利用虚拟化和自动化运维,节省资源,节省运维,按需计费。

#灵活性,利用容器技术,隔离环境,支持多语言,自定义软件栈,  个性化配置等。

 

 

CloudSpace对于App的访问,有Lvs集群接入,通过Router来路由到具体App分配到宿主机(N)->容器(C)->实例(I)。对于三者关系, 对于PAAS平台,会维护一个机器池,每个机器称为宿主机,每个宿主机上有多个容器,每个容器会部署一个App的实例。对于App在平台上,实例的分布有Master基于数据决策,调度到不同宿主不同容器,达到动态缩扩容要求,满足应用的性能变化。

1.Node分层视图

  

对于PaaS平台部署应用最小物理单元为Node,从结构上分为三层:

第一层为机器(简称Machine),提供给容器虚拟化的物理集群,对应用透明。

第二层为容器(简称Container),提供给App部署最小虚拟化单元,对应用透明。

第三层为实例(简称 Instance),提供给App运行的实例,依赖软件栈配置。

 

2.Container技术

主流PaaS模型包括 进程级、容器级、VM级,三种最重要区别隔离机制实现策略不同。

对于CloudSpace的容器技术迭代经历了两个重要版本: 

第一种:LXC 基于容器的虚拟化技术

  • 共享OS和内核

  • User Space + Kernel Space

  • Cgroup + Namespace

  • 容器的创建,销毁,启动,停止

      命令:  lxc-create, destroy,start,stop,attach, execute

第二种:Docker 轻量级的操作系统虚拟化解决方案

  

 

Docker是一个构建在LXC之上的,基于进程容器的轻量级VM解决方案。

  • 与VM不同

    Docker则直接在宿主平台上加载运行应用程序. 本质上他在底层使用LXC启动一个Linux Container,通过Cgroup等机制对不同容器内运行的应用程序进行隔离,权限管理和quota分等,每个container拥有自己独立的各种命名空间(亦即资源)包括:  PID 进程, MNT 文件系统, NET 网络, IPC , UTS 主机名等。

  • 与LXC不同

    Docker是Lxc的一个高级封装,提供了各种辅助工具和标准接口方便使用,可以依靠Lxc和各种脚本实现与docker类似的功能。除此之外,Docker核心思想就体现在它的运行容器构建方案上, 为了最大化重用Image运行时所构造的运行环境,实际上是由具有依赖关系的多个Layer组成的。有了层级化的Image做基础,不同的APP共用底层文件系统及相关软件栈,同一个APP的不同实例也可以实现共用绝大多数数据。

  

CloudSpace系统(如上图)有六大组件构成:

1.Agent组件(应用代理)

  

  • 容器生命周期

    容器创建/配置/启动/停止等指令,有Master通过Agent下发执行,应用于容器的生命周期。

  • 语言运行环境初始化

    容器本身语言无关,但在启动时会指定语言类型(如java),并初始化语言相关的软件栈(如 Jetty),为应用配置好环境。

  •  与Master交互命令

    Agent与Master通过消息方式进行通信,接受Master对容器与应用的控制。

  • 运行数据采集

    Agent负责对应用依赖的机器和容器,进行性能数据采集(如 cpu,load,io等)。

  • APP状态管理

Agent负责对应用的可用性进行健康检查。

 

2.Router组件(路由)

  

CloudSpace部署多个Router共同处理所有HTTP流量。Controller获得信息并实时更新路由表,持续维护分布式路由状态,并将用户请求URL的访问路由至具体的应用,保持在应用实例之间分发流量实现负载均衡。

  •  Dynamic Upstream

APP在Master调度过程中,会动态更新Router中的映射地址,即为用户访问APP的域名与容器地址,便于支持APP的动态所扩容策略。

  •  Management Interface

Router开放接口,来支持Master围绕APP动态load配置信息,实时控制应用链路映射,支持相关特性实现。

  • Http/Https

Route支持针对有https需求的应用配置https证书能力。

  • Sticky Session

      Route反向代理应用请求,可以根据配置支持IPHash能力,便于应用支持粘性会话功能,但在实例调度时,仍然失效,只能一定程度保持状态。更好建议是采用分布式集中缓存的token或cookie方案来实现。

3. Master组件(控制)

Master是PAAS平台最核心的控制中心,主要围绕APP针对网络和实例进行管理。对网络利用SDN来进行多APP及服务间访问限制;对于实例集中在资源分配和实例调度两方面,最重要利用规则引擎实现了动态缩扩容,支持应用的弹性部署,能够从容地应对业务的流量高峰。

  • 对于APP资源分配,就是容器数量与类型配置选择。对于已选定的APP资源也可以进行扩展,即分为横向扩展(实例数量)和纵向扩展(实例配置)。

  

  

  • Master主要依据APP的指标设置规则和采集机器及容器的性能数据做动态分析,对于APP实例调度,支持四种策略来实现自动缩扩容。

 

  

 

  • 策略一:负载调度

若APP部署了三个实例(A/B/C),围绕APP的三个实例的负载数据(cpu/mem/load等)进行采集,然后计算APP平均负载指标,来对比指标设置数据,若达到阀值,就触发APP负载调度。Master会计算需要扩容3个实例能达到阀值以下,接着在剩余资源中找到不同宿主机(负载最低)启动APP的新实例DEF,最终APP启动了六个实例来服务线上业务。

  • 策略二:性能调度

若APP部署了三个实例(A/B/C),围绕APP的三个实例的性能数据(qps/tps/rt/等)进行采集,然后计算APP平均性能指标,来对比指标设置数据,若达到阀值,就触发APP性能调度。Master会计算需要扩容3个实例能达到阀值以下,接着在剩余资源中找到不同宿主机(负载最低)启动APP的新实例DEF,最终APP启动了六个实例来服务线上业务。

  • 策略三:故障调度

若APP部署了三个实例(A/B/C),围绕APP设置健康检查配置(端口、协议和频次),Agent周期进行健康探测,然后根据结果状态判断来触发故障调度。故障分为三种Node、Container,不管那种故障类型,只是调度范围不同。对于Node,是针对Node上所有app,对于Container,是针对Container内app,首先Master要发指令给Router,剔除掉原有映射关系,避免请求到故障实例上。对于负载和性能调度策略,在缩扩容时也要考虑映射关系动态变更。

  • 策略四:最大最小调度

对于APP的业务有高峰有低谷,常常流量不平均,期望在高峰时扩容,低谷时缩容,提升对资源利用率。正式这种考虑,需要依据APP最小最大调度数设置(如: 3<x<6),Master利用规则引擎,实现自动缩扩容。围绕APP动态计算性能和负载的综合数据指标,并进行同比和环比计算,来预测指标趋势,最终决定是要扩还是缩。

 

总结:自动缩扩容机制,本质上是利用Router的动态Upstream机制,实现APP期望的实例数动态映射。现在有很多网关方案均支持这种特性,感兴趣也可以研究下k8s,比原有方案会简单不少。

 

4.Monitor组件(监控)

  

对于监控来讲,基于日志自研的APM系统,对于APP的应用请求和业务日志通过Flume采集,经过实时计算分钟级的性能指标(机器/容器/APP),存储在数据库中,提供Console进行可视化展示,同时让开发者可以基于ES查询实现日志搜索查询。

 

5.Service组件(服务)

Sevice是一个独立的、插件式的模块,便于第三方方便地把自己的服务整合成CloudSpace服务。在此PAAS平台中已经包含了服务的框架及核心类库,如MongoDB、Mysql、 PostgreSql、RabbitMQ、Redis和ElasticSearch等,并且第三方可以继承Node和Gateway基础类来开发自己的服务。

 

6.Net模块(网络)

PAAS平台主要采用了floodlight实现SDN功能,来控制容器的OVS的配置,实现APP间的网络限制功能。对于floodlight的高可用利用ZK特性实现了M/S架构二次开发,并对ovs可视化视图进行了指标优化,进而提升了平台安全性。

 

三、CloudSpace架构设计未来规划

 

1.支持多平台多区域

  • 支持多平台:

考虑多平台的资源集成架构设计,增加Azure,Aws等资源平台。

  •  支持多区域:

考虑多Region架构设计,支持后续会逐步增加节点

2.支持开放平台原则

  • 持续完善OpenApi

      便于第三方管理平台集成服务

  • 接入更多的服务

      便于满足用户更多的业务需求

3. 支持AIops功能

在不断完善devops外,引入更加智能aiops,为用户提供一致的开发/测试/生产环境,更好的提升交付价值的效率。

4.  支持新应用架构

   跟进新一代微服务技术Service  Mesh的发展。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章