Devil的个人博客

Spring Cloud-Config前言分布式系统面临的配置问题 微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、动态的配置管理设置是必不可少的。 Spring Cloud提供了ConfigServer来解决这个问题。 简介 是什么？Spring Cloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。 能干嘛？ 集中管理配置文件 不同环境不同配置，动态化的配置更新，分环境部署比如dev/test/prod/beta/release 运行期间动态调整配置，不再需要在每个服务部署的机器上配置文件，服务回向配置中心统一拉取配置自己的信息 当配置发生变动，服务不需要重启即可感知到配置的变化并应用新的配置。 将配置信息以REST接口的形式暴露 post、curl访问刷新即可 怎么使用？Spring Cloud Config分为客户端和服务端两个部分。 服务端也称为分布式配置中心，他是 ...

Spring Cloud-Gateway Spring Cloud全家桶中有一个很重要的组件就是网关，在1.x版本中都是采用Zuul网关; 但在2.x版本中，zuul的升级一直跳票，Spring Cloud最后自己研发了一个网关替代Zuul。Gateway是原Zuul1.x版的替代。 zuul官网：zuul-wiki Gateway官网：Spring Cloud Gateway 简介Gateway是在Spring生态系统之上构建的API网关服务，基于Spring 5，Spring Boot2和 Project Reactor等技术。 Gateway旨在提供一种简单而有效的方式来对API进行路由，以及提供一些强大的过滤器功能，例如：熔断、限流、重试等。 This project provides an API Gateway built on top of the Spring Ecosystem, including: Spring 5, Spring Boot 2 and Project Reactor. Spring Cloud Gateway aims to prov ...

Spring Cloud-Hystrix前言分布式系统面临的问题 复杂分布式体系结构中的应用有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。 服务雪崩多个微服务之间调用的时候，假设微服务A调用微服务B和C，微服务B和微服务C又调用其他的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。 对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的时，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用或系统。 所以， 通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题得模块还调用了其他得模块，这样就会发生级联故障，或者叫雪崩。 简介Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时 ...

Spring Cloud-OpenFeign简介 Feign is a declarative web service client. It makes writing web service clients easier. To use Feign create an interface and annotate it. It has pluggable annotation support including Feign annotations and JAX-RS annotations. Feign also supports pluggable encoders and decoders. Spring Cloud adds support for Spring MVC annotations and for using the same HttpMessageConverters used by default in Spring Web. Spring Cloud integrates Eureka, Spring Cloud CircuitBreaker, as wel ...

Spring Cloud-Ribbon简介Spring Cloud Ribbon是基于NetFlix Ribbon实现的一套客户端 均衡负载工具 Ribbon = 负载均衡 + RestTemplate 简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法和服务调用。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面的所有机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们很容易使用Ribbon实现自定义的负载均衡算法。 Netflix-Ribbon-wiki 注意：Ribbon已经进入了维护阶段，Spring Cloud意向使用LoadBalancer替换 LB负载均衡（Load Balance）是什么简单的说就是将用户的请求平摊的分配到多个服务上，从而达到HA（高可用）。 常见的负载均衡右软件Nginx、LVS、硬件 F5等。 集中式LB即在服务的消费方和提供方之间使用独立的LB设施（可以是硬件，如F5，也 ...

Spring Cloud-ConsulConsul官网 Consul中文文档 Spring Cloud Consul 中文文档 参考手册 中文版 简介 Consul is a service mesh solution providing a full featured control plane with service discovery, configuration, and segmentation functionality. Each of these features can be used individually as needed, or they can be used together to build a full service mesh. Consul requires a data plane and supports both a proxy and native integration model. Consul ships with a simple built-in proxy so that everything works out of th ...

CAP理论CAP理论告诉我们，一个分布式系统不可能同时满足以下三种 ⚫ 一致性（C:Consistency） ⚫ 可用性（A:Available） ⚫ 分区容错性（P:Partition Tolerance） 这三个基本需求，最多只能同时满足其中的两项，因为P是必须的，因此往往选择就在CP或者AP中。 一致性（C:Consistency） 在分布式环境中，一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。 可用性（A:Available） 可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。 分区容错性（P:Partition Tolerance） 分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。 ZooKeeper保证的是CP ZooKeeper不能保证每次服务请求的可用性。（注：在极端环境下，ZooKeeper可能会丢弃一些请求，消 ...

Zookeeper Atomic Broadcast(Zookeeper 原子广播协议)什么是ZAB算法Zab借鉴了Paxos算法(Multi Paxos)，是特别为Zookeeper设计的支持崩溃回复的原子广播协议。基于该协议，Zookeeper设计了为只有一台客户端(Leader)负责处理外部的写事务请求，然后Leader客户端将数据同步到其他Follower节点。即Zookeeper只有一个Leader可以发起提案。 ZAB协议内容ZAB协议包括两种基本的模式：消息广播、崩溃恢复。 消息广播 客户端发起一个写操作请求。 Leader服务器将客户端的请求转化为事务Proposal提案，同时为每个Proposal分配一个全局ID，即zxid Leader服务器为每个Follower服务器分配一个单独的队列，然后将需要广播的Proposal依次放到队列中去，并且根据FIFO策略进行消息发送。 Follower接受到Proposal后，会首先将起以事务日志的方式是写入本地磁盘中，写入成功后向Leader反馈一个Ack响应消息 Leader接收到超过半数以上Follower的Ack响应消 ...

Paxos-wiki(转载)Paxos算法是莱斯利·兰伯特（英语：Leslie Lamport，LaTeX中的“La”）于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。本文是对维基百科上Paxos算法文献的翻译。 假设条件为了简化 Paxos 的介绍, 先明确以下假设和定义。 Processors Processors 以任意速度运行。 Processors 可能会遇到故障。 具有稳定存储的 Processors 在失败后可以重新加入协议（遵循崩溃-恢复故障模型）。 不会发生拜占庭将军问题。 Network 每个 Processor 可以将消息发送到其它任何 Processor。 消息是异步发送的，可能要花很长时间才能发出。 消息可能会丢失、乱序或重复。 消息在发送过程中没有损坏（即没发生拜占庭式故障）。 Processor的数量通常，使用 n=2F+1 个 Processor 可以在 F 个 Processor 同时发生故障时依然保持共识算法的正常运行：换句话说，非故障的 Processor 数量必须大于故障的 Processor 数量。然而，采用重新 ...

Paxos算法详解前言–拜占庭将军问题在介绍共识算法之前，先介绍一个简化版拜占庭将军的例子来帮助理解共识算法。 假设多位拜占庭将军中没有叛军，信使的信息可靠但有可能被暗杀的情况下，将军们如何达成是否要进攻的一致性决定？ 解决方案大致可以理解成：先在所有的将军中选出一个大将军，用来做出所有的决定。 举例如下：假如现在一共有 3 个将军 A，B 和 C，每个将军都有一个随机时间的倒计时器，倒计时一结束，这个将军就把自己当成大将军候选人，然后派信使传递选举投票的信息给将军 B 和 C，如果将军 B 和 C 还没有把自己当作候选人（自己的倒计时还没有结束），并且没有把选举票投给其他人，它们就会把票投给将军 A，信使回到将军 A 时，将军 A 知道自己收到了足够的票数，成为大将军。在有了大将军之后，是否需要进攻就由大将军 A 决定，然后再去派信使通知另外两个将军，自己已经成为了大将军。如果一段时间还没收到将军 B 和 C 的回复（信使可能会被暗杀），那就再重派一个信使，直到收到回复。 背景Paxos是什么? Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式 ...