基于云计算与SOA的企业集成架构及实现

作者：张晓娟 易明巍

欢迎访问e展厅 展厅 3 CIO信息化管理展厅 电子商务/企业门户, IT运维管理, 制造执行系统MES, 流程管理BPR/BPM, SOA/SaaS/云计算, ... 通过对云计算的部署模式及逻辑结构的探讨，分析其面临的集成挑战；并将SOA 这一基于服务的架构融入云计算，作为建立云计算集成架构的一个解决途径；最后通过一个企业案例来具体分析和说明企业如何综合运用这两者来构建企业系统集成架构。 企业在经过了多年的信息化建设后，财务、ERP(企业资源计划)、CRM(客户关系管理)、HR(人力资源管理)等企业管理软件已被广泛的应用。但这些异构系统形成多个应用和数据的孤岛，难于共享数据和资源；企业业务流程各异而且随着市场发展这些流程不断更新，标准的应用软件很难适应业务流程更新与重组的速度与个性化需求，因而大大提高了企业营运成本，降低了企业的市场快速响应能力。较之不断地加大系统投入来实现系统软、硬件的可扩展性，集成无疑成为更为现实和合理的选择。 通过云的方式享受软硬件服务，目前对许多企业来说是应用先进信息技术的最好途径，它不仅降低了企业的软硬件服务拥有成本，缩短了信息化建设周期，还大大减少了企业的运维成本。所以，云计算的兴起可能是未来几年最为重要的IT 产业趋势，随着云计算不断发展，云应用会越来越普及，市场研究机构IDC对IT 职业人士的一项调查显示，目前已有4%的公司以一定的方式部署了云计算，尽管大多采用的是软件即服务（SaaS）的形式，比如Salesforce 公司的CRM（客户关系管理）应用程序等。IDC 高级副总裁佛兰克-杰恩斯曾在云计算论坛上表示，预计到2012 年，将有9%的公司部署这一服务。而据Gartner 估计企业应用在SaaS 模式上的投入将以每年19.4%的速度增长。 笔者认为，云计算作为一个融合了底层IaaS，中间层PaaS，到上层SaaS 的一整套服务集，开始被引进了集成服务，并与系统集成——一个由物理层、数据层、应用层、流程层和表现层集成所代表的企业集成框架[3]相对应，所有云计算能提供的服务需要在企业整体架构的背景下才能有效的发挥作用，也就是说企业自身需要一个清晰的基于服务的IT 基础设施架构，在这个架构之中去应用云计算。为解决云计算面临的集成架构挑战，本文将SOA 这一基于服务的架构融入云计算， 作为建立云计算集成架构的一个解决途径；并通过一个企业案例来具体说明企业如何综合运用这两者构建企业系统集成架构。 1 云计算及其面临的集成挑战 1.1 云计算组件的逻辑结构 云计算到目前为止还没有一个准确的定义，但目前来说一个普遍的认为是云计算是分布式计算、并行处理和网格计算的发展，或者说是这些计算机科学概念的商业实现；也可以认为云计算是一种付费即使用的自助式应用模式，即将一组可配置的共享计算资源（网络、存储、应用等）通过无时无处不在的网络提供给用户使用，并且用户几乎不用与服务提供商进行任何交互，从而使得用户可以以最小的管理开销来配置和使用这些资源。 为了更好的解释云计算所提供的服务，DavidLinthicum 根据目前主流云计算服务商及其提供的服务，使用一种“堆栈”的图示(图1)来解释各组件间的逻辑关系及他们的交互。 事实上，云计算可以拥有足够的硬件和运营服务资源，也即它本身就是一个大的系统集成环境，一个融合了底层IaaS，中间层PaaS 到上层SaaS 的一整套服务集，能为企业提供从底层基础设施的集成到中间层应用平台的集成再到应用层的应用集成全套的集成服务，但前提是这个集成需要在企业拥有清晰完善的基于服务架构的IT 框架的背景下才能最高效的发挥作用。 1.2 云计算与集成 云计算的真正价值在于使企业拥有使用位于本企业之外其它的数据中心里的服务、数据和流程的能力。但如果企业不加计划盲目地使用云计算，不仅不能利用云计算的优势，长远来看也许会付出极大的代价。一方面，对于企业来说长期以来不断出现的“烟囱”式的信息系统在解决了企业燃眉之急的需求的同时也给企业IT 系统投资与维护带来了巨大资金和技术的压力，此时企业转向利用云计算的优势减轻企业信息系统投资与维护的压力，但是急于向云中搬迁企业的数据、应用但却没有任何架构方面的长远考虑，也没有考虑与此密切相关的云计算与本地系统的集成问题；在另一方面，众多的云计算供应商不会考虑到与企业集成的问题。因为云服务提供商们一直认为企业既然使用他们提供的云计算服务，就没有必要再将云端的数据同步回企业中，因为企业应用已在云中部署。然而事实并非如此。在许多情况下，虽然云计算是非常实用并能够使企业受益的，但如果认为无需从云计算平台向企业本地系统实施核心数据、应用或流程集成，另外的一些问题就会随之而来，例如业务系统不能处于自己的掌控中那么意味着企业将无法应付云服务提供商终断服务（如由于自然灾害或是服务商转型所带来的服务终止）所带来的危害。 从集成角度来看，应用云计算企业将面临的问题会有： （1）企业在一段较长的时间内不会也不可能将所有应用转移到云端，即使全部转移到云端也不大可能将所有的应用全部部署在同一个云服务提供商处，而一定会有一些部署在企业内部的系统或不同的云服务提供商，因此，云端的应用必须和企业内部系统的应用以及在其他云中的应用整合，使他们能够相互联通，才不至于形成新的“孤岛”。 （2）大量的集成项目会使IT 部门的开发和维护面临巨大挑战。企业需要的是集成系统要能够在任何时间以任何形式部署在任何平台上，而且这些集成系统又是错综复杂地连接在一起的。 首先，从数据方面看，一方面企业需要而且有必要在本地保留云端数据的备份，因为企业所使用的云端服务是由云服务提供商提供的，企业自身无法掌控这些服务。如果云计算服务中断、云计算服务失控或与服务提供商无意继续经营该业务，企业将面临业务系统中断的风险，事实上这类事件正在不断地出现。所以企业都需要在企业本地系统中保留企业相关数据的最新备份。另一方面，企业极有可能同时使用位于企业内部的系统与位于不同云中的系统，因此，集成势在必行。基于企业对于IT 系统不在自己掌握所带来的风险的考虑，一种平衡风险的有效办法就是根据自己的需要将IT 系统分散置于不同的数据中心（公共云）中，这样既减少了自己维护的困难，也减少了所有应用放在同一片云中所带来的全部IT 系统宕机风险，同时企业也可以根据自己不同的需求选择最合适的云服务提供商来降低投资。 其次，从应用和由各种应用组合而成的流程角度，企业要充分考虑哪些系统适合放在云端，哪些系统适合放在本地。例如CRM 系统对于企业来说是没有多大附加值的系统，因此企业完全没有必要自己去开发一套CRM 系统，况且现在很多云服务商已经能提供很好CRM 软件，那么企业就可以去租用云端的CRM系统。而对于企业的关键系统来说，就必须考虑到把其迁移到云端的风险。企业应采取怎样的措施来应对风险成为摆在决策者面前一个不可回避的问题。 综上，目前的企业部署云端系统需要和企业内的本地系统协同工作，集成就成了成功的关键。随着云计算的发展，越来越多的企业应用将逐步转换到云计算。如果事先不实施长期策略和目标，将会加大复杂性并降低投资回报率。因此，集成需要有架构远见提前考虑。 2 云计算与SOA的融合——集成架构的建立 如前所述，如果企业不考虑集成的架构而盲目去追求云计算的话，随着企业在云端的应用越来越多而这些应用仍然又回到了“信息孤岛”——一个更大的信息孤岛的状态，这时企业再去想把他们集成在一起会付出更大的代价。 SOA 架构被认为是目前企业级信息系统可靠和高效的建模思想和软件构建方法，通过模块化、集成化、动态组装，使得系统的重用性、可靠性、可扩展性和开发速度大大提高。因此，这种架构能够让组织快速地构件和部署新的应用程序和服务，以及根据组织的需要使用任意的内部和外部服务的组合。SOA 基于服务的架构在过去的几年中一直被认为是解决架构问题及企业集成最有效的方法。然而，在另一方面，大量的公司在实践SOA 之后发现，事情往往并不是想象中的那么简单，他们在开展SOA 项目后发现SOA 需要一个规模宏大的计划，而且要想看到部署SOA 所带来的效益要相当长的一段时间，一般的公司难以负担SOA 所带来前期阵痛的。 从系统工程和企业应用的角度，“云计算和SOA可以独立运用或同时运用。云计算并没有取代SOA 或分布式组件集成技术；相反，云计算的平台与存储服务为SOA 的服务集成提供增值性（value-added）的支撑[5]。”如David Linthicum 所建议的，可以将SOA 看作架构的一个解决途径，一个利用云计算资源的更好的方式。其理念主要是从架构角度的中考虑云计算；而不是将云计算作为一次性的解决方案。 资源与功能服务化是云计算的一个核心思想。面向服务的架构为云中的资源与服务的组织方式提供了可行的方案，云计算依赖于面向服务的思想，通过标准化、流程化、和自动化的松耦合组建为用户提供服务，不过云集算将不仅仅是一种设计架构的模式或方法，而且是一个完整的应用运行平台，基于面向服务架构思想构建的解决方案将在云中运行，服务于云外用户[7]。因此，云计算与SOA 的融合，能够使企业中的SOA 架构扩展到防火墙之外到云计算服务提供商那里，从而获得云计算的种种优势，形成优势互补而又避免了他们的不足，真正做到以最低的投入获得最高的回报。 3 企业案例：云计算环境下的系统集成架构及解决方案 3.1 案例背景 XX 集团是一家全国性的民用液化气气体生产、销售、储运与服务全面运营的企业，为中国内地最大的跨区域能源终端运营商之一，XX 集团已先后在湖南、安徽、贵州、江苏、云南、山东、浙江、湖北、广东等省成功投资运营数十家气体经营企业。 随着XX 集团的规模不断扩大，该集团目前面临着急迫的信息系统整合问题，由于XX 集团的各分公司分布于全国各地，且各下属公司信息系统总体上是各自为阵、分别实施，由于地域差异和管理理念不同，各家公司系统的业务功能模块存在差异，不能彼此共享、互通，造成总部与下属企业之间信息不畅；数据的分散存储导致集团无法对各公司的客户和业务数据进行深度挖掘和分析，无法实现集团化的业务推进和集团内部的资源调配，更无法构筑集团性的统一平台。所以集团每年都要投入大量资金对各地的信息系统进行打补丁式的小修小改以适应当地规模的扩大。 近年来随着SOA 技术的成熟，以及云计算技术的日趋普及，集团决定集全集团各分公司之力建立一套全新的全集团通用的信息系统，全面扭转之前的在信息化建设上的被动局面。 3.2 XX 集团私有云平台模型 根据XX 集团信息化建设要求，结合云计算、SOA等技术，提出了XX 集团业务系统信息化平台框架，称为XXPlatform（如图2）。它以基础设施服务IaaS为基础，SaaS 平台为核心，包括以下4 个方面的内容： （1）面向XX 集团各地各分支机构的云服务基础架构IaaS，用于为连入平台的各个分公司提供服务的基础设施。 （2）SaaS 平台，为集团各分公司提供从资源采购到终端销售的全套业务的在线解决方案。 （3）XX 集团公共服务平台，用于为各分公司提供除业务逻辑之外的其他公共性服务，如办公系统，邮件系统，存储系统，数据挖掘等。 （4）可选的本地平台，主要是为规模较大的区域性分公司提供个性化业务的开发环境。 3.2.1 基础设施层 基础设施服务（IaaS）提供服务器、存储等硬件设施。XX 集团计划建立一个面向全集团的云计算中心，搭建自己的基础设施平台IaaS，为全国各地的分公司提供硬件基础设施保障。 XX 集团在各省或地区均有一个规模较大的分公司，每一家这种类型的分公司均有着较好的硬件资源，部分分公司在最近1-2 年都投入了上百万用于更新服务器等硬件设施，但是这些服务器并没有完全发挥效率，有的数据备份服务器甚至一天只工作2-3 小时用于备份数据，但是由于其负责在主服务器故障时接替其工作，往往这类服务器配置和主服务器一样，因此造成了极大的资源浪费。因此，在此次信息化建设中XX 集团计划对全集团的IT 资源进行梳理，将各地的部分优质IT 资源集中到集团的云计算中心，形成该信息化建设的基础设施层，据测算，目前XX 集团的所有优质IT 资源集中起来已可以满足集团在未来3-5 年的业务发展需要，而由于采用了云计算的技术架构，通过虚拟化技术等手段可在当需要扩展计算能力时弹性增加服务器数量或者直接租用第三方资源来获得而不必去重新为新加入的服务器搭建平台，大量减轻企业IT 人员负担，节约IT 支出。 3.2.2 中间件层 该中间件层位于基础服务层之上，起到承上启下的作用，它在下面的基础设施层所提供资源的基础上提供了多种服务，比如缓存服务和REST服务等。 （1）REST：通过REST 技术，能够非常方便和优雅地将中间件层所支撑的部分服务提供给调用者。 （2）多租户：就是能让一个单独的应用实例可以为多个组织服务，而且保持良好的隔离性和安全性，并且通过这种技术，能有效地降低应用的购置和维护成本。 （3）并行处理：为了处理海量的数据，需要利用庞大的X86 集群进行规模巨大的并行处理。 3.2.3 云管理层 云管理层负责提供多种管理和维护等方面的工作，主要有下面这六个方面[9]： （1）帐号管理：通过良好的帐号管理技术，能够在安全的条件下方便用户地登录，并方便管理员对帐号的管理。 （2）SLA 监控：对各个层次运行的虚拟机，服务和应用等进行性能方面的监控，使它们都能在满足预先设定的SLA(Service Level Agreement)的情况下运行。 （3）安全管理：对数据，应用和帐号等IT 资源采取全面保护，使其免受犯罪分子和恶意程序的侵害。 （4）负载均衡：通过将流量分发给一个应用或者服务的多个实例来应对突发情况。 （5）运维管理：主要是使运维操作尽可能地专业和自动化，从而降低云计算中心的运维成本。 3.2.4 SaaS 服务集成平台 该SaaS 平台是XX 集团信息化建设的核心，其能够实现公司运行所需的所有业务逻辑，该平台提供一系列基于SOA 标准的服务，包括贯穿公司业务流程的资源采购系统-->储运调拨系-->零灌业务系-->零售业务系-->客服中心系统-->CRM 系统-->财务管理服务-->商务智能等服务，该平台目前计划部署在集团的云计算中心中，全国各个分公司只需通过浏览器接入该SaaS 平台就可完成全部业务操作。同样，由于该平台采用的云计算架构，使得该平台可以既可以在XX 集团云服务中心部署，也可以根据业务需要在各省或区域中心分公司部署，形成该地区的云计算中心，提供了根据业务量的灵活部署方式，为将来的业务发展预留了极大的空间。 3.2.5 本地基础系统平台 本地基础平台为本地应用提供基础平台，这类本地应用包括各本地呼叫中心、分公司门户系统、本地经营特色的数据分析系统以及本地第三方服务等。 其中在本地基础平台中较为重要的是数据同步服务和XX 集团SaaS 核心功能备份系统，由于民用液化气行业关系到居民的基本生活保障，因此对于公司的正常运营与否直接关系到居民的民生问题，公司最大的忌讳就是业务系统停止运行，因此该备份系统的目的是将云平台中的SaaS 中的核心销售系统的备份放在本地中，定时和云计算中心同步核心销售数据（经过精简的销售数据，这样就不至于消耗过多的处理资源），这样可以保证一旦云计算中心由于某种原因出现停止服务的情况可以马上切入本地的运行平台上工作，保证居民的燃气供应。 综上，该SaaS 平台较好的满足了目前公司业务需求，包含了几乎所有的业务功能，各分公司还可在该平台上通过开放的接口开发和集成新的服务以更好的满足公司的发展需求。 3.3 XX 集团云计算平台服务架构 3.3.1 SOA 架构 XX SaaS系统云服务平台的系统架构是以SOA为基础，采用JAVA 语言开发，以OSGi 标准对各个服务进行统一封装，为服务提供者提供统一的服务发布功能，为服务消费者和提供者之间提供统一的通信方式。 具体来说该系统具有如下特征：松散耦合；明确定义接口；无状态的服务；粗粒度的服务；位置透明性；协议无关性。 3.3.2 服务模型 1. 系统架构设计 根据对XX 集团业务需求特点的分析，定义该SaaS 以SOA 的思想为基础的系统架构。该系统架构如图3 所示： 各层次功能分担如下： （1）业务运行基础平台OSGi该架构上的所有服务均遵循OSGi 标准，并且均封装为OSGi 服务，以供其他组件调用。新开发的应用系统都基于统一开发平台进行开发，可以调用已有的服务。已有的应用系统通过统一的接口接入平台。 （2）数据服务层 负责对应用数据的存储，执行数据处理，采用Oracle 数据库软件进行管理，保证数据读取和存储的高效和稳定。 （3）业务逻辑层 该层为企业应用逻辑的实现层，将各类业务逻辑以合适的粒度封装和发布为服务的形式，供应用开发进行调用。 （4）服务接口层 服务接口层是整个架构的核心，负责前后端应用之间的交互，定义业务逻辑服务所提供的操作、服务相互之间交互的消息标准和方式。它包含服务总线，服务注册库和服务查找与调用三大元素，服务总线将SOA 的所有参与者相互连接在一起，定义数据传输的标准格式，封装各种类型的消息传递方式；服务注册库将所有业务逻辑服务定义在一起，通过它可以发现服务，获得使用服务的所有信息；服务查询和调用则对查找和调用业务逻辑服务的方法进行封装。正是由于该层的存在才避免了传统EAI 方式的密如蛛网的接口开发。 （5）客户层 客户端通过浏览器方式调用相应服务。 2. 应用架构 XX 集团SaaS 服务平台由一系列服务功能组成，这些功能分为4 个层次，如图4 所示。 ·数据层：对数据的存储与处理 ·通用服务层：提供用户注册、账户管理、统一认证、服务注册、支付管理、安全管理、日志、监控等通用服务。 ·应用层：提供企业业务逻辑的核心功能。 ·门户层：门户系统应用。 上述各种服务通过组合，可构成不同的应用平台或应用系统。应用服务的运行状态监控、服务切换、服务分配等都由云服务平台中的核心服务实现，以此实现系统的自治。 3.4 整合机制 为了实现与各地分公司部分原有系统（这些系统往往是各地个性化的应用）的整合，XX 集团云平台需要建立统一的基础信息，统一的开放API等。 （1）统一的基础信息。整个XX 集团云服务系统需要建立统一的基础信息，如用户信息、采购信息、销售信息、库存信息、财务信息等，这些信息为服务整合奠定了基础。 （2）统一的API。OpenAPI 是web2.0 的一种服务模式，也是云计算的服务方式。利用这些API 可以实现对分散数据和服务进行整合，能带来具有新价值web服务。 XX 云服务平台提供的所有服务分为三个层次：系统内的私有服务、分公司个性化私有服务、平台公有服务，分别为：(1)同一系统内的私有服务的注册和管理由OSGi 基础框架完成。这些服务无需对系统外提供；(2)分公司个性化私有服务，可以被分公司本地平台其他服务调用；(3)公有服务(即OpenAPI 平台所访问)。后面这两类服务都通过应用／服务注册管理和同步机制来实现。分公司和第三方软件开发商可以很方便地调用API，构建自己的应用系统和服务，实现对海量数据的集成，实现对已有服务的集成，设计更多的业务模式和功能，实现自有应用的快速接入。 4 结语 云计算是计算机领域的新浪潮，可以预计，在不远的将来，云计算将成为企业IT 的首选。但云计算实现其全部潜力将依赖于将云与内部部署应用程序和数据库进行集成以及不同云之间应用的集成，这样才能避免又一次“数据孤岛”的形成。与此同时，基于服务的架构经过多年的发展已日趋成熟，越来越多的企业正在以服务的理念对企业的IT 架构进行改革。云计算与SOA 的融合能够增强服务的部署，为企业带来更为敏捷的IT。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (8/15/2012)