【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

面向服务体系和遗留系统

  • 2015-04-27
  • 本文字数:4770 字

    阅读完需:约 16 分钟

这篇文章首次出现在 IEEE__ 软件杂志上。 IEEE__ 软件对当前战略性技术问题提供可靠的、业内同行的评述信息。为了应对可靠、灵活地运行企业的挑战,IT 管理者和技术领导者需要依靠 IT 专家来获得最先进的解决方案信息。

企业系统已经从单片孤岛(monolithic silos)快速发展为使用机制灵活、面向服务的分布式应用系统。为了跟上这一趋势,IT 组织必须近乎实时地调整他们的遗留系统,以面对商业变化的挑战,这一机会稍纵即逝。面向服务的体系(SOAs)已经演进成可灵活进行操作,并能连接业务进程和底层系统。Nicolas Serrano、Josune Hernantes 和 Gorka Gallardo 提供了当前 SOA 技术的概述以及如何在遗留环境中去演进。我很期待听到来自读者和这个领域具有前瞻性的专栏作家的见解,以及你们更多想知道的东西。— Christof Ebert

今天的业务必须能够灵活、快速地适应市场需求,但是即使很小的处理变化也会引起多个 IT 系统的重新返工,因为它们原本是设计成应用孤岛(application silos)的。为了保持它的竞争力,维护性的开发工作必须减少,然而 IT 系统却必须持续地演进。面向服务的体系(SOA)可以使基于孤岛(silo-based)的系统演进到面向服务的系统。它的设计思想包括松耦合、底层逻辑抽象、灵活性、重用和可发现性(discoverability)。1,2 在 SOA Manifesto 中还描述了其它一些指导原则。

SOA 初级知识中,最新奇之处在于它的基础框架设计是基于服务的,而不是聚焦在整个应用上。服务是小的、离散的软件单元,能提供特定的功能并在多个应用间被重用。SOA 应用了松耦合的设计理念,这意味每个服务都是分割的实体,它们对其它共享资源的依赖是有限的,如数据库、遗留应用或者 API。它在生产者和消费者之间帮助提供一个抽象层,从而有利于在不影响消费者的情况下来灵活改变服务的实现。SOA 对业务提供了许多益处,但它也不是灵丹妙药,可以包治百病。SOA 的优势在于:

  • 使用自然地方法来对复杂系统建模,即不依赖于技术和平台、可以对来自不同提供商的服务进行集成;
  • 推动使用松耦合,这对其与遗留系统的接口设计有帮助;
  • 通过应用重用来提高效率,以减少成本和开发时间;
  • 提高灵活性和扩展性,这样通过将现有应用集成,可以比较容易地开发出多种业务;
  • 可以减少维护成本;
  • 使系统间使用基于标准的互操作;
  • 提供位置无关的数据访问,这可以通过任何通道,如智能手机、平板或笔记本;并且
  • 允许使用增量的方法来快速满足客户需求,即通过增加一个新的服务来满足特定的商业需求。然而,SOA 不足之处在于:
  • 在应用间很难实现异步通信;
  • SOA 实现实时响应和高数据传输时会非常有挑战,这是因为 XML 强调地是健壮而非速度(尽管还可以选择其它方案,如 JSON);
  • SOA 有很多安全性缺陷,这是由于应用和系统使用了进程共享;并且
  • 在逻辑上分离的系统间交互时,SOA 会涉及到复杂的事务管理。

向 SOA 迈进并不容易,有此意愿的企业必须意识到困难和固有的那些问题。无需多言,每个 IT 组织在 SOA 实现时都会经历许多权衡和折中,而且每条道路的距离也不尽相同。为了效率和灵活性,我们推荐在遗留环境中用增量方法来迁移到 SOA。

Web 服务(Web Services)

对于大多数组织来说,Web 服务是实现松耦合体系最简单的方式。通过一组基于 XML 的公开标准,如 WSDL、SOAP 和 UDDI,就可以具有互操作的能力,这些标准提供了定义、发布和使用 Web 服务的通用方法。

Web 服务是从 Web 应用演进而来的,实际上,它们是简化版的 Web 应用。Web 服务不再提供用户接口及其数据,而仅仅提供数据接口;呈现信息给用户的任务转而由客户端的应用程序来负责。因此,Web 服务是实现 SOA 最通用的方法,实际上,许多系统使用了 Web 服务但并没有把自己定义成 SOA。

SOA(和 Web 服务)的主要优势在于相同的服务可以被不同的客户端来使用。原先为 Web 应用设计的数据仍会被任何类型的客户端使用而无需更改。这其中的例子包括从服务器获取数据而无需提供显示 SQL 数据库查询的桌面应用,或者是那些从 SOA 服务获取数据的付费或公众的信息客户端。

遗留系统可以封装成 SOA 服务并对 HTTP 协议直接做出响应,或者它工作在代理服务器的后面,代理服务器负责将请求翻译成遗留系统的语言。最终,HTTP 中的消息是明文的,它可以来自任何系统或编程语言。

技术(Technologies)

当需要创建灵活的应用时 SOA 是一个好的选项,但如何去选择正确的技术来实现则依赖于你的需求和环境。为了那些愿意在自己的业务处理中选择 SOA 的组织,让我们一起来回顾那些最相关的技术考量。

SOAP 和 REST 的对比

当设计 Web 服务时,我们需要定义一组规则用来交换信息。当前最适合完成这个任务的工具是 SOAP 和 REST。3SOAP 是个老一点的协议,它是类似 CORBA 这样已有技术在互联网环境下的实现。SOAP 可以利用多种传输协议(HTTP、SMTP 等等),这给了它更多的灵活性。由于数据是在 XML 中交换的,所以当信息量和传输的消息较大时会有性能问题。SOAP 可以和 Web 服务安全(Web Services Security)一起使用,后者是个签名和加密消息的协议,它为消息交换提供了更多的安全性。4

REST 是新的协议,它也用 HTTP 作为传输协议,但它可以处理更多的数据格式,如 XML、JSON 等等,它依赖于特定的 URL 而不是 XML。REST 是 SOAP 轻量级的替代者。REST 在实现上没有那么多约束,所以他的灵活性更高,也更轻,对文档的依赖更少。与 SOAP 只能使用 POST 方法不同,REST 可以使用 Get 方法,所以缓存不仅可以在业务设计中去实现,也可以通过基础框架来完成。

具体选择 REST 或 SOAP 取决于组织需求和限制条件。一些时候,我们会选择企业应用能力更强的 SOAP,另一些时候,我们则选择更好性能和更轻量的替代者,如 REST。因为 SOAP 有更好的安全和故障处理能力,大多数企业级的 IT 商家都会把它作为优选的 Web 服务实现。而 REST 则具有简易、性能好以及实现上不那么严格的特性,这些使它成为 Internet 业务中实现协同工作 API 的优选。

遗留系统的更新改造(Legacy Modernization)

尽管 SOA 体系是无缝连接企业系统并减少协议 5 和平台阵痛的最好选项,但大多数人仍需要同现存的框架来打交道。当你试图采纳 SOA 体系来改造遗留系统时,并不存在一个完美方案,这是因为涉及到方方面面的因素。你需要对当前的技术堆栈进行考量,然后基于全局性的成本风险分析进行最优的系统迁移。

因为遗留系统通常都在支持关键性的业务处理,所以必须采取 step-by-step 方式的改造计划,并设计可行的演进方案使现有系统通过混合方法(hybrid approach)变为完全的 SOA 体系。这里有几种策略可以使遗留系统转化为 SOA 体系。

第一个方法是将当前遗留系统用另一个或一组系统替换。通常,如果当前商用现货系统(COTS)能够满足遗留系统的需求和功能,那么这种替换就是个好办法。这个方案减少了维护但增加了未来修改的成本。第二种选项是用中间件来封装现有遗留系统并通过 Web 服务来提供遗留系统的接口。用这种方法,遗留系统功能被封装在服务层里面并插接在 SOA 环境里面。这可能解决不了一些问题:遗留应用可以集成不同的几种服务,这时就不能象期望的那样对它们解耦。然而,当重写遗留系统代价太大、遗留系统可以重用,并需要性价比好的解决方案时,这也是个好办法。最后,也是第三个选项是重写开发和编码现有的遗留系统。这是个非常好的办法,因为你可以对应用的架构施加作用并得到最优的解耦层级。但是,遗留应用通常是关键性的,而且因为涉及到之前的技术以及缺乏文档,有些时候修改它们会非常困难或代价很高,这种修改可能会引起一些问题并增加项目风险。这种情况下,正确的评估涉及的所有风险是必不可少的。

企业应用集成(Enterprise Application Integration)

当在任何 SOA 行动中计划应用集成时,许多供应商的产品可以帮助你来简化这种迁移。然而,不同的产品在能力和复杂性上有所不同,所以选择正确的方案对于成功至关重要。你可以将这些选项基于集成的复杂性级别划分为三个不同的组(看图 1)

图 1 三种企业应用集成的框架

  • 集成框架(Integration frameworks)是所有选项中最轻的,它基本由不同开发环境中的 API 实现库组成。集成框架的例子有 Apache Camel、JAVA 环境下的 Spring Integration 以及.NET 下的 NServiceBus。
  • 企业服务总线(Enterprise Service Bus)产品提供集成框架的能力以及部署、管理和运行时监控的工具。ESP 支持在服务生产者和消费者之间的连接,因此在提供工具上具有优势,它可以显著减少成本和复杂性并且能在更高的抽象层来解决集成的问题。ESB 产品的例子包括 Oracle Service Bus 和 Mule ESB。
  • 集成套件(Integration suites)提供全套的软件栈,它不仅提供 ESB 的能力,而且提供更多特定业务的工具,比如业务过程管理、业务活动监控、主数据管理和一个知识库。所有这些特性可以帮助你快速响应变化。一层层去理解这些竞争性的方案是比较困难的,所以表 1 对这三种集成方案做了一个对比。

表 1: 三种集成方案的对比

做出选择

很明显,做出最好的选项依赖于特定的需求和复杂性。首先,你先得决定框架是否已足够满足需求。例如,当你只有两个应用要连接或者你可以只用单个技术(如 REST)就能满足需求时,你就可选择最简单的方法(集成框架)而不用考虑它对工具和支持的缺乏;如果不是,那么 ESB 是一个不错的选择。但是,如果需要更多的特性,你就最好用一个更多能力和更复杂的栈,比如集成套件。

继续向前,下一个演进的步骤将是如何使 SOA 汇聚和使云计算变得容易。云的出现给企业带来的益处包括:云计算可以按需来提供资源,以容纳数据、服务和进程。

如此,在云上进行集成就成为企业今天要面对的一项主要挑战。在这样的场景下,iPaaS(integration platform as a service)作为可以满足广泛集成需求的适合选项就应运而生了。iPaaS 作为云服务套件,可以使户创建、管理并治理连接广泛应用和数据源的集成流(integration flows),而无需安装或管理任何的硬件或中间件。

展望未来,调研咨询公司 Gartner 预测到 2016 年,全世界至少 35% 的大中型组织将会使用一个或多个某种形式的 iPaaS 产品。然而,专家们以为 iPaaS 并不能取代 SOA,对于复杂集成场景传统的 SOA 仍然是需要的,比如企业内部或企业间的低延迟消息系统和数据密集交易系统。

参考

  1. N. Gold et al., “Understanding ServiceOriented Software,” IEEE Software, vol. 21, no. 2, 2004, pp. 71–77.
  2. S. Jones, “Toward an Acceptable Definition of Service,” IEEE Software, vol. 22, no. 3, 2005, pp. 87–93.
  3. S. Mumbaikar and P. Padiya, “Web Services Based on SOAP and REST Principles,” Int’l J. Scientific and Research Publications, vol. 3, no. 5, 2013, pp. 1–4.
  4. P. Louridas, “SOAP and Web Services,” IEEE Software, vol. 23, no. 6, 2006, pp. 62– 67.
  5. S. Vinoski, “REST Eye for SOA Guy,” IEEE Internet Computing, vol. 11, no. 1, 2007, pp. 82–84.

关于作者

Nicolas Serrano是 Navarra 大学工程学院的计算机科学和软件工程教授 。他的研究方向包括信息技术及其在个人和职业发展上的应用。可以通过 nserrano@tecnun.es 来联系他。

Josune Hernantes是 Navarra 大学工程学院的计算机科学和软件工程教授 。她的研究方向包括软件工程和信息系统。Hernantes 从 Navarra 大学工程学院得到了计算机科学博士学位。可以通过 jhernantes@tecnun.es 来联系他。

Gorka Gallardo是 Navarra 大学工程学院的信息系统教授 。他的研究方向主要是信息技术。可以通过 ggallardo@tecnun.es 来联系他。

这篇文章首次出现在 IEEE__ 软件杂志上。 IEEE__ 软件对当前战略性技术问题提供可靠的、业内同行的评述信息。为了应对可靠、灵活地运行企业的挑战,IT 管理者和技术领导者需要依靠 IT 专家来获得最先进的解决方案信息。

查看英文原文: Service-Oriented Architecture and Legacy Systems

2015-04-27 13:464046

评论

发布
暂无评论
发现更多内容

项目管理系列(1)-如何开好一个周会

Ian哥

项目管理 28天写作

一次慢查询暴露的隐蔽的问题

AI乔治

Java sql 架构 SQL优化

未来五年数字经济九大技术趋势,区块链成数字时代刚需!

CECBC

人工智能

关于时间管理的思考

.

28天写作

线程池是怎么回收空闲线程的?如果你认为有定时任务,那你就错了!

看点代码再上班

Java 程序员 后端 开发

如何让开发人员接受DevSecOps

啸天

DevOps 开发者 DevSecOps 升职加薪 应用安全

夜莺二次开发指南-用户资源中心

ning

滴滴夜莺 夜莺监控

夜莺二次开发指南-资产设备管理

ning

滴滴夜莺 夜莺监控

僵尸进程的成因以及僵尸可以被“杀死”吗?

AI乔治

Java 架构 进程

发达国家加紧数字货币政策布局

CECBC

数字货币

CSS13 - 定位

Mr.Cactus

html/css

读《百度不需要用户》,我似乎懂得了领导者的无奈

李忠良

AI 企业

【Mysql-InnoDB 系列】关于一致读

程序员架构进阶

MySQL 架构 innodb 28天写作

面试被问AQS、ReentrantLock答不出来?这些知识点让我和面试官聊了半小时!

Java鱼仔

Java 面试 并发 JUC

Deno 双周刊 #1 - Deno 获 2020 JS 开源年度突破奖

hylerrix

typescript deno Node 周刊 V8

聚焦目标,团队工作不再一盘散沙(上)

一笑

管理 敏捷 目标管理 28天写作

分布式唯一ID解决方案-雪花算法

JavaPub

Java 分布式

【Mysql-InnoDB 系列】事务模型

程序员架构进阶

MySQL 架构 innodb 事务 28天写作

28 天带你玩转 Kubernetes-- 第五天(玩转Docker)

Java全栈封神

Docker Kubernetes k8s 28天写作

28天瞎写的第二百一六天:LumaQQ 和 luma 二三事

树上

28天写作

用Rust写点啥:数据结构篇——单向链表

Kurtis Moxley

数据结构 rust

外行话之不玩游戏,怎么做好游戏?

Justin

游戏 28天写作 外行话

JFR定位线上问题实例 - JFR导致的雪崩问题定位与解决

AI乔治

Java 架构 线程

小马哥刷力扣 - LeetCode 9. 回文数

小马哥

LeetCode 算法和数据结构 28天写作

一文带你快速入门Canal,看这篇就够了!

大数据老哥

大数据 实时数仓 canal

夜莺二次开发指南-监控系统(3)

ning

滴滴夜莺 夜莺监控

一文学会Java死锁和CPU 100% 问题的排查技巧

AI乔治

Java 架构 死锁 cpu 100%

读书笔记:《Remote》

lidaobing

28天写作 Remote

时间之外的颜色「幻想短篇 5/28」

道伟

28天写作

夜莺二次开发指南-任务执行中心

ning

滴滴夜莺 夜莺监控

HDFS SHELL详解(6)

罗小龙

hadoop 28天写作 hdfs shell

面向服务体系和遗留系统_SOA_Nicolas Serrano_InfoQ精选文章