分布式SOA基础架构崭露头角

简介: 目前,关于面向服务的架构,即SOA,和有关如何“正确”构建SOA的争论无处不在。我个人认为这一点都不奇怪,因为现在每一种新兴的计算趋势都会带来不同的争论,并且每一家厂商都会借此机会大张旗鼓地宣传他们的技术和产品是最适合用户的,能够帮助用户充分利用每一种新兴技术和产品的优势。
目前,关于面向服务的架构,即SOA,和有关如何“正确”构建SOA的争论无处不在。我个人认为这一点都不奇怪,因为现在每一种新兴的计算趋势都会带来不同的争论,并且每一家厂商都会借此机会大张旗鼓地宣传他们的技术和产品是最适合用户的,能够帮助用户充分利用每一种新兴技术和产品的优势。为了充分挖掘狂热IT趋势中的用户兴趣,厂商们都会积极地重新定位自身已有的产品组合。然而,糟糕的是,这种做法往往会造成认识上的混乱,甚至让用户对SOA丧失信心。因为厂商往往无法完全兑现他们所做的承诺,销售的所谓适合SOA架构的技术解决方案也许最终证明并不合适。

  想要对SOA建立正确的认识,首先必须认识到从概念上来讲SOA是一种分布式的架构。作为SOA的核心要素之一,服务的目的是要实现与另一项服务的远程通信,尤其是要实现数据互享。而SOA架构的目的则是要彻底变革IT系统的构建方式,由原来的建立专有的单一应用变为建立更为高级和整合的应用,这种应用的显著特点就是充分利用已有的、可以共享和重复使用的功能,也就是服务。

  在部署和使用可共享和重复使用的服务方面,分布式SOA架构是最为简单易行的途径。并且不论是从成本角度还是从技术角度,分布式SOA架构都对目前业界普遍认同的渐进式的部署提供了最好的支持,同时,使系统具备更强的部署灵活性、适应性和可维护性(例如,一个服务与整个应用来比,对服务的验证和升级要容易得多)。

  然而不幸的是,集中式的SOA架构方式还在被不断开发和鼓吹。这些厂商们会不遗余力地说服潜在用户,他们所提供的技术和产品自始至终都支持SOA架构,且从设计伊始便是为了方便用户建立SOA架构,而不管这些技术和产品原本是为JEE应用服务器而设计,还是为EAI系统而设计。

  换句话说,对分布式SOA架构持反对意见的厂商这样做,是由他们所拥有的软件架构的性质所决定的。一个EAI Hub,或是基于JEE的应用堆栈式架构,亦或其他解决方案,它们的消息请求都必须经过中央控制点,因此都不能被称为真正的分布式解决方案。因为在它们的架构中,如果要执行某项服务请求,都必须通过Hub或中央服务器来实现。集中式SOA架构会增加成本,限制资源的再利用,降低系统的灵活性,并且有可能导致成本高昂的系统瓶颈。最糟糕的结果是,它还有可能成为用户取消SOA计划的第一原因。如果SOA架构的灵活性不足以满足用户的各项需求,无疑会导致用户对SOA架构的彻底失望。

  如果我们来认真研究一下互联网,大家就可以明白什么是能够成功满足用户需求的分布式架构。互联网是迄今为止规模最大的分布式应用,SOA架构正应该具备互联网的这种分布式特性。当用户使用浏览器点击URL链接时,其请求并不是通过安装在服务器或Hub的中央控制程序来路由,而是由浏览器直接传递到请求页面所在的网络服务器。这种方法非常适合互联网,同样也非常适合企业的SOA架构。由于请求不需要通过Hub或中央服务器,因此互联网的每个端点可以自由更新而不致影响客户端,也不会影响其他站点,更不需要更新Hub或中央服务器。一个好的SOA架构就应该具备这种功能。

  还好,具备SOA分布式特性的基础架构解决方案确实存在。分布式SOA架构通过智能端点让具备某种服务功能的应用自动找寻其他服务,并与其实现相互通信。这些智能端点同时还具备极强的可获得性和高安全性能等企业级服务特性,从而能够确保其具备现有的企业关键应用所需要的各种性能。分布式SOA架构就是建立一个平台中立、高度灵活且基于标准的IT环境,从而能够更好地应对不断变化的技术和业务环境。因此,分布式SOA环境能够更好地满足基于SOA架构的应用程序对各项技术和成本的要求。而且,分布式SOA允许客户按照自己的计划渐进地部署服务,比如一次部署一两个服务,在未来根据具体的业务需要,为系统增加服务编排、注册/贮存、管理等各项高级功能。

  需要强调的是,我并不是说通过EAI系统、hub或JEE服务器建立的集中式SOA架构的方式都不好,都是错误的。在许多情况下,现有企业应用很多都是采用上述形式实现的。我所要说明的是一个好的SOA架构不应该局限于完成EAI系统或JEE应用服务器架构所能做的;实际上,一个好的SOA架构应该包容集中式的系统,并将它们融入到可重用的服务体系中,这才是分布式SOA架构的真谛。

  在当今的航空业,低成本航空运营商正在挑战资深航空运营商的业务。以航空运输业的发展为例,我们可以从中发现分布式的优点同样在航空业中得到了充分的体现。资深运营商都是依靠昂贵的Hub和星型模式,通过特定的专用运输Hub输送旅客。费用昂贵的大型飞机将旅客从小型机场运送到中央的Hub机场,在这里,旅客才能继续他们的旅程到达最终的目的地。在这种模式下,飞机运营成本更高,机场设施收费也会更高。随着低成本的航空运营商的兴起,他们的运输模式是分布式、点到点的模式(小型飞机往返于小型机场之间),为旅客节约了时间和成本而大受欢迎,这使得传统Hub模式的航线正在面临巨大的财务问题。

  SOA用户不需要更多相同的冗繁、昂贵的堆栈软件架构。他们所需要的是专门针对满足SOA发展趋势而设计的好软件,也就是如何使得已有(或新的)IT资产可以得到更好重用,如何令IT系统更加灵活,并能快速构建新应用。SOA的设计也需要更好的方法来实施和部署可重用的服务,并且做到能够随时随地且简易直接地使用这些服务。其实,用户更需要低成本的SOA解决方案,令他们可以从小规模SOA做起,并随着业务的增长逐步扩大规模,同时根据自身的需求增加服务质量和其他功能等;与此同时,使用点到点的通信方式,避免新增加昂贵的服务器和Hub。简而言之,SOA用户需要的SOA架构必须真正具备SOA架构的固有特性,也就是分布式的特性。 
相关文章
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
251 2
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
11月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
1478 3
|
人工智能 安全 Java
智慧工地源码,Java语言开发,微服务架构,支持分布式和集群部署,多端覆盖
智慧工地是“互联网+建筑工地”的创新模式,基于物联网、移动互联网、BIM、大数据、人工智能等技术,实现对施工现场人员、设备、材料、安全等环节的智能化管理。其解决方案涵盖数据大屏、移动APP和PC管理端,采用高性能Java微服务架构,支持分布式与集群部署,结合Redis、消息队列等技术确保系统稳定高效。通过大数据驱动决策、物联网实时监测预警及AI智能视频监控,消除数据孤岛,提升项目可控性与安全性。智慧工地提供专家级远程管理服务,助力施工质量和安全管理升级,同时依托可扩展平台、多端应用和丰富设备接口,满足多样化需求,推动建筑行业数字化转型。
451 5
|
9月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
存储 缓存 NoSQL
分布式系统架构8:分布式缓存
本文介绍了分布式缓存的理论知识及Redis集群的应用,探讨了AP与CP的区别,Redis作为AP系统具备高性能和高可用性但不保证强一致性。文章还讲解了透明多级缓存(TMC)的概念及其优缺点,并详细分析了memcached和Redis的分布式实现方案。此外,针对缓存穿透、击穿、雪崩和污染等常见问题提供了应对策略,强调了Cache Aside模式在解决数据一致性方面的作用。最后指出,面试中关于缓存的问题多围绕Redis展开,建议深入学习相关知识点。
907 8
|
9月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
604 1
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
631 61
|
10月前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
4062 57
|
消息中间件 人工智能 监控
文生图架构设计原来如此简单之分布式服务
想象一下,当成千上万的用户同时要求AI画图,如何公平高效地处理这些请求?文生图/图生图大模型的架构设计看似复杂,实则遵循简单而有效的原则:合理排队、分工明确、防患未然。
587 14
文生图架构设计原来如此简单之分布式服务