企业私有云PaaS平台建设规划方法原则和内容

　　今天再整理和分享下我最近出版的《SOA与大数据实战-企业私有云平台规划和建设》里面的部分内容。前面谈中台，微服务和云原生比较多，最近自己的思考重点也在传统企业IT架构如何进行微服务改造，如何基于云原生解决方案思路平滑上云。
　　而越是深入思考，越能得到如下结论。
　　即对于传统企业完全按照互联网的思路构建中台或微服务基本都是死路一条，而对于公有云厂商同样不能真正理解企业传统架构和业务复杂性，理想化的推动云原生也是死路。
　　我自己上面这本书本身在14年左右完成初稿，一直拖到今年在出版，但是在13年就提出了私有云PaaS平台，平台+应用，业务能力组件化和组件能力服务化等思路绝对是具备足够的前瞻性。虽然很多传统的技术已经被新技术所取代，类似传统的PaaS平台已经逐步被容器云平台驱动，ESB总线逐步被API网关或ServiceMesh取代。但是当时整个的规划架构思想仍然值得当前大部分企业在实施微服务，构建自己云原生演进实践的时候思考。私有云PaaS-建设背景
　　结合企业在信息化规划和建设中遇到的实际问题来分析企业私有云PaaS平台建设的背景和原因。假设一个企业已经完成了初步的私有云IaaS资源池建设，然后各个业务系统仍然按传统的独立规划建设模型进行，具体如下：
　　结合该图可以看到，在业务系统建设中遇到的问题主要包括：
　　烟囱式的系统建设模式
　　这个是企业信息化建设中经常遇到的问题，即各个业务系统孤立建设，越建越多，系统之间大量复杂的蜘蛛网式交互和数据传递。由于业务系统间本身的交互困难导致了端到端流程存在断点，多个系统间基础数据不一致等一系列问题。
　　虽然很多大型企业在IT系统构建中已经引入了基于SOA理念的集成平台，但是平台本身的作用仍然停留在数据集成和系统间接口管理。即集成平台虽然解决了传统的点对点集成到总线式集成和统一管控的转变，但是业务系统本身孤立和竖井式建设的本质并没有改变。
　　业务系统中大量可复用的能力没有提取并抽象到平台层统一建设，业务系统本身没有基于SOA参考架构的思想进行灵活构建，这些都导致了整个IT系统和环境日趋复杂。
　　数据交换和能力共享
　　传统的企业信息化建设过程中往往会实施数据交换平台等实现业务系统间的数据交换和协同，这不可避免导致的问题就是通用的共享业务数据在多个业务系统中多点落地，由于数据交换平台本身的可靠性或数据管控能力差距，都导致了在某一个时点同样的数据在多个系统中不一致。
　　为了解决这个问题，有些企业开始逐步实施了MDM主数据管理系统，虽然实现了数据的统一流程管理和质量管理，但是如果MDM系统仍然是采用传统的数据收集和分发机制，仍然不可避免带来数据多点落地和不一致性的问题。导致这种结果的核心原因还是没有从传统的数据交换和集成转化为服务能力开放和共享思路上。
　　这里需要强调的是：SOA服务共享的思路重点是业务能力通过服务的方式进行开放和暴露，这种服务是粗粒度的服务，通过底层的数据规则和计算来完成，外围业务系统往往只需要消费服务能力而不是同步底层数据。
　　IaaS层能力无法完全发挥
　　当前已经有不少企业进行了虚拟化资源池建设和实施，也初步搭建了自己的IaaS层管理平台，但是要注意到如果只实施了IaaS平台，对于应用来讲虽然物理资源不可见，但是逻辑资源仍然可见，往往IaaS层在资源分配中仍然会将逻辑资源固定的分配给业务应用。那么对于各个业务系统在业务忙闲不同的时候，就很难真正的去动态调度底层的逻辑资源能力，而无法真实实现资源的最大化利用。
　　而引入私有云PaaS平台真正实现了应用托管和自动部署后，才可能通过PaaS平台的调度规则和性能分析监控，去动态调度底层的IaaS资源池中的资源。即通过引入PaaS层后不仅仅是物理资源对业务系统透明，包括逻辑资源也对业务系统透明，对于最终的业务系统而言只关心服务能力的使用，而无须关系提供服务能力的资源。
　　云计算包括当前云原生核心发展趋势即不断的从最底层的IaaS朝上层发展，而在过渡到PaaS层一个核心就是从对资源的的需求变化为对服务的需求，底层虚拟机和容器对你不可见。
　　业务系统建设规范和标准
　　在企业信息化建设过程中，不同的开发商往往都使用自己的开发框架和语言、技术架构、数据库和应用中间件等。这不可避免的导致了企业IT规划建设部门面临一个复杂的软硬件环境，这不仅仅导致了后期运维管控的困难，还造成了各个业务系统间的适配和协同困难，这也是业界经常提到IT建设部门逐步被开发厂商所绑架的一个原因。
　　系统本身架构可扩展性
　　随着企业业务的高速发展，海量数据，高并发业务场景下的高可用性和一致性问题，传统数据架构已经无法解决，即使借助小机，商用数据库也存在无法伸缩扩展的问题，因此需要考虑全新的架构模式。这种架构模式核心一方面是SOA组件化架构思想的应用，一方面是分布式和并行计算技术、大数据处理和分析技术的使用等。
　　所以引入私有云PaaS平台不是简单地实现公有云的资源调度和应用托管能力，更多的是要形成一套基于PaaS平台的上层应用开发框架、开发标准、开发流程、技术规范体系等，将企业内各个业务系统的开发都准备的标准化为统一的业务构件和能力单元。私有云PaaS-建设目标
　　企业私有云PaaS平台的建设目标仍然基于企业总体战略目标出发，根据战略目标分解为具体的业务目标和技术目标，同时技术目标又为具体业务目标的实现服务。
　　对于企业私有云PaaS平台建设的业务目标，主体仍然包括了企业信息化建设成本降低和业务敏捷性增强两个方面的内容。PaaS平台的建设核心不仅仅是云计算等各种技术的使用，更加重要的是将传统业务系统孤立烟囱式的建设模式，转化为平台+应用的建设模式，打破原有的业务系统边界形成业务组件化开发和协同的架构模式，真正实现业务模块的快速构建，对业务需求和流程变化的快速响应。具体的业务目标主要包括：
　　降低IT建设的投资和成本
　　通过私有云PaaS平台能力开放和复用的思想，将原有的重复开发的功能组件转换为平台层开放能力以降低重复成本。通过PaaS平台的应用托管和资源动态调度，最大化的实现原有的IaaS基础设施资源池资源的最大化利用。通过私有云的集中化建设模式实现分散多套系统建设投资和后期运维成本等。
　　对于当前PaaS平台建设中的微服务和云原生方式，要意识到一开始本身不是降低成本，而是增加了成本，特别是学习成本，集成成本，人员成本等。但是当整个平台+应用的模式构建完成后，一定是降低后续持续交付成本，运维成本。
　　提升业务敏捷性
　　对于业务敏捷性的提升包括两个方面的内容，一个是对于新建设的业务系统或应用，可以基于PaaS平台层已有的技术和业务复用能力快速地订购使用，而不需要业务系统全新重头开发；另外一方面是当出现业务需求和流程变更的时候，基于SOA面向服务架构思想，可以灵活地对服务进行重新组装和编排，以满足新的业务和流程需要。
　　通过私有云PaaS平台的建设，将逐步弱化原有的业务系统概念和边界，对于企业端到端业务的支撑将变为多个底层的核心业务能力组件的协同，这些业务组件基于私有云PaaS平台统一的规范和架构体系，通过标准的服务方式进行协同，基于同样的底层基础数据和技术能力，在这种模式下将彻底转变原有的业务系统隔离和信息孤岛，真正实现业务的端到端流程整合和管控。
　　提升业务敏捷性是当前传统企业IT架构转型，构建中台或逐步微服务架构改造，实现内部私有云和公有云的混合云架构，并在此基础上实现持续集成和交付的核心目标。
　　私有云建设的技术目标，主要是作为企业IT建设部门和技术层面出发，考虑通过私有云平台建设后在技术层面的收益。
　　建设灵活可扩展的架构体系
　　对于云计算本身即具备弹性伸缩扩展能力，而对于私有云PaaS平台建设，通过平台+应用的服务化构建模式，通过各种分布式技术的使用，真正形成一套完全可以灵活水平扩展的弹性架构体系，这种架构体系能够满足IT系统在业务高速发展下5到10年，甚至更长时间段的灵活支撑和水平扩展，而不是类似传统架构体系在扩展性方面受到诸多约束。
　　建设高可用的私有云生态环境
　　业务系统的高可用性始终是企业信息化建设和后期运维管控的一个重要内容，通过私有云平台的建设，期望的是形成一个高可用、高可靠、安全一致的IT生态环境。通过分布式集群技术，冗余、异地容灾备份，双中心等多种措施真正形成一个高可用的环境。
　　形成企业可复用的IT资产库
　　传统的业务系统开发模式往往很难真正的抽取各个业务系统的共性能力并服务化，而私有云PaaS平台建设在基于SOA的思想指导下，通过可复用服务能力的识别和开发，形成可复用的企业IT资产库和服务目录。对于单纯的私有云PaaS技术平台而言不是资产，但是对于提供了可共享的业务，数据和技术服务能力后的PaaS平台则是企业重要的IT核心资产。
　　形成标准化的IT治理和管控体系
　　通过私有云平台的建设，可以进一步的规划企业内部业务系统的建设标准和流程，业务系统的开发流程和技术架构，所有的业务系统基于同样一套技术标准体系，开发流程进行需求分析，设计和开发，过程管理等。真正提升企业内部信息化部门对IT系统的管控能力。
　　降低对单一厂家硬件或软件的依赖
　　对于中国互联网领域前几年开始推行的去IOE运动的重要性，已经逐步被大型企业所接受，随着国家相关信息化发展规划和安全政策，开源和国产化将逐步成为趋势。因此在当前私有云建设规划中重点可以考虑去IOE和开源软件的使用。私有云PaaS-建设原则
　　结合传统的IT系统规划和建设原则，私有云PaaS平台的规划和建设原则如下：
　　标准化原则
　　虽然当前私有云PaaS平台的建设标准还不完善，但是可以看到类似Gartner等已经逐步推出有相应的参考架构可以参考，同时对于云计算技术本身已经有相应的国家标准出台。因此在私有云建设过程中需要遵循这些标准体系进行规划、设计和实施。
　　先进性原则
　　在系统的总体设计上，需要借鉴国内外大型IT服务和集成厂商的成功经验，同时要关注同类平台的建设教训。在技术上，要采用国际上先进的且成熟的技术，采用国际标准体系架构，使得设计更加合理、更为先进。充分考虑企业信息化本身的现状和特点，在注重平台的实用性的前提下，尽可能采用先进的软、硬件环境；在软件的开发思想上，严格按照软件工程的标准和面向对象的理论来设计，保证系统的先进性。
　　安全性原则
　　系统在设计时将遵循安全性的原则，采用高可靠性的产品和技术，充分考虑整个系统运行的安全策略和机制，具有较强的容错能力和良好的恢复能力，保障系统安全、稳定、高效的运行。在安全设计中要全面考虑网络安全、数据安全和用户安全。
　　可扩展性原则
　　对于私有云PaaS平台的建设，系统的软硬件环境都必须能够根据业务的发展灵活的水平扩展，也能够通过SOA架构和服务化思想灵活的满足业务变化需求。在水平扩展过程中至少需要做到不对已有的硬件投资或软件体系架构造成修改和变更，而是通过可配置或热切换的方式进行能力扩展，同时在能力扩展过程中基本保证线性扩展能力。
　　稳定性原则
　　一般稳定性是指系统的正确性、健壮性两个方面，系统是在网络环境下运行的，并且系统管理的数据量大，数据的使用并发性强等，这些特点对系统的设计提出了更高的要求。因此，一方面系统在提交之前应该反复测试，把错误减少到最小程度，保证系统的正常的运转；另一方面，系统必须有足够的健壮性，在发生意外情况下，能够很好的处理并给出错误提示，并且能够得到及时的恢复，减少不必要的损失。
　　开放性原则
　　为适应将来业务和技术发展的需求，系统建设必须具有较强的开放性，平台和应用的建设应基于面向服务（SOA）的理念构建，需底层的接入与业务的处理分离，实现服务的封装、重用，在增加新业务时不需要更改系统的软件结构和网络结构。除具有标准的开放式技术接口外，还能够完成与现有系统具有标准接口的系统完全对接，能够充分利用已有服务。
　　投资保护原则
　　满足系统整体性能的前提下，充分利用已有的设备、软件和数据资源，新添置的设备以满足使用为原则。私有云PaaS建设方法论
　　对于企业私有云平台建设主要还是围绕通过私有云建设后最大化资源利用率，降低能耗和硬件采购成本，实现数据中心的集中管控和运维，促进企业内部信息化部门的服务化转型等。云计算本身具备的技术特点和优势，由于企业对信息化资产和安全的管控需求，企业信息化应用本身业务规则，逻辑和一致性的高要求等，往往很难真正迁移到当前的公有云平台，这也是诸多大型企业都开始独立建立自己的私有云数据中心和云平台的原因。
　　目前，很多企业的内部私有云平台建设仅仅还是在解决IaaS层和虚拟化资源池的问题，而这远远没有达到私有云建设的核心业务目标和核心价值所在。因此在启动企业内部私有云PaaS平台建设时，需要进一步明确平台建设的核心指导思想。
　　集中和系统化
　　既然私有云谈集中化，那么大系统观就显得更加重要，在大系统观下企业内部的IT建设和业务系统最终就是一个大系统，其他的仅仅是业务模块和组件单元。在企业私有云PaaS平台建设下将彻底打破原有的企业信息化建设中业务系统竖井式的建设模式，真正转变为基于SOA服务化思想下的平台+应用构建模式。
　　在业务系统组件化后，原有的业务系统边界将被彻底打破，整个企业的信息化系统将转变成为一个平台能力支撑下的多个业务组件构成的大系统。在大系统建设模式下涉及到两个方面的整合，一个是向底层的资源池整合和平台化，一个是最顶层的云门户化集成，而大系统中剩余的就是各个业务组件单元。大系统建设要解决的核心问题就是资源的复用问题和资源的水平调度和扩展问题。
　　传统的企业信息化建设模式很难真正地按大系统观的思想来规划和建设，大系统建设模式首先要解决企业架构中的业务架构和数据架构问题，然后才是应用架构和技术架构问题。只有按企业架构业务驱动IT思想，分层和组件化的思想才可能真正的理解大系统的概念，分层和分模块地进行建设。
　　如果引入了企业私有云，我们的信息化建设还是传统的各个业务系统独立建设，后续再考虑协同的模式，那么私有云本身还是停留在技术优势上面，很难真正的体现业务价值。
　　平台和分层化
　　当我们在谈PaaS（平台即服务）的时候，但是很多时候我们的理解却是它是一个可托管的云端运行平台，可能也包括了在线开发平台，测试平台。但是我们一定要注意到私有云里面的平台不仅仅是解决平台的云化问题，更加重要的是需要解决业务组件本身基于SOA组件化思想设计、基于平台搭建和集成问题。
　　技术平台真正的是可以做到标准化开发方法和开发模式，提升开发效率，将私有云PaaS平台对应用的约束完全固化到开发框架和平台中。平台化一方面解决标准化问题，同时解决可复用问题，还进一步解决前端应用和产品的可配置问题。
　　在引入了私有云和云本身的分层架构概念后，结合传统的企业应用架构，特别是服务化的分层架构，需要重新对企业私有云下的分层架构进行整合。即在整个私有云PaaS平台体系下分为资源，服务和应用三个层面。其中资源层既包括了IaaS层物理基础设施，也包括了私有云PaaS技术平台，而应用则包括了各个松耦合的业务组件模块和顶层云门户集成。在平台和应用层之间是服务层构建，通过标准化的SOA参考架构体系，真正实现了平台层服务能力和应用层功能构建之间的解耦。
　　集成和协同化
　　这个是大型企业信息化规划建设的一个核心内容，不管是否引入企业私有云都需要考虑集成方面的问题。在引入私有云后传统的企业业务系统间的集成转换为业务组件或模块间的集成，同时在进一步强化分层架构思想后，引入了多层之间的纵向服务集成。对于集成主要包括两个方面的内容：
　　首先是数据的集成和数据的融合，这里面涉及到主数据和共享数据中心的建设问题，核心目标就是解决共享数据只有一套，有唯一的源头的创建更新机制，数据以共享数据服务的方式将能力发布出去，供其它业务组件使用。这个和传统数据交换和集成有很大的区别，即在于数据本身不会落地到各个业务系统形成多份数据拷贝，而是按需实时访问和使用。
　　其次是业务的集成和协同，要完成一个端到端的业务流程和业务协同，最终将转换为业务组件间的服务交互和协同问题，那么核心问题就转变为了业务组件如何划分最合理，最能够保证业务组件之间的内聚性，真正能够实现业务组件的彻底解耦问题。
　　私有云建设完成后，组件化资源池里面有大量的业务组件，这些业务组件提供业务服务，如果这些业务组件不能很好的通过业务服务协同起来完成最终的业务目标，那么资源池化和共享的价值发挥不出来。
　　演进和平衡观
　　要明白企业私有云的建设一定不是一步到位和一蹴而就的，这个有点类似传统的软件工程思想都没有理解透彻一下就过渡到敏捷方法往往栽跟头。私有云建设有成熟度模型，有参考架构，但是一定要结合企业信息化实际情况制定切实可行的演进思路和发展路线。目标架构可以有，但是一定要逐步演进和发展。
　　我们说的平衡包括了建设期和运维期的平衡，业务可行性和技术先进性的平衡，CAP三个方面的平衡，开发难度周期和可扩展性的平衡，成本和收益的平衡等多个方面的内容。要知道在引入私有云架构后，虽然可以更好的实现可扩展性和容错性，但是必然牺牲一致性方面的需求，而对于企业信息化应用来说，往往事务完整性和数据一致性才是最最重要的。
　　分布式架构有分布式的好处，但是分布式架构却带来事务一致性方面的问题，带来了开发难度的问题，带来了后续运维难度的问题，这些都必须要去考虑。目标架构虽然理想，但是当前阶段的成熟度下是否适用就必须要去评估。再完美的技术如果最终无法落地，也仅仅是空中楼阁而已。
　　企业私有云PaaS平台建设中涉及到IPaaS集成平台，BPaaS流程平台和APaaS应用调度平台，还涉及分布式数据库和数据库资源池化。而到现在来看比较成熟的仍然是集成共享服务平台，统一流程管理平台，数据平台等。其它内容往往并不成熟，特别是对于完全动态的资源调度和水平扩展能力，在实施性和稳定性上仍然没有答案，在完全基于开源的方式来构建企业内部的私有云PaaS的时候更是风险重重。
　　结合企业架构和IT规划的思想，参考SOA服务化架构，基于企业私有云建设的目标和原则要求，私有云平台的总体规划可以理解为传统IT规划和企业架构在平台和服务化思想下的进一步细化和展开，具体总体规划方法如下：
　　结合上图，对企业私有云PaaS规划的核心方法和步骤进行简要说明如下：
　　首先仍然是以传统的IT规划和企业架构规划为导入，体现业务驱动IT，在进行企业架构分析的时候要充分考虑平台化和SOA的思想，不论是在业务架构，数据架构还是应用架构的规划和设计中都需要进行共享业务和技术能力的识别，考虑服务能力的共享而非简单的数据集成和接口。
　　在企业架构规划的基础上，根据共享能力的识别开始进行平台层功能架构和技术架构的规划，在规划过程中可以参考业界PaaS标准架构体系和企业自身的平台化需求。充分识别可行的共享技术服务和平台服务能力。
　　在平台层能力基本规划清楚后，考虑企业架构集成架构的规划成功，从服务共享需求和业务集成需求两个层面来考虑服务层的规划，包括功能规划和技术规划，形成可共享的SOA服务目录集和服务视图，作为可复用的服务资产。
　　基于平台层和服务层规划的输出，结合SOA和CBM组件化业务模型的思想，开始进行应用层规划，包括了业务组件规划，功能架构规划和基于组件的应用集成规划等。
　　在平台层，服务层和应用层基于私有云总体架构体系指导下规划完成后，开始考虑结合企业信息化现状和成熟度，给出企业私有云演进路线和实施策略规划。对于本章所涉及到的企业私有云建设规划，基本也是围绕该总体规划方法论展开进行论述。
　　参考私有云和SOA参考架构体系，结合私有云建设平台+应用的构建思想，可以得出上图所示的私有云PaaS平台总体架构体系。在该架构体现中PaaS平台层分为PaaS技术平台，SOA共享服务平台和PaaS管理平台三方面的内容。PaaS技术平台提供的技术能力都通过SOA服务总线向外开放和暴露。具体说明如下：
　　平台层-技术能力平台
　　该层在传统公有云PaaS平台提供的中间件和数据库资源池和服务能力，消息缓存等技术服务能力的基础上，结合私有云PaaS平台的特点增加了平台层技术能力。其中主要包括了主数据平台，4A平台和流程平台三部分的核心能力。
　　服务层-SOA服务总线
　　对于PaaS技术平台提供的技术服务和数据服务能力，对于业务系统中业务组件提供的业务服务能力，流程平台提供的流程服务能力统一接入到SOA服务总线。SOA服务总线实现统一的服务目录管理，服务全生命周期管理功能。通过SOA服务层，可以真正实现应用层和PaaS技术能力平台的功能解耦。
　　PaaS管理平台
　　实现PaaS平台的基于资源和服务的全生命周期管控，包括资源和服务的申请，开通，控制和鉴权，资源和服务的回收，性能分析和监控，应用托管和自动部署等核心功能。
　　应用层
　　基于PaaS平台构建的应用层，重心将转化为松耦合的业务组件的构建，业务组件的重点是提供可协同的业务服务能力，提供本业务组件需要的服务组装和界面展现能力。通过业务组件化将逐步打破传统的业务系统边界，而松耦合的业务组件最终又通过统一的云应用门户进行集成和整合。平台层功能规划
　　对于PaaS平台层的功能规划主要还是从业务系统建设采用平台+应用构建思想后，可以下沉到平台层的技术和业务服务能力进行分析，以确定具体可以规划的功能点。平台层功能的核心是支撑上层的业务系统或业务组件，和传统的公有云PaaS功能规划不同的是，对于私有云PaaS功能既涉及到纯技术能力，也包括了可复用的公共基础能力和业务能力的下沉。对于传统的烟囱式业务系统构建向平台+应用方式构建转换，具体可以参考下图：
　　平台层功能规划的核心基本围绕该图展开，具体说明如下：
　　数据库和中间件
　　传统的IaaS层仅仅实现了物理设施的资源池化，而没有实现数据库和中间件的资源池，在PaaS平台建设过程中可以将数据库和中间件以服务的方式对应用提供和开放。用户将不再关心数据库和中间件的安装和配置，而仅仅需要订购数据库和应用中间件容器的服务能力。这既是传统的公有云APaaS部分的标准内容，也包括了DaaS数据库即服务层的内容。
　　注：上云原生，不是简单的容器云部分，更加重要的是中间件服务和技术服务部分，特别是数据库服务，即由传统的申请虚拟机转变到直接申请云服务厂商的数据库服务能力。
　　技术服务平台
　　对于任何一个业务系统的构建可以看到，业务系统内部本身也有一个公有的技术组件满足业务系统上层多个业务模块的需要。其中包括了系统管理，共性的各种技术能力（消息、日志、安全、异常、缓存、文件、通知、任务）等多个方面的内容，对于这些公有的技术组件能力需要根据私有云建设过程中的实际情况来考虑是否规划到平台层统一建设和实现。
　　数据层
　　数据层的一个核心就是共享数据，其中包括了共享动态数据和主数据，对于这些数据往往被上层多个业务系统使用和消费。而传统的业务系统建设模式往往这些数据在多个系统中建立和维护，数据在多个系统中同步和落地，这些都导致了数据的不一致性等问题。
　　在PaaS平台建设过程中需要考虑进行集中化规划和建设，如建设MDM主数据管理平台，SID共享数据库中心等。这样这些共享数据可以实现集中化的数据存储并通过数据服务的方式朝外提供标准统一的服务能力。
　　业务规则
　　业务规则往往随着业务系统的不同差异很大，也是很难真正集中平台化模式建设的。而当前规则引擎可以解决该问题。即业务规则抽取到规则引擎中统一配置和管理，然后规则引擎以规则服务的方式将最终的能力暴露给业务系统使用。对于规则引擎平台可以在当前的BPaaS业务流程平台即服务中统一规划和考虑。
　　流程层
　　流程层包括了HWF人工工作流和BPEL自动化业务工作流，不论是哪种类似在PaaS平台建设中都需要考虑集中化建设。流程层的集中化建设对应到标准的PaaS参考架构中BPaaS部分的内容，对于各个业务系统都使用同一个流程引擎进行流程建模，流程执行和流程监控。同时在规划的时候要注意到4A平台的集中化建设是流程平台规划的基础和前提。
　　SOA服务总线
　　主要是实现平台层可共享的能力以服务的方式统一注册和暴露给上层业务应用使用。同时对于上层业务组件之间的数据集成和应用集成也需要由服务总线来完成。SOA服务总线属于PaaS参考架构中iPaaS集成平台即服务的重要内容。
　　在实现完全的微服务架构化后可以采用API网关来实现接口集成和能力对外开放，但是存在遗留系统的情况下，传统的类似ESB服务总线仍然需要存在相当长一段时间。
　　界面展现层
　　界面展现层重点是强调可复用的界面UI组件，也包括了在平台化建设后对于各个拆分后的业务组件通过统一应用框架进行集成。
　　在这里的界面展现层也可以理解为前后端分离开发后的前端开发，但是前端不仅仅是单纯的界面展现，也包括了服务组合和编排等能力。平台层技术规划
　　对于平台技术规划，结合前面的平台功能规划需求，主要从数据库和存储、应用托管和资源调度、ESB集成中间件、底层建模几个方面进行展开说明。
　　数据库和存储
　　首先谈下数据库，要意识到数据库的集中包括了两个方面的内容，一个是数据库服务器硬件的集中化，一个是数据本身的集中化。对于类似Oracle RAC集群数据库实现的是数据库硬件，软件和数据的全部集中，但是数据库集群算不上真正的分布式数据库。mysql cluster集群可以算作分布式数据库，可以实现数据的水平shading功能，但是cluster集群本身在大数据量和大并发下，对于复杂业务逻辑操作存在性能瓶颈，这是不可回避的事实，在cluster集群配合读写分离集群共同使用的时候又出现了数据存储分布的问题。数据物理存储的分布又导致了底层数据库数据日志同步，分布式数据库事务一系列衍生问题。
　　可以说，在大型的企业内，具有高度一致性和复杂业务逻辑规则处理的业务系统，现有mysql自身的能力是存在差距的，其原因就是为了尽量的保证数据库的分布式和水平可扩展性带来了诸多新问题，这些新问题将急剧的加大应用层开发的复杂度，也带来传统架构下没有的一致性难以处理的问题。
　　在云架构下的数据库集中化要意识到，其本质是逻辑集中，即整个数据库通过DaaS层实现了公共的数据服务提供，而实际物理数据库仍然是分离的。那么在这种情况下对于DaaS层的要求相对高。包括我们说的SQL解析，异构数据库的语法层屏蔽，底层分布式事务的事务协调，都是新问题，解决不好整个数据库虽然可扩展了，但是性能、一致性、开发复杂度各方面都带来巨大挑战。很多时候我们在谈去IOP好像很简单，其实去任何一个内容都是需要进行各方面的权衡，最终做一个决策。
　　对于数据库层面，还有就是NoSQL数据库的使用问题，至少现在看来，企业内的业务系统本身能够迁移到完全的NoSQL数据库是不显示的。主要原因还是复杂的业务规则和一致性要求，开发的复杂度和成本，性能问题等。现在来看可以用NoSQL数据库的场景往往并不多，只有少量的业务功能和场景可以转换为Key-Value模式进行存储和解析，比如类似日志，文件等技术服务和组件，可以先开始考虑使用NoSQL数据库。对于简单的业务对象，包括对象本身简单，对象关系也简单，事务也简单场景可以超NoSQL数据库进行迁移。
　　再到存储层面，可以将基于HDFS分布式文件系统架构的分布式存储相当来说已经相当成熟，企业内的非结构化文件存储，文件的读取和访问完全可以统一到分布式文件存储架构上。基于Hadoop开源框架来构建分布式存储服务是完全可行的技术方案，但是要注意到对于分布式存储服务构建中仍然存在结构化的元数据，这些元数据的存储可以采用传统的结构化数据库，也可以采用NoSQL数据库。
　　综上所述，对于数据库和存储方面涉及到的技术主要包括如下方面内容： 分布式或伪分布式的数据库集群技术。
　　 数据库的水平拆分和垂直拆分，分布式事务处理技术
　　 DaaS数据库即服务层（包括连接池管理，分片路由，SQL解析等）
　　 NoSQL数据库和HDFS分布式文件系统
　　 应用托管和资源调度
　　对于中间件资源池的构建，可以说是企业私有云中APaaS的核心内容。具体的功能前面文章已经谈到过包括了自动部署、应用托管、应用虚拟化的中间件资源池，资源根据应用符合的动态调度等方面的内容。
　　对分布式调度有两种方案：
　　一种是基于传统虚拟机+高层负载均衡的调度模式，在该模式下需要解决的问题是负载均衡设备API的完全开放，能够通过程序来实现计算单元的挂接和卸载，而对于虚拟化本身的动态创建，安装，启动激活则属于传统的IaaS层需要考虑的问题。
　　第二种调度方案即基于容器技术实现的资源调度，类似当前主流的K8s+Docker来实现的中间件容器云。要明白调度单元越轻量则调度效率越高，但是各个调度单元之间的隔离性会很差。在这种调度策略下要解决的问题主要是各个调度单元的隔离，已有的CPU和内存资源在各个调度单元之间的分配而不出现资源抢占情况，中间件实例的自动创建，启动，程序部署包的自动部署等一系列问题。
　　不论是哪种调度策略和方案，APaaS里面都涉及到另外两个方面的内容，即管控平台和各个调度单元之间的消息通讯机制，现在各家的方案都需要依赖高效的消息中间件技术，一个是实现消息事件的快速传递，一个是实现各个单元之间的彻底解耦。第二个方面技术是对于各个调度单元的健康信息采集，这个采集通过SSH或其它底层API技术来实现不难，但是难的地方却是采集的高效性和性能。要实现高效调度，数据的采集频率会很高，如何保证采集程序本身性能和低能耗就必须考虑。
　　如果我们把数据库和中间件都实现了分布式部署，那么整个应用可以算得上是完全的分布式架构系统。
　　对于应用托管和资源调度主要涉及到的技术包括 高性能消息中间件技术
　　 高可靠和准实时的性能数据采集和分析
　　 调度规则和调度引擎技术
　　 逻辑资源应用容器技术，资源隔离技术
　　 负载均衡和软集群技术等
　　 ESB和集成中间件
　　在私有云架构下面，ESB集成中间件的作用更加重要，这里面要注意既包括了传统的消息中间件，也包括了数据集成中间件和服务集成中间件。ESB服务总线是整个私有云架构中的集成枢纽，是共享服务的提供中心。特别是在PaaS架构下强调数据库和中间件本身的集中化后，更加强调集中化后的共享数据服务和业务服务的提供，强调基于PaaS平台搭建的各个业务系统或业务组件间的及时消息传递等。
　　对于ESB核心包括了消息协议转换，路由，服务目录中心，服务监控，服务鉴权，消息发布订阅等一系列内容。基于组件化架构的思想，PaaS平台下要实现的是业务组件间的业务集成和协同，是实现集中化后数据的共享服务，而不是传统意义上的数据交换平台。
　　谈到ESB必须提到组件化架构思想，很多时候我们谈业务应用基于SOA架构思想，但实际上往往并没有按照SOA架构思想来构建应用。业务组件化，组件服务化，业务组件之间通过业务服务进行交互，服务可以组合，组装和编排来构建和实现完整的业务逻辑，这些就是最基本的SOA架构思想。
　　回归技术层面，ESB平台本身也需要考虑在大数据量和大并发量下的性能问题，也就是说作为PaaS基础能力组件的ESB平台本身也需要水平扩展和基于分布式架构。ESB架构下应用服务器可以在集群架构下完全水平扩展，而服务本身的无状态特性，又可以很方便的实现数据库的水平扩展和垂直切分。
　　还有业务集成和传统数据集成是完全两个层面的内容，ESB应用集成不是替代传统的基于ETL数据集成，而是两者相互结合。而在PaaS云架构下，如果真正可以实现数据库的集中化，往往已经没有再进行ETL数据转换和清洗的必要，至少ODS这层是当前大数据库就可以完全胜任的。而真正引入了分布式数据库和NoSQL数据库之后往往导致了ETL过程的复杂化，简单的ETL操作变化为了分布式的ETL操作。
　　对于ESB集成中间件涉及到技术包括： ESB企业服务总线（路由，适配，协议转换，鉴权，服务代理等）
　　 大数据和大文件集成技术
　　 EDA事件驱动架构和CEP复杂事件处理
　　 BPEL和BPM业务流程管理
　　 分布式事务和事务一致性
　　 底层建模技术
　　由于在谈PaaS的时候我们一直强调的就是能够集中考虑和建设的东西都尽量下沉和集中化。那么在集中化建设的过程中自然涉及到对原有组件模块的进一步抽象和封装集成。而这里最重要的还是权限模型、组织模型、工作流引擎模型等核心技术模型和抽象。也涉及到对于业务应用中的核心元数据模型的抽象。
　　对于业务系统数据建模的时候，可以看到需要进一步按面向对象的思想来进行建模，多借鉴MDA和领域驱动设计中领域模型的概念，只有做好了基础对象层的抽象和封装，才能给更好地提供领域层的对象服务。要明白上层应用更好的构建方式就是更加地关注对象和对象服务，而不是关注底层的数据库。而且由于传统的业务系统切分为多个业务组件后，更加需要一个公共的领域服务层，屏蔽底层细节。
　　对于底层建模涉及到的方法和技术包括： 面向对象的分析和设计方法
　　 MDA模型驱动架构和DDD领域驱动设计
　　 SOA参考架构和技术规范标准
　　 基于SOA的组件化架构设计方法和技术
　　 缓存、消息、日志、安全、规则引擎等相关技术