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

 

总结：自动缩扩容机制，本质上是利用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的发展。