浅析分布式系统(一)

1. 分布式系统

1.1 集中式系统

集中式系统用一句话概括就是:一个主机带多个终端。终端没有数据处理能力,仅负责数据的录入和输出。而运算、存储等全部在主机上进行。

特点

集中式系统的最大的特点就是部署结构非常简单,底层一般采用从IBM、HP等厂商购买到的昂贵的大型主机。因此无需考虑如何对服务进行多节点的部署,也就不用考虑各节点之间的分布式协作问题。

但是,由于采用单机部署。很可能带来系统大而复杂、难于维护、发生单点故障(单个点发生故障的时候会波及到整个系统或者网络,从而导致整个系统或者网络的瘫痪)、扩展性差等问题。

正是由于集中式系统的问题在大量互联网中变得极为显著,因此诞生出分布式系统架构的使用必要性。

1.2 分布式系统(distributed system)

在《分布式系统概念与设计》一书中,对分布式系统做了如下定义:

分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。

简单来说就是一群独立计算机集合共同对外提供服务,但是对于系统的用户来说,就像是一台计算机在提供服务一样。

一个标准的分布式系统应该具有以下几个主要特征

  • 分布性

    分布式系统中的多台计算机之间在空间位置上可以随意分布,系统中的多台计算机之间没有主、从之分,即没有控制整个系统的主机,也没有受控的从机。

  • 透明性

    系统资源被所有计算机共享。每台计算机的用户不仅可以使用本机的资源,还可以使用本分布式系统中其他计算机的资源(包括CPU、文件、打印机等)。

  • 同一性

    系统中的若干台计算机可以互相协作来完成一个共同的任务,或者说一个程序可以分布在几台计算机上并行地运行。

  • 通信性

    系统中任意两台计算机都可以通过通信来交换信息。

和集中式系统相比,分布式系统的性价比更高、处理能力更强、可靠性更高、也有很好的扩展性。

但是,分布式在解决了网站的高并发问题的同时也带来了一些其他问题:

首先,分布式的必要条件就是网络,这可能对性能甚至服务能力造成一定的影响。其次,一个集群中的服务器数量越多,服务器宕机的概率也就越大

另外,由于服务在集群中分布式部署,用户的请求只会落到其中一台机器上,所以,一旦处理不好就很容易产生数据一致性问题

2. 分布式系统关联的实际问题

说一下dubbo的工作原理?注册中心挂了可以继续通信吗?说说一次rpc请求的流程?

分布式系统的架构离不开分布式消息中间件、分布式搜索引擎、分布式缓存、RPC框架相关的问题:

  • 原理性问题

    kafka高可用架构原理、es分布式架构原理、redis线程模型原理、Dubbo工作原理。及这些技术的高级应用和特性。

  • 新技术的新问题

    每种技术引入之后生产环境都可能会碰到一些问题。

  • 如何自己设计系统

    如何自己设计MQ、如何自己设计搜索引擎,如何自己设计缓存,如何自己设计RPC框架

一般来说结合项目死扣细节是严格的面试官习惯的面试模式:

百度:深入底层、基础性;

阿里:结合项目死扣细节,扣很深的技术底层;

小米:数据结构和算法。

3. RPC(远程过程调用)

3.1 RPC

RPC,即 Remote Procedure Call(远程过程调用),是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程。

通俗表述就是:A计算机提供一个服务,B计算机可以像调用本地服务那样调用A计算机的服务。

通过上面的概念可知,实现RPC主要是做到两点:

(1)实现远程调用其他计算机的服务

要实现远程调用,肯定是通过网络传输数据。A程序提供服务,B程序通过网络将请求参数传递给A,A本地执行后得到结果,再将结果返回给B程序。因此需要考虑:

  • 采用何种网络通讯协议?

现在比较流行的RPC框架,都会采用TCP作为底层传输协议。

  • 数据传输的格式怎样?

两个程序进行通讯,必须约定好数据传输格式。另外数据在网路中传输需要进行序列化,所以还需要约定统一的序列化的方式。

(2)像调用本地服务一样调用远程服务

如果仅仅是远程调用,还不算是RPC,因为RPC强调的是过程调用,调用的过程对用户而言是应该是透明的,用户不应该关心调用的细节,可以像调用本地服务一样调用远程服务。所以RPC一定要对调用的过程进行封装。

3.2 HTTP

Http协议,超文本传输协议,是一种应用层协议。规定了网络传输的请求格式、响应格式、资源定位和操作的方式等。但是底层采用什么网络传输协议,并没有规定,不过现在都是采用TCP协议作为底层传输协议。

综上,Http与RPC的远程调用非常像,都是按照某种规定好的数据格式进行网络通信,有请求有响应。两者非常相似,但是还是有一些细微差别。

3.4 http 和 RPC 的区别

1)RPC并没有规定数据传输格式,这个格式可以任意指定,不同的RPC协议,数据格式不一定相同。

2)Http中还定义了资源定位的路径,RPC中并不需要

3)最重要的区别,RPC需要满足像调用本地服务一样调用远程服务,也就是对调用过程在API层面进行封装。Http协议没有这样的要求,因此请求、响应等细节需要我们自己去实现。

通过对比可以看出:

RPC方式更加透明,对用户更方便。Http方式更灵活,没有规定API和语言,跨语言、跨平台。但RPC方式需要在 API 层面进行封装,限制了开发的语言环境。

3.3 常见实现框架

3.3.1 国内框架

Dubbo

阿里开源的一款高性能RPC框架,在国内应用广泛,期间停止维护过一段时间,如今又开始了更新,并且捐献给Apache基金会,孵化中。

由于 spring cloud 全家桶的出现,也有很多公司转向 spring cloud 快速开发微服务。

Dubbox

当当团队基于Dubbo升级的一个版本,支持RESTful风格API的远程调用,基于Kryo/FST的Java高效序列化实现等功能,可直接用于生产环境。

Motan

新浪微博于2016年开源,”在微博平台中已经广泛应用,每天为数百个服务完成近千亿次的调用”。

3.3.2 国外框架

GRPC

Google开源,具有平台无关性,基于http/2协议,支持服务追踪、负载均衡、健康检查等功能。

Thrift

可伸缩的跨语言服务的RPC软件框架,最早由Facebook开发,2007年捐献给了Apache基金会管理,现在是Apache的顶级项目。

Finagle

Twitter基于Netty开发的支持容错的、协议无关的RPC框架,支撑了Twitter的核心服务。

4. Dubbo

4.1 框架设计

图例说明:

1)图中左边淡蓝背景的为服务消费方使用的接口,右边淡绿色背景的为服务提供方使用的接口,位于中轴线上的为双方都用到的接口。

2)图中从下至上分为十层,各层均为单向依赖,右边的黑色箭头代表层之间的依赖关系,每一层都可以剥离上层被复用,其中:Service 和 Config 层为 API,其它各层均为 SPI。

SPI 全称为 Service Provider Interface,是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中,并由服务加载器读取配置文件,加载实现类。这样可以在运行时,动态为接口替换实现类。

SPI 在java.util.ServiceLoader的文档里有比较详细的介绍。

不过,Dubbo 并未使用 Java 原生的 SPI 机制,而是对其进行了增强,使其能够更好的满足需求。如果想要学习 Dubbo 的源码,SPI 机制务必弄懂。

Dubbo SPI 官方文档:http://dubbo.apache.org/zh-cn/docs/source_code_guide/dubbo-spi.html

3)图中绿色小块的为扩展接口,蓝色小块为实现类,图中只显示用于关联各层的实现类。

4)图中蓝色虚线为初始化过程,即启动时组装链,红色实线为方法调用过程,即运行时调时链,紫色三角箭头为继承,可以把子类看作父类的同一个节点,线上的文字为调用的方法。

4.2 各层说明

service 配置层

接口层,其接口的具体实现是由服务提供者和消费者自己来实现。

config 配置层

对外配置接口,以 ServiceConfig, ReferenceConfig 为中心,可以直接初始化配置类,也可以通过 spring 解析配置生成配置类

proxy 服务代理层

服务接口透明代理,生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy为中心,扩展接口为 ProxyFactory

registry 注册中心层

封装服务地址的注册与发现,以服务 URL 为中心,扩展接口为 RegistryFactory, Registry, RegistryService

cluster 路由层

封装多个提供者的路由及负载均衡,并桥接注册中心,以 Invoker 为中心,扩展接口为 Cluster, Directory, Router, LoadBalance

monitor 监控层

RPC 调用次数和调用时间监控,以 Statistics 为中心,扩展接口为 MonitorFactory, Monitor, MonitorService

protocol 远程调用层

封装 RPC 调用,以 Invocation, Result 为中心,扩展接口为 Protocol, Invoker, Exporter

exchange 信息交换层

封装请求响应模式,同步转异步,以 Request, Response 为中心,扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer

transport 网络传输层

抽象 mina 和 netty 为统一接口,以 Message 为中心,扩展接口为 Channel, Transporter, Client, Server, Codec

serialize 数据序列化层

可复用的一些工具,扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

官方参考文档:

架构设计:https://dubbo.apache.org/zh-cn/docs/dev/design.html

4.3 工作流程

第一步,provider注册中心注册。

第二步,consumer从注册中心订阅服务,注册中心会通知consumer注册成功的服务。

第三步,consumer调用provider提供接口。

第四步,consumer和provider都异步的通知监控中心。

官方参考文档:

服务调用过程:https://dubbo.apache.org/zh-cn/docs/source_code_guide/service-invoking-process.html

4.4 通信协议

dubbo支持哪些通信协议?支持哪些序列化协议?

4.4.1 dubbo://

Dubbo 缺省协议采用单一长连接NIO 异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。

反之,Dubbo 缺省协议不适合传送大数据量的服务,比如传文件,传视频等,除非请求量很低。

4.4.2 hessian://

Hessian 协议用于集成 Hessian 的服务,Hessian 底层采用 Http 通讯,采用 Servlet 暴露服务,Dubbo 缺省内嵌 Jetty 作为服务器实现。

Hessian 是 Caucho 开源的一个 RPC 框架,其通讯效率高于 WebService 和 Java 自带的序列化。

Dubbo 的 Hessian 协议可以和原生 Hessian 服务互操作,即:

  • 提供者用 Dubbo 的 Hessian 协议暴露服务,消费者直接用标准 Hessian 接口调用
  • 或者提供方用标准 Hessian 暴露服务,消费方用 Dubbo 的 Hessian 协议调用。

官方参考文档:

协议参考手册:https://dubbo.apache.org/zh-cn/docs/user/references/protocol/introduction.html

性能测试报告:https://dubbo.apache.org/zh-cn/docs/user/perf-test.html

4.5 负载均衡

dubbo负载均衡策略和集群容错策略都有哪些?动态代理策略呢?

Dubbo 提供了 4 种负载均衡实现,分别是:

基于权重随机算法的RandomLoadBalance

基于最少活跃调用数算法的LeastActiveLoadBalance

基于 hash 一致性的ConsistentHashLoadBalance

基于加权轮询算法的RoundRobinLoadBalance

官方参考文档:

负载均衡源码分析:http://dubbo.apache.org/zh-cn/docs/source_code_guide/loadbalance.html

Dubbo的负载均衡:http://dubbo.apache.org/zh-cn/blog/dubbo-loadbalance.html

4.6 集群容错

4.6.1 集群容错策略

在集群调用失败时,Dubbo 提供了多种容错方案,缺省为 failover 重试。

各节点关系:

  • 这里的 InvokerProvider 的一个可调用 Service 的抽象,Invoker 封装了 Provider 地址及 Service 接口信息
  • Directory 代表多个 Invoker,可以把它看成 List<Invoker> ,但与 List 不同的是,它的值可能是动态变化的,比如注册中心推送变更
  • ClusterDirectory 中的多个 Invoker 伪装成一个 Invoker,对上层透明,伪装过程包含了容错逻辑,调用失败后,重试另一个
  • Router 负责从多个 Invoker 中按路由规则选出子集,比如读写分离,应用隔离等
  • LoadBalance 负责从多个 Invoker 中选出具体的一个用于本次调用,选的过程包含了负载均衡算法,调用失败后,需要重选

Dubbo主要内置了如下几种策略:

4.6.1.1 Failover Cluster

失败自动切换,当出现失败,重试其它服务器。Dubbo 默认的容错策略。

4.6.1.2 Failfast Cluster

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

4.6.1.3 Failsafe Cluster

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

4.6.1.4 Failback Cluster

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

4.6.1.5 Forking Cluster

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

4.6.1.6 Broadcast Cluster

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

官方参考文档:

Design For failure:https://dubbo.apache.org/zh-cn/blog/dubbo-cluster-error-handling.html

集群容错:http://dubbo.apache.org/zh-cn/docs/user/demos/fault-tolerent-strategy.html

4.6.2 各种策略对比

下表对各种策略做一个简单对比:

策略名称 优点 缺点 主要应用场景
Failover 对调用者屏蔽调用失败的信息 增加RT,额外资源开销,资源浪费 对调用rt不敏感的场景
Failfast 业务快速感知失败状态进行自主决策 产生较多报错的信息 非幂等性操作,需要快速感知失败的场景
Failsafe 即使失败了也不会影响核心流程 对于失败的信息不敏感,需要额外的监控 旁路系统,失败不影响核心流程正确性的场景
Failback 失败自动异步重试 重试任务可能堆积 对于实时性要求不高,且不需要返回值的一些异步操作
Forking 并行发起多个调用,降低失败概率 消耗额外的机器资源,需要确保操作幂等性 资源充足,且对于失败的容忍度较低,实时性要求高的场景
Broadcast 支持对所有的服务提供者进行操作 资源消耗很大 通知所有提供者更新缓存或日志等本地资源信息

4.7 动态代理扩展

dubbo 的 SPI 思想是什么?

官方参考文档:

Dubbo可扩展机制实战:http://dubbo.apache.org/zh-cn/blog/introduction-to-dubbo-spi.html

动态代理扩展:http://dubbo.apache.org/zh-cn/docs/dev/impls/proxy-factory.html

4.7.1 Java SPI 机制

Java SPI(Service Provider Interface)是JDK内置的一种动态加载扩展点的实现。在ClassPath的META-INF/services目录下放置一个与接口同名的文本文件,文件的内容为接口的实现类,多个实现类用换行符分隔。JDK中使用java.util.ServiceLoader来加载具体的实现。

4.7.2 Dubbo 的 SPI 机制

Java SPI的使用很简单。也做到了基本的加载扩展点的功能。但Java SPI有以下的不足:

  • 需要遍历所有的实现,并实例化,然后我们在循环中才能找到我们需要的实现。
  • 配置文件中只是简单的列出了所有的扩展实现,而没有给他们命名。导致在程序中很难去准确的引用它们。
  • 扩展如果依赖其他的扩展,做不到自动注入和装配
  • 不提供类似于Spring的IOC和AOP功能
  • 扩展很难和其他的框架集成,比如扩展里面依赖了一个Spring bean,原生的Java SPI不支持

所以Java SPI应付一些简单的场景是可以的,但对于Dubbo,它的功能还是比较弱的。Dubbo对原生SPI机制进行了一些扩展。接下来,我们就更深入地了解下Dubbo的SPI机制。

4.7.3 Dubbo 的 SPI 的特点:

1)对Dubbo进行扩展,不需要改动Dubbo的源码

2)自定义的Dubbo的扩展点实现,是一个普通的Java类,Dubbo没有引入任何Dubbo特有的元素,对代码侵入性几乎为零。

3)将扩展注册到Dubbo中,只需要在ClassPath中添加配置文件。使用简单。而且不会对现有代码造成影响。符合开闭原则。

4)Dubbo的扩展机制设计默认值:@SPI(“dubbo”) 代表默认的spi对象

5)Dubbo的扩展机制支持IoC,AoP等高级功能

6)Dubbo的扩展机制能很好的支持第三方IoC容器,默认支持Spring Bean,可自己扩展来支持其他容器,比如Google的Guice。

7)切换扩展点的实现,只需要在配置文件中修改具体的实现,不需要改代码。使用方便。

4.7.4 如何扩展dubbo中的组件

首先自己实现org.apache.dubbo.rpc.Protocol接口,比如实现类叫:org.woodwhales.dubbo.MyProtocol,这个实现类可以是本地jar,也可以是pom.xml 依赖的远程jar。

随后将这个jar 信息配置到 dubbo 配置中:

1
2
3
4
5
6
<!-- 声明协议,如果没有配置id,将以name为id -->
<dubbo:protocol id="myProtocol_Id" name="myProtocol" />
<!-- 引用协议,如果没有配置protocol属性,将在ApplicationContext中自动扫描protocol配置 -->
<dubbo:service protocol="myProtocol_Id" />
<!-- 引用协议缺省值,当<dubbo:service>没有配置prototol属性时,使用此配置 -->
<dubbo:provider protocol="myProtocol_Id" />

最后,需要在META-INF配置文件中创建一个名称为:org.apache.dubbo.rpc.Protocol的配置文件,里面写上name对应的类全名:

如:

META-INF/dubbo/org.apache.dubbo.rpc.Protocol:

1
myProtocol=org.woodwhales.dubbo.MyProtocol

官方参考文档:http://dubbo.apache.org/zh-cn/docs/dev/impls/protocol.html

4.8 服务治理

如何基于dubbo进行服务治理、服务降级、失败重试以及超时重试?

服务治理是一个很复杂且很需要话费精力去研究的课题,一般会从以下方面进行课题研究:

1)调用链路自动生成

一个大型的分布式系统或微服务架构,其系统是由大量的服务组成。那么这些服务之间互相是如何调用的?调用链路是怎么样的?就需要基于dubbo做的分布式系统中,对各个服务之间的调用自动记录下来,然后自动将各个服务之间的依赖关系和调用链路生成出来,做成一张可视化的图,方便查看当前服务的运行情况。

dubbo 服务治理官方参考文档:

服务治理和配置管理:http://dubbo.apache.org/zh-cn/docs/admin/serviceGovernance.html

2)服务访问压力以及时长统计

需要自动统计各个接口和服务之间的调用次数以及访问延时,而且要分成两个级别。

一个级别是接口粒度,就是每个服务的每个接口每天被调用多少次,TP50,TP90,TP99,三个档次的请求延时分别是多少;

第二个级别是从源头入口开始,一个完整的请求链路经过几十个服务之后,完成一次请求,每天全链路走多少次,全链路请求延时的TP50,TP90,TP99,分别是多少。

这些东西都搞定了之后,后面才可以来看当前系统的压力主要在哪里,如何来扩容和优化。

3)其他

服务分层(避免循环依赖),调用链路失败监控和报警,服务鉴权,每个服务的可用性的监控(接口调用成功率?几个9?)99.99%,99.9%,99%。

4.9 服务降级

比如服务A调用服务B,结果服务B挂掉了,暂停了服务,此时服务A会重试多次尝试继续调用服务B,发现一直无法正常调用,那么就需要将服务A采取降级措施:让服务A执行一个备用的逻辑,给用户返回响应。

Dubbo 中可以在消费者的配置一个本地伪装的mock服务。

官方参考文档:

本地伪装:http://dubbo.apache.org/zh-cn/docs/user/demos/local-mock.html

服务降级:http://dubbo.apache.org/zh-cn/docs/user/demos/service-downgrade.html

4.10 失败/超时重试

Dubbo启动时默认有重试机制和超时机制。 超时机制的规则是如果在一定的时间内,provider没有返回,则认为本次调用失败, 重试机制在出现调用失败时,会再次调用。如果在配置的调用次数内都失败,则认为此次请求异常,抛出异常。

重试机制带来的问题

由于服务响应慢,Dubbo自身的超时重试机制可能会带来一些麻烦,常见的应用场景故障:重复发送邮件 、重复账户注册。

解决方案

1)对于核心的服务中心,去除dubbo超时重试机制,并重新评估设置超时时间。

去掉超时重试机制 :

1
<dubbo:provider delay="-1" timeout="6000"  retries="0"/>

重新评估设置超时时间:

1
<dubbo:service interface="*.*" ref="*"  timeout="延长服务时间"/>

2)业务处理代码必须放在服务端,客户端只做参数验证和服务调用,不涉及业务流程处理。

5. 幂等性

分布式服务接口的幂等性如何设计(比如不能重复扣款)?

幂等性问题不是技术问题,这个问题没有通用方法,需要结合业务来看应该如何保证幂等性。

基于唯一标识,存到缓存中或者存到数据库中,因此每次操作就有了一个操作日志。当第一个操作请求操作了就记录下来,下一个相同的操作发现有这个操作的日志,那么就不再执行这次操作。

6. 顺序性

对于数据顺性不严格的情况下,可以使用算法将同一个操作的相同操行都 hash 到同一个节点中,节点机器系统的内部使用内存队列来顺序执行操作,这样能很大程度保证数据的顺序性。

如果对数据的顺序性十分严格,那么就需要使用到分布式锁 + 消息中间件,但是这样会使得高并发的性能降低。

7.如何自己设计一个RPC框架

7.1 实现思路

  • RPC有两个使用方式:一个是本地调用端,一个是远程实现端
  • 调用端使用动态代理,代理消费者需要远程调用的接口。
  • 将本地调用的接口方法信息(形参,方法名,返回类型等)通过网络发送至远程实现端。
  • 远程实现端接收到相应信息,反射调用对象的实现类。
  • 执行完实现类后把返回值发回给调用端。
  • 调用端接收到返回值,代理返回结果,远程调用完毕。

7.2 实现细节问题

远程调用要解决的主要/细节问题:

1)序列化 : 如何将对象转化为二进制数据进行传输,如何将二进制数据转化对象。

可以使用java自带的序列化,Hessian,protobuff,json,xml等

性能比较高的是protobuffhessianprotobuff使用的时候需要编写proto文件,有侵入性,比较麻烦,而Hessian性能比protobuff稍差,不过近来出现了一个基于protobuff的框架:protostuff--不用编写proto文件,基于注解,性能可以,推荐使用。

2)数据的传输(协议,第三方框架,如netty)

出于并发性能的考虑,传统的阻塞式 IO 显然不太合适,因此我们需要异步的 IO,即 NIO。Java 提供了 NIO 的解决方案,Java 7 也提供了更优秀的NIO.2支持。可以选择Netty或者mina来解决 NIO 数据传输的问题。

3)服务的注册/发现,单点故障,分布式服务

使用ZooKeeper提供服务注册与发现功能,解决单点故障以及分布式部署的问题(注册中心)

4)服务的监控和管理

需要单独开发一个应用对服务进行监控和管理。

8. 扩展资料

用大白话聊聊分布式系统

分布式系统理论 - 从放弃到入门

大家都在说的分布式系统到底是什么?

学习分布式系统需要怎样的知识?

[分布式系统]全面介绍分布式系统

分布式系统原理介绍

分布式学习最佳实践:从分布式系统的特征开始(附思维导图)

什么是分布式系统,如何学习分布式系统

详解分布式系统本质:“分治”和“冗余”

美团即时物流的分布式系统架构设计

认识分布式架构

《大规模分布式存储系统》学习笔记

分布式系统简介

原生分布式数据库与中间件的区别

分布式系统 - 体系结构

我理解的分布式系统-饿了么物流技术团队

一文详解:如何设计出高可用的分布式架构?

各大厂分布式链路跟踪系统架构对比

分布式架构系统拆分原则、需求、微服务拆分步骤

核心银行系统分布式架构转型

基于服务的分布式事务(上篇)

分布式架构的概述

图解分布式系统架构演进之路

左耳朵耗子推荐:分布式系统架构经典资料

聊聊分布式系统的架构套路

分布式系统的特点以及设计理念

以电商网站为例,谈大型分布式架构设计与优化

分布式系统的架构思路

分布式系统

《大型网站系统与Java中间件》读书笔记(上)

分布式系统之学习资源推荐

一文讲透分布式系统的精髓

分布式存储系统 知识体系

《分布式java应用》读书笔记–第六章

如何给老婆解释什么是RPC

RPC原理及RPC实例分析

RPC和HTTP

simpleRpc解析-服务端

RPC简介及框架选择

关于RPC协议的通俗理解

如何理解RPC

既然有 HTTP 请求,为什么还要用 RPC 调用?

HTTP,TCP, socket,RPC 与gRPC都是啥?

谁能用通俗的语言解释一下什么是 RPC 框架?

体系化认识 RPC

深入浅出 RPC - 浅出篇

深入浅出 RPC - 深入篇

深入理解RPC之协议篇

深入理解 RPC 消息协议设计

深入理解 RPC)

深入理解 RPC 专题

架构师之路 - RPC 理解

解密Dubbo:自己动手编写RPC框架

你应该知道的RPC原理

Http和RPC区别

RPC、HTTP、Socket区别

关于RPC、HTTP、WebService的区别

微服务调用为啥用RPC框架,Http不更简单吗?

HTTP-RPC:轻量级跨平台 REST 框架

《RabbitMQ官方指南》RPC

远程调用方式 ==> RPC与Http的比较

微服务(概念篇):什么是微服务?一篇文章让你彻底搞明白

高级开发必须理解的Java中SPI机制

服务治理框架dubbo上手指南

谈Dubbo服务框架

dubbo 序列化机制之 hessian2序列化实现原理分析

在Dubbo中使用高效的Java序列化(Kryo和FST)

hessian学习基础篇——序列化和反序列化

hessian序列化源码分析

浅析Hessian协议

Hessian Lite序列化简析

dubbo源码解析(四十二)序列化——开篇

dubbo典型协议、传输组件、序列化方式组合性能对比测试

基于dubbo框架下的RPC通讯协议性能测试

Java学习之路-Hessian学习

Hessian的使用以及理解

Hessian原理分析

分布式服务架构之Hessian原理分析(一)

dubbo高可用:负载均衡机制(十二)

Dubbo的负载均衡

Dubbo学习笔记7:Dubbo的集群容错与负载均衡策略

【Dubbo源码分析】四种负载均衡

深入浅出微服务框架dubbo(三):流程篇

Dubbo的负载均衡

Dubbo学习源码总结系列四–集群容错机制

Dubbo负载均衡与集群容错机制

Dubbo集群容错机制

理解 Dubbo SPI 扩展机制

Dubbo SPI机制详解

聊聊Dubbo(五):核心源码-SPI扩展

dubbo源码解析-从spi聊聊双亲委派机制

dubbo之SPI解析

深入剖析 dubbo spi 机制(一)——扩展点加载

dubbo SPI

深入理解Java SPI机制

dubbo SPI机制分析浅析

Dubbo扩展点加载机制 - ExtensionLoader

Dubbo实践(七)扩展点

dubbo 大白话系列-扩展点机制

分布式服务治理框架Dubbo

dubbo服务治理(一)降级

dubbo超时重试和异常处理

Dubbo 超时与重试的实现分析

什么是分布式系统中的幂等性

分布式系统互斥性与幂等性问题的分析与解决

什么是分布式系统中的幂等性

分布式系统中的幂等设计

高并发的核心技术-幂等的实现方案

分布式服务的幂等性设计

HTTP幂等性概念和应用 | 酷 壳 – CoolShell

分布式系统互斥性与幂等性问题的分析和解决

基于redis(lua)和zookeeper分布式锁(秒杀)实现,分布式接口幂等实现,分布式速率限制实现,分布式ID生成器实现

分布式系统的数据一致性和处理顺序问题

关于分布式系统的数据一致性问题(一)

关于分布式系统的数据一致性问题

谈谈分布式系统的一致性

小议分布式系统的一致性模型

分布式系统中的时间、时钟和事件顺序

分布式系统的一致性与共识性

分布式系统一致性的发展历史(一)

一致性杂谈

分布式系统:Lamport 逻辑时钟

分布式系统 - 一致性和复制

Zookeeper: 分布式过程协同技术详解

分布式系统与消息的投递

浅析分布式一致性模型

分布式原理

分布式存储:Partition 细节

第07课:分布式微服务架构体系详解——分布式一致性

几种一致性模型的分析

分布式锁以及三种实现方式

深入浅出Zookeeper(二) 基于Zookeeper的分布式锁与领导选举

自己用 Netty 实现一个简单的 RPC

y解读及如何设计一个简单的RPC框架

如何用一天时间实现自己的RPC框架

如何设计一个 RPC 系统

如何写一个RPC框架(一):关注点与我的实现

自己实现一个RPC框架

【远程调用框架】如何实现一个简单的RPC框架(一)想法与设计

设计RPC接口时,你有考虑过这些吗?

从 0 到 1 编写一个 RPC 框架 (基于 Zookeeper)

如何设计一个通讯协议

徒手撸框架–实现 RPC 远程调用

深入浅出RPC原理

微博平台的 RPC 服务化实践

高并发架构系列:如何从0到1设计一个类Dubbo的RPC框架

百亿级企业级 RPC 框架开源了!

RPCX: 一个用Go实现的类似Dubbo的分布式RPC框架

从motan看RPC框架设计

RPC消息协议设计

分布式服务框架XXL-RPC

七个步骤,带你快速读懂 RPC 框架原理

网易有钱RPC框架介绍

API设计,从RPC、SOAP、REST到GraphQL(一)

远程过程调用(RPC)详解

RPC - 麻雀虽小,五脏俱全

一文看懂微服务和常用的微服务落地技术

分布式系统笔记(1)-MapReduce-MapReduce/)

gRPC的那些事 - streaming

用GoLang实现微服务(一)

gRPC 使用 protobuf 构建微服务

gRPC官方文档(中文版)

rpc框架之gRPC 学习 - hello world

Google 开源 RPC 框架 gRPC 初探

Google gRPC学习笔记

gRPC的原理和使用

自定义RPC框架实战(一) 设计思路

Java打造RPC框架(一):思路

Java打造RPC框架(二):11个类实现简单Java RPC

【RPC高性能框架总结】7.手写rpc框架-整体设计思路

视频/专栏学习资料:

深入理解 RPC : 基于 Python 自建分布式高并发 RPC 服务

Java视频教程_Dubbo

2019Java微服务架构(SpringBoot+Dubbo+Zookeeper)

Dubbo教程-分布式项目实战演示

ZooKeeper分布式专题与Dubbo微服务入门

老司机带你在分布式系统下掌握编程式事务以及接口的幂等性设计精髓

手写RPC框架及原理分析

netty入门到精通(RPC实现)

如何手写RPC框架

手写实现千万级流量架构必备的RPC框架

RPC远程调用综合实战

Rpc架构设计分析与实现

分布式通信rpc教程

参考书籍:

《大型网站系统与Java中间件实践》

updated updated 2020-03-01 2020-03-01
本文结束感谢阅读

本文标题:浅析分布式系统(一)

本文作者:木鲸鱼

微信公号:木鲸鱼 | woodwhales

原始链接:https://woodwhales.cn/2019/07/01/037/

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

0%