必然精通分布式系统核心:面向服务的分布式架构,Web服务的分类

简介: 在技术层面上,Web服务可以通过多种方式实现。目前,业界主流分类方法是将Web服务区分为“大”Web服务和RESTful Web服务。

Web服务的分类

在技术层面上,Web服务可以通过多种方式实现。目前,业界主流分类方法是将Web服务区分为“大”Web服务和RESTful Web服务。

网络异常,图片无法展示
|

“大”Web服务

“大”Web服务使用遵循SOAP标准的XML消息,SOAP是一种定义消息架构和消息格式的XML语言。此类系统通常包含服务所提供的操作的机器可读描述,用WSDL编写,WSDL是一种用于按语法定义接口的XML语言。

Java制定了JAX-WS规范为“大”Web服务提供功能。目前JAX-WSAPI已经移到Java SE 8中,这意味着不管是Java SE应用还是Java EE应用,都可以开箱即用地使用JAX-WS API。

SOAP消息格式和WSDL接口定义语言得到了广泛的应用。许多开发工具,如NetBeans、Eclipse,可以降低开发Web服务应用程序的复杂性。

基于SOAP的设计必须包含以下元素。

·必须建立正式合约来描述Web服务提供的接口。WSDL可以用来描述合约的细节,它可包括消息、操作、绑定和Web服务的位置。还可以在JAX-WS服务中处理SOAP消息,而无须发布WSDL。

·架构必须满足复杂的非功能性需求。许多Web服务规范满足了这些需求,并为它们建立了通用词汇表。例如,事务、安全、寻址、信任、协调等。

·架构需要处理异步处理和调用。在这种情况下,标准(如Web服务可靠消息)和API(如JAX-WS)提供的基础设施及其客户端异步调用支持可以开箱即用。

RESTful Web服务

RESTful非常适合基本的、即席的集成场景。RESTful Web服务通常比基于SOAP的服务更好地与HTTP集成,因此不需要XML消息或WSDL服务-API定义。RESTful Web服务也简称为REST服务。

由于RESTful Web服务使用现有的知名W3C和IETF标准(HTTP、XML、URI、MIME),并且具有轻量级基础结构,允许以最少的工具构建服务,因此开发RESTful Web服务成本较低,具有很低的采用门槛。可以使用NetBeans、Eclipse等开发工具来进一步降低开发RESTfulWeb服务的复杂性。

在Java EE中,JAX-RS(Java API for RESTful Web Services)规范旨在提供RESTful Web服务的功能。Jersey项目是JAX-RS规范的实现参考。Jersey实现了对JAX-RS规范中定义的注释的支持,使开发人员能够轻松地使用Java来构建RESTful Web服务。

RESTful设计一般满足以下特征。

·Web服务是完全无状态的。一个好的测试是考虑交互是否能在服务器重新启动后存活下来。

·缓存基础设施可用于提升性能。如果Web服务返回的数据不是动态生成并且可以缓存的,那么可以利用Web服务器和其他中介提供的固有缓存基础设施来提升性能。但是,开发人员必须小心,因为对于大多数服务器来说,这种缓存仅限于HTTP GET方法。

·服务提供者和服务消费者对传递的上下文和内容要相互理解。因为没有正式的方法来描述Web服务接口,所以双方必须就描述正在交换的数据的模式和有意义的处理数据的方法达成一致。在现实世界中,将服务作为RESTful实现公开的大多数商业应用程序还以流行的编程语言向开发人员分发描述接口的所谓增值工具包。

·带宽尤其重要,需要限制。RESTful对于一些受限设备(例如PDA和手机)特别有用,对于这些设备,必须限制XML有效负载上的消息头和SOAP元素的额外层的开销。

·使用RESTful可以轻松地将Web服务交付或聚合到现有网站。开发人员可以使用JAX-RS和Ajax等技术以及DWR等工具包来消费Web应用程序中的服务。服务不是从头开始,而是可以通过XML公开,由HTML页面使用,而无须对现有网站架构进行重大重构。现有的开发人员将更有生产力,因为他们正在添加一些他们已经熟悉的东西,而不是从头开始学新技术。

有关RESTful Web服务的内容,还将在第8章详细讲解。

Web服务技术选型

选择使用“大”Web服务和RESTful Web服务是要针对具体的场景的。

“大”Web服务:解决企业计算中常见的高级QoS需求。与RESTfulWeb服务相比,“大”Web服务更容易支持WS-组协议,这些协议提供了安全性和可靠性等标准,并与其他符合WS-的客户机和服务器进行互操作。在老的遗留项目或者传统的企业级项目中,“大”Web服务还有用武之地。

RESTful Web服务:使编写Web应用程序更轻松,这些应用程序应用RESTful风格的部分或全部约束,从而在应用程序中引入所需的属性,例如松耦合(在不破坏现有客户端的情况下,更轻松地演进服务器)、可伸缩性(从小到大)和架构简单性(使用现成组件,例如代理或HTTP路由器)。你会选择使用JAX-RS来开发你的Web应用程序,因为许多类型的客户端使用RESTful Web服务比较容易,同时允许服务器进行演进和扩展。客户端可以选择使用服务的部分或全部方面,并将其与其他基于Web的服务混搭起来。随着移动App、云计算、CloudNative、微服务等架构的兴起,越来越多的应用倾向使用RESTful Web服务。

本文给大家讲解的内容是分布式系统核心:面向服务的分布式架构,Web服务的分类

本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。

相关文章
|
10月前
|
开发框架 监控 安全
Windows Defender 导致 Web IIS 服务异常停止排查
某日凌晨IIS服务异常停止,经查为Windows Defender安全补丁KB2267602触发引擎更新,导致系统资源波动,进而引发应用池回收。确认非人为操作,系统无重启。通过分析日志与监控,定位原因为Defender更新后扫描加重负载。解决方案:将IIS及.NET相关路径添加至Defender排除列表,避免业务影响。
1039 116
|
10月前
|
关系型数据库 Apache 微服务
《聊聊分布式》分布式系统基石:深入理解CAP理论及其工程实践
CAP理论指出分布式系统中一致性、可用性、分区容错性三者不可兼得,必须根据业务需求进行权衡。实际应用中,不同场景选择不同策略:金融系统重一致(CP),社交应用重可用(AP),内网系统可选CA。现代架构更趋向动态调整与混合策略,灵活应对复杂需求。
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
284 2
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
监控 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注册中心服务 构建商品
1546 3
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
1288 0
|
10月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
10月前
|
消息中间件 运维 监控
《聊聊分布式》BASE理论 分布式系统可用性与一致性的工程平衡艺术
BASE理论是对CAP定理中可用性与分区容错性的实践延伸,通过“基本可用、软状态、最终一致性”三大核心,解决分布式系统中ACID模型的性能瓶颈。它以业务为导向,在保证系统高可用的同时,合理放宽强一致性要求,并借助补偿机制、消息队列等技术实现数据最终一致,广泛应用于电商、社交、外卖等大规模互联网场景。
|
10月前
|
算法 NoSQL 关系型数据库
《聊聊分布式》分布式系统核心概念
分布式系统由多节点协同工作,突破单机瓶颈,提升可用性与扩展性。CAP定理指出一致性、可用性、分区容错性三者不可兼得,BASE理论通过基本可用、软状态、最终一致性实现工程平衡,共识算法如Raft保障数据一致与系统可靠。
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
685 61

热门文章

最新文章