微服务架构

最新推荐文章于 2024-09-26 16:51:01 发布

洪河王大爷

最新推荐文章于 2024-09-26 16:51:01 发布

阅读量1.1k

点赞数 15

文章标签：架构微服务云原生

本文链接：https://blog.csdn.net/aRtHuR1207/article/details/142523463

版权

文章目录

一、微服务架构介绍
二、出现和发展
- 2.1 传统开发模式和微服务的区别
- 2.2 微服务开发
四、SOA和微服务的区别
五、分布式与微服务的区别
- 5.1 CAP理论
- 5.2 Base理论
六、微服务实现方案
- 6.1 服务治理
- - 6.1.1 SpringCloud
  - 6.1.2 Spring Cloud Alibaba
七、对于企服平台的架构设想

一、微服务架构介绍

微服务（Microservice Architecture）是一种软件架构概念，它将应用程序构建为一套小的、松散耦合的服务集合。通俗点说就是将业务功能分散到各个服务中以实现业务实现的解耦。每个服务运行在其独立的进程中，通常围绕着一个特定的业务功能进行构建，拥有自己的数据存储和处理机制，通过轻量级的通信协议（如HTTP RESTful API）相互协作。这种架构风格强调服务的独立部署、可伸缩性和灵活性，旨在提高大型复杂应用系统的开发、部署和维护效率。

微服务的核心特点包括：

服务自治性：每个微服务都是独立部署、独立运行的单元，拥有自己的数据库和数据模型，从而确保了数据的局部性和服务的自治性。
小型且专注：微服务通常围绕一个特定的业务能力构建，保持小而专注，使得服务易于理解和开发。
分布式开发：微服务架构支持使用不同的语言和技术栈开发不同的服务，提高了技术的多样性和团队的灵活性。
去中心化数据管理：在微服务架构中，每个服务管理自己的数据库，避免了传统单体架构中的数据耦合问题。
敏捷开发与部署：由于服务的规模较小，团队可以快速构建、测试和部署新的服务版本，加快迭代速度和市场响应。
容错性：服务的独立性使得系统更能容忍失败，单个服务的故障不会导致整个应用的瘫痪。
可伸缩性：微服务可以根据需求独立地进行水平扩展，提高了系统的整体性能和可用性。

微服务架构的挑战：

服务间通信：服务之间的通信和数据交换需要依赖于网络，增加了系统的复杂度和通信成本。
数据一致性：每个服务管理自己的数据库，维护数据一致性成为一个挑战，尤其是在分布式事务处理方面。
服务发现和负载均衡：随着服务数量的增加，如何有效地管理服务的地址和负载成为重要问题。
运维复杂性：独立部署和管理多个服务增加了运维的复杂度，需要自动化的部署、监控和故障恢复机制。
微服务架构通过将大型应用拆分为独立、易于管理和协作的小型服务，为解决大规模系统开发和运维的复杂性提供了有效策略。然而，成功实施微服务架构需要克服其固有的挑战，合理规划服务的拆分和管理策略。

二、出现和发展

微服务概念最早在2011年左右被提出，当时一些前瞻性的技术团队和组织（包括Netflix、Amazon、eBay等）已经开始探索将大型应用拆分为更小、更灵活的服务单元的方法。2012年，这一概念在一次软件架构师研讨会上被广泛讨论，2014年开始受到各方的关注，而2015年，可以说是微服务的元年。

Martin Fowler：国际著名的OO专家，敏捷开发方法的创始人之一，现为ThoughtWorks公司的首席科学家。在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面，都是世界顶级的专家，现为Thought Works公司的首席科学家。Thought Works是一家从事企业应用开发和——集成的公司。早在20世纪80年代，Fowler就是使用对象技术构建多层企业应用的倡导者，他著有几本经典书籍：《企业应用架构模式》、《UML精粹》和《重构》等。 ———— 百度百科
PS：玩微服务就得认识这很有意思的老头儿，他是个奇人，特别擅长抽象归纳和制造概念，而这些归纳和概念都有一个特点（例如新生名词：微服务）：一解释就懂，一问就不知，一讨论就吵架！！！

2.1 传统开发模式和微服务的区别

先来看看传统的web开发方式，通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的，这种方式一般被称为Monolithic（单体式开发）。
所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。

优点：

开发简单，集中式管理
基本不会重复开发
功能都在本地，没有分布式的管理和调用消耗
缺点：效率低、维护难、不灵活、稳定性差、扩展性不够。。。

2.2 微服务开发

四、SOA和微服务的区别

SOA（Service-Oriented Architecture，面向服务的架构）是一种软件设计模式，其核心思想是将应用程序构建为一系列相互独立、松散耦合的服务集合。这些服务通常围绕业务功能构建，可以跨网络、跨平台进行交互和通信。SOA的目标是提高软件的复用性、灵活性和可维护性，同时降低长期的开发和维护成本。

SOA非常适合需要将现有的系统和应用进行整合、提供统一服务接口的场景。通过引入SOA，企业可以更好地利用现有的IT资产，提高业务流程的灵活性和响应速度，同时降低新服务开发的复杂度和成本。

五、分布式与微服务的区别

微服务架构是一种设计方法，它将应用程序划分为一组小的、松散耦合的服务。每个服务通常实现特定的业务功能，运行在自己的进程中，并通过定义良好的API进行通信。微服务架构强调服务的自治性和独立性，每个服务可以独立开发、部署、运行和扩展。

分布式系统由一组网络中的计算机组成，这些计算机共同工作以达到一个共同的目标。分布式系统的设计和实现侧重于实现组件之间的有效协作，同时处理故障容忍、数据一致性、并发和资源共享等挑战。

总的来说，微服务架构是构建分布式系统的一种方法，强调服务的独立性和小规模，而分布式系统作为一个更广泛的概念，涵盖了在多个物理或虚拟节点上分布工作负载的所有方面。

5.1 CAP理论

CAP理论，也被称为布鲁尔定理（Brewer’s Theorem），是由加州大学伯克利分校的计算机科学家Eric Brewer在2000年提出的。CAP是三个词Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容忍性）的首字母缩写。CAP理论阐述了在一个分布式系统中，一致性、可用性和分区容忍性这三个基本需求，不可能同时完全满足，最多只能同时满足其中的两项。

一致性（Consistency）：一致性指的是所有节点在同一时间看到的数据是一致的。即在进行了某项更新操作之后，无论客户端访问哪一个节点，都能得到相同的数据结果。这里的一致性是指强一致性，即系统能够保证在任何时刻，所有的节点都能对外提供最新的数据。
可用性（Availability）：可用性指的是每个请求都能在有限的时间内得到响应，不管是成功还是失败的响应。换句话说，每个操作都必须能够在某个时间段内完成，确保系统对外服务的持续可用。
分区容忍性（Partition Tolerance）：分区容忍性是指系统能够容忍网络分区。在一个分布式系统中，由于网络问题可能导致某些节点之间无法通信，形成"网络分区"。即使出现这种网络分割的情况，系统仍然能够正常运行。

5.2 Base理论

BASE理论是对CAP理论的一种延伸，主要应用于分布式系统设计中，用以指导如何在CAP理论指出的三个特性（一致性、可用性、分区容忍性）之间做出权衡。相较于CAP理论中的强一致性要求，BASE理论提倡的是通过放宽一致性要求以获得更高的系统可用性。BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的首字母缩写。

基本可用（Basically Available）：基本可用是指分布式系统在遇到故障时，允许损失部分可用性——但仍然保证核心可用。例如，系统在面临网络分割（Partition Tolerance）时，可能将某些请求转移至队列中缓冲，或者返回一个简化的非实时性的查询结果，从而保证系统的基本运行，而不是完全的宕机或不可用。
软状态（Soft State）：软状态意味着系统的状态不需要时刻保持一致，而是可以存在一定时间的不一致。这与传统数据库系统中的强一致性状态不同，软状态允许系统在没有接收到新的更新时，其状态仍然会因为时间的推移而变化，即系统状态是有时效性的。
最终一致性（Eventually Consistent）：最终一致性是指系统中的所有副本，在经过一段时间后，最终能够达到一致的状态。在分布式系统中，由于各种原因（如网络延迟、分区等）可能导致数据的不一致性，最终一致性保证了在没有新的更新操作下，数据副本最终能够自行达成一致。这种一致性模型为系统的高可用性和伸缩性提供了更大的灵活性。

六、微服务实现方案

服务划分和界定
a. 服务粒度的确定：如何恰当地划分服务是微服务开发中的一个关键挑战。服务过大可能会导致单体应用的问题，服务过小则可能增加通信和管理的复杂性。
b. 业务边界的定义：正确定义服务的业务边界，确保服务的独立性和自治性，是设计微服务系统时的一大挑战。
数据一致性管理
a. 数据一致性：在微服务架构中，每个服务通常管理自己的数据库，这样会带来跨服务数据一致性的问题。
b. 分布式事务：在多个微服务之间处理事务，尤其是要保证原子性和一致性时，实现分布式事务比在单体应用中更复杂。
网络问题
a. 网络延迟：服务间的通信依赖网络，网络延迟和可靠性成为影响系统性能的关键因素。
b. 服务发现和负载均衡：在动态环境中，服务实例的地址可能会变化，如何快速发现服务并进行负载均衡，是微服务架构需要解决的问题。
安全问题
a. 服务间安全：服务之间的通信需要安全保障，如何有效地实现服务间的认证和授权，保护数据不被未授权访问，是开发过程中必须考虑的问题。
运维挑战
a. 部署和运维复杂性：微服务的独立部署增加了运维的复杂性。自动化部署、监控和故障恢复等成为必须解决的问题。
b. 监控和日志管理：在微服务架构中，需要跨多个服务收集和分析日志，监控系统的健康状况，这比在单体应用中更加复杂。
技术和团队挑战
a. 技术多样性：微服务允许每个服务使用最适合的技术栈，但这也可能导致团队间的技术壁垒，增加学习成本。
b. 团队沟通：微服务架构要求团队之间有良好的沟通和协作，以避免服务间接口不一致或重复开发。

6.1 服务治理

在微服务架构中，服务治理是指对服务的发现、配置、管理、监控、和故障恢复等方面的一套规范和机制，旨在确保微服务系统的健康、可靠和高效运行。由于微服务架构涉及到多个独立服务的协同工作，服务治理成为了维护系统稳定性和可扩展性的关键组成部分

Spring Cloud和Spring Cloud Alibaba为开发者提供了一套完整的微服务解决方案，支持服务发现、配置管理、消息传递等功能，帮助开发者构建稳定和可维护的微服务应用。

6.1.1 SpringCloud

Spring Cloud基于Spring Boot，提供了一套微服务相关的工具集，包括服务发现（Eureka）、配置管理（Spring Cloud Config）、断路器（Hystrix）、API网关（Zuul）等，使得构建云原生应用变得简单。

Eureka：服务注册与发现。
Spring Cloud Config：集中配置管理。
Hystrix：断路器，提高服务的弹性。
Zuul：API网关，提供动态路由、监控、弹性伸缩和安全功能。

6.1.2 Spring Cloud Alibaba

Spring Cloud Alibaba旨在为Spring Cloud提供一套阿里巴巴中间件的集成方案。它不仅包括了Spring Cloud的标准组件，还增加了Nacos、Sentinel、RocketMQ等阿里巴巴开源项目的支持，进一步丰富了微服务的功能。

Nacos：作为服务发现和配置管理的解决方案。
Sentinel：流量控制、熔断降级、系统负载保护。
RocketMQ：消息队列服务，支持大规模的消息处理。
Dubbo：高性能Java RPC框架，用于服务间同步调用。

七、对于企服平台的架构设想

7.1 中央缓存与分布式锁

7.1.1 中央缓存——redis

在微服务架构中，中央缓存是一种跨多个进程（服务）缓存共享的机制，旨在提供系统整体的性能和响应深度，同时减少缓存冗余与后端数据源的压力。

共享性：中央缓存为所有微服务提供了一个共享的、统一的缓存环境，使得缓存数据可以被多个服务访问和复用。
一致性：通过中央缓存机制，可以更有效地维护缓存数据的一致性，确保不同服务看到的数据是一致的。
高可用性和扩展性：中央缓存通常部署在高可用的集群上，能够根据需要水平扩展，以支持更大规模的数据和更高的访问频率。

扩展：根据我的理解，其实在计算机体系中存在很多这样的设计思想，例如线程间和进程间的通信。例如：在计算机体系中，线程间并不能直接通信，而且为了处理速度，每个线程都会自己维护一个缓存，对属性的操作其实都在变相操作自己缓存中的属性，然后将自己缓存中的变化刷新到主内存，其他线程才会感知到，这样，就实现了速度与资源之间的一个折中。至于，为了实现这种方案从而引出的可见性、原子性与指令重排序就不再扩展。
总结：所以，基于我的设计与经验，我认为：服务基于业务拆分、数据基于中央缓存整合。

7.1.2 分布式锁

分布式锁是在分布式系统中用于保证多个节点之间同步访问共享资源的一种机制。由于分布式系统中的各个组件可能分散在不同的服务器或网络中，标准的锁机制（如在单个进程或机器上使用的互斥锁）不能有效地跨多个节点工作。因此，需要分布式锁来确保在任何时刻只有一个节点可以访问特定的资源或执行特定的操作。

由于我们的系统设计中存在“中央缓存”的概念，所以在分布式锁的选择中，确定使用中央缓存实现分布式锁Redisson。在 Redisson 中，实现了多种锁：例如可重入锁、读写锁。为了使用方便，我对 Redisson 的锁抽象出了一个工具类简化使用，并考虑到实际使用，抽象出了一个注解用于简化与解耦业务代码。

7.2 进程间通信与事件驱动

消息队列（MQ，Message Queue）是分布式系统中用于在应用程序之间异步传递消息的中间件组件。它允许不同的应用程序或不同部分的同一个应用程序通过交换消息进行通信，而无需直接连接到彼此。消息队列提供了一种松耦合的通信方式，大大增强了系统的扩展性、可靠性和灵活性。

解耦：消息队列使得生产者（发送消息的应用程序）和消费者（接收消息的应用程序）之间相互独立，它们不需要知道对方的存在。这样，即使一个服务出现故障，也不会直接影响到其他服务。
异步处理：消息队列允许消息的发送者和接收者异步处理消息。发送者可以继续处理其他任务，而不需要等待消息被接收和处理。这样可以提高应用程序的响应速度和吞吐量。
负载均衡：在处理大量请求时，消息队列可以将消息分发给多个处理器（消费者），从而分散负载，避免某一服务因请求过多而过载。
容错性：消息队列通常提供消息持久化的功能，即使系统崩溃，消息也不会丢失，可以在系统恢复后继续处理。这增强了系统的可靠性。
顺序保证：某些消息队列支持消息的顺序传递，确保消息按照发送的顺序被处理。
跨语言和平台的通信：消息队列提供了标准化的通信协议，使得不同编程语言编写的应用程序或运行在不同平台上的应用程序可以轻松通信。

7.2.1 事件驱动

事件驱动架构（Event-Driven Architecture，EDA）是一种软件架构模式，它基于事件的生成、检测、消费和响应来构建应用程序和服务。在这种架构中，事件是状态变化的表示，可以由系统中的任何组件生成，并由一个或多个独立组件处理。事件驱动架构使应用程序能够高效地响应实时发生的事件，提高了系统的灵活性、可扩展性和解耦度。

7.3 注册中心与配置中心

在微服务架构中，注册中心扮演着至关重要的角色，它是实现服务发现机制的核心组件。由于微服务架构涉及到多个独立的服务协同工作，服务之间需要互相了解对方的网络位置（如IP地址和端口）以进行通信。随着系统规模的扩大和环境的动态变化，静态配置服务地址变得不再可行，这时注册中心的作用就显得尤为重要。

而配置中心是一个专门用于管理和存储应用配置信息的系统。随着微服务数量的增加，手动管理每个服务的配置明显是不明智的，效率和可靠性都面临着巨大考验。配置中心的出现，解决了面临的问题。

7.3.1 Nacos 简介

Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。简单来说 Nacos 就是注册中心 + 配置中心的组合，提供简单易用的特性集，帮助我们解决微服务开发必会涉及到的服务注册与发现，服务配置，服务管理等问题。 Nacos 还是 Spring Cloud Alibaba 组件之一，负责服务注册与发现。

7.3.2 Nacos 领域模型

Nacos 数据模型 Key 由三元组唯一确定, Namespace默认是空串，公共命名空间（public），分组默认是 DEFAULT_GROUP。

Nacos提供了 Key 的三元组，至于这个三元组怎么定义，完全交给客户，也既：Nacos的三元组只是一种规范，并没有强制的维度定义。目前在我们的系统上，我对这个三元组定义有以下建议：
● Namespce：定义为项目维度，例如现在我们正在实现的企服平台，就可以作为一个命名空间；之后的开发者平台又作为一个命名空间。
● GroupId：定位为环境维度，例如目前我们可以定义的有：开发环境、测试环境、预发布环境和线上环境。

7.4 服务网关

Spring Cloud Gateway 作为SpringCloud生态系统中的网关，目标是替代Netflix Zuul。Gateway不仅提供统一路由方式，并且基于Filter链的方式提供网关的基本功能。例如：安全，监控/指标，和限流。

总结：微服务网关就是一个系统，通过暴露该微服务网关系统，方便我们进行相关的鉴权，安全控制，日志统一处理，易于监控，限流等相关功能。

7.4.1 工作原理

Gateway的客户端回向Spring Cloud Gateway发起请求，请求首先会被HttpWebHandlerAdapter进行提取组装成网关的上下文，然后网关的上下文会传递到DispatcherHandler。
DispatcherHandler是所有请求的分发处理器，DispatcherHandler主要负责分发请求对应的处理器，比如将请求分发到对应RoutePredicateHandlerMapping(路由断言处理器映射器）。
路由断言处理映射器主要用于路由的查找，以及找到路由后返回对应的FilteringWebHandler。
FilteringWebHandler主要负责组装Filter链表并调用Filter执行一系列Filter处理，然后把请求转到后端对应的代理服务处理，处理完毕后，将Response返回到Gateway客户端。

7.5 服务间调用

在微服务架构中，服务间调用是指各个独立部署的微服务之间进行互相通信的过程。由于每个微服务都是独立运行的，它们需要通过定义好的接口来实现数据的交换和功能的调用。服务间调用的方式主要有同步调用和异步调用两种模式，每种模式都有其适用场景和特点。

7.5.1 OpenFeign

OpenFeign是一个声明式的Web服务客户端，它使得编写Web服务客户端变得更加简单。它是Spring Cloud中的一个模块，用于简化微服务之间的HTTP调用。通过使用OpenFeign，开发者可以通过简单地声明接口和注解来调用远程服务，而不需要手动构造HTTP请求。

声明式REST客户端：OpenFeign允许开发者通过Java接口以声明方式定义服务绑定，减少了模板代码的编写。
集成Ribbon和Hystrix：OpenFeign内部集成了Ribbon客户端负载均衡和Hystrix断路器，提供负载均衡和服务熔断的能力，增强了微服务调用的可靠性和弹性。
易于集成和使用：作为Spring Cloud生态系统的一部分，OpenFeign与Spring Boot应用无缝集成，简化了配置和服务调用的代码。
自动编码和解码支持：支持请求和响应的自动编码和解码，开发者只需要关注业务逻辑。
请求重试机制：提供了简单的请求重试机制，增加了调用远程服务的健壮性。

对于客户端负载均衡，由于Ribbon停止维护，业内更加推荐使用 SpringCloud 自己开源的：Loadbalancer.

7.5.2 引入依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

7.5.3 启用 Feign 客户端

@EnableFeignClients(basePackages = "com.rainbowred")
@SpringBootApplication(scanBasePackages = "com.rainbowred")
public class AApplication {

    public static void main(String[] args) {
        SpringApplication.run(AApplication.class);
    }

}

7.5.4 定义 Feign 接口

@Component("aHelloController")
@FeignClient(value = "A-Application", contextId = "aHelloController")
public interface IAHelloController {

    @GetMapping("/a/hello/{name}")
    ApiResponse<String, ?> hello(@PathVariable("name") String name);

}

这里有几个需要规范的地址：

定义 Bean 名称为去掉 I 之后的接口名称首字母消息（字母 I 用于标识当前类是接口）
FeignClient注解中 value 值用于指定接口实现的服务，contextId 用于标识注册的 Bean 名称。
方法签名上的注解不会被继承，所以最好的方案是直接拷贝当前方法签名到实现类中。

7.5.5 实现 Feign 接口提供具体服务

@RestController
public class AHelloController implements IAHelloController {

    @Override
    @GetMapping("/a/hello/{name}")
    public ApiResponse<String, ?> hello(String name) {
        return ApiResponse.success("hello " + name);
    }

}

7.5.6 调用测试

@RestController
public class BHelloController implements IBHelloController {

    @Autowired
    private IAHelloController aHelloController;

    @Override
    @GetMapping("/b/hello/{name}")
    public ApiResponse<String, ?> hello(String name) {
        // return ApiResponse.success("hello " + name);
        return aHelloController.hello(name);
    }

}

7.6 服务限流、熔断、降级

Sentinel 是由阿里巴巴开源的面向分布式服务架构的高可用性保障组件。它主要专注于流量控制、熔断降级和系统负载保护，旨在保障微服务或分布式系统在高并发情况下的稳定性和可靠性。通过实时监控服务间的调用情况，Sentinel 能够在系统出现不稳定状态之前，自动进行流量控制和降级，防止系统过载，确保核心服务的高可用。

7.6.1 核心功能

流量控制：支持多种流量控制策略，如QPS（每秒查询率）、线程数等，可以针对来源进行区别处理，有效防止系统过载。
熔断降级：当下游服务不稳定（如响应时间过长）时，自动进行熔断保护，切断请求，防止雪崩效应。
系统负载保护：当系统负载（如CPU使用率、系统平均负载）超过设定阈值时，自动对入口流量进行限制，保护系统不被压垮。
热点参数限流：对频繁访问的“热点”参数进行限流，避免由于热点参数的大量访问导致的应用崩溃。
集群流量控制：支持集群模式下的流量控制，保证在分布式应用场景下的稳定性。
实时监控与动态规则配置：提供实时监控功能，能够通过控制台动态配置规则，无需修改代码或重启应用。

7.6.2 工作原理

Sentinel 的工作原理主要基于资源（如HTTP请求、Dubbo接口等）的实时监控和规则判断。当请求到达被Sentinel保护的资源时，Sentinel会根据预定义的规则（如QPS阈值、响应时间等）进行检查，如果请求符合流量控制或熔断降级的条件，则会立即进行相应的控制措施，否则允许请求通过。

7.6.3 SentinelResource

@SentinelResource 注解是 Sentinel 在 Spring Cloud 中提供的一个注解，它用于定义资源并自动集成 Sentinel 的保护功能，如流量控制、熔断降级等。通过使用 @SentinelResource 注解，你可以轻松地对方法进行保护，使其在面对高并发或异常情况时自动执行预定义的策略，如限流、降级等，从而保证系统的稳定性和可靠性。

value：资源名称，必需属性。用于唯一标识一个资源，通常建议使用方法全路径名。
entryType：入口类型，可选属性。用于区分入口（IN）和出口（OUT）流量，默认为 EntryType.OUT。
blockHandler：指定处理 BlockException 的方法名称，可选属性。当资源访问被 Sentinel 的规则阻止时，指定的方法将被调用。
blockHandlerClass：指定处理 BlockException 的类，可选属性。与 blockHandler 配合使用，用于指定自定义的处理类。
fallback：指定降级方法的名称，可选属性。当资源访问发生异常时，指定的方法将被调用进行降级处理。
fallbackClass：指定降级方法所在的类，可选属性。与 fallback 配合使用，用于指定自定义的降级处理类。
exceptionsToIgnore：定义哪些异常类型的抛出不会触发 fallback 方法的执行，可选属性。

7.6.4 Sentinel 整合 Geteway

Spring Cloud Gateway 默认是有限流功能的，但限流功能比较简单，所以咱们今天要实现的是 Spring Cloud Gateway 整合 Spring Cloud AlibabaSentinel 实现限流和熔断功能，这种方式也是目前生产环境主流的限流和熔断的实现方法。

7.6.5 Sentinel 整合 OpenFeign

Sentinel 整合 OpenFeign 是为了在微服务调用中实现流量控制、熔断保护和服务降级等功能。OpenFeign 是一个声明式的 Web 服务客户端，使得编写 HTTP 客户端变得更简单。通过整合 Sentinel，我们可以利用其丰富的功能来保护微服务间的调用，提升系统的稳定性和可靠性。

开启 Sentinel 与 OpenFeign 的整合功能

feign:
  sentinel:
    enabled: true

7.6.6 Sentinel规则持久化

略。。。

7.7 本地事务与分布式事务

在软件开发中，事务是保证数据一致性和完整性的一种机制，尤其是在数据库操作中。根据应用的架构和数据操作范围，事务可以分为本地事务和分布式事务。

7.7.1 本地事务

本地事务是最常见的事务类型，它仅涉及一个数据库管理系统（DBMS）和一个数据源。在本地事务中，所有的操作都在同一个数据库实例中执行，要么全部成功，要么全部失败。这种事务遵循ACID原则：

原子性（Atomicity）：事务中的所有操作要么全部完成，要么全部不执行。
一致性（Consistency）：事务完成时，数据库从一个一致性状态转移到另一个一致性状态。
隔离性（Isolation）：并发执行的事务彼此隔离，避免互相干扰。
持久性（Durability）：事务一旦提交，其结果就是永久性的，即使发生系统故障也不会丢失。

本地事务的典型应用场景包括单一数据库的增删改查操作等场合，大多数关系型数据库管理系统（如MySQL、Oracle、SQL Server等）都提供了对本地事务的支持。

7.7.2 分布式事务

随着微服务、SOA（面向服务的架构）等分布式架构的流行，数据操作往往跨越多个数据库甚至多个服务，此时就需要用到分布式事务。分布式事务涉及多个数据源或服务，要求即使这些数据源或服务分布在不同的系统或网络中，事务操作也必须保持ACID属性。
分布式事务的实现比本地事务复杂得多，常见的实现方案包括：

两阶段提交（2PC, Two-Phase Commit）：分为准备阶段和提交阶段，确保所有参与者都能够提交事务，否则就全部回滚。
三阶段提交（3PC, Three-Phase Commit）：在两阶段提交的基础上增加了一个预提交阶段，以减少阻塞时间，提高系统的可用性。
TCC（Try-Confirm-Cancel）：业务逻辑分为尝试、确认和取消三个操作，适用于业务逻辑较为复杂的分布式事务场景。
消息队列：通过消息队列实现最终一致性，适用于对实时性要求不高的场景。

分布式事务的挑战在于如何在保证数据一致性的同时，不过度影响系统的性能和可用性。因此，在设计分布式系统时，应尽量减少跨服务的事务，或通过业务逻辑上的拆分、最终一致性等策略来规避分布式事务的使用。

总的来说，本地事务和分布式事务各有适用场景，选择合适的事务机制对于确保数据的一致性和系统的稳定性至关重要。

7.7.3 分布式事务解决方案——Seta

Seata 是一个开源的分布式事务解决方案，旨在提供高性能和简单易用的分布式事务服务。它的目标是在微服务架构下，确保跨多个数据库、微服务、消息系统等分布式系统中的事务一致性。Seata 通过对分布式事务进行全局控制，解决了微服务架构中服务间调用复杂度高和一致性维护困难的问题。

a. 核心组件

TC (Transaction Coordinator) - 事务协调器：维护全局事务的状态，协调参与全局事务的所有分支事务，确保分支事务要么全部提交，要么全部回滚。
TM (Transaction Manager) - 事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与 TC 交互注册分支事务和报告分支事务状态，并驱动分支事务的提交或回滚。

b. 工作流程

开始全局事务：TM 调用 TC 开始一个新的全局事务。
注册分支事务：参与全局事务的每个微服务（或称为 RM），在执行本地事务前，向 TC 注册自己的分支事务。
执行业务操作：每个微服务执行其本地事务。
分支事务上报：执行完本地事务后，每个微服务向 TC 上报其分支事务的执行结果（成功或失败）。
提交或回滚全局事务：TM 根据分支事务的执行结果，决定是请求 TC 提交全局事务，还是回滚全局事务。TC 将根据全局事务的最终状态，指示所有参与的分支事务进行相应的提交或回滚操作。

7.8 链路跟踪与日志监控

7.8.1 链路跟踪

微服务链路跟踪是一种监控和诊断微服务架构（MSA）中服务调用流程的技术。随着微服务架构的普及，一个业务请求通常会跨越多个微服务进行处理。在这种分布式系统中，服务间的调用关系错综复杂，一旦出现性能瓶颈或故障，要快速定位问题变得极其困难。微服务链路跟踪技术的出现，旨在解决这一问题，通过追踪和记录整个请求处理过程中的详细信息，帮助开发和运维人员理解请求的流转路径，分析服务性能，以及快速定位问题来源。

微服务链路跟踪中，主要包含以下几个核心概念：

Trace（跟踪）：表示一次完整的请求链路，从开始到结束，跨越多个微服务的调用过程。它是由多个 Spans 组成的。
Span（跨度）：表示请求链路中的一个单元工作，比如一个 HTTP 请求处理或数据库查询。每个 Span 会记录关键信息，如操作名称、开始和结束时间、标签（用于查询）等。
Parent Span 和 Child Span：在一个 Trace 中，Span 之间存在层级关系，即一个 Span 可以是另一个 Span 的父级或子级。这种结构能够反映出服务调用的依赖关系。

链路跟踪的工作流程

请求入口：当一个请求进入系统时，链路跟踪系统会生成一个唯一的 Trace ID，并创建第一个 Span 来标识这次请求的开始。
服务调用：请求在微服务架构中流转时，每进入一个新的服务，链路跟踪系统都会创建一个新的 Span。这个新的 Span 会记录其父 Span 的信息，以及自己的信息，如开始时间、结束时间、服务信息等。
数据收集与存储：所有 Span 的信息会被收集起来，并存储到链路跟踪系统的数据库中。这些数据可以是分布式的，也可以是集中式的，取决于具体的链路跟踪方案。
数据分析与展示：通过专门的界面，对收集到的跟踪数据进行查询、分析和可视化展示，帮助用户理解请求的流转情况，分析系统性能，定位问题。