精华内容
下载资源
问答
  • 复杂的企业应用系统都会基于一些平台来开发和运行。这些平台软件主要提供一些各个应用系统共同需要的功能,如用于数据传输...企业应用开发者基于平台开发企业应用系统,可以专注于企业业务逻辑的实现,其他公共的功能
     复杂的企业应用系统都会基于一些平台来开发和运行。这些平台软件主要提供一些各个应用系统共同需要的功能,如用于数据传输的消息中间件,用于远程数据交互,方法调用的各种组件技术,用于数据存储和访问的数据库,做规则推理的规则引擎,做数据展现的图表工具,做流程编排的流程工具等等。这些工具彼此配合构成一个完整的企业应用平台。企业应用开发者基于平台开发企业应用系统,可以专注于企业业务逻辑的实现,其他公共的功能由平台提供。
    

    我按现在SOA的思想来绘制企业应用平台软件结构层次图,然后再和EAI平台,应用服务器来对应。

     

     

    <?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

    企业应用平台软件结构层次图

     

    企业应用平台软件一般都包括设计时编排配置工具和运行时引擎。

    2.1  服务总线

    服务总线包含用于底层数据传输的消息中间件。具备一定的功能,对外提供接口的功能单元称作服务,不同类别的服务会运行在服务总线上的不同容器内。容器在消息中间件基础上支持远程数据交互,方法调用,支持异构接口和系统间数据格式的转换。基于这些服务可以编排实现逻辑流程来完成更复杂的功能。

    服务的实现方式可以有多种:

    (a)     程序语言Java, C++等。

    (b)     已有的组件技术EJB,CORBA,COM.

    (c)     调用已有软件,或者系统的功能。

    (d)     基于已有服务编排更复杂的服务。

    一般EAI平台的功能和服务总线的功能对应。EAI平台提供各种技术适配器,产品和系统适配器封装已有技术,产品和系统的功能为基础的服务,也支持用程序语言实现一些功能单元。通过EAI流程编排工具可以把这些基础的服务功能单元编排为复杂的流程。

    J2EE应用服务器里的EJB容器,提供对EJB组件的支持。对应于服务总线上的一种类别的服务容器。事实上服务总线是个集成组件技术的平台,也可以称作组件容器的容器。现在应用服务器的功能越来越多,支持Web Service组件技术,加入符合JCA规范的集成工具等等。在功能上也更加靠近服务总线。

    服务总线是分布式的服务平台,之上的服务都是可以分布部署运行的。EAI平台有分布式的(如TIBCOEAI平台),也有集中式的。J2EE应用服务器一般都是集中式的。从系统的扩展性,可靠性,性能等方面讲,分布式系统都更有优势。

    所有这些平台都提供流程编排和驱动工具,提供图形化的流程编排方式,基于服务功能单元编排逻辑流程,把这些对数据做传输交互,内容格式转换,计算处理的操作串起来,组合成更复杂的操作,提供粒度更大的功能。这种流程编排支持选择,循环,调用子流程等逻辑流程功能,支持用于做服务功能单元之间数据内容映射的功能。流程编排语言的语法定义也类似于过程程序语言的语法定义,但一般都比程序语言简单,没有面向对象语言的特点,不支持泛型,虚函数等功能,没法实现很好的功能封装和复用。数据内容映射和转换语言也是如此。所以一般使用流程编排和驱动工具,适合在已有功能单元的基础上编排实现不很复杂的逻辑流程。如果业务本身很复杂,流程分支多,对象变量多,子流程多,彼此关系复杂,这种情况下最好使用其他实现方式来实现这些业务,而不是使用流程编排工具以图形化的方式来开发这些业务。

    使用服务总线平台开发应用,根据不同的情况选择不同的服务实现方式:

    (a)      调用已有技术实现的功能,已有软件或者系统的功能,可以使用适配器作用的服务。

    (b)     如果是复杂的数据计算处理,最好使用程序语言来实现,选择程序语言的服务开发方式。

    (c)      如果需要做规则推理,又不想自己实现规则推理逻辑的话,可以使用规则引擎,自己只需要定义规则。

    (d)     基于已有服务的不很复杂的流程,可以使用流程编排语言来实现,当然是图形化的方式。

    从上面的分析说明,可以看到服务总线做了数据传输交互,数据格式转换,连接已有系统等技术层面的工作;应用开发者要做的是数据计算处理,规则定义,逻辑流程编排等业务逻辑的实现。

     

    2.2 业务流程管理

    业务流程管理在设计时层面更靠近业务开发人员,提供业务层面的流程编排,企业组织结构的建模;在运行时增加人机交互,提供工作流审批的功能。业务流程管理工具可以调用服务总线上的自动流程服务和其他各类服务。

     

    2.3 数据展现和用户界面

    数据结果展现可以是各类图形,报表,用户界面可以使用胖客户端或者浏览器。对于一个包含很多应用系统的企业,门户为这些系统提供一个统一的入口。

     

    2.4 事件处理和业务活动监测

    企业应用系统中数据流可以分为业务数据流和监测控制流。 事件是应用系统的监测和控制数据,各个层面的系统状态信息,操作记录都可视为事件。事件之间有时间和因果的联系。状态模式诊断,故障原因推理,控制动作决策这样的场景都会使用事件处理机制。基于具体业务数据的业务活动监测需要用到事件处理,而事件处理一般都基于规则引擎来做事件推理和判断。

     

    2.5 规则引擎

    在数据计算处理范畴,有一种处理模式区别于普通的过程式处理。对于待处理的对象,有很多的处理规则,即满足什么条件做什么动作。程序需要持续匹配对象状态确定需要做什么操作。而这些规则在系统运行时会经常由业务人员改变,所以规则引擎就应需而生,作为规则的解释执行虚拟机,分割了规则推理操作和规则本身。规则可以由业务人员编写,由规则引擎解释运行。

     

    2.6 商业智能

    商业智能对历史数据进行分析统计挖掘,发现数据中的模式和规律,为商业活动提供行为决策。对比实时性很强的事件处理,商业智能平台偏重的是海量历史数据的挖掘处理。

     

    2.7 基础工具产品

    平台的基础工具产品包括:

    (a)     部署管理工具。用于应用工程的打包部署,应用系统内机器,软件,部署实例的管理。

    (b)     策略控制。用于服务功能基本单元的管理,服务访问的安全控制。

    (c)     平台监测控制。用于运行时平台各个软件实例的状态监测,软件运行出错时的处理,宕机时的自动重启等等。

    展开全文
  • 互联网+时代的企业应用集成平台

    千次阅读 2017-11-28 12:51:21
    在互联网+时代,企业中的业务人员将面临比以往更加复杂的信息化环境,不仅仅是以往经常使用的那些业务系统,还包括部署在云端的应用系统,与各种设备和货物关联的物联网,更加贴近客户的移动和社交网络等等。...


    在互联网+时代,企业中的业务人员将面临比以往更加复杂的信息化环境,不仅仅是以往经常使用的那些业务系统,还包括部署在云端的应用系统,与各种设备和货物关联的物联网,更加贴近客户的移动和社交网络等等。

    如何帮助业务人员应对这种复杂的环境,并从中获得业务收益,是当前的企业IT部门所面临的重要挑战。在以往仅面对本地化信息平台时,通过应用集成平台实现整合的业务信息化平台来实现业务创新的方式,在当前的互联网+时代同样适用。

    应用系统的整合和集成其实已经不是一个新话题,我早在2003年就接触过这个话题,不过在那个时候,更多的还是在进行系统之间的点对点对接,已解决数据传输的问题。但是现在,我们更多的是将应用系统的整合与集成架构成为一个完整的平台。Gartner就曾经提出过一种步进式的应用策略,来构建这样一个平台,并通过该平台实现业务的创新。

    该策略的基本思想是,业务应用系统作为实现业务运作的主体,需要保持稳定,尽量不进行修改(业务记录系统层);业务系统之间的协作与集成会根据用户的需求的不同而发生变化,可以将这部分抽取到一个专门的体系当中,既可以实现协作与集成,从而实现业务的差异化,也可以将这部分从系统中剥离出来,保持底层业务系统的稳定(业务差异化系统层);基于差异化系统层中所产生的IT资产,进行创新应用的扩展,实现业务的创新(业务创新系统层)。

    我们这里所讲的企业应用集成平台,就是要实现业务差异化系统层和业务创新系统层,以此实现企业业务的创新。

    上图是步进式应用策略的分层模型示例:

    • 业务记录系统是企业使用的各类业务系统,包括本地应用和云应用
    • 业务差异化系统是企业各系统之间的交互流程、集成流程、数据流程
    • 业务创新系统是扩展的各类互联网应用、移动化应用、云应用、大数据应用等

    一个企业应用集成平台,通常包括这样几个逻辑层次:

    • 主数据层:构建标准化数据平台,实现标准化数据的管理与共享,是形成整合的信息化平台的基础。
    • 数据集成层:构建整合的数据平台,实现数据的采集与整理,包括数据仓库和大数据平台,是实现决策支持平台的基础
    • 应用集成层:构建标准化的服务平台,关联并打通各个业务应用,实现业务应用之间的相互协作,是实现平台敏捷扩展和创新的基础
    • 流程集成层:梳理企业的业务运营流程,形成敏捷化、标准化、可视化的业务流程平台,使整个企业的业务进行规范化运营,并为未来的业务优化打下基础。
    • 门户集成层:为业务人员建立跨部门、跨系统、跨渠道的统一工作平台,为业务人员提供更优秀的工作体验和信息共享能力

    上面的各个逻辑层次最终会有一个统一的运维管控平台和安全管理平台进行全面的管理。

    上图就是企业应用集成平台的整体逻辑架构。

    在互联网+时代的企业应用集成平台,虽然在逻辑架构上与本地化平台没有多大的差异,但是在技术实现上还是有很多需要注意的点:

    • 安全:众多位于企业外部的基于互联网的应用,包括云应用、社交网络、移动应用、物联网等,需要纳入到应用集成的范围当中,因此将会面临比单纯的内部网络更复杂的安全问题,包括网络安全、数据安全、应用的安全等
    • 部署问题:因为需要面对来自互联网的需求,因此集成平台的部署将不会只局限于企业内部,也可以部署到公有云端。因为大多数企业的应用场景都比较复杂,各类要求也不同,因此会更多的采用混合部署模式,兼顾公有云和本地部署的方式
    • 去中心化:在互联网、云平台流行的时代,数据总线、流程平台等将会是一个逻辑概念,原有的集中式部署的平台将不会再是唯一的选择,很多采用分布式技术构建的平台,将能够更好的适应互联网的需求,比如在高峰期进行灵活的扩展。不过,同时分布式平台也会带来管理和维护上的复杂性,用户可以根据自己的实际需求进行选择。
    • 整体管控:环境变的更加复杂,所以对于管控的要求也就更高,因为大多数企业用户都是非IT行业用户,对于其所有的运维人员,以一套方便易用、功能全面的管控平台也是非常重要的。


     

    展开全文
  • 仿佛PaaS平台及其相关技术一下进入了黄金时期,各种各样的技术组合,各种各样的技术验证,以及伴随着容器相关的创业公司布道,仿佛只要有了PaaS平台及其相关的技术,就能解决一切的企业IT问题。但是,企业IT,尤其...
    文/ 天云软件 技术总监 牛继宾
    

    伴随着Docker技术的兴起,以及容器集群管理平台Mesos、Kubernetes、Swarm、Rancher等的大行其道,仿佛PaaS平台及其相关技术一下进入了黄金时期,各种各样的技术组合,各种各样的技术验证,以及伴随着容器相关的创业公司布道,仿佛只要有了PaaS平台及其相关的技术,就能解决一切的企业IT问题。但是,企业IT,尤其是非互联网传统企业,PaaS平台的构建与业务上云是一个长期的过程,绝不是一个Docker+kubernetes/Mesos/Swarm构建完以后就能完成的,IaaS年代是这样,PaaS年代也是这样。

    在互联网公司或者自研发型的应用,开发环境与部署运行环境非常的类似,这也是Docker或者容器相关技术在应用上的一个很大的优势(比如构建开发、测试、部署的DevOps流水线),但是在传统企业便不一定能行得通,比如某个企业的IT应用开发维护是外包的,标准软件需要采购、应用开发需要在应用开发商完成、硬件是另外的硬件提供商,到货后需要硬件系统集成、标准软件部署、应用开发部署调试,需要很多供货商来完成,往往以项目经理统筹完成,很难由一套DevOps之类的平台来解决所有问题。

    那么传统企业PaaS平台设计需要什么样的功能?上云时又需要进行如何改造?这是本文探讨的重点。

    一、传统企业的应用架构与应用分类

    屏幕快照 2016-06-16 上午9.53.36

    大家对这种架构耳熟能详,但也请做云计算或者容器技术的同事不要对这种架构嗤之以鼻,因为这种架构也包含很多对我们有学习借鉴意义的技术模块:

    • 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所谓的批处理不是一个概念,也不在一个层级。这种应用我们暂时不考虑。

    屏幕快照 2016-06-16 上午9.54.00

    OLTP,也叫联机事务处理(Online Transaction Processing)系统,表示事务性非常高的系统,一般都是高可用的在线系统,评估其系统的时候,一般看其每秒执行的Transaction以及Execute SQL的数量。典型的OLTP系统有客户关系管理系统、电子商务系统、银行、证券等。

    要求:一致性、高可用性。

    OLAP,也叫联机分析处理(Online Analytical Processing)系统,有的时候也叫决策支持系统,就是我们说的数据仓库。在这样的系统中,语句的执行量不是考核标准,因为一条语句的执行时间可能会非常长,读取的数据也非常多。所以,在这样的系统中,考核的标准往往是磁盘子系统的吞吐量(带宽),如能达到多少MB/s的流量。

    下面我们分别分析一下这两类应用的云化需求与云化的分析。

    注意:这些要求分析与要求是在Docker与各类容器管理平台火起来之前总结与做的,不是依据Docker或者容器相关技术的要求做的。所以,对我们跳出容器的惯性思维,构建一个适合传统企业的PaaS云平台有很强的指导意义。

    二、传统企业的应用云化改造需求

    (一)OLTP类应用云化的要求

    屏幕快照 2016-06-16 上午9.54.16

    云化关键点1:系统弹性伸缩

    通过应用与数据分离和集群化部署,实现系统快速扩容、处理能力灵活水平线性扩展、故障自动隔离。对于独立的应用主机可以进行灵活弹性伸缩。

    屏幕快照 2016-06-16 上午9.54.36

    弹性伸缩特点:

    1. 在线快速扩容:系统扩容操作低耗时、无数据迁移、服务不间断;
    2. 处理能力线性扩展:系统处理能力可以通过新增节点近线性提升,实现高吞吐、高并发处理能力,应对业务爆发式增长;
    3. 故障自动接管:集群可以自动发现故障节点并调整任务调度策略,在不影响处理的同时接管故障节点,保持系统高可用。

    云化关键点2:应用集群化部署

    将紧密耦合的大应用模块化拆分为多个模块化小应用,通过资源池提供系统资源的整体利用率,并将拆分后的子模块部署于资源池(后来我们搞Docker的称之为微服务化)。当硬件资源实施池化后,才具备了支撑应用的弹性伸缩,实现硬件的按需分配的基本需求,充分提高资源利用率。

    云化关键点3:通过数据分级分类实现应用与数据分离

    根据数据实时性、重要性、敏感性等因素,将数据分成数个级别,各个级别的数据对系统的作用、采用存储、保护方式也都有所不同。

    屏幕快照 2016-06-16 上午9.54.54

    通过对应用提供数据的透明访问,屏蔽数据的位置差异、数据分布差异、数据存储等差异:

    1. 位置无关性:数据在远程还是本地存储,对应用最好透明。
    2. 分布无关性:数据分布在多个数据节点,对应用透明。比如查询某个客户的所有相关数据,虽然同一个用户信息分布在多个数据节点上,但对应用来说就好像一个集中数据库进行查询。
    3. 存储无关性:数据存储在内存库、物理库(关系型数据库、NoSQL数据库)、File还是缓存等介质,对应用透明。

    云化关键点4:合理规划实现数据分布式部署

    对不同业务的数据、不同类型的数据进行有效规划部署。通过某种特定的条件,将存放在同一个数据库中的数据分散存放到多个数据库上,实现数据分布存储,通过路由规则路由访问特定的数据库。

    数据库拆分方式包括:

    • 垂直(纵向)拆分:将数据库表按业务、功能拆分到不同的数据库表,比如分为客户资料库、订单库、资源库、资料库等,这种方式多个数据库之间的表结构不同;目的是降低业务之间的影响,减少系统承载压力。
    • 水平(横向)拆分:将同一个表的数据进行分块保存到不同的数据表中,这些数据库中的表结构完全相同。

    拆分以后,带来的问题,需要做到:对外提供统一访问,对应用屏蔽数据访问复杂度。数据访问层提供数据互访能力,拆分访问合并返回。

    所以需要构建统一数据访问引擎,或者数据路由层(Data layer层)。开源的比如有Hibernate Shards、Ibatis-Sharding、淘宝TDDL等。

    云化关键点5:数据平台化

    数据平台化是指通过应用架构和数据架构的重新梳理、规划与调整,将业务处理中的业务数据和状态数据与应用分离,实现应用的轻量化、无状态;构建统一的数据访问层,实现数据的共享访问。数据平台化是数据处理水平线性扩展的前提和基础。

    数据平台化特点:

    • 应用轻量化:缩短开发周期,提升新业务响应速度;
    • 应用无状态:实现应用的同质化,应用层处理能力的独立扩展,实现应用灵活调度和分配;
    • 数据共享访问:逐步实现数据集中访问,跨地市的流量共享、流量统付、流量转移业务能够更高效支撑。

    (二)OLAP型应用云化的需求

    首先看一下传统的数据仓库典型架构:

    屏幕快照 2016-06-16 上午9.55.11

    这种架构以处理结构化数据为主,基本部署于Oracle、小型机、SAN存储之上,扩展性不足,难以处理海量数据。大数据处理技术的兴起让这类应用的云化找到了思路。云化时总体推荐混搭架构,即采用多种技术架构建设大数据中心:

    1. 垂直混搭架构:

    屏幕快照 2016-06-16 上午9.55.23

    这种架构比较容易部署,但会形成多个相互独立的信息孤岛;未来缺乏可行的系统演进路;

    2. 水平混搭架构:

    屏幕快照 2016-06-16 上午9.55.37

    • 企业级数据云平台:逐渐实现企业内数据的统一存储,承载数据的加工计算;未来提供企业数据的统一存储和计算能力;
    • 数据仓库、集市和挖掘库:计算逐渐迁移到云平台实现轻载化;直接从云平台加载应用结果数据,实现上层应用的兼容性;
    • 流处理平台:实时计算结果存储到云数据平台,可通过能力开放平台的消息中间件直接供应用访问。

    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数据库。

    数据云平台完成所有的后台计算。

    屏幕快照 2016-06-16 上午9.55.50

    OLAP云化关键点3:数据ETL云化建设

    • 传输的实时化:支持MQ等分布式实时消息传输机制;
    • 基于内存的计算:数据不落地,避免海量数据的两次重复加载;
    • 计算的轻量化:清单级的过滤、排重、规则化,更多的计算任务由大数据存储和计算平台来完成;
    • 分布式并行执行:高可用性、分布式调度、资源分配;
    • 技术实现:Kafka+HDFS+MR/Spark。

    屏幕快照 2016-06-16 上午9.56.06

    三、基于容器的PaaS平台架构的构建

    我们提到了传统企业中两类核心的应用,并且在Docker流行之前便规划了一些云化的关键点,并形成了PaaS平台,使之运行于IaaS平台与Hadoop YARN集群之上。

    屏幕快照 2016-06-16 上午9.56.18

    基于此架构有以下几个主要问题:

    1. 可以实现应用编排与部署,但是编排的基础单元是虚拟机模板,模板比较重,而且镜像很难修改,编排、分发、运行、持续集成等都有很大的困难,因此构建在模板上的应用形成的服务很难用;
    2. 基于虚拟机的弹性伸缩相应时间也比较慢,我们尝试做过基于Cloudwatch+Autoscaling的虚拟机弹性伸缩功能,发现弹性伸缩对业务的响应时间有一个偏差,这个偏差大约在十几分钟,在抢购、秒杀等业务中基本不可接受;
    3. 很难在企业内部形成一个统一的私有云集群来同时运行这两类业务,因此两个PAAS集群实际上是两个独立的集群,都是按照业务最高峰配置,存在资源浪费的现象,运维也是分开运维。

    Docker及其相关技术兴起之后,我们基于容器的相关生态圈技术,构建了新一代PaaS平台。

    屏幕快照 2016-06-16 上午9.56.37

    使用容器+容器镜像管理替代服务目录管理+虚拟机模板管理。

    在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层有两种调度模式:

    1. Mesos粗粒度,这种模式下,一旦一台机器(一个Node)分配给某个框架,其他框架便不能使用;
    2. Mesos细粒度,这种模式下,多个框架可以共享一台机器(一个Node)。

    粗粒度存在资源还是不能完全共享的问题,因此仍然有资源浪费的问题,细粒度模式可以改变这种问题,但是又带来新的问题:

    1. Mesos集群运行多种框架,包括Spark,也运行着很多Web、中间件、数据库等服务,但是Mesos不支持抢占,无法设置任务优先级,而Spark默认是贪婪模式,这样就会出现Spark运行时无法发布其他Web任务到Mesos集群上的情况。
    2. Hadoop与Spark在运行时,Shuffle阶段数据会交互写HDFS磁盘,这时网络资源会被大量占用(我们称之为东西向流量),导致Web服务基本不能响应(我们称之为南北向流量)。

    (二)多租户的问题

    目前多个框架之间每个都有自己的用户管理模式,默认情况下,如果多个框架之间有交叉使用,需要在多个框架之间租户互相打通,涉及到Mesos、Hadoop、Kubernetes的账号打通问题,需要开发独立的账户中心,并且完成同步。

    最后讨论一下应用上云时的考虑点,并给出一个例子:

    1. 应用最好无状态,无状态化的应用天生适合上云。这时服务的注册于发现、应用的弹性伸缩完全交给云平台来做,比如Mesos+Marathon的HAProxy+etcd+Confd或者Kubernetes8s的service+RC;
    2. 已经集群化的应用组件部署相对困难,比如基于PaaS平台发布单个实例的Redis容器,但是发布Redis集群就比较困难,苦难就困难在Redis集群中的节点需要相互通信,而容器如果重启或者IP发生变化都会对集群造成影响;
    3. 服务注册与发现如果应用本身提供了,PaaS平台的服务注册与发现功能便不能使用,不能两套服务注册与发现同时使用。

    这里给出一个应用上云部署的例子:

    屏幕快照 2016-06-16 上午9.56.53

    上图左边是某传统企业电商应用最初架构,Web部署于一台高配置x86服务器、APP部署于一台中端小型机、DB部署于一台中端小型机,右边是初步进行了改造后的架构,即迁移到PaaS平台之前应用已经做了模块化与集群化的初步改造:

    1. 前台用负载均衡将流量引入到三个Web节点中,每个Web节点部署于x86服务器,Session集中存在Redis集群(无状态化改造,交互用HTTP+JSON短连接);
    2. APP层也通过Redis集中存放状态信息,做到了无状态化,每个APP节点部署于三台x86服务器;
    3. Web与APP在流量大的时候可以做到手动扩容,但是需要配置固定的IP,APP服务(提供给)的注册发现是基于ZooKeeper完成(应用自己来完成服务注册于发现);
    4. DB层做了主从数据库,部署与x86服务器。

    该应用里面还用到了Kafka,用来做数据总线,也采取了集群化部署。

    屏幕快照 2016-06-16 上午9.57.06

    针对目前的现状,如上图,应用迁移到PaaS平台需要做三方面的工作:

    1. 完成Web层的服务注册与发现,在此基础上实现web层的自动扩缩容,此处基于Kubernetes的ingress service(一个改造后的Nginx,运行在一个Kubernetes的POD里面)实现软负载+RC控制节点伸缩实现(每个Web部署于一个pod);
    2. APP层的自动扩缩容,由于已经完成了基于ZooKeeper的服务注册于发现,所以只需APP层能够弹性伸缩部署即可;此处基于RC控制节点伸缩实现;
    3. DB层由于运行稳定,暂时不做PaaS化但是,基于访问路由做到分布式部署。

    剩余一个问题需要探讨,Redis集群、ZooKeeper集群、Kafka集群(用作消息总线)要不要做PaaS化?如何做?

    首先回答一个问题,Redis、Zookeeper、Kafka等集群PaaS化(容器化)的难点在哪儿?

    主要是这些集群节点之间的互相通信与数据传输即东西向流量,要求这些节点之间的IP配置需要固定IP,而且重新启动以后相应的配置信息不能改变。容器自身的启动、网络配置比较动态化,对需要固定的集群配置而言是一个挑战。

    比如大多数的PaaS平台提供单个实例的Redis缓存服务不是问题,但是提供任意配置的Redis集群便不支持。我们经过前期的测试,实现了容器平台下的此类应用的集群化部署,以ZooKeeper为例:

    屏幕快照 2016-06-16 上午9.57.22

    ZooKeeper自身部署要求:

    1. ZooKeeper client依赖固定ZooKeeper server IP来完成服务;
    2. ZooKeeper server配置(所有成员IP必须固定);
    3. 至少3个独立节点;

    解决方案(基于Kubernetes):

    1. Client通过固定3个service IP连接ZooKeeper server;
    2. 构建3个单POD的RC;
    3. 配置DeamonSet,指定ZooKeeper的POD所启动运行的主机;
    4. ZooKeeper自身配置使用Service DNS name;
    5. 存储进行持久化。

    最后,需要说明的是,应用上云后一个很重要因素,PaaS平台(Docker为基础的构建),稳定性与可靠性也是至关重要的,我们在部署迁移应用时,每次都会针对应用做较为详细的测试,测试案例包括:

    • 无负载的POD并发测试;
    • 频繁创建带业务的POD及其稳定性;
    • 业务的并发性测试;
    • 不同业务的IO并发性能测试;
    • 容器间网络性能测试;
    • 几类常见的数据库性能测试;
    • Nginx集群性能测试;
    • Kubernetes Rc机制测试;
    • Docker对MEM资源限制能力的测试;
    • Docker对进程数量限制能力的测试;

    等等。这些测试方面供大家参考,具体测试方法与步骤可针对应用自行设计,不在这里具体分享。

    Q&A

    Q:在你的新一代PaaS平台中,我怎么对公司的很多个不同的应用做不同的集群,有些集群偏向于大量的IO占用,有些集群偏向于大量的网络占用,有些集群偏向于大量的内存占用,并且启用的集群间还有通信和交互,针对这些不均衡现象该如何处理?

    A:所以PaaS平台硬件资源会针对不同应用去做区分,在企业私有云建设时,需要对应用进行梳理,将不同的应用分类,底层采取相应集群支撑,比如计算密集型、IO密集型等,同时综合考虑波峰波谷与业务特性进行配置。

    Q:公司有很多Web系统,每一个Web系统都有自己的存储、数据库,所以如果融入PaaS平台的话,首先第一点软硬件问题如何做到全部满足,其次就是就算把我的DB层整合迁徙到你的PaaS的DB层,我是不是还要做其它方面的投入,比如开发成本等等,还有就是DB的兼容性是不是会有问题?

    A:Web层我们推荐做无状态化,且要做应用与数据分离,session信息集中存放。DB迁移到PaaS层是一个比较慎重的过程,PaaS层优先考虑开源数据库。如果原先是MySQL基于PaaS平台也提供的MySQL数据库服务,那么开发成本基本比较小,只需考虑版本问题。

    Q:请问MySQL部署数据应用能承载多大数据量,响应速度如何?

    A:我们一个项目中,采用读写分离的MySQL架构,几千万的数据表,及时查询没问题,这也要看硬件配置与数据索引的建立等。

    Q:有些传统公司,有些软件设备是以序列号安装使用的,所以这一块融入PaaS平台是不是不太可能?

    A:比较困难,另外还有一个问题是License限制的问题,在弹性架构中也比较难。

    Q:请问架构改造会不会导致应用要重新开发?

    A:会,从IOE架构到x86架构,从x86物理机到虚拟机到Docker,应用需要以越来越小的模块化分布式部署,也就是说逐步向微服务化过渡。

    Q:为什么Kubernetes和Mesos要一起用呢,考虑点在哪里?

    A:针对单个应用Docker化,我们开始的选型定位在Kubernetes,主要考虑了POD的应用场景更类似虚拟机,另外Kubernetes的模块比较丰富,像负载均衡、服务发现等已经成熟,后来用Mesos是因为需要把大数据之类的应用进行整合。需要Kubernetes/Spark on Mesos。

    Q:开发周期过长或者客户开发能力弱会导致整个架构流产 有配套的应用改造方案吗?

    A:对传统企业而言,一开始就搭建一个大而全PaaS方案是不现实的,我们推荐从某一个典型应用做起。我们针对交易性应用、分布式应用、批处理应用等应用都有配套改造方案。

    Q:Mesos使用集中式存储和分布式存储效率上有什么不同吗?

    A:这个看应用,集中式存储在集群中应用时,如果针对单一与应用划分Volume,性能会好一些,如果是分布式应用,比如MR类的应用,分布式存储反而会好。

    Q:容器弹性伸缩策略具体怎么考虑的,CPU?

    A:CPU、内存、IO、用户连接数等都可以作为弹性伸缩的策略依据。

    展开全文
  • 认识ES2007平台 CHARISMA平台,是一款企业应用的快速开发平台。利用它,企业及开发商均可以非常方便、快速、高质量地开发复杂的业务系统,包括OA、CRM、EAI、MIS、ERP、电子政务平台、信息资源管理系统、网上直报...

    认识方正平台

            方正平台,是一款企业级应用的快速开发平台。利用它,企业及开发商均可以非常方便、快速、高质量地开发复杂的业务系统,包括OACRMEAIMISERP、电子政务平台、信息资源管理系统、网上直报、多级上报等系统。
      方正平台内集成了在线自定义WEB报表引擎和在线定制流程引擎。利用在线自定义WEB报表引擎,用户可以集成企业内分散的业务数据,制作各类复杂的WEB报表;利用在线定制流程引擎提供的可视化流程设计,用户不需编码即实现流程相关开发,并支持区域配置和个性化设置,配置灵活。
      利用方正平台的开发功能及自定义WEB报表功能,可以非常轻松实现多级数据上报。
      方正平台采用业界领先的J2EE技术构建,采用MVC设定模式,B/S的多层结构,技术上相当领先。
    方正平台适合哪些客户
      方正平台即适合于最终客户,也适合开发商。
      1) 最终客户自主开发业务系统
      如果最终用户有一定的开发能力,可以自己分析业务需求,那么完全可以利用方正平台快速、自主地开发业务系统。
      2) 最终客户进行数据整合,制作综合查询、分析系统
      对于政府机关、大的企业集团,在信息化建设过程中,会产生多个数据库,面对分散的数据,领导很难进行决策分析。利用方正平台可以将这些数据库集成起来,方便从这些数据库中抽取数据,制作各类WEB报表,供领导分析决策。
      3) 最终客户实现多级数据上报、汇总
      在政府机关及企业集团的日常工作中,下级单位需要定期向上级逐级申报业务数据,并进行分级数据汇总,制作各类WEB报表。利用方正平台可以非常轻松实现这种需求。
      4) 开发商基于方正平台开发项目
      对于开发商而言,可以将整个项目基于方正平台上开发,降低开发成本及维护成本。特别是对于以前使用PBVBDELPHI的开发商,想快速转型到基于J2EE开发WEB应用上来,尤其适合。
      5) 开发商集成方正报表
      开发商可以将方正报表引擎集成到项目中,作为系统中综合查询、统计及WEB报表的解决方案。
    方正平台的开发模式
      应用方正平台进行业务开发,与传统的编码式开发不同,而是基于引擎模式开发的。
      基于引擎模式开发,就是开发业务系统时,不编写也不产生源代码,只需通过WEB页面进行参数定制即可。这些参数存放在系统数据库中,系统运行时,由引擎调用这些参数进行页面展现及业务处理。
      应用方正平台开发业务系统,80%以上的模块均不用编写代码,通过WEB定制即可。
      对于比较复杂的业务模块,可以结合编码方式实现,因为方正平台是完全开发的平台,可以应用一切JAVA技术及组件对其功能进行扩充。
      开发复杂业务逻辑时,可以应用方正平台提供的强大、灵活的API
    为什么利用方正平台可以快速开发
    平台提供了先进的体系框架,及安全、稳定、高效的运行环境,即提供了系统级的模块;
    提供了完善的系统管理功能,包括多级组织机构管理、用户管理、基于角色的任意细粒度的权限管理、日志管理等;
    通过自定义WEB报表引擎,可以零编码、方便、快速地实现业务系统里的所有查询、统计及报表模块;
    通过数据维护引擎,可以方便地实现业务系统里所有增删改功能,包括批量、组合,并可以实现复杂的业务逻辑;
    通过MVC业务控制引擎,可以免编码实现大部分业务逻辑;
    通过自定义表单引擎,可以实现那些要求输入特殊参数的页面定制,结合MVC业务控制引擎,可以实现很复杂的业务逻辑。
    对于特别复杂的业务逻辑,可以通过平台提供的大量接口方便实现。
    利用方正平台开发业务系统的好处
    可以方便、快速地开发业务系统,80%以上模块不需要编写代码,甚至零编码,开发周期只需传统模式的10%--30%,降低开发成本。
    内建自定义WEB报表引擎,系统上线运行后,也可以随时在线制作、维护、发布报表,不用任何编码,可以充分满足企业领导对报表要求不断变化的需求。
    可以在线定制、维护及发布系统模块,一方面降低用户及开发商的维护成本,又一方面又可以迅速响应用户业务变化,提高企业的市场竞争力。
    企业可以根据自身需求,自主开发业务系统,由于方正平台提供并封装所有的系统级应用模块,对开发人员的技术水平要求较低,只要懂一些数据库方面的知识,即可自主快速地开发业务系统。
    技术领先,系统稳定性高,运行效率高,易于扩展升级。方正平台自2001年即开始开发,现在已相当成熟,而且有着庞大的客户群体,稳定性极高,功能扩展很快。

     

    展开全文
  • OpenJWeb(v1.9) 企业级信息化应用平台开源版发布公告(基于Java语言开发) 最近不少软件公司、生产企业、程序员对openjweb快速开发平台表示了极大关注,为了推动中国开源事业的发展,推动企业信息化应用的标准化...
  • 互联网时代飚速发展,大数据作为近年热门兴起的行业之一已经越来越受人们重视,但是大学并没有相关专业随之同速发展,大部分企业招收的大数据人才80%来源于培训机构,东时教育联合高校建设大学生就业社会实践基地,...
  • 企业应用(Enterprise Applications): 物联网(IOT): 云计算基础(Cloud Essentials): 云基础产品体系完整度全球领先,基础产品及功能持续投入建设,源源不断的通过新技术提高企业云上的计算、运维、开发和...
  • 什么是Enterprise Library Enterprise Library是一组应用程序块(Application Block)的集合。他们是可重用的软件组件,被设计用来帮助开发者面对常用的企业级开发任务。用来解决我们在企业级开发中遇到常见问题,如...
  • Basic4android 是目前最简单、最强大的Android平台快速应用开发工具。 - 包含开发优秀实用安卓软件所需的所以功能 - 编译为安卓平台本地代码,没有额外的运行库和依赖库 - 拥有超过4万开发者社区,帮助初学者尽快...
  • 主流的Web应用程序平台

    千次阅读 2017-09-06 20:15:40
    主流的Web应用程序平台 动态网站应用程序平台的搭建需要使用Web服务器发布网页,而Web服务器软件又需要安装在操作系统上,并且动态网站都需要使用脚本语言对服务器端进行编程,所以也要在同一个服务器中为Web服务器...
  • 企业应用集成与开源ESB产品ServiceMix和Mule介绍议程•企业对应用集成的内在需求•企业IT设施面临的问题•企业应用集成的架构方案•ESB的角色与职责•ServiceMix简介–ServiceMix架构–ServiceMix组件概览–...
  • 2、OA工具流互联方式(1) 钉钉(2) 飞书(3) 企业微信(4) Welink3、后台管理平台应用(1) 钉钉(2) 飞书(3) 企业微信(4) Welink4、第三方赋能权限(1) 钉钉(2) 飞书(3) 企业微信(4) Welink五、...
  • 最近翻了一下SAP企业移动平台最新版本3.0的相关资料,和之前的版本相比较,变化非常大...另一种则是通过HWC来实现的online应用,这个HWC容器是SUP专用的定制浏览器应用,它主要是通过HMTL来实现了跨平台功能。后来加
  • 新一代的Web应用快速开发...OpenJWeb是一款基于Java语言开发的Web应用快速开发平台,也是优秀的企业信息化应用平台,它确实实现了在几分钟之内就能产生一个增删改查模块的功能。OpenJWeb彻底解决了传统的低水平的手工
  • 企业多层分布式应用架构

    千次阅读 2009-02-12 17:39:00
    企业多层分布式应用架构 2000-07-19· anony·yesky 在信息产业高速发展的今天,企业间的竞争将更加激烈。随着规模的不断扩大和业务的不断更新,企业迫切需求完整的分布式解决方案,用于管理复杂的异构环境,实现...
  • ERP即企业资源计划系统,是指建立在信息技术的基础上,以系统化的管理思想,为企业决策层及员工提供的管理平台。它是一种跨地区、跨部门、甚至跨公司整合实时信息的企业管理系统。
  • 基于企业服务架构的新一代企业管理应用软件 --在2007年中国开发者精英论坛上的演讲IT168耿英英: 企业发展离不开信息化,而信息化的关键是企业管理的信息化,新一代的企业管理软件,使得现代的企业可以达到一个更高...
  • python 应用领域介绍 Python作为一种功能强大且通用的编程语言而广受好评,它具有非常清晰的语法特点,适用于多种操作系统,目前在国际上非常流行,正在得到越来越多的应用。 下面就让我们一起来看看它的强大功能...
  • JSAAS=云应用框架+SAAS+应用开发平台

    千次阅读 2017-03-28 17:09:58
    JSaaS如何支持传统应用开发与云应用开发
  • 《Spring 3.x 企业应用开发实战》源代码下载

    千次下载 热门讨论 2012-10-10 08:20:18
    本光盘内容包括《Spring 3.x 企业应用开发实战》一书部分章节的源代码及第18章、第19章的电子版本。 Spring 3.0是Spring在积蓄了3年之久后,隆重推出的一个重大升级版本,进一步加强了Spring作为Java领域第一开源...
  • 正如字面意思,本课程讲解的是一个真正意义上的、企业级的项目实战,主要介绍了企业应用系统中后端应用权限的管理,主要涵盖了六大核心业务模块、十几张数据库表,可以基于此去做企业应用系统的二次开发,甚至...
  • 那通过对这些平台和工具的安全功能分析,相信你已经知道了,应该如何正确配置和使用这些工具,来避免底层应用出现安全隐患,以防影响整个应用的安全性。 公司中有很多研发和运维人员,他们都在使用和维护自己的系统...
  • JavaEE Web应用开发平台WebBuilder开发团队专访

    万次阅读 多人点赞 2012-10-22 11:22:57
    使用WebBuilder能简单、快速地开发出企业级的Web应用系统。  WebBuilder官网:http://www.putdb.com  为了使大家对这一平台有更深一层的了解,我们采访了WebBuilder的开发团队。  欢迎大家推荐更多开源...
  • OpenJWeb(v2.61)企业级信息化应用开发平台技术白皮书 OpenJWeb开源组织手机:18600510596王先生QQ:29803446Email:baozhengw@163.com网站: http://www.openjweb.com 编写日期:2013-08-06 目 录 第一章概述.......
  • 应用使能平台AEP

    万次阅读 2018-05-24 20:44:33
    什么是应用使能平台AEP 应用使能平台,即Application Enablement Platform(AEP),又有翻译成应用支持平台应用支撑平台的。根据字面意思,AEP就是能快速开发部署物联网应用的云平台,常常以平台即服务(PaaS)的...
  • 企业管理软件平台架构内幕揭秘

    万次阅读 热门讨论 2008-04-10 13:01:00
    企业管理软件,由于进入门坎低,各行各业各层次企业都需要,做面向企业应用比做面向个人应用要赚钱多,好销售,所以中国内地有相当大部分的程序员在从事着企业管理软件的开发。尤其是接项目的软件公司
  • 基于SOA的新一代企业管理应用软件

    千次阅读 2007-02-06 13:30:00
    基于SOA的新一代企业管理应用软件-- 在2007年《2006年度中国企业信息化500强大会》上的主题发言 尊敬的各位领导、各位来宾,IT界的同仁和媒体界的朋友们,大家早上好!热烈祝贺在2006年度中国企业信息化500强大会上...
  • 轻量级Java EE企业应用实战(第4版):Struts 2+Spring4+Hibernate整合开发(含CD光盘1张)(国家级奖项获奖作品升级版,四版累计印刷27次发行量超10万册的轻量级Java EE经典著作) 李刚 编著  ISBN 978-7-121-...
  • OpenJWeb2.61版全部开源公告OpenJWeb...OpenJWeb的愿景是打造卓越的企业级信息化应用服务平台,让越来越多的企事业单位使用OpenJWeb作为信息化应用的基础架构。OpenJWeb从2.61版本开始实现了基础平台和业务子系统的代
  • 前言: 本文写于2014年2月,五年弹指一挥间,近期整理发表,本文出自门心叼龙的博客,属于原创类容,侵权必究。转载请注明出处。...1.1.2 基于WebGIS的车联网平台应用介绍 3 1.2 论文的主要研...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 394,577
精华内容 157,830
关键字:

企业应用平台的主要功能包括