王加伦的技术分享

服务雪崩 服务雪崩效应是一种因“服务提供者的不可用”（原因）导致“服务调用者不可用”（结果），并将不可用逐渐放大的现象 如下图： 一个服务失败，导致整条链路的服务都失败的情形，我们称之为服务雪崩 我把服务雪崩的参与者简化为 服务提供者 和 服务调用者，并将服务雪崩产生的过程分为以下三个阶段来分析形成的原因: 服务提供者不可用 重试加大流量 服务调用者不可用 服务雪崩的每个阶段都可能由不同的原因造成，比如造成 服务不可用 的原因有: 硬件故障 程序 Bug 缓存击穿 用户大量请求 硬件故障可能为硬件

自我保护机制 当EurekaServer与EurekaClient网络不通的情况下，EurekaServer不会将EurekaClient服务剔除。 通过一个场景来了解一下： 有两个服务：用户服务app-user、订单服务app-order，用户服务做了集群，有两台机器，分别是8010和8011 现在order使用负载均衡的轮询机制，调用user的接口，可以看到是8010和8011轮询访问的。 那如果现在8010这台服务宕机了，会是什么情况？ ​ 当访问8010的时候，就报错了，我们再看一下Eureka

搭建服务提供者 新建maven项目配置pom 引入eureka客户端 <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency&gt

创建复合maven工程 父项目配置pom文件 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http:/..

分布式系统CAP定理 分布式系统协议只能在CAP这三者间有所折中。 Consistenct (强一致性）也称原子一致性/线性一致性 在任意时刻，更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。 强一致性 顺序一致性 任何一次读都能读到某个数据的最近一次写的数据。 系统的所有进程的顺序一致，而且是合理的。即不需要和全局时钟下的顺序一致，错的话一起错，对的话一起对。 弱一致性 系统中的某个数据被更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值。

文章目录优点缺点采不采用微服务 优点 快速响应变更 单一职责 独立部署 独立拓展 边界清晰 不过度受制于技术栈 精细粒度业务控制 降级熔断 局部限流 面向业务/领域模型 不依赖数据模型 易于抽象 缺点 部署结构复杂 模块众多 额外组件 依赖平台支撑 依赖微服务组件 研发成本 分布式问题 一致性 异常补偿 拆分的水平 粒度过粗/过细 采不采用微服务 业务规模 （成本收益） 预期迭代的次数以及需要的效率 研发团队配置 业务领域 （服务如何拆分以及粒度）