| 编辑推荐: |
本文主要介绍PaaS解决了什么问题，PaaS平台主要支持了通用应用架构和应用运维以及PaaS架构设计，希望对您的学习有所帮助。
本文来自于CSDN，由Alice编辑、推荐。 |
|
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.支持新应用架构
跟进新一代微服务技术ServiceMesh的发展。
|
