Bus 2020-01-07 Bus 简介 Spring Cloud Bus（消息总线）通过一个轻量级的消息中间件可以连接分布式系统中的各个节点。可以使用该总线来广播某些状态的改变（比如配置信息发生变更）或其他管理指令，以下是 Bus 适用的场景： 一个事件，需要广播或者单独传递给某个接口。 配置更新了，但是其他系统不知道是否更新。 SpringCloud 默认使用 RabbitMQ 作为消息队列组件。 分布式配置中心 Config 结合 Bus 部署 MQ 服务 这里基于 Docker 部署 RabbitMQ docker pull rabbitmq:management #拉取镜像 docker run -d --hostname rabbit-host --name="myrabbitmq" -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin -p 5672:5672 -p 15672:15672 rabbitmq:3-management 访问控制台 http://192.168.31.210:15672/ config-c....
Config 2020-01-07 配置中心的由来 分布式系统中往往部署在 N 服务器上，逐一管理维护成本很高，所以配置中心应运而生。配置中心被用作集中管理不同环境（Dev、Test、Stage、Prod）和不同集群配置，以及在修改配置后将实时动态推送到应用上进行刷新。 #配置中心应具备的功能 OpenAPI 业务无关性 配置生效监控 一致性 K-V 存储 统一配置实时推送 配合灰度与更新 配置全局恢复、备份与历史 高可用集群 Spring Cloud Config Spring Cloud Config 是一个集中化外部配置的分布式系统，由服务端和客户端组成。它不依赖于注册中心，是一个独立的配置中心。 支持多种存储配置信息的形式：JDBC、Vault、Native、SVN、Git。 Git 版工作原理 客户端启动时候向 ConfigServer 发起请求 ConfigServer 接收服务端请求后，根据配置的仓库地址，将 Git 上的文件克隆到本地的一个临时目录中（此目录是一个 Git 的本地仓库目录）。 然后 ConfigServer 再读取本地文件返回给客户端（优点：Git 服务器网络故障，依然可以使....
Sleuth 2020-01-07 全链路监控 微服务架构下，服务按照不同的维度进行拆分，一次请求可能会涉及多个服务，并且可能由不同的团队开发，使用不同的编程语言，可能部署在几千个节点上，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。 APM（Application Performance Management），其中最出名的是谷歌公开的论文提到的 Dapper。Dapper 论文中对实现一个分布式跟踪系统提出了如下需求： 性能低损耗：分布式跟踪系统对服务的性能损耗应该尽可能做到可以忽略不计，尤其是对性能敏感的应用不能产生损耗。 对应用透明：即要求尽可能用非侵入的方式来实现跟踪，尽可能做到业务代码的低侵入，对业务开发人员应该做到透明化。 可伸缩性：是指不能随着微服务和集群规模的扩大而使分布式跟踪系统瘫痪。 跟踪数据可视化和迅速反馈：即要有可视化的监控界面，从跟踪数据收集、处理到结果的展现尽量做到快速，这样就可以对系统的异常状况作出快速反应。 持续监控：即要求分布式跟踪系统必须是 7 *24 小时工作的，佛足额将难以定位到系统偶尔抖动....
Zuul 2020-01-07 诞生背景 微服务架构将后端拆解成许多个单独的应用：看似清晰的服务拆分，实则杂乱无章，完成一个业务逻辑，需要到不同主机和不同端口上面调取接口。于是一个面向服务治理、服务编排的㢟出现了——微服务网关。 Zuul 是从设备和网站到后端应用程序所有请求的前门，为内部服务提供可配置的对外 URL 到服务的映射关系，基于 JVM 的后端路由器，其具备以下功能： 统一接入：智能路由、AB 测试、灰度测试、负载均衡、容灾处理、日志埋点 流量监控：限流处理、服务降级 安全防护：鉴权处理、监控、机器网络隔离 虽然 Zuul2.x 采用 Netty 有较大的性能提升，单改动较大，考虑到稳定性 Spring Cloud Finchley 继续沿用 Netflix Zuul 1.x 版本，另外由于 Spring Cloud Gateway 已经孵化成功，相较于 Zuul 在功能以及性能上都有明显提升，Pivotal 公司正在走一条“去 Netflix 化”的路线。 主流开源网关概览 入门案例 Maven 依赖 <dependency> <groupId>org.spring....
Hystrix 2020-01-07 服务可用性 复杂分布式体系结构中的服务具有多个依赖关系，每个依赖关系在某些时候都将不可避免地失败。如果主服务未能与这些外部故障隔离，则他们可能会收。 例如，对于依赖于 30 个服务的服务 A，其中每个服务的正常运行时间为 99.99％，服务 A 的最终可用性如下： 99.99^30 = 99.7％正常运行时间 十亿次请求中的 0.3％= 3,000,000 请求失败次数 每月平均 2 小时的服务宕机时间，即使所有依赖项都具有出色 99.99％的正常运行时间。 现实情况通常更糟。即使所有依赖项都表现良好，如果您没有为整个系统设计弹性，那么即使 0.01％停机时间对数十种服务中的每项服务的总体影响也相当于每月停机时间可能达到数小时。 分布式体系结构中服务之间的依赖问题 由业务原因在某一时刻，某服务并发请求骤增，导致该服务的延迟，响应过慢。 复杂分布式体系结构中的应用程序之间往往存在多层级联赖的关系，当 Provider 服务在某一时刻出现故障，如果 Consumer 服务如果没有与这些故障服务隔离，会导致 Consumer 服务也会出现请求堆积、资源占用、宕机不可....
