初识分布式、微服务、Dubbo

最新推荐文章于 2024-04-17 17:07:26 发布

傻元宝宝

最新推荐文章于 2024-04-17 17:07:26 发布

阅读量161

点赞数 1

分类专栏： java基础知识文章标签： dubbo 分布式微服务

本文链接：https://blog.csdn.net/weixin_51675791/article/details/128866628

版权

java基础知识专栏收录该内容

20 篇文章 0 订阅

订阅专栏

1.分布式系统简介

1.1大型互联网架构目标

传统企业级项目：小众群体、企业员工、性能要求不高，只需要功能实现、用户忍耐度高

|大型互联网项目：全体网民、大众群体、性能要求极高、速度要快、稳定性要好、不能出错、用户忍耐度低
|---------------特点：用户多、流量大、并发高、海量数据、易受攻击、功能繁琐、变更快
|---------衡量标准：
----------------------| 响应时间：执行一个请求从开始到收到数据的时间
----------------------|----吞吐量：单位时间内系统能处理的请求数
------------------------------------|每秒查询数
------------------------------------|每秒事务数
------------------------------------|一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
------------------------------------|一个页面的一次访问，只会形成一个TPS，但一次页面请求，可能产生多次对服务器的请求，就会有多个QPS
----------------------|— 并发数：
------------------------------------|并发连接数：客户端向服务端发出请求建立TCP连接，每秒服务器建立的TCP连接数量
------------------------------------|------请求数：每秒多少请求
------------------------------------|并发用户数：单位时间内有多少用户
|---------------目标：
----------------------|—高可用：长时间正常访问
----------------------|—高性能：快速访问
----------------------|—可伸缩：通过增加硬件提高处理能力、减少硬件降低处理能力
----------------------|高可扩展：低耦合、模块化、易于增加功能、易维护
----------------------|—安全性：安全访问、数据加密、安全存储
----------------------|—敏捷行：快速变更、随需应变、快速响应

1.2集群和分布式

集群：很多人干一件事

分布式：很多人干不一样的事，合起来干大事

     （多台机器部署：当一台机器挂掉时，其他机器还可以用）
     （分开部署：当一部分功能不够时，把对应的功能再部署一份）

1.3架构演进

在这里插入图片描述
（1）单体架构：把所有功能模块装在一个app，不拆分

优点：简单、开发部署方便、小项目
缺点：项目启动慢、可靠性差、可伸缩性差、扩展性和可维护性差、性能低

（2）垂直架构：垂直架构是指将单体架构中的多个模块拆分为多个独立的项目。形成多个独立的单体架构。

在这里插入图片描述

解决单体架构的问题
缺点：重复功能多

（3）分布式架构：分布式架构是指在垂直架构的基础上，将公共业务模块抽取出来，作为独立的服务供其他调用者消费，以实现服务的共享和重用。

RPC: Remote Procedure Call 远程过程调用。有非常多的协议和技术来都实现了RPC的过程。比如:HTTPREST风格，Java RMI规范、WebServiceSOAP协议Hession等等。

解决垂直架构的问题
缺点：服务的交叉调用时，服务提供方一旦产生变更，所有消费方都需要变更

（4）SOA架构：(Service-OrientedArchitecture，面向服务的架构)是一个组件模型它将应用程序的不同功能单元(称为服务)进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。

ESB:(Enterparise Servce Bus) 企业服务总线，服务中介。主要是提供了一个服务于服务之间的交互。ESB包含的功能如:负载均衡，流量控制，加处理，服务的监控，异常处理，监控告急等等。
在这里插入图片描述

	解决分布式架构的问题

（5）微服务架构：微服务架构是在SOA上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。微服务架构 =80%的SOA服务架构思想 +100%的组件化架构思想+ 80%的领域建模思想
在这里插入图片描述

特点:

服务实现组件化:开发者可以自由选择开发技术。也不需要协调其他团队
服务之间交互一般使用RESTAPI
去中心化:每个微服务有自己私有的数据库持久化业务数据
自动化部署:把应用拆分成为一个一个独立的单个服务，方便自动化部署、测试、运维

2.Dubbo

2.1简介

Dubbo是阿里巴巴开源的基于 Java 的高性能RPC（一种远程调用）分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

Dubbo最开始是一款RPC框架，随着功能越来越完善，现在Dubbo是一款Java服务框架。RPC是远程过程调用，RPC同时也是一种计算机通信协议，他可以从A机器调用B机器的程序，调用的时候就类似于调用本地程序一样方便。

其核心部分包含：
1、远程通讯：提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
2、集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
3、自动发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

2.2面试问答

1.Dubbo都有哪些特性
Dubbo具有负载均衡、服务超时处理、集群容错、服务降级、本地存根、本地伪装、参数回调、异步调用等特性。

2.Dubbo的负载均衡是怎么实现的
在Dubbo中，消费者调用服务者的时候会记录服务者的active，比如现在有一个消费者，有A、B两个服务者。
当消费者向A服务发送一条消息的时候，消费者自身会记录A服务的active会加1，当消费者接收到服务者A的相应结果后会将A服务的active减1。
而在消费者选择使用哪个服务者的时候正是根据每个服务者active的大小来判断的，首先选择active小的来调用。

3.Dubbo服务超时怎么设置吧，有什么要注意的
Dubbo可以在消费者和服务端都设置超时时间，消费者的超时时间是消费者发出消息后到消费者接收到消息的时间。
服务端的超时时间是服务端接收消息后到处理完毕后发出的时间。
需要注意的是消费端的时间尽量设置的要比服务端的时间要长，因为如果消费端设置的是2秒，服务端设置的是5秒，而服务执行就需要3秒，那么消费端肯定是超时了，但是这个时候服务端并没有超时，不会发生异常。

4.Dubbo的集群容错问题
集群容错是服务端有多个提供者，他们构成集群，当消费者调用服务端的时候服务端通过负载均衡策略选出一个提供者来提供服务，当调用这个服务者发生错误的时候，Dubbo后续采取了一系列策略。

Dubbo提供了多种集群容错模式。

Failover Cluster：失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries=“2” 来设置重试次数(不含第一次)。

Failfast Cluster：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

Failsafe Cluster ：失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

Failback Cluster：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

Forking Cluster：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=“2” 来设置最大并行数。

Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

3.附

RPC的简介
RPC(Remote Procedure Call Protocol)：远程过程调用

两台服务器A、B，分别部署不同的应用a,b。当A服务器想要调用B服务器上应用b提供的函数或方法的时候，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义传达调用的数据。
说白了，就是你在你的机器上写了一个程序，我这边是无法直接调用的，这个时候就出现了一个远程服务调用的概念。

RPC是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

RPC需要解决的问题

通讯问题：主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。
寻址问题：A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。
序列化与反序列化：当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。
同理，B服务器接收参数要将参数反序列化。B服务器应用调用自己的方法处理后返回的结果也要序列化给A服务器，A服务器接收也要经过反序列化的过程。