【编者的话】本次分享从四个方面展开:传统企业的应用架构与应用分类;传统企业的应用云化改造需求;基于容器的PaaS平台架构的构建;PaaS平台问题以及传统应用上云改造的一些注意点。
伴随着Docker技术的兴起,以及容器集群管理平台Mesos、Kubernetes、Swarm、Rancher等的大行其道,仿佛PaaS平台及其相关技术一下进入了黄金时期,各种各样的技术组合,各种各样的技术验证,以及伴随着容器相关的创业公司布道,仿佛只要有了PaaS平台及其相关的技术,就能解决一切的企业IT问题。但是,企业IT,尤其是非互联网传统企业,PaaS平台的构建与业务上云是一个长期化的过程,绝不是一个Docker+kubernetes/Mesos/Swarm构建完以后就是完成了的,IaaS年代是这样,PaaS年代也是这样。
在互联网公司或者自研发型的应用,开发环境与部署运行环境非常的类似,这也是Docker或者容器相关技术在应用上的一个很大的优势(比如构建开发、测试、部署的DevOps流水线),但是在传统企业便不一定能行得通,比如某个企业的IT应用开发维护是外包的,标准软件需要采购、应用开发需要在应用开发商完成、硬件是另外的硬件提供商,到货后需要硬件系统集成、标准软件部署、应用开发部署调试,需要很多供货商来完成,往往以项目经理统筹完成,很难由一套DevOps之类的平台来解决所有问题。
那么传统企业PaaS平台设计需要什么样的功能?上云时又需要进行如何改造,这是我们今晚探讨的一些重点。
一、传统企业的应用架构与应用分类
大家对这种架构耳熟能详,但也请做云计算或者容器技术的同事不要对这种架构嗤之以鼻,但是这种架构在也包含很多的对我们有学习借鉴意义的技术模块:
- SAN存储:包括高、低、中不同的存储,存储中磁盘的RAID配置、存储池配置、存储的集群配置、存储的容灾备份、数据的热点迁移、数据的缓存、存储之间的SAN交换机配置(划分Zoning,连接主机)等都需要专业的存储工程师(衍生出来了很多的认证),这种存储可以做到高IOPS、低延迟、高可靠性,是目前大多数的分布式存储难以匹敌的,且目前存储厂商在SAN上也做到了虚拟化;
- 主机:小型机、x86服务器,小型机以IBM小型机为例,小型机虚拟化比x86虚拟化出现的年代早了几十年,当时是硬分区技术,后来发展到逻辑分区+IO虚拟化,逻辑分区可以做到分配0.1个CPU的细粒度,同时也在2007年就推出了类似于容器的技术,做到了进程级别的隔离,但因为不开源、不方便打包、镜像管理没有Docker方便,最终只在少数客户处进行了部署使用;
- DB:传统的数据库厂商比如Oracle为例,很早就推出了RAC技术,同时,2012年左右Oracle研发中心内部就开始使用Container技术搭建DB as a Service(这比我们目前大多数的Docker相关的创业公司还早);
- APP:以IBM WebSphere为例,十年之前就有WAS集群的概念,可以部分做到横向扩展。
传统企业这种架构统治了企业IT数十年之久,在大的行业,通常以商用中间件、商用DB、小型机、SAN存储部署。这种架构存在扩展性不足的问题,但是在传统企业架构中大量存在。
我们部署一个IT系统,最终的目的是为了解决传统的问题,所谓把线下业务线上化,这些业务最终的服务对象是数据,而数据处理大致可以分成两大类:联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。
当然还有其他的业务类型,比如银行或者运营商的每月出账系统,这种系统为也是一种批处理系统,但是实时性很强,跟Hadoop MR所谓的批处理不是一个概念,也不在一个层级。这种应用我们暂时不考虑。
OLTP,也叫联机事务处理(Online Transaction Processing),表示事务性非常高的系统,一般都是高可用的在线系统,评估其系统的时候,一般看其每秒执行的Transaction以及Execute SQL的数量。典型的OLTP系统有客户关系管理系统、电子商务系统、银行、证券等。
要求:一致性、高可用性。
OLAP,也叫联机分析处理(Online Analytical Processing)系统,有的时候也叫决策支持系统,就是我们说的数据仓库。在这样的系统中,语句的执行量不是考核标准,因为一条语句的执行时间可能会非常长,读取的数据也非常多。所以,在这样的系统中,考核的标准往往是磁盘子系统的吞吐量(带宽),如能达到多少MB/s的流量。
下面我们分别分析一下这两类应用的云化需求与云化的分析。
注意:这些要求分析与要求是在Docker与各类容器管理平台火起来之前总结与做的,不是依据Docker或者容器相关技术的要求做的。所以,对我们跳出容器的惯性思维,构建一个适合传统企业的PaaS云平台有很强的指导意义。
二、传统企业的应用云化改造需求
一、OLTP类应用云化的要求
云化关键点1:系统弹性伸缩
通过应用与数据分离和集群化部署,实现系统快速扩容、处理能力灵活水平线性扩展、故障自动隔离。对于独立的应用主机可以进行灵活弹性伸缩。
弹性伸缩特点:
- 在线快速扩容:系统扩容操作低耗时、无数据迁移、服务不间断;
- 处理能力线性扩展:系统处理能力可以通过新增节点近线性提升,实现高吞吐、高并发处理能力,应对业务爆发式增长;
- 故障自动接管:集群可以自动发现故障节点并调整任务调度策略,在不影响处理的同时接管故障节点,保持系统高可用。
云化关键点2:应用集群化部署
将紧密耦合的大应用模块化拆分为多个模块化小应用,通过资源池提供系统资源的整体利用率,并将拆分后的子模块部署于资源池(后来我们搞Docker的称之为微服务化)。当硬件资源实施池化后,才具备了支撑应用的弹性伸缩,实现硬件的按需分配的基本需求,充分提高资源利用率。
云化关键点3:通过数据分级分类实现应用与数据分离
根据数据实时性、重要性、敏感性等因素,将数据分成数个级别,各个级别的数据对系统的作用、采用存储、保护方式也都有所不同。
通过对应用提供数据的透明访问,屏蔽数据的位置差异、数据分布差异、数据存储等差异:
- 位置无关性:数据在远程还是本地存储,对应用最好透明。
- 分布无关性:数据分布在多个数据节点,对应用透明。比如查询某个客户的所有相关数据,虽然同一个用户信息分布在多个数据节点上,但对应用来说就好像一个集中数据库进行查询。
- 存储无关性:数据存储在内存库、物理库(关系型数据库,NoSQL数据库)、File还是缓存等介质,对应用透明。
云化关键点4:合理规划实现数据分布式部署
对不同业务的数据、不同类型的数据进行有效规划部署。通过某种特定的条件,将存放在同一个数据库中的数据分散存放到多个数据库上,实现数据分布存储,通过路由规则路由访问特定的数据库。
数据库拆分方式包括:
- 垂直(纵向)拆分:将数据库表按业务、功能拆分到不同的数据库表,比如分为客户资料库、订单库、资源库、资料库等,这种方式多个数据库之间的表结构不同;目的是降低业务之间的影响,减少系统承载压力。
- 水平(横向)拆分:将同一个表的数据进行分块保存到不同的数据表中,这些数据库中的表结构完全相同。
拆分以后,带来的问题,需要做到:对外提供统一访问,对应用屏蔽数据访问复杂度。数据访问层提供数据互访能力,拆分访问合并返回。
所以需要构建统一数据访问引擎,或者数据路由层(Data layer层)。开源的比如有Hibernate Shards 、 Ibatis-Sharding、淘宝TDDL等。
云化关键点5:数据平台化
数据平台化是指通过应用架构和数据架构的重新梳理、规划与调整,将业务处理中的业务数据和状态数据与应用分离,实现应用的轻量化、无状态;构建统一的数据访问层,实现数据的共享访问。数据平台化是数据处理水平线性扩展的前提和基础。
数据平台化特点:
- 应用轻量化:缩短开发周期,提升新业务响应速度;
- 应用无状态:实现应用的同质化,应用层处理能力的独立扩展,实现应用灵活调度和分配;
- 数据共享访问:逐步实现数据集中访问,跨地市的流量共享、流量统付、流量转移业务能够更高效支撑。
二、OLAP型应用云化的需求
首先看一下传统的数据仓库典型架构:这种架构以处理结构化数据为主,基本部署于Oracle、小型机、SAN存储之上,扩展性不足,难以处理海量数据。大数据处理技术的兴起让这类应用的云化找到了思路。云化时总体推荐混搭架构,即采用多种技术架构建设大数据中心:
- 垂直混搭架构:
这种架构比较容易部署,但会形成多个相互独立的信息孤岛;未来缺乏可行的系统演进路; - 水平混搭架构:
- 企业级数据云平台:逐渐实现企业内数据的统一存储,承载数据的加工计算;未来提供企业数据的统一存储和计算能力;
- 数据仓库、集市和挖掘库:计算逐渐迁移到云平台实现轻载化;直接从云平台加载应用结果数据,实现上层应用的兼容性;
- 流处理平台:实时计算结果存储到云数据平台,可通过能力开放平台的消息中间件直接供应用访问。
OLAP云化关键点1:数据计算引擎开源化
M/R计算引擎:用HDFS文件保证每一步计算结果,避免硬件故障导致重头执行。
- 优点:可靠性高;
- 缺点:数据处理任务是一系列M/R任务的串行执行,输入和输出都是HDFS文件,导致频繁的磁盘I/O,执行速度慢;
- 局限性:原始单一的编程模型和数据结构,导致开发效率低,限制更多应用的产生。
Spark计算引擎:RDD是分布式内存的抽象。
- 优点:执行效率比起M/R提升100倍以上;提供丰富的操作算子增强编程能力,简化应用开发;
- 缺点:对内存等资源要求高;可靠性不如M/R;
- Yarn实现资源调度和分配:一个节点上可同时执行M/R和Spark任务,资源相互隔离、执行互不干扰。
OLAP云化建设关键点2:数据集市云化建设
建设现状:传统小机+Oracle数据库和新建的MPP数据库两种建设模式。
- 演进策略一:用MPP数据库来取代小机+Oracle数据库;
- 演进策略二:用数据云平台+开源MYSQL/PGSQL集群来代替小机+Oracle数据库。
数据云平台完成所有的后台计算。
OLAP云化关键点3:数据ETL云化建设
- 传输的实时化:支持MQ等分布式实时消息传输机制;
- 基于内存的计算:数据不落地,避免海量数据的两次重复加载;
- 计算的轻量化:清单级的过滤、排重、规则化,更多的计算任务由大数据存储和计算平台来完成;
- 分布式并行执行:高可用性、分布式调度、资源分配;
- 技术实现:Kafka+HDFS+MR/Spark。
三、基于容器的PaaS平台架构的构建
我们提到了传统企业中两类核心的应用,并且在Docker流行之前便规划了一些云化的关键点,并形成了PaaS平台,使之运行于IaaS平台与Hadoop YARN集群之上。基于此架构有以下几个主要问题:
- 可以实现应用编排与部署,但是编排的基础单元是虚拟机模板,模板比较重,而且镜像很难修改,编排、分发、运行、持续集成等都有很大的困难,因此构建在模板上的应用形成的服务很难用;
- 基于虚拟机的弹性伸缩相应时间也比较慢,我们尝试做过基于Cloudwatch+Autoscaling的虚拟机弹性伸缩功能,发现弹性伸缩对业务的响应时间有一个偏差,这个偏差大约在十几分钟,在抢购、秒杀等业务中基本不可接受;
- 很难在企业内部形成一个统一的私有云集群来同时运行这两类业务,因此两个PAAS集群实际上是两个独立的集群,都是按照业务最高峰配置,存在资源浪费的现象,运维也是分开运维。
Docker及其相关技术兴起之后,我们基于容器的相关生态圈技术,构建了新一代PaaS平台。
使用容器+容器镜像管理替代服务目录管理+虚拟机模板管理。
在Instance PaaS(iPaaS)平台上除了基于Kubernetes的容器管理、镜像管理、应用管理等功能,还构建了如下子系统:
- 日志子系统:基于ELK实现;
- 计算子系统:集成OpenStack与自研的Skyform CMP;
- 存储子系统:通过Cinder,支持ISCSI、NFS、Ceph三类存储,与IAAS打通;
- 网络子系统:我们选用了Netron+OVS的SDN解决方案;
- 监控子系统:通过Ceilometer+MongoDB进行实施数据的监控、Phoenix+Hadoop进行历史数据分析;
- 用户交互子系统:基于Node.js开发。
整体的PaaS平台构建基于Kubernetes、Hadoop、Spark on Mesos,构建完整的DCOS平台。
需要说明的是,在传统企业在云平台还需要对接大量的系统,比如ITIL、4A/3A、人力资源系统、审计系统等,这些系统与云平台的接口集成不在本次讨论范围内。
下面说一下基于以上的PaaS平台对传统应用云化关键点的解决。
针对OLTP类应用云化的5个关键点的解决:
- 关键点1,系统弹性伸缩:通过Kubernetes RC+service实现;
- 关键点2,应用集群化部署:通过Mesos/Kubernetes构建x86集群,将应用分布式改造以后部署与集群;
- 关键点3,通过数据分级分类实现应用与数据分离:通过Big data PaaS的HDFS服务与Instance PaaS的DB服务可以提供部分数据分级服务的基础,但是数据分级与存储,以及访问透明性未能完全实现,需要在业务层面进行适配;
- 关键点4,合理规划实现数据分布式部署:通过在Instance PaaS提供数据库服务,以及开开源数据路由服务,实现,注:需要DBA规划数据的存储;
- 关键点5,数据平台化:应用改造后即可实现。
OLAP云化的3个关键点的解决:
- 关键点1,数据计算引擎开源化:可由Bigdata PAAS直接提供MR、Spark服务;
- 关键点2,数据集市云化建设:可由Instance PaaS平台提供开源MySQL+TDDL实现;
- 关键点3,数据ETL云化建设:可由Instance PaaS提供Kafka、Big data PaaS提供MR、SPARK实现。
四、PaaS平台问题及传统应用上云改造的一些注意点
一、基于Kubernetes、Hadoop、Spark on Mesos的问题
这种调度实际上是两级的调度框架,Mesos本身只管资源(主要是CPU与MEM),提供offer给上层的调度框架使用。一级调度即Mesos层有两种调度模式:- Mesos粗粒度,这种模式下,一旦一台机器(一个Node)分配给某个框架,其他框架便不能使用;
- Mesos细粒度,这种模式下,多个框架可以共享一台机器(一个Node)。
粗粒度存在资源还是不能完全共享的问题,因此仍然有资源浪费的问题,细粒度模式可以改变这种问题,但是又带来新的问题:
- Mesos集群运行多种框架,包括Spark,也运行着很多Web、中间件、数据库等服务,但是Mesos不支持抢占,无法设置任务优先级,而Spark默认是贪婪模式,这样就会出现Spark运行时无法发布其他Web任务到Mesos集群上的情况。
- Hadoop与Spark在运行时,Shuffle阶段数据会交互写HDFS磁盘,这时网络资源会被大量占用(我们称之为东西向流量),导致Web服务基本不能响应(我们称之为南北向流量)。
二、多租户的问题
目前多个框架之间每个都有自己的用户管理模式,默认情况下,如果多个框架之间有交叉使用,需要在多个框架之间租户互相打通,涉及到Mesos、Hadoop、Kubernetes的账号打通问题,需要开发独立的账户中心,并且完成同步。最后讨论一下应用上云时的考虑点,并给出一个例子:
- 应用最好无状态,无状态化的应用天生适合上云。这时服务的注册于发现、应用的弹性伸缩完全交给云平台来做,比如Mesos+Marathon的HAProxy+etcd+Confd或者Kubernetes8s的service+RC;
- 已经集群化的应用组件部署相对困难,比如基于PaaS平台发布单个实例的Redis容器,但是发布Redis集群就比较困难,苦难就困难在Redis集群中的节点需要相互通信,而容器如果重启或者IP发生变化都会对集群造成影响;
- 服务注册与发现如果应用本身提供了,PaaS平台的服务注册与发现功能便不能使用,不能两套服务注册与发现同时使用。
这儿,给出一个应用上云部署的例子:
上图左边是某传统企业电商应用最初架构,Web部署于一台高配置x86服务器、APP部署于一台中端小型机、DB部署于一台中端小型机,右边是初步进行了改造后的架构,即迁移到PaaS平台之前应用已经做了模块化与集群化的初步改造:
- 前台用负载均衡将流量引入到三个Web节点中,每个Web节点部署于x86服务器,Session集中存在Redis集群(无状态化改造,交互用HTTP+JSON短连接);
- APP层也通过Redis集中存放状态信息,做到了无状态化,每个APP节点部署于三台x86服务器;
- Web与APP在流量大的时候可以做到手动扩容,但是需要配置固定的IP,APP服务(提供给)的注册发现是基于ZooKeeper完成(应用自己来完成服务注册于发现);
- DB层做了主从数据库,部署与x86服务器。
该应用里面还用到了Kafka,用来做数据总线,也采取了集群化部署
针对目前的现状,如上图,应用迁移到PaaS平台需要做三方面的工作:
- 完成Web层的服务注册与发现,在此基础上实现web层的自动扩缩容,此处基于Kubernetes的ingress service(一个改造后的Nginx,运行在一个Kubernetes的POD里面)实现软负载+RC控制节点伸缩实现(每个Web部署于一个pod);
- APP层的自动扩缩容,由于已经完成了基于ZooKeeper的服务注册于发现,所以只需APP层能够弹性伸缩部署即可;此处基于RC控制节点伸缩实现;
- DB层由于运行稳定,暂时不做PaaS化但是,基于访问路由做到分布式部署。
剩余一个问题需要探讨,Redis集群、ZooKeeper集群、Kafka集群(用作消息总线)要不要做PaaS化?如何做?
首先回答一个问题,Redis、Zookeeper、Kafka等集群PaaS化(容器化)的难点在哪儿?
主要是这些集群节点之间的互相通信与数据传输即东西向流量,要求这些节点之间的IP配置需要固定IP,而且重新启动以后相应的配置信息不能改变。容器自身的启动、网络配置比较动态化,对需要固定的集群配置而言是一个挑战。
比如大多数的PaaS平台提供单个实例的Redis缓存服务不是问题,但是提供任意配置的Redis集群便不支持。我们经过前期的测试,实现了容器平台下的此类应用的集群化部署,以ZooKeeper为例:
ZooKeeper自身部署要求:
- ZooKeeper client依赖固定ZooKeeper server IP来完成服务;
- ZooKeeper server配置(所有成员IP必须固定);
- 至少3个独立节点;
解决方案(基于Kubernetes):
- Client通过固定3个service IP连接ZooKeeper server;
- 构建3个单POD的RC;
- 配置DeamonSet,指定ZooKeeper的POD所启动运行的主机;
- ZooKeeper自身配置使用Service DNS name;
- 存储进行持久化。
最后,需要说明的是,应用上云后一个很重要因素,PaaS平台(Docker为基础的构建),稳定性与可靠性也是至关重要的,我们在部署迁移应用时,每次都会针对应用做较为详细的测试,测试案例包括:
- 无负载的POD并发测试;
- 频繁创建带业务的POD及其稳定性;
- 业务的并发性测试;
- 不同业务的IO并发性能测试;
- 容器间网络性能测试;
- 几类常见的数据库性能测试;
- Nginx集群性能测试;
- Kubernetes Rc机制测试;
- Docker对MEM资源限制能力的测试;
- Docker对进程数量限制能力的测试;
等等,这些测试方面供大家参考,具体测试方法与步骤可针对应用自行设计,不在今晚的具体分享之内,今晚的话题到此结束。
Q&A
Q:在你的新一代PaaS平台中,我怎么对公司的很多个不同的应用做不同的集群,有些集群偏向于大量的IO占用,有些集群偏向于大量的网络占用,有些集群偏向于大量的内存占用,并且启用的集群间还有通信和交互,针对这些不均衡现象该如何处理?Q:公司有很多Web系统,每一个Web系统都有自己的存储、数据库,所以如果融入PaaS平台的话,首先第一点软硬件问题如何做到全部满足,其次就是就算把我的DB层整合迁徙到你的PaaS的DB层,我是不是还要做其它方面的投入,比如开发成本等等,还有就是DB的兼容性是不是会有问题?
A:所以PaaS平台硬件资源会针对不同应用去做区分,在企业私有云建设时,需要对应用进行梳理,将不同的应用分类,底层采取相应集群支撑,比如计算密集型、IO密集型等,同时综合考虑波峰波谷与业务特性进行配置。
Q:后面的OLAP主要的作用是数据整合和存储与分析,但是首先要解决的就是各个应用的数据不一致问题,还有就是数据中又分业务数据和非业务数据,这些问题是各个应用的团队自己解决吗?该怎么解决?
A:Web层我们推荐做无状态化,且要做应用与数据分离,session信息集中存放。DB迁移到PaaS层是一个比较慎重的过程,PaaS层优先考虑开源数据库。如果原先是MySQL基于PaaS平台也提供的MySQL数据库服务,那么开发成本基本比较小,只需考虑版本问题。
Q:请问MySQL部署数据应用能承载多大数据量,响应速度如何?
A:数据仓库大数据平台中数据不一致的问题由ETL+数据建模来解决,应用团队要参与一起进行数据分析与建模。
Q:有些传统公司,有些软件设备是以序列号安装使用的,所以这一块融入PaaS平台是不是不太可能?
A:我们一个项目中,采用读写分离的MySQL架构,几千万的数据表,及时查询没问题,这也要看硬件配置与数据索引的建立等。
Q:讲session集中到Redis,是需要做代码层面的修改吗?
A:比较困难,另外还有一个问题是License限制的问题,在弹性架构中也比较难。
Q:请问架构改造会不会导致应用要重新开发?
A:要修改,每次session的操作都要到Redis中增删改。
Q:为什么Kubernetes和Mesos要一起用呢,考虑点在哪里?
A:会,从IOE架构到x86架构,从x86物理机到虚拟机到Docker,应用需要以越来越小的模块化分布式部署,也就是说逐步向微服务化过渡。
Q:分处于不同子网的容器和虚拟机之间三层网络通信如何解决的?中间还走传统三层交换机?
A:针对单个应用Docker化,我们开始的选型定位在Kubernetes,主要考虑了POD的应用场景更类似虚拟机,另外Kubernetes的模块比较丰富,像负载均衡、服务发现等已经成熟,后来用Mesos是因为需要把大数据之类的应用进行整合。需要Kubernetes/Spark on Mesos。
Q:开发周期过长或者客户开发能力弱会导致整个架构流产 有配套的应用改造方案吗?
A:三层网络之间的互通还是走三层交换机。二层组网我们基于OVS+VXLAN。
Q:另外大量采用开源工具 如何解决 版本升级及后期维护?
Q:对传统企业而言,一开始就搭建一个大而全PaaS方案是不现实的,我们推荐从某一个典型应用做起。我们针对交易性应用、分布式应用、批处理应用等应用都有配套改造方案。
Q:Mesos使用集中式存储和分布式存储效率上有什么不同吗?
A:一般会跟应用的代码配套做版本升级与维护。
Q:容器弹性伸缩策略具体怎么考虑的,CPU?
A:这个看应用,集中式存储在集群中应用时,如果针对单一与应用划分Volume,性能会好一些,如果是分布式应用,比如MR类的应用,分布式存储反而会好。
以上内容根据2016年6月14日晚微信群分享内容整理。分享人牛继宾,曾任VMware研发中心研发工程师,IBM实验室服务部高级技术专家,目前在天云软件(北京天云融创软件技术有限公司)担任技术总监。擅长云计算与大数据相关技术,除了底层平台技术,对云计算解决IT应用系统的实际问题、应用的分布式改造、业务支撑等也有丰富的经验。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。
A:CPU、内存、IO、用户连接数等都可以作为弹性伸缩的策略依据。
有疑问加站长微信联系(非本文作者)
![](https://static.golangjob.cn/static/img/footer.png?imageView2/2/w/280)