第六章 嵌入式服务治理方案

6.1 Dubbo

  6.1.1 Dubbo概述

    服务间基于RPC的方式调用。

  6.1.2 核心流程

    Dubbo中必有的核心概念只有服务提供者、服务消费者和注册中心这三个,治理中心以及监控中心并非必需品。

    服务提供者初始化后会向注册中心注册服务;服务消费者启动时向注册中心订阅服务。注册中心在服务提供者列表发生变化时将变化的内容主动通知给服务消费者。服务提供者和服务消费者在初次连通后,持有长连接,通过透明化的远程调用进行通信。

  6.1.3 注册中心

    大多数情况,Dubbo都是配合Zookeeper注册中心来使用的。

  6.1.4 负载均衡

    Dubbo采用客户端负载均衡方式,由服务消费者一方决定当前通信发送至哪个服务提供者。

    服务消费者启动时会从注册中心同步一份有效的服务提供者列表,缓存起来,当服务列表变化时,会更新。每次调用服务时,根据合适的负载均衡算法选择一个服务提供者。

    Dubbo的服务发现和负载均衡机制,有如下三个特征:

  • 弹性好:基于服务发现机制,动态、灵活、实时。
  • 高可用:去中心化的服务治理方案,注册中心挂了后,可以使用缓存。但是在注册中心挂了后,无法感知新上线的服务。
  • 性能优:服务提供者和消费者之间点对点直接连接,连接建立后无需断开。

    Dubbo支持随机、轮询(会导致大量请求阻塞在短板服务上)、最少活跃调用数和一致性哈希这四种负载均衡策略。

重点说一下一致性哈希:为了解决因特网中的热点(Hot spot)问题。

                比如:有4个服务器,每个都缓存图片,当定位一个图片时,为了避免访问四次,可以用取模运算的方式来决定图片的位置。但是问题是:当服务器增加或减少时,取模运算会导致所有的图片位置都不对,缓存在短时间内全部失效,叫缓存雪崩。为了避免这种情况,提出一致性哈希算法,目的是当服务器数量增加和减少时,图片缓存的位置不变,不会发生雪崩。                    

  6.1.5 远程通信

    Dubbo通信协议采用的是Java NIO实现的多路复用。对于每一个服务消费者来说,Dubbo协议的服务提供者会创建固定数量的长连接传输消息,有效减少握手次数,Dubbo通信协议使用线程池并发处理请求来增加并发效率。由于连接复用,传输大文件时带宽占用率高可能会成为系统瓶颈,因此Dubbo通信协议适合处理高并发的小数据量互联网请求,不适合处理视频、高清照片。 

  6.1.6 限流

    Dubbo服务提供者可以设置限流。

  6.1.7 治理中心

    提供一个可视化中心,辅助做运维工作。提供了分组查询、配置更改、加权降权、禁用启用、权限控制、负责人管理等运维功能。

  6.1.8 监控中心

  6.1.9 DubboX的扩展

    DubboX由当当网开源,X是extensions一词,是对Dubbo的扩展。

    Rest协议:Dubbo缺乏对RESTful风格支持。 DubboX弥补了这一缺憾。

              高新能序列化:序列化对远程调用的响应速度、吞吐量、网络带宽影响大。Dubbo支持的不算太好,DubboX进行了扩展。

6.2 Spring Cloud

  提供了一套云原生开发组件。

  6.2.1 概述

    Spring Cloud是基于Spring boot的嵌入式服务治理框架,建立在工程师熟悉约定的前提下。

  6.2.2 开发脚手架Spring Boot

    

  6.2.3 服务发现

  6.2.4 负载均衡

  6.2.5 熔断

  6.2.6 远程通信

原文地址:https://www.cnblogs.com/liufei1983/p/11504278.html

时间: 2024-10-08 21:11:27

第六章 嵌入式服务治理方案的相关文章

【第一章】 服务治理(Eureka)

Spring Cloud是一系列框架的集合,其基于Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,构建了服务治理(发现注册).配置中心.消息总线.负载均衡.断路器.数据监控.分布式会话和集群状态管理等功能,为我们提供一整套企业级分布式云应用的完美解决方案. Spring Cloud包含了多个子项目(针对分布式系统中涉及的多个不同开源产品),比如:Spring Cloud Config.Spring Cloud Netflix.Spring Cloud CloudFound

第八章 跨语言服务治理方案 Service Mesh

8.1 Service Mesh 概述 新兴的下一代微服务架构,被称为下一代微服务,同时也是云原生技术栈的代表技术之一. 8.1.1 Service Mesh的由来 从2016年到2018年,service mesh经历了从无到有的过程 8.1.2 Service Mesh的定义 服务网格是一个基础设施层,用于处理服务间通信.现代云原生应用有着复杂的服务拓扑结构,服务网格负责在这些拓扑结构中实现请求的可靠传递.实践中,服务网格通常被实现为一组轻量级网络代理,它们与应用程序部署在一起,对应用程序透

分布式服务治理框架Dubbo

前言 Dubbo是一个被国内很多互联网公司广泛使用的开源分布式服务治理框架,是一个非常全面的SOA基础框架,当当网在Dubbo基础上新增了一些功能,并将其命名为Dubbox(Dubbo eXtensions). 为什么需要Dubbo? 以前所有的业务处理,都在一个系统当中: 接着,这个大系统按照业务领域划分为N个业务系统: 各个业务系统之间不可避免需要交互,采用什么呢?HTTP的方式?WebService?... 我们将面临很多URL的管理,服务之间的调用链,依赖关系,服务的负载均衡.监控等等

个人学习分布式专题(二)分布式服务治理之Dubbo框架

目录 Dubbo框架 1.1 Dubbo是什么 1.2 Dubbo企业级应用示例(略) 1.3 Dubbo实现原理及架构剖析 1.4 Dubbo+Spring集成 Dubbo框架 1.1 Dubbo是什么:Dubbo是一个分布式服务框架,致力于提高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案.简单的说,dubbo就是个服务框架,如果没有分布式的需求,其实是不需要用的.告别web service模式中的WSdl,以服务者与消费者的方式在dubbo上注册. dubbo可满足的基本需求

【.NET Core项目实战-统一认证平台】第十六章 网关篇-Ocelot集成RPC服务

原文:[.NET Core项目实战-统一认证平台]第十六章 网关篇-Ocelot集成RPC服务 [.NET Core项目实战-统一认证平台]开篇及目录索引 一.什么是RPC RPC是"远程调用(Remote Procedure Call)"的一个名称的缩写,并不是任何规范化的协议,也不是大众都认知的协议标准,我们更多时候使用时都是创建的自定义化(例如Socket,Netty)的消息方式进行调用,相比http协议,我们省掉了不少http中无用的消息内容.因此很多系统内部调用仍然采用自定义

第三章 服务治理:Spring Cloud Eureka

Spring Cloud Eureka是Spring Cloud Netflix 微服务套件中的一部分,它基于Netflix Eureka做了二次封装,主要负责完成微服务架构中的服务治理功能.Spring Cloud 通过为Eureka增加了Spring Boot风格的自动化配置,我们只需通过引入依赖和注解配置就能让Spring Boot构建的微服务应用轻松的与Eureka服务治理体系进行整合. 服务治理: 服务治理可以说是微服务架构中最为核心和基础的模块,主要用来实现各个微服务实例的自动化注册

分布式的几件小事(六)dubbo如何做服务治理、服务降级以及重试

1.服务治理 服务治理主要作用是改变运行时服务的行为和选址逻辑,达到限流,权重配置等目的. ①调用链路自动生成 一个大型的分布式系统,会由大量的服务组成,那么这些服务之间的依赖关系和调用链路会很复杂,这就需要dubbo对多个服务之间的调用自动记录下来,生成一张图,显示出来. ②服务反复问压力以及时长统计 需要自动统计各个接口和服务之间的调用次数以及访问延时,而且要分成两个级别.一个级别是接口粒度,就是每个服务的每个接口每天被调用多少次,TP50,TP90,TP99,三个档次的请求延时分别是多少:

【RL-TCPnet网络教程】第2章 嵌入式网络协议栈基础知识

第2章        嵌入式网络协议栈基础知识 本章教程为大家介绍嵌入式网络协议栈基础知识,本章先让大家有一个全面的认识,后面章节中会为大家逐一讲解用到的协议. 基础知识整理自百度百科,wiki百科等. 2.1   初学者重要提示 2.2   TCP/IP协议栈简介 2.3   TCP/IP参考模型 2.4   OSI参考模型 2.5   RL-TCPnet和参考模型的对应关系 2.6   网络协议收录文件RFC 2.7   以太网和IEEE 802.3 2.8   网线相关知识 2.9   总

架构设计:系统间通信(15)——服务治理与Dubbo 上篇

1.上篇中"自定义服务治理框架"的问题 在之前的文章中(<架构设计:系统间通信(13)--RPC实例Apache Thrift 下篇(1)>.<架构设计:系统间通信(14)--RPC实例Apache Thrift 下篇(2)>),我们基于服务治理的基本原理,自己实现了一个基于zookeeper + thrift的服务治理框架.但实际上前文中我们自行设计的服务治理框架除了演示基本原理外,并没有多大的实际使用价值,因为还有很多硬性需求是没有实现的: 访问权限:在整个