啾啾头号大粉丝打工买粮博客

[Java微服务架构]系列也是接近尾声了，本系列系统梳理了从单体架构到分布式架构，微服务架构有哪些改变，做了什么样的设计以满足服务的CAP特性，为什么那样设计？设计时有哪些问题需要考虑，各个设计优缺点是什么？

在微服务架构中，权鉴从单一入口变成了分布式授权，架构上需要“集中管理+分布式执行OAuth”

Sage较之前的2PC与TCC，因为事务回滚机制的同步与事务调度方式不同，新能上有所差异。2PC实现比较简单，但有着网络不可靠、事务隔离级别不足问题。TCC解决了2PC问题且是非阻塞状态，且可以有更柔性的实现，如融合服务降级+补偿机制，但是需要服务应用“预留资源”，在部分场景中使用不了。Sage不用预留资源，且也有补偿机制，且补偿机制较2PC全部回滚更灵活，只需要回滚已经提交的，且补偿机制可以按顺序部分回滚。总的来说，在设计分布式事务时不同方案有不同的优缺点。

分布式事务处理

”单服务多数据源“事务是怎么处理呢？”多服务单数据源“事务是怎么处理呢？

本篇先介绍“事务特性”与“单服务单数据源”全盘将介绍如引言所述分布式系统中事务的处理。

服务集群需要一个统一对外交互的代理人角色，即微服务网关。

本篇主要讨论服务集群故障时的处理方案设计。包含故障处理与流量控制，其中故障处理包括熔断+降级，流量控制则介绍了流量控制的3个问题与经典的4个限流算法。

本文主要讨论客户端负载均衡，即怎么在服务集群中选取一个合适的服务来调用。包含常见负载均衡算法的介绍。

讲述了服务通信的同步通信方式REST与gRPC，并简单介绍了RPC是什么，gRPC为什么快。

以服务通信为目标倒推，从服务发现出发，讲述服务是怎么注册的，服务注册的形式，常见的注册中心是怎么划分服务的，服务又是以什么形式存储的，集群环境在注册中心怎么保证服务信息的一致性。

Java微服务尽量选择成熟的框架方案，设计之初不要过度设计，需以业务驱动为核心，通过垂直拆分、弱依赖、服务自治等原则逐步演进。