企业私有云PaaS平台-背景目标和整体方法论(200917)

原文转载自 「人月神话的BLOG」 ( http://blog.sina.com.cn/s/blog_493a84550102z95a.html ) By 人月神话

预计阅读时间 0 分钟(共 0 个字, 0 张图片, 0 个链接)


今天继续分享企业私有云PaaS平台规划建设的背景,目标和整体方法论,也是对我前面分享的私有云PaaS平台建设PPT的一些关键内容的进一步阐述和说明。

私有云PaaS平台建设背景

结合企业在信息化规划和建设中遇到的实际问题来分析企业私有云PaaS平台建设的背景和原因。假设一个企业已经完成了初步的私有云IaaS资源池建设,然后各个业务系统仍然按传统的独立规划建设模型进行,具体如下:

结合该图可以看到,在业务系统建设中遇到的问题主要包括:

烟囱式的系统建设模式

这个是企业信息化建设中经常遇到的问题,即各个业务系统孤立建设,越建越多,系统之间大量复杂的蜘蛛网式交互和数据传递。由于业务系统间本身的交互困难导致了端到端流程存在断点,多个系统间基础数据不一致等一系列问题。

虽然很多大型企业在IT系统构建中已经引入了基于SOA理念的集成平台,但是平台本身的作用仍然停留在数据集成和系统间接口管理。即集成平台虽然解决了传统的点对点集成到总线式集成和统一管控的转变,但是业务系统本身孤立和竖井式建设的本质并没有改变。业务系统中大量可复用的能力没有提取并抽象到平台层统一建设,业务系统本身没有基于SOA参考架构的思想进行灵活构建,这些都导致了整个IT系统和环境日趋复杂。

数据交换和能力共享

传统的企业信息化建设过程中往往会实施数据交换平台等实现业务系统间的数据交换和协同,这不可避免导致的问题就是通用的共享业务数据在多个业务系统中多点落地,由于数据交换平台本身的可靠性或数据管控能力差距,都导致了在某一个时点同样的数据在多个系统中不一致。

为了解决这个问题,有些企业开始逐步实施了MDM主数据管理系统,虽然实现了数据的统一流程管理和质量管理,但是如果MDM系统仍然是采用传统的数据收集和分发机制,仍然不可避免带来数据多点落地和不一致性的问题。导致这种结果的核心原因还是没有从传统的数据交换和集成转化为服务能力开放和共享思路上。这里需要强调的是:SOA服务共享的思路重点是业务能力通过服务的方式进行开放和暴露,这种服务是粗粒度的服务,通过底层的数据规则和计算来完成,外围业务系统往往只需要消费服务能力而不是同步底层数据。

IaaS层能力无法完全发挥

当前已经有不少企业进行了虚拟化资源池建设和实施,也初步搭建了自己的IaaS层管理平台,但是要注意到如果只实施了IaaS平台,对于应用来讲虽然物理资源不可见,但是逻辑资源仍然可见,往往IaaS层在资源分配中仍然会将逻辑资源固定的分配给业务应用。那么对于各个业务系统在业务忙闲不同的时候,就很难真正的去动态调度底层的逻辑资源能力,而无法真实实现资源的最大化利用。

而引入私有云PaaS平台真正实现了应用托管和自动部署后,才可能通过PaaS平台的调度规则和性能分析监控,去动态调度底层的IaaS资源池中的资源。即通过引入PaaS层后不仅仅是物理资源对业务系统透明,包括逻辑资源也对业务系统透明,对于最终的业务系统而言只关心服务能力的使用,而无须关系提供服务能力的资源。

业务系统建设规范和标准

在企业信息化建设过程中,不同的开发商往往都使用自己的开发框架和语言、技术架构、数据库和应用中间件等。这不可避免的导致了企业IT规划建设部门面临一个复杂的软硬件环境,这不仅仅导致了后期运维管控的困难,还造成了各个业务系统间的适配和协同困难,这也是业界经常提到IT建设部门逐步被开发厂商所绑架的一个原因。

系统本身架构可扩展性

随着企业业务的高速发展,海量数据,高并发业务场景下的高可用性和一致性问题,传统数据架构已经无法解决,即使借助小机,商用数据库也存在无法伸缩扩展的问题,因此需要考虑全新的架构模式。这种架构模式核心一方面是SOA组件化架构思想的应用,一方面是分布式和并行计算技术、大数据处理和分析技术的使用等。

所以引入私有云PaaS平台不是简单地实现公有云的资源调度和应用托管能力,更多的是要形成一套基于PaaS平台的上层应用开发框架、开发标准、开发流程、技术规范体系等,将企业内各个业务系统的开发都准备的标准化为统一的业务构件和能力单元。

私有云PaaS平台建设目标

企业私有云PaaS平台的建设目标仍然基于企业总体战略目标出发,根据战略目标分解为具体的业务目标和技术目标,同时技术目标又为具体业务目标的实现服务。

业务目标

对于企业私有云PaaS平台建设的业务目标,主体仍然包括了企业信息化建设成本降低和业务敏捷性增强两个方面的内容。PaaS平台的建设核心不仅仅是云计算等各种技术的使用,更加重要的是将传统业务系统孤立烟囱式的建设模式,转化为平台+应用的建设模式,打破原有的业务系统边界形成业务组件化开发和协同的架构模式,真正实现业务模块的快速构建,对业务需求和流程变化的快速响应。具体的业务目标主要包括:

01-降低IT建设的投资和成本

通过私有云PaaS平台能力开放和复用的思想,将原有的重复开发的功能组件转换为平台层开放能力以降低重复成本。通过PaaS平台的应用托管和资源动态调度,最大化的实现原有的IaaS基础设施资源池资源的最大化利用。通过私有云的集中化建设模式实现分散多套系统建设投资和后期运维成本等。

02-提升业务敏捷性

对于业务敏捷性的提升包括两个方面的内容,一个是对于新建设的业务系统或应用,可以基于PaaS平台层已有的技术和业务复用能力快速地订购使用,而不需要业务系统全新重头开发;另外一方面是当出现业务需求和流程变更的时候,基于SOA面向服务架构思想,可以灵活地对服务进行重新组装和编排,以满足新的业务和流程需要。

通过私有云PaaS平台的建设,将逐步弱化原有的业务系统概念和边界,对于企业端到端业务的支撑将变为多个底层的核心业务能力组件的协同,这些业务组件基于私有云PaaS平台统一的规范和架构体系,通过标准的服务方式进行协同,基于同样的底层基础数据和技术能力,在这种模式下将彻底转变原有的业务系统隔离和信息孤岛,真正实现业务的端到端流程整合和管控。

技术目标

私有云建设的技术目标,主要是作为企业IT建设部门和技术层面出发,考虑通过私有云平台建设后在技术层面的收益。

01-建设灵活可扩展的架构体系

对于云计算本身即具备弹性伸缩扩展能力,而对于私有云PaaS平台建设,通过平台+应用的服务化构建模式,通过各种分布式技术的使用,真正形成一套完全可以灵活水平扩展的弹性架构体系,这种架构体系能够满足IT系统在业务高速发展下5到10年,甚至更长时间段的灵活支撑和水平扩展,而不是类似传统架构体系在扩展性方面受到诸多约束。

02-建设高可用的私有云生态环境

业务系统的高可用性始终是企业信息化建设和后期运维管控的一个重要内容,通过私有云平台的建设,期望的是形成一个高可用、高可靠、安全一致的IT生态环境。通过分布式集群技术,冗余、异地容灾备份,双中心等多种措施真正形成一个高可用的环境。

03-形成企业可复用的IT资产库

传统的业务系统开发模式往往很难真正的抽取各个业务系统的共性能力并服务化,而私有云PaaS平台建设在基于SOA的思想指导下,通过可复用服务能力的识别和开发,形成可复用的企业IT资产库和服务目录。对于单纯的私有云PaaS技术平台而言不是资产,但是对于提供了可共享的业务,数据和技术服务能力后的PaaS平台则是企业重要的IT核心资产。

04-形成标准化的IT治理和管控体系

通过私有云平台的建设,可以进一步的规划企业内部业务系统的建设标准和流程,业务系统的开发流程和技术架构,所有的业务系统基于同样一套技术标准体系,开发流程进行需求分析,设计和开发,过程管理等。真正提升企业内部信息化部门对IT系统的管控能力。

05-降低对单一厂家硬件或软件的依赖

对于中国互联网领域前几年开始推行的去IOE运动的重要性,已经逐步被大型企业所接受,随着国家相关信息化发展规划和安全政策,开源和国产化将逐步成为趋势。因此在当前私有云建设规划中重点可以考虑去IOE和开源软件的使用。

私有云PaaS平台建设原则

结合传统的IT系统规划和建设原则,私有云PaaS平台的规划和建设原则如下:

标准化原则

虽然当前私有云PaaS平台的建设标准还不完善,但是可以看到类似Gartner等已经逐步推出有相应的参考架构可以参考,同时对于云计算技术本身已经有相应的国家标准出台。因此在私有云建设过程中需要遵循这些标准体系进行规划、设计和实施。

先进性原则

在系统的总体设计上,需要借鉴国内外大型IT服务和集成厂商的成功经验,同时要关注同类平台的建设教训。在技术上,要采用国际上先进的且成熟的技术,采用国际标准体系架构,使得设计更加合理、更为先进。充分考虑企业信息化本身的现状和特点,在注重平台的实用性的前提下,尽可能采用先进的软、硬件环境;在软件的开发思想上,严格按照软件工程的标准和面向对象的理论来设计,保证系统的先进性。

安全性原则

系统在设计时将遵循安全性的原则,采用高可靠性的产品和技术,充分考虑整个系统运行的安全策略和机制,具有较强的容错能力和良好的恢复能力,保障系统安全、稳定、高效的运行。在安全设计中要全面考虑网络安全、数据安全和用户安全。

 可扩展性原则

对于私有云PaaS平台的建设,系统的软硬件环境都必须能够根据业务的发展灵活的水平扩展,也能够通过SOA架构和服务化思想灵活的满足业务变化需求。在水平扩展过程中至少需要做到不对已有的硬件投资或软件体系架构造成修改和变更,而是通过可配置或热切换的方式进行能力扩展,同时在能力扩展过程中基本保证线性扩展能力。

稳定性原则

一般稳定性是指系统的正确性、健壮性两个方面,系统是在网络环境下运行的,并且系统管理的数据量大,数据的使用并发性强等,这些特点对系统的设计提出了更高的要求。因此,一方面系统在提交之前应该反复测试,把错误减少到最小程度,保证系统的正常的运转;另一方面,系统必须有足够的健壮性,在发生意外情况下,能够很好的处理并给出错误提示,并且能够得到及时的恢复,减少不必要的损失。

开放性原则

为适应将来业务和技术发展的需求,系统建设必须具有较强的开放性,平台和应用的建设应基于面向服务(SOA)的理念构建,需底层的接入与业务的处理分离,实现服务的封装、重用,在增加新业务时不需要更改系统的软件结构和网络结构。除具有标准的开放式技术接口外,还能够完成与现有系统具有标准接口的系统完全对接,能够充分利用已有服务。

投资保护原则

满足系统整体性能的前提下,充分利用已有的设备、软件和数据资源,新添置的设备以满足使用为原则。

核心指导思想

对于企业私有云平台建设主要还是围绕通过私有云建设后最大化资源利用率,降低能耗和硬件采购成本,实现数据中心的集中管控和运维,促进企业内部信息化部门的服务化转型等。云计算本身具备的技术特点和优势,由于企业对信息化资产和安全的管控需求,企业信息化应用本身业务规则,逻辑和一致性的高要求等,往往很难真正迁移到当前的公有云平台,这也是诸多大型企业都开始独立建立自己的私有云数据中心和云平台的原因。

目前,很多企业的内部私有云平台建设仅仅还是在解决IaaS层和虚拟化资源池的问题,而这远远没有达到私有云建设的核心业务目标和核心价值所在。因此在启动企业内部私有云PaaS平台建设时,需要进一步明确平台建设的核心指导思想。

集中和系统化

既然私有云谈集中化,那么大系统观就显得更加重要,在大系统观下企业内部的IT建设和业务系统最终就是一个大系统,其他的仅仅是业务模块和组件单元。在企业私有云PaaS平台建设下将彻底打破原有的企业信息化建设中业务系统竖井式的建设模式,真正转变为基于SOA服务化思想下的平台+应用构建模式。

在业务系统组件化后,原有的业务系统边界将被彻底打破,整个企业的信息化系统将转变成为一个平台能力支撑下的多个业务组件构成的大系统。在大系统建设模式下涉及到两个方面的整合,一个是向底层的资源池整合和平台化,一个是最顶层的云门户化集成,而大系统中剩余的就是各个业务组件单元。大系统建设要解决的核心问题就是资源的复用问题和资源的水平调度和扩展问题。

传统的企业信息化建设模式很难真正地按大系统观的思想来规划和建设,大系统建设模式首先要解决企业架构中的业务架构和数据架构问题,然后才是应用架构和技术架构问题。只有按企业架构业务驱动IT思想,分层和组件化的思想才可能真正的理解大系统的概念,分层和分模块地进行建设。

如果引入了企业私有云,我们的信息化建设还是传统的各个业务系统独立建设,后续再考虑协同的模式,那么私有云本身还是停留在技术优势上面,很难真正的体现业务价值。

平台和分层化

当我们在谈PaaS(平台即服务)的时候,但是很多时候我们的理解却是它是一个可托管的云端运行平台,可能也包括了在线开发平台,测试平台。但是我们一定要注意到私有云里面的平台不仅仅是解决平台的云化问题,更加重要的是需要解决业务组件本身基于SOA组件化思想设计、基于平台搭建和集成问题。

技术平台真正的是可以做到标准化开发方法和开发模式,提升开发效率,将私有云PaaS平台对应用的约束完全固化到开发框架和平台中。平台化一方面解决标准化问题,同时解决可复用问题,还进一步解决前端应用和产品的可配置问题。

在引入了私有云和云本身的分层架构概念后,结合传统的企业应用架构,特别是服务化的分层架构,需要重新对企业私有云下的分层架构进行整合。即在整个私有云PaaS平台体系下分为资源,服务和应用三个层面。其中资源层既包括了IaaS层物理基础设施,也包括了私有云PaaS技术平台,而应用则包括了各个松耦合的业务组件模块和顶层云门户集成。在平台和应用层之间是服务层构建,通过标准化的SOA参考架构体系,真正实现了平台层服务能力和应用层功能构建之间的解耦。

集成和协同化

这个是大型企业信息化规划建设的一个核心内容,不管是否引入企业私有云都需要考虑集成方面的问题。在引入私有云后传统的企业业务系统间的集成转换为业务组件或模块间的集成,同时在进一步强化分层架构思想后,引入了多层之间的纵向服务集成。对于集成主要包括两个方面的内容:

首先是数据的集成和数据的融合,这里面涉及到主数据和共享数据中心的建设问题,核心目标就是解决共享数据只有一套,有唯一的源头的创建更新机制,数据以共享数据服务的方式将能力发布出去,供其它业务组件使用。这个和传统数据交换和集成有很大的区别,即在于数据本身不会落地到各个业务系统形成多份数据拷贝,而是按需实时访问和使用。

其次是业务的集成和协同,要完成一个端到端的业务流程和业务协同,最终将转换为业务组件间的服务交互和协同问题,那么核心问题就转变为了业务组件如何划分最合理,最能够保证业务组件之间的内聚性,真正能够实现业务组件的彻底解耦问题。

私有云建设完成后,组件化资源池里面有大量的业务组件,这些业务组件提供业务服务,如果这些业务组件不能很好的通过业务服务协同起来完成最终的业务目标,那么资源池化和共享的价值发挥不出来。

演进和平衡观

要明白企业私有云的建设一定不是一步到位和一蹴而就的,这个有点类似传统的软件工程思想都没有理解透彻一下就过渡到敏捷方法往往栽跟头。私有云建设有成熟度模型,有参考架构,但是一定要结合企业信息化实际情况制定切实可行的演进思路和发展路线。目标架构可以有,但是一定要逐步演进和发展。

我们说的平衡包括了建设期和运维期的平衡,业务可行性和技术先进性的平衡,CAP三个方面的平衡,开发难度周期和可扩展性的平衡,成本和收益的平衡等多个方面的内容。要知道在引入私有云架构后,虽然可以更好的实现可扩展性和容错性,但是必然牺牲一致性方面的需求,而对于企业信息化应用来说,往往事务完整性和数据一致性才是最最重要的。

分布式架构有分布式的好处,但是分布式架构却带来事务一致性方面的问题,带来了开发难度的问题,带来了后续运维难度的问题,这些都必须要去考虑。目标架构虽然理想,但是当前阶段的成熟度下是否适用就必须要去评估。再完美的技术如果最终无法落地,也仅仅是空中楼阁而已。

企业私有云PaaS平台建设中涉及到IPaaS集成平台,BPaaS流程平台和APaaS应用调度平台,还涉及分布式数据库和数据库资源池化。而到现在来看比较成熟的仍然是集成共享服务平台,统一流程管理平台,数据平台等。其它内容往往并不成熟,特别是对于完全动态的资源调度和水平扩展能力,在实施性和稳定性上仍然没有答案,在完全基于开源的方式来构建企业内部的私有云PaaS的时候更是风险重重。

私有云PaaS平台总体规划方法

结合企业架构和IT规划的思想,参考SOA服务化架构,基于企业私有云建设的目标和原则要求,私有云平台的总体规划可以理解为传统IT规划和企业架构在平台和服务化思想下的进一步细化和展开,具体总体规划方法如下:

结合上图,对企业私有云PaaS规划的核心方法和步骤进行简要说明如下:

首先仍然是以传统的IT规划和企业架构规划为导入,体现业务驱动IT,在进行企业架构分析的时候要充分考虑平台化和SOA的思想,不论是在业务架构,数据架构还是应用架构的规划和设计中都需要进行共享业务和技术能力的识别,考虑服务能力的共享而非简单的数据集成和接口。

在企业架构规划的基础上,根据共享能力的识别开始进行平台层功能架构和技术架构的规划,在规划过程中可以参考业界PaaS标准架构体系和企业自身的平台化需求。充分识别可行的共享技术服务和平台服务能力。

在平台层能力基本规划清楚后,考虑企业架构集成架构的规划,从服务共享需求和业务集成需求两个层面来考虑服务层的规划,包括功能规划和技术规划,形成可共享的SOA服务目录集和服务视图,作为可复用的服务资产。

基于平台层和服务层规划的输出,结合SOA和CBM组件化业务模型的思想,开始进行应用层规划,包括了业务组件规划,功能架构规划和基于组件的应用集成规划等。

在平台层,服务层和应用层基于私有云总体架构体系指导下规划完成后,开始考虑结合企业信息化现状和成熟度,给出企业私有云演进路线和实施策略规划。对于本章所涉及到的企业私有云建设规划,基本也是围绕该总体规划方法论展开进行论述。

私有云PaaS平台总体架构体系

参考私有云和SOA参考架构体系,结合私有云建设平台+应用的构建思想,可以得出上图所示的私有云PaaS平台总体架构体系。在该架构体现中PaaS平台层分为PaaS技术平台,SOA共享服务平台和PaaS管理平台三方面的内容。PaaS技术平台提供的技术能力都通过SOA服务总线向外开放和暴露。具体说明如下:

平台层-技术能力平台

该层在传统公有云PaaS平台提供的中间件和数据库资源池和服务能力,消息缓存等技术服务能力的基础上,结合私有云PaaS平台的特点增加了平台层技术能力。其中主要包括了主数据平台,4A平台和流程平台三部分的核心能力。

服务层-SOA服务总线

对于PaaS技术平台提供的技术服务和数据服务能力,对于业务系统中业务组件提供的业务服务能力,流程平台提供的流程服务能力统一接入到SOA服务总线。SOA服务总线实现统一的服务目录管理,服务全生命周期管理功能。通过SOA服务层,可以真正实现应用层和PaaS技术能力平台的解耦。

PaaS管理平台

实现PaaS平台的基于资源和服务的全生命周期管控,包括资源和服务的申请,开通,控制和鉴权,资源和服务的回收,性能分析和监控,应用托管和自动部署等核心功能。

应用层

基于PaaS平台构建的应用层,重心将转化为松耦合的业务组件的构建,业务组件的重点是提供可协同的业务服务能力,提供本业务组件需要的服务组装和界面展现能力。通过业务组件化将逐步打破传统的业务系统边界,而松耦合的业务组件最终又通过统一的云应用门户进行集成和整合。

微服务架构下的私有云PaaS平台建设

本部分谈下一个企业全新构建IT系统和应用,没有遗留系统负担的情况下,如何基于微服务架构思想进行规划和建设。

谈微服务架构思想实际上是包含了平台+应用思想,业务组件化服务化思想,SOA和云思想,包括当前主流的DevOps思想的一个融合,而不仅仅是简单的微服务架构。因此对于一个新创建的企业要基于微服务架构思想来整体规划内部IT并不是一件容易的事情。

首先我们对整体规划建设进行拆分,主要应该包括以下关键的建设任务和内容。

底层私有云平台建设,这个即考虑全部基于IaaS资源池进行并尽量去IOE架构,当前实际上对于涉及到数据库仍然或涉及到部分的Oracle数据库和集中存储,企业在选型和规划的时候要考虑本身去掉这部分潜在风险。服务器资源可以考虑全部采用X86服务器并进行虚拟化,提供虚拟机资源作为计算能力。

容器云PaaS平台建设,对于PaaS平台建设当前可以基于轻量的Docker容器进行,并通过Kubernates进行资源管理和动态调度。而如果规划建设DevOps支撑平台,即在DevOps平台建设过程中统一建设容器化PaaS平台,当然在DevOps平台中会进一步实现了持续集成和流水线作业能力,实现开发,运行和后期运维监控的一体化管理。通过实施DevOps平台可以进一步对当前的开发团队规划,岗位角色分工,软件过程改进等进一步优化。

在微服务架构实施中,还有一个重点就是制定微服务架构开发框架,标准和规范体系。以指导后续开发厂商按照统一的标准方法,工具和流程进行微服务组件模块和接口服务的开发,确保开发标准和规范一致性,也进一步确保了后续多个微服务模块在集成的时候不会出现问题。

把这些都谈后,再转回谈需要统一建设的技术平台部分。

4A平台,这个是必须建设的内容,不仅仅是实现统一用户,统一认证和鉴权,统一组织,统一审计等内容。在微服务架构下,4A平台进一步扩展传统业务系统中系统管理模块的内容,即能够实现到微服务模块内部的功能菜单和按钮级的操作授权,同时能够实现灵活定义的数据级授权和配置。

公共流程平台,这个公共流程平台也是必须,实现统一的类似内部多租户的流程引擎,实现流程的设计建模,运行,监控的全部统一化。各个业务组件模块仅仅是使用流程平台提供的能力。

技术服务平台,这个实际涉及到消息,缓存,文件,任务,日志,通知,分布式存储等诸多技术服务能力,可以根据企业需要来确定哪些要单独实现为独立的技术服务能力开放提供。这个没有明确的要求,但是根据实际项目实践来看,类似发送短信邮件的通知类服务,文件存储类服务往往都是必须要规划建设的。

监控运维平台,这个平台实际上包括了传统的IT网管监控,同时还包括了当前的APM业务性能监控两个方面的内容。同时两者内容本身又相互集成和融合。由于采用了容器化PaaS,实际上微服务开发商对底层资源的情况并不清楚,因此更加需要这样一个监控运维平台能够同时监控到业务性能和资源层性能,并实时预警。

除了技术平台外,再来看下业务中台部分可以规划建设哪些内容。

主数据平台建设,基于当前企业信息化规划建设实施,对于业务中台部分能够统一考虑的只有基础主数据部分内容,因为这部分是共性基础数据服务提供能力。当然基于微服务架构模式下,实际上也没有独立的主数据平台概念,实际上应该只有类似供应商,产品,客户等微服务模块。

中间即是满足各个业务能力实现的微服务模块应用,相互独立自治,松耦合。微服务模块间通过轻量的Http API即可进行交互和协同。当然在这个过程中涉及到微服务网关的使用等。

最上层规划统一门户平台,门户平台重点就是实现业务功能在应用层的简单组装和配置,类似App Store商店一样,最终的业务用户可以根据自己的需求安装相关的业务系统应用。即门户具备足够的灵活定制能力。同时对于DevOps平台最好和前端门户结合,即通过DevOps平台发布和部署的微服务可以直接发布到最终的门户应用上面。



 
more_vert