SpringCloud 浅谈_mz_01
SpringCloud
- 1.2特性
- 1.3 引导应用程序上下文
- 1.4 微服务
- 1.5 微服务与传统服务架构说明：
- 1.5 服务异步消息模式
- TCC
##1 spring Cloud
Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。分布式系统的协调导致了样板模式, 使用Spring Cloud开发人员可以快速地支持实现这些模式的服务和应用程序。他们将在任何分布式环境中运行良好，包括开发人员自己的笔记本电脑，裸机数据中心，以及Cloud Foundry等托管平台。
1.2特性
- Spring Cloud专注于提供良好的开箱即用经验的典型用例和可扩展性机制覆盖。
- 分布式/版本化配置
- 服务注册和发现
- 路由
- service - to - service调用
- 负载均衡
- 断路器
- 分布式消息传递
1.3 引导应用程序上下文
一个Spring Cloud应用程序通过创建一个“引导”上下文来进行操作，这个上下文是主应用程序的父上下文。开箱即用，负责从外部源加载配置属性，还解密本地外部配置文件中的属性。这两个上下文共享一个Environment，这是任何Spring应用程序的外部属性的来源。Bootstrap属性的优先级高，因此默认情况下不能被本地配置覆盖。
您可以通过设置spring.cloud.bootstrap.enabled=false（例如在系统属性中）来完全禁用引导过程。
分布式服务架构原理、设计与实战
1.4 微服务
什么是微服务：
以开放一组小型服务的方式来开放一个独立的应用系统。其中每个小型服务都运行在自己的进程中。
并采取HTTP资源API这样的轻量机制来进行通信
这些服务围绕业务功能进行构建。并能通过全自动的部署机制来进行独立部署。
微服务的特性：
- 每个微服务都可以独立运行在自己的进程里
- 一些了独立运行的微服务共同构建起整个系统
- 每个服务为独立开发，一个微服务一般完成某个特定的功能，比如：
订单管理、用户管理等； - 微服务之间通过轻量的通信机制进行通信，例如rest api或者 rpc的方式进行调用。
1.5 微服务与传统服务架构说明：
- 微服务把每一个职责单 的功能放在 个独立的服务中
- 每个服务运行在一个单独的进程中。
- 每个服务有多个实例在运行，每个实例可以运行在容器化平台内，达到平滑伸缩的效 果。
- 每个服务有自己的数据存储，实际上，每个服务应该有自己独享的数据库、缓存、消息,队列等资源。
- 每个服务应该有自己的运营平台，以及独 的运 人员，这包括技术运维和业务运营人员：每个服务都高度自治，内部的变化对外透明。
- 每个服务都可根据性能需求独立地进行水平伸缩
1.5 服务异步消息模式
，同步调用模式在具体服务的调用链示意图如
调用的过程中会阻塞线程，如果服务提供方迟迟没有返回，则服务消费方会一直阻塞，在严重
情况下会撑满服务的线程池，出现雪崩效应。
因此，在构建微服务架构系统时，通常会梳理核 系统的最小化服务集合，这些核心的系统服务使用同步调用，而其他核心链路以外的服务可以使用异步消息队列进行异步化。
服务异步消息模式的架构
典型的案例就是在电商系统中，交易完成后向物流系统发起消息通知，通知物流系统发货，
###1.6 熔断模式
对于微服务系统也 样，当服务的输入负载迅速增加时 如果没有有效的措施对负载进行
熔断，则会使服务迅速被压垮，服务被压垮会导致依赖的服务都被压垮，出现雪崩效应，因此，
可通过模拟家庭的电路保险开关，在微服务架构中实现熔断模式。
###1.7 限流模式
- 计数器
通过原子变量计算单位时间的访问次数，如果超出某个阙值，则拒绝后续的请求。等到下一个单位时间再重新计数。 - 令牌桶
通过一个线程在单位时间内产生固定数量的令牌，然后令牌放入队列，每次请求调用需要从桶中拿取 个令牌，拿到令牌后才有资格执
行请求调用， 否则只能等到到令牌再执行，或者直接丢弃。
- 信号量
限流类似于生活中的漏洞，无论倒入多少油，下面有漏管的流量是有限的，实际上我们
应用层使用的信号量也可以实现限流。
public class SemaphoreExample {
private ExecutorService exec= Executors . newCachedThreadPool() ;
public static vo main(String[] args) {
final Semaphore sem =new Semaphore(S);
for (int index = 0; index < 20 ; index++) {
Runnable run= new Runnable() {
public void run() {
try {
／／获得许可
sem. acquire();
／／同时只有 个请求可以到达这里
Thread .sleep( (long) (Math.random()));
／／释放许可
sem .release();
System .out.println 剩余许可：” sem . availablePermi ts() ) ;
} catch (InterruptedException e) {
e.printStackTrace() ;
}
}
};
exec . execute(run) ;
}
exec.shutdown();
}
}
#2. 微服务Spring Cloud
###2.1 spring boot
通过使用 Spring Boot 可以很容易地创建独立的、具有高品质的基于 Spring 的应用程序，基于
Sping Boot 建的应用可以随时随地启动和运行 般只需要较少的配置和搭建环境的工作量。
以前jee时代
Spring Boot 的思路正好相反，它将容器嵌入自启动的 Jar 包中，在 Spring Boot 应用启动
时， 内部启动嵌入的容器，例如： Tomcat Jetty Ne町等，然后通过内嵌的服务器将应用中
提供的服务暴露。
###2.2 Netflix
Netflix Netflix 公司开发且合并到 Spring Cloud 项目中， 主要提供了服务发现、断路器和
监控、智能路由、客户端负载均衡、 易用 REST 客户端等服务化必需的功能
###2.3 Spring Cloud Netflix
Spring Cloud Netflix 集成了 Spring Boot 对微服务敏捷启动和发布的功能，以及 Netflix 提供
的微服务 管理和治理的能力 成为 个完美的微服务解决方案。在 Spring Cloud Netflix 平台
下，开发人员通过几个简单的注解配置即可完成 个大规模分布式系统的发布工作。
Spring Cloud Netflix 包括服务发现组件 Eureka 、容错性组件 Hystrix 、智能路由组件 Zuul
和客户端负载均衡组件 Ribbon。
- 服务在 Eureka 服务器实例上注册。
- Zuul 作为 个特殊的服务在 eureka上注册并发现服务。
- Zuul 作为网关、路由 ，将发现的服务导出给 PC 网站、 App 和开放平台使用。
- Ribbon 的 RestTemplate、 FeignClient 使用简单的服务调用的方法调用服务1 、服务2 等。
在这个微服务的使用流程中， Netflix 具有如下特点：
- 服务在 Eureka 实例中注册，由 Spring 管理的 Bean 来发现和调用
- 通过配置的方式可以启动嵌入式的 Eureka 服务器。
- Feign 客户端通过声明的方式即可导入服务代理
- Zuul 使用 Ribbon 服务实现客户端的负载均衡
- 通过声明的方式即可插入 Hystrix 的客户端
- 通过配置的方式即可启动 Hystrix 面板服务器
- Spring 环境中可以直接配置 Netflix 的组件
- Zuul 可以自动注册过滤器和路由器，形成 个反向代理服务器
- Hystrix 面板可以对服务的状态进行监控，并提供了容错机制
#3 分布式系统一致性的
案例 ：下订单和扣库存
电商系统中有 个经典的案例 即下订单和扣库存如何保持 如果先下订单，扣库存
失败，那么将会导致超卖；如果下订单不成功，扣库存成功，那么会导致少卖 这两种情
会导致运营成本增加，在严重情况下需要赔付。
案例 ：同步调用超时
服务化的系统间调用常常因为网络问题导致系统间调用超时，即使是网络状况很好的机房，
在亿次流量的基数下，同步调用超时也是家常便饭。系统 同步调用系统 超时，系统
以明确得到超时反馈，但是无法确定系统 是否已经完成了预设的功能 于是，系统 不知
应该继续做什么，如何反馈给使用方。
案例 ：异步回调超时
此案例和上 个同步超时的案例类似，不过这是 个受理模式的场景，使用了异步回调
回处理结果，系统 同步调用系统 发起指令，系统 采用受理模式，受理后则返回成功信
然后系统 处理后异步通知系统 处理结果。在这个过程中，如果系统 由于某种原因迟
没有收到回调结果，那么这两个系统间的状态就不一致 互相认知的状态不同会导致系统间
生错误，在严重情况下会影响核 链路上
案例 ：掉单
在分布式系统中，两个系统协作处理 个流程，分别为对方的上下游，如果 个系统中存
在一请求（通常指订单），另外 个系统不存在，则会导致掉单，掉单的后果很严重，有时也
会导致资金损失。
案例 ：系统间状态不一致
此案例与上面掉单的案例类似，不同的是两个系统间都存在请求，但是请求的状态不 致。
案例 ：缓存和数据库不一致
易系统 本上离不开 系型数据库，依赖关系型数据库提供的 ACID 特性，但是在大规
模、高并发的互联网系统里， 些特殊的场景对读操作的性能要求极高，服务于交易的数据库
难以抗住大规模的 ，通常需要在数据库前增加 层缓存，那么缓存和数据库之间的数据
如何保持 致性？是要保持强 致性还是弱 致性呢？
案例 ：本地缓存节点间不一致
个服务池上的 个节点为了满足较高的性能需求，需要使用本地缓存，这样每个节点都
会有一份缓存数据的复制，如果这些数据是静态的、不变的，就永远不会有问题，但是如果这
些数据是半静态的或者经常被更新的，则被更新时各个节点的更新是有先后顺序的，在更新的
瞬间 ，在某个时间窗口内各个节点的数据是不 致的，如果这些数据是为某个开关服务的，则
想象
案例 ：缓存数据结构不一致
这个案例时有发生，某系统需要在缓存中暂存某种类型的数据 该数据由多个数据元素组成，
其中 ，某个数据元素需要从数据库或者服务中获取，如果 部分数据元素获取失败，则由于程序
确，仍然将不完全的数据存入缓存中，在缓存使用者使用时很有可能因为数据的不完全
抛出 常，例如 Nul!PointerException 等，然后可能因为没有合理处理异常而导
三种设计模式：
####ACID 酸
- A: Atomicity ，原子性
- C: Consistency 致性。
- I: Isolation ，隔离性。
- D: Dur bility ，持久性。
####CAP 帽子
C: Consistency 致性 在分布式系统中的所有数据备份，在同 时刻具有同样的值，所有节点在同一时刻 取的数据都是最新的数据副本。
A: Availability ，可用性，好的响应性能。完全的可用性指的是在任何故障模型下，服务都会在有限的时间内处理完成井进行响应。
P:Partition tolerance ，分区容忍性。尽管网络上有部分消息丢失，但系统仍然可继续工作
**CAP帽子不可同时满足以上三点 **
####BASE 碱
BA: Basically Available ，基本可用
S: Soft State ，软状态，状态可以在一段时间内不同步。
E: Eventually Consistent ，最终一致，
##补充：一阶段提交协议：
#####二阶段提交协议
jee XA协议：
- 准备阶段 协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可
以完成，则会写 redo 或者 undo 日志，然后锁定资源，执行操作，但是并不提交。 - 提交阶段 如果每个参与者明确返回准备成功，也就是预留资源和执行操作成功，则协
调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；
如果任何一个参与者明确返回准备失败， 就是预留资源或者执行操作失败，则协调者向
与者发起中止指令，参与者取消己经变更的事务，执行 undo 日志，释放锁定的资源
阻塞、单点故障、脑裂
三段提交协议
-
询问阶段：协调者询问参与者是否可以完成指令，协调者只需要回答是或不是，而不
要做真正的操作 ，这个阶段超时会导致中止 -
准备阶段 如果在询问阶段所有参与者都返回可以执行操作，则协调者向参与者发送预
执行请求，然后参与者写 redo、undo 日志，执行操作但是不提交操作：如果在询问
段任意参与者返回不能执行操作的结果，则协调者向参与者发送中止请求，这里的逻
辑与两阶段提交协议的准备阶段是相似的。 -
提交阶段：如果每个参与者在准备阶段返回准备成功，也就是说预留资源和执行操作成
功，则协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源：
如果任何参与者返回准备失败，也就是说预留资源或者执行操作失败，则协调者向
与者发起中止指令，参与者取消已经变更的事务，执行 undo 日志，释放锁定的资源，
这里的逻辑与两阶段提交协议的提交阶段一致。
TCC
TCC 协议将一个任务拆分成 Try Confirm Cancel 个步骤
正常的流程会先执行 可，如果执行没有问题，则再执行 Confirm ，如果执行过程中出 了问题，
则执行操作的逆操作 Cance 从正常的流程上讲，这仍然是 个两阶段提交协议，但是在执
出现问题时有 定的自我修复能力，如果任何参与者出现了问题，则协调者通过执行操作的逆
操作来 Cancel 之前的操作，达到最终一致
##未完待续，最近比较偷懒所以先更新我之前整理的资料。后续代码案例敬请期待！