大型网站技术架构,7网站的可扩展架构之利用分布式服务打造可复用的业务平台

消息队列通过消息对象分解系统耦合性,不同子系统处理同一个消息;

分布式服务通过接口分解系统耦合性,不同子系统通过相同的接口描述进行服务调用。

巨无霸应用的问题:

1、编译、部署困难

2、代码分之管理困难

3、数据库连接耗尽

4、新增业务困难

解决的方案就是拆分,将模块独立部署,降低系统耦合性。拆分可以分为纵向拆分和横向拆分两种。

纵向拆分:将一个大应用拆分成多个小应用,如果新增业务较为独立,那么就直接将其设计部署为一个独立的Web应用系统。

横向拆分:将复用的业务拆分出来,独立部署为分布式服务,新增业务只需要调用这些分布式服务,不需要依赖具体模块代码,即可快速搭建一个应用系统,而模块内业务逻辑变化的时候,只要接口保持一致就不会影响业务程序和其他模块。

纵向拆分相对较为简单,通过梳理业务,将较少相关的业务剥离,使其成为独立的Web应用。而对于横向拆分,不但需要识别可复用的业务设计服务接口规范服务依赖关系,还需要一个完善的分布式服务管理框架

7.3.1 Web Service与企业级分布式服务

Web Service曾经是用以整合异构系统及构建分布式系统的主要技术。

服务提供者通过WSDL向注册中心描述自身提供的服务接口属性,注册中心使用UDDI发布服务提供者提供的服务,服务请求者从注册中心检索到服务信息后,通过SOAP和服务提供者通信,使用相关服务。

Web Service的缺点:

1、臃肿的注册和发现机制

2、低效的XML序列化手段

3、开销相对较高的HTTP远程通信

4、复杂的部署与运维手段

难以满足大型网站对系统高性能、高可用、易部署、易维护的要求。

7.3.2 大型网站分布式服务的需求与特点

对于大型网站,除了Web Service所提供的服务注册与发现,服务调用等标准功能,还需要分布式服务框架能够支持一下特性。

负载均衡

对于访问量大的服务,部署在集群上。分布式服务框架能够支持服务请求者使用可配置的负载均衡算法访问服务,使服务提供者集群实现负载均衡。

失效转移

当某个服务实例不可用,就将访问切换到其他服务实例上,以实现服务整体高可用。

高效的远程通信

多路复用,异步非阻塞调用,高效的通信模型和线程模型支持

整合异构系统

对应用最少侵入

服务模块本身需要支持可集中部署,也可分布式部署

版本管理

支持服务多版本发布,服务提供者先升级接口发布新版本的服务,并同时提供旧版本的服务供请求者调用,当请求者调用接口升级后才可以关闭旧版本服务。

实时监控

没有监控的服务是不可能实现高可用的。监控服务提供者和调用者的各项指标,提供运维和运营支持。

7.3.3 分布式服务框架设计

Dubbo远程调用框架,调用流程。

 服务消费者程序通过服务接口使用服务,而服务接口通过代理加载具体的服务,具体服务可以是本地的代码模块,也可以是远程的服务,因此对应用较少入侵:

应用程序只需要调用服务接口,服务框架根据配置自动调用本地或远程实现。

服务框架客户端模块通过服务注册中心加载服务提供者列表,查找需要的服务接口,并根据配置的负载均衡策略将服务调用请求发送到某台服务提供者服务器。如果服务调用失败,客户端模块会自动从服务提供者列表选择一个可供同样服务的另一台服务器重新请求服务,实现服务的自动失效转移,保证服务高可用。

Dubbo的远程通信模块支持多种通信协议和数据序列化协议,使用NIO通信框架,具有较高的网络通信性能。

小结:

分布式服务应该有的功能,Dubbo基本上都提供了,Dubbo,优秀,值得学习。

作者: 元宝爸爸

出处:https://www.cnblogs.com/wozixiaoyao/p/11965398.html

版权:本文采用「署名-非商业性使用-相同方式共享 4.0 国际」知识共享许可协议进行许可。

觉得文章不错,点个关注呗!

原文地址:https://www.cnblogs.com/xinrong2019/p/11565044.html