传统企业PaaS平台功能设计与业务上云思考

传统企业PaaS平台功能设计与业务上云思考传统企业的应用架构与应用分类SAN存储：包括高、低、中不同的存储，存储中磁盘的RAID配置、存储池配置、存储的集群配置、存储的容灾备份、数据的热点迁移、数据的缓存、存储之间的SAN交换机配置（划分Zoning，连接主机）等都需要专业的存储工程师（衍生出来了很多的认证），这种存储可以做到高IOPS、低延迟、高可靠性，是目前大多数的分布式存储难以匹敌的，且目前存储厂商在SAN上也做到了虚拟化；传统企业的应用架构与应用分类主机：小型机、x86服务器，小型机以IBM小型机为例，小型机虚拟化比x86虚拟化出现的年代早了几十年，当时是硬分区技术，后来发展到逻辑分区+IO虚拟化，逻辑分区可以做到分配0.1个CPU的细粒度，同时也在2007年就推出了类似于容器的技术，做到了进程级别的隔离，但因为不开源、不方便打包、镜像管理没有Docker方便，最终只在少数客户处进行了部署使用；传统企业的应用架构与应用分类APP：以IBMWebSphere为例，十年之前就有WAS集群的概念，可以部分做到横向扩展。传统企业的应用架构与应用分类传统企业的应用云化改造需求OLTP类应用云化的要求云化关键点1：系统弹性伸缩通过应用与数据分离和集群化部署，实现系统快速扩容、处理能力灵活水平线性扩展、故障自动隔离。对于独立的应用主机可以进行灵活弹性伸缩。弹性伸缩特点：在线快速扩容：系统扩容操作低耗时、无数据迁移、服务不间断；处理能力线性扩展：系统处理能力可以通过新增节点近线性提升，实现高吞吐、高并发处理能力，应对业务爆发式增长；故障自动接管：集群可以自动发现故障节点并调整任务调度策略，在不影响处理的同时接管故障节点，保持系统高可用。云化关键点2：应用集群化部署将紧密耦合的大应用模块化拆分为多个模块化小应用，通过资源池提供系统资源的整体利用率，并将拆分后的子模块部署于资源池（后来我们搞Docker的称之为微服务化）。当硬件资源实施池化后，才具备了支撑应用的弹性伸缩，实现硬件的按需分配的基本需求，充分提高资源利用率。云化关键点3：通过数据分级分类实现应用与数据分离根据数据实时性、重要性、敏感性等因素，将数据分成数个级别，各个级别的数据对系统的作用、采用存储、保护方式也都有所不同位置无关性：数据在远程还是本地存储，对应用最好透明。分布无关性：数据分布在多个数据节点，对应用透明。比如查询某个客户的所有相关数据，虽然同一个用户信息分布在多个数据节点上，但对应用来说就好像一个集中数据库进行查询。存储无关性：数据存储在内存库、物理库（关系型数据库、NoSQL数据库）、File还是缓存等介质，对应用透明。云化关键点4：合理规划实现数据分布式部署对不同业务的数据、不同类型的数据进行有效规划部署。通过某种特定的条件，将存放在同一个数据库中的数据分散存放到多个数据库上，实现数据分布存储，通过路由规则路由访问特定的数据库。数据库拆分方式包括：垂直（纵向）拆分：将数据库表按业务、功能拆分到不同的数据库表，比如分为客户资料库、订单库、资源库、资料库等，这种方式多个数据库之间的表结构不同；目的是降低业务之间的影响，减少系统承载压力。水平（横向）拆分：将同一个表的数据进行分块保存到不同的数据表中，这些数据库中的表结构完全相同。云化关键点5：数据平台化数据平台化是指通过应用架构和数据架构的重新梳理、规划与调整，将业务处理中的业务数据和状态数据与应用分离，实现应用的轻量化、无状态；构建统一的数据访问层，实现数据的共享访问。数据平台化是数据处理水平线性扩展的前提和基础。数据平台化特点：应用轻量化：缩短开发周期，提升新业务响应速度；应用无状态：实现应用的同质化，应用层处理能力的独立扩展，实现应用灵活调度和分配；数据共享访问：逐步实现数据集中访问，跨地市的流量共享、流量统付、流量转移业务能够更高效支撑。OLAP型应用云化的需求OLAP型应用云化的需求这种架构以处理结构化数据为主，基本部署于Oracle、小型机、SAN存储之上，扩展性不足，难以处理海量数据。大数据处理技术的兴起让这类应用的云化找到了思路。云化时总体推荐混搭架构，即采用多种技术架构建设大数据中心：垂直混搭架构OLAP型应用云化的需求水平混搭架构OLAP型应用云化的需求企业级数据云平台：逐渐实现企业内数据的统一存储，承载数据的加工计算；未来提供企业数据的统一存储和计算能力；数据仓库、集市和挖掘库：计算逐渐迁移到云平台实现轻载化；直接从云平台加载应用结果数据，实现上层应用的兼容性；流处理平台：实时计算结果存储到云数据平台，可通过能力开放平台的消息中间件直接供应用访问。OLAP型应用云化的需求OLAP云化关键点1：数据计算引擎开源化M/R计算引擎：用HDFS文件保证每一步计算结果，避免硬件故障导致重头执行。优点：可靠性高；缺点：数据处理任务是一系列M/R任务的串行执行，输入和输出都是HDFS文件，导致频繁的磁盘I/O，执行速度慢；局限性：原始单一的编程模型和数据结构，导致开发效率低，限制更多应用的产生。OLAP型应用云化的需求OLAP云化建设关键点2：数据集市云化建设建设现状：传统小机+Oracle数据库和新建的MPP数据库两种建设模式。演进策略一：用MPP数据库来取代小机+Oracle数据库；演进策略二：用数据云平台+开源MYSQL/PGSQL集群来代替小机+Oracle数据库。OLAP型应用云化的需求数据云平台完成所有的后台计算。OLAP型应用云化的需求OLAP云化关键点3：数据ETL云化建设传输的实时化：支持MQ等分布式实时消息传输机制；基于内存的计算：数据不落地，避免海量数据的两次重复加载；计算的轻量化：清单级的过滤、排重、规则化，更多的计算任务由大数据存储和计算平台来完成；分布式并行执行：高可用性、分布式调度、资源分配；技术实现：Kafka+HDFS+MR/Spark。基于容器的PaaS平台架构的构建基于此架构有以下几个主要问题：可以实现应用编排与部署，但是编排的基础单元是虚拟机模板，模板比较重，而且镜像很难修改，编排、分发、运行、持续集成等都有很大的困难，因此构建在模板上的应用形成的服务很难用；基于虚拟机的弹性伸缩相应时间也比较慢，我们尝试做过基于Cloudwatch+Autoscaling的虚拟机弹性伸缩功能，发现弹性伸缩对业务的响应时间有一个偏差，这个偏差大约在十几分钟，在抢购、秒杀等业务中基本不可接受；很难在企业内部形成一个统一的私有云集群来同时运行这两类业务，因此两个PAAS集群实际上是两个独立的集群，都是按照业务最高峰配置，存在资源浪费的现象，运维也是分开运维。新一代PaaS平台新一代PaaS平台使用容器+容器镜像管理替代服务目录管理+虚拟机模板管理。在InstancePaaS（iPaaS）平台上除了基于Kubernetes的容器管理、镜像管理、应用管理等功能，还构建了如下子系统：日志子系统：基于ELK实现；计算子系统：集成OpenStack与自研的SkyformCMP；存储子系统：通过Cinder，支持ISCSI、NFS、Ceph三类存储，与IaaS打通；网络子系统：我们选用了Netron+OVS的SDN解决方案；监控子系统：通过Ceilometer+MongoDB进行实施数据的监控、Phoenix+Hadoop进行历史数据分析；用户交互子系统：基于Node.js开发。整体的PaaS平台构建基于Kubernetes、Hadoop、SparkonMesos，构建完整的DCOS平台。需要说明的是，在传统企业在云平台还需要对接大量的系统，比如ITIL、4A/3A、人力资源系统、审计系统等PaaS平台对传统应用云化关键点的解决针对OLTP类应用云化的5个关键点的解决：系统弹性伸缩：通过KubernetesRC+service实现；应用集群化部署：通过Mesos/Kubernetes构建x86集群，将应用分布式改造以后部署与集群；通过数据分级分类实现应用与数据分离：通过BigdataPaaS的HDFS服务与InstancePaaS的DB服务可以提供部分数据分级服务的基础，但是数据分级与存储，以及访问透明性未能完全实现，需要在业务层面进行适配；合理规划实现数据分布式部署：通过在InstancePaaS提供数据库服务，以及开开源数据路由服务，实现，注：需要DBA规划数据的存储；数据平台化：应用改造后即可实现。OLAP云化的3个关键点的解决数据计算引擎开源化：可由BigdataPAAS直接提供MR、Spark服务；数据集市云化建设：可由InstancePaaS平台提供开源MySQL+TDDL实现；数据ETL云化建设：可由InstancePaaS提供Kafka、BigdataPaaS提供MR、SPARK实现。PaaS平台问题及传统应用上云改造的一些注意点基于Kubernetes、Hadoop、SparkonMesos的问题这种调度实际上是两级的调度框架，Mesos本身只管资源（主要是CPU与MEM），提供offer给上层的调度框架使用。一级调度即Mesos层有两种调度模式：Mesos粗粒度，这种模式下，一旦一台机器（一个Node）分配给某个框架，其他框架便不能使用；Mesos细粒度，这种模式下，多个框架可以共享一台机器（一个Node）。PaaS平台问题及传统应用上云改造的一些注意点粗粒度存在资源还是不能完全共享的问题，因此仍然有资源浪费的问题，细粒度模式可以改变这种问题，但是又带来新的问题：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的ingressservice（一个改造后的Nginx，运行在一个Kubernetes的POD里面）实现软负载+RC控制节点伸缩实现（每个Web部署于一个pod）；APP层的自动扩缩容，由于已经完成了基于ZooKeeper的服务注册于发现，所以只需APP层能够弹性伸缩部署即可；此处基于RC控制节点伸缩实现；DB层由于运行稳定，暂时不做PaaS化但是，基于访问路由做到分布式部署。中间件Redis集群、ZooKeeper集群、Kafka集群（用作消息总线）要不要做PaaS化？如何做？主要是这些集群节点之间的互相通信与数据传输即东西向流量，要求这些节点之间的