在这里简单谈下企业私有云paas平台所涉及到的核心技术内容。
数据库和存储
首先谈下数据库,首先要意识到数据库的集中包括了两个方面的内容,一个是数据库服务器硬件的集中化,一个是数据本身的集中化。对于类似oralce
rac集群数据库实现的是数据库硬件,软件和数据的全部集中,但是数据库集群算不上真正的分布式数据库。mysql
cluster集群可以算作分布式数据库,可以实现数据的水平shading功能,但是cluster集群本身在大数据量和大并发下,对于复杂业务逻辑操作存在性能瓶颈,这是不可回避的事实,在cluster集群配合读写分离集群共同使用的时候又出现了数据存储分布的问题。数据物理存储的分布又导致了底层数据库数据日志同步,分布式数据库事务一系列衍生问题。
可以说对于大型的企业内,具有高度一致性和复杂业务逻辑规则处理的业务系统,现在mysql本身的胜任能力是存在差距的,其原因就是为了尽量的保证数据库的分布式和水平可扩展性带来了诸多新问题,这些新问题将急剧的加大应用层开发的复杂度,也带来传统架构下没有的一致性难以处理问题。
在云架构下的数据库集中化要意识到,其本质是逻辑集中,即整个数据库通过DAAS层实现了公共的数据服务提供,而实际物理数据库仍然是分离的。那么在这种情况下对于DAAS层的要求相对高。包括我们说的sql解析,异构数据库的语法层屏蔽,底层分布式事务的事务协调,都是新问题,解决不好整个数据库虽然可扩展了,但是性能,一致性,开发复杂度各方面都带来巨大挑战。很多时候我们在谈去IOP好像很简单,其实去任何一个内容都是需要进行各方面的权衡,最终做一个决策。
对于数据库层面,还有就是nosql数据库的使用问题,至少现在看来,企业内的业务系统本身能够迁移到完全的nosql数据库是不显示的。主要原因还是复杂的业务规则和一致性要求,开发的复杂度和成本,性能问题等。现在来看可以用nosql数据库的场景往往并不多,只有少量的业务功能和场景可以转换为key-value模式进行存储和解析,比如类似日志,文件等技术服务和组件,可以先开始考虑使用nosql数据库。对于简单的业务对象,包括对象本身简单,对象关系也简单,事务也简单场景可以超nosql数据库进行迁移。
再到存储层面,可以将基于hdfs分布式文件系统架构的分布式存储相当来说已经相当成熟,企业内的非结构化文件存储,文件的读取和访问完全可以统一到分布式文件存储架构上。基于hadoop开源框架来构建分布式存储服务是完全可行的技术方案,但是要注意到对于分布式存储服务构建中仍然存在结构化的元数据,这些元数据的存储可以采用传统的结构化数据库,也可以采用nosql数据库。
中间件资源池和资源调度
对于中间件资源池的构建,可以说是企业私有云中apaas的核心内容。具体的功能前面文章已经谈到过包括了自动部署,应用托管,应用虚拟化的中间件资源池,资源根据应用符合的动态调度等方面的内容。
对分布式调度有两种方案,一种是基于传统虚拟机+高层负载均衡的调度模式,在该模式下需要解决的问题是负载均衡设备API的完全开放,能够通过程序来实现计算单元的挂接和卸载,而对于虚拟化本身的动态创建,安装,启动激活则属于传统的iaas层需要考虑的问题。
第二种调度方案即我们说的应用虚拟化,调度的单元为各个轻量的中间件容器,这个容器可以是应用服务器中间件容器,也可以是更加轻量的web容器,要明白调度单元越轻量则调度效率越高,但是各个调度单元之间的隔离性会很差。在这种调度策略下要解决的问题主要是各个调度单元的隔离,已有的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操作。
底层建模技术
由于在谈paas的时候我们一直强调的就是能够集中考虑和建设的东西都尽量下沉和集中化。那么在集中化建设的过程中自然涉及到对原有组件模块的进一步抽象和封装集成。而这里最重要的还是权限模型,组织模型,工作流引擎模型等核心技术模型和抽象。也涉及到对于业务应用中的核心元数据模型的抽象。
对于业务系统数据建模的时候,可以看到需要进一步按面向对象的思想来进行建模,多借鉴MDA和领域驱动设计中领域模型的概念,只有做好了基础对象层的抽象和封装,才能给更好的提供领域层的对象服务。要明白上层应用更好的构建方式就是更加的关注对象和对象服务,而不是关注底层的数据库。而且由于传统的业务系统切分为多个业务组件后,更加需要一个公共的领域服务层,屏蔽底层细节。
青春就应该这样绽放 游戏测试:三国时期谁是你最好的兄弟!! 你不得不信的星座秘密