分布式架构篇

ww_kobe

已于 2023-10-22 04:55:23 修改

阅读量547

点赞数

文章标签：分布式架构

于 2023-10-05 01:13:29 首次发布

本文链接：https://blog.csdn.net/ww_kobe/article/details/133564076

版权

1、微服务

微服务（Microservices）是一种软件架构风格，把一个单独的应用程序开发为一套小服务，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是 HTTP API。这些服务围绕业务能力来构建，并通过完全自动化部署机制来独立部署。这些服务使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。

简而言之：拒绝大型单体应用，基于业务边界进行服务拆分，各个服务独立部署运行。

1.1 分布式&集群&节点

《分布式系统原理与范型》定义：分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统。分布式系统是建立在网络之上的软件系统。

分布式是指将不同的业务分布在不同的地方，集群是指将几台服务器集中在一起实现同一业务，节点是指集群中一个服务器。

例如：京东是一个分布式系统，众多业务运行在不同的机器，所有的业务构成一个大型的业务集群。每一个小的业务，比如订单系统访问压力大的时候，一台服务器是不够的，我们应该将订单系统部署到多个服务器，也就是每一个业务系统也可以做集群化。

总结：集群是个物理形态，分布式是个工作方式，分布式中每一个节点都可以做集群，而集群并不一定就是分布式的。只要是一堆机器就可以集群，他们是不是一起协作干活，这个谁也不知道。

1.2 架构演变

单体服务（Monolithic Service）：是一种传统的软件架构方式，将整个应用程序作为一个单一的、紧耦合的单元进行开发和部署。单体服务通常由多个模块组成，这些模块共享一个数据库和代码库。然而，随着应用程序规模的增长，单体服务可能变得庞大且难以维护，且部署和扩展困难。
SOA（Service-Oriented Architecture：面向服务的架构）：是一种软件架构设计原则，强调将应用程序拆分为相互独立的服务，通过标准化的接口进行通信。SOA关注于服务的重用性和组合性，但并没有具体规定服务的大小。
微服务：是在SOA的基础上进一步发展而来，是一种特定规模下的服务拆分和部署方式。微服务架构强调将应用程序拆分为小型、自治且松耦合的服务，每个服务都专注于特定的业务功能。这种架构的应用程序更加灵活、可伸缩和可维护。

需要注意的是，微服务是一种特定的架构风格，而SOA是一种设计原则。微服务可以看作是对SOA思想的一种具体实践方式，但不等同于SOA。

微服务与单体服务的区别在于规模和部署方式。微服务将应用程序拆分为更小的、自治的服务单元，每个服务都有自己的数据库和代码库，可以独立开发、测试、部署和扩展，带来了更大的灵活性、可维护性、可扩展性和容错性。

1.3 微服务带来的挑战

系统复杂性增加： 一个服务拆分成了更多个服务，整体系统的复杂性增加，需要处理服务之间的通信、部署、监控和维护等方面的复杂性。
服务间通信开销：微服务之间通过网络进行通信，传递数据需要额外的网络开销和序列化开销，可能导致性能瓶颈和增加系统延迟。
数据一致性和事务管理：每个微服务都有自己的数据存储，数据一致性和跨服务的事务变得更加复杂，需要额外解决分布式事务和数据同步的问题。
部署和运维复杂性：微服务架构涉及多个独立部署的服务，对于部署、监控和容错机制要求更高，需要建立适当的部署管道和自动化工具，以简化部署和运维过程。
团队沟通和协作成本：每个微服务都由专门的团队负责，可能增加团队之间的沟通和协作成本。需要有效的沟通渠道和协作机制，确保服务之间的协调和一致性。
服务治理和版本管理：随着微服务数量的增加，服务的治理和版本管理变得更加复杂。需要考虑服务的注册发现、负载均衡、监控和故障处理等方面，以确保整个系统的可靠性和稳定性。
分布式系统的复杂性：微服务架构涉及构建和管理分布式系统，而分布式系统本身具有一些固有的挑战，如网络延迟、分布式一致性和容错性。

1.4 微服务解决方案

目前主流的微服务解决方案有三种

Dubbo：

Dubbo是一个高性能、轻量级的Java微服务框架，最初由阿里巴巴开发并于2011年开源。它提供了服务注册与发现、负载均衡、容错、分布式调用等功能，后来一度停止维护，在近两年又重新开始迭代，并推出Dubbo3。
Dubbo基于RPC（Remote Procedure Call：远程过程调用）的通信模型，具有较高的性能和可扩展性。它支持多种传输协议（如TCP、HTTP、Redis）和序列化方式（如JSON、Hessian、Protobuf），可根据需求进行配置。
Dubbo更多的被认为是一个高性能的RPC框架，一些服务治理功能依赖第三方组件实现，如使用ZooKeeper、Apollo等。

Spring Cloud Netflix：

Spring Cloud Netflix是Spring Cloud的一个子项目，结合了Netfix开源的多个组件，但是Netflix自2018年停止维护和更新Netflix OSS项目，所以Spring Cloud Netflix也逐渐进入了维护模式。
Spring Cloud Netflix包含了Netflix许多组件，如Eureka（服务注册与发现）、Ribbon（客户端负载均衡）、Hystrix（断路器）、Zuul（API网关）等。他们都是高度可扩展的，经过大规模实践验证的微服务组件。

Spring Cloud Alibaba：

Spring Cloud Alibaba是Spring Cloud另一个子项目，与阿里巴巴的分布式应用开发框架相关。它提供了一整套与Alibaba生态系统集成的解决方案。
Spring Cloud Alibaba包括Nacos（服务注册与发现、配置管理）、Sentinel（流量控制、熔断降级）、RocketMQ（消息队列）等组件，以及与Alibaba Cloud（阿里云）的集成。它为构建基于Spring Cloud的微服务架构提供了丰富的选项。
据说Spring Cloud Alibaba项目的发起人已经跑路去了腾讯，并发起了Spring Cloud Tecent项目，社区发展存在隐优。

2、微服务组件

微服务给系统开发带来了一些问题和挑战，如服务调用的复杂性、分布式事务的处理、服务的动态管理等。为了更好的解决这些问题，各种微服务治理的组件应运而生，充当微服务架构的基石和支撑。

2.1 注册中心

A 服务调用 B 服务，A 服务并不知道 B 服务当前在哪几台服务器有，哪些是正常的，哪些是已下线的。解决这个问题可以引入注册中心，用来管理和维护分布式系统中各个服务的地址和元数据，实时感知其它服务的状态，从而避免调用不可用的服务。

2.1.1 注册中心作用

服务注册：各个服务在启动时向注册中心注册自己的网络地址、服务实例信息和其它相关元数据。这样其它服务就可以通过注册中心获取到当前可用的服务列表。
服务发现：客户端通过向注册中心查询特定服务的注册信息，获得可用服务实例。这样客户端就可以根据需要选择合适的服务进行服务调用，实现了服务之间的解耦。
负载均衡：注册中心可以对同一服务的多个实例进行负载均衡，将请求分发到不同的实例上，提高整体的系统性能和可用性。
故障恢复：注册中心能够监测和检查服务的状态，当服务实例发生故障或下线时，可以及时更新注册信息，从而保证服务能够正常工作。
服务治理：通过注册中心可以进行服务的配置管理、动态扩缩容、服务路由、灰度发布等操作，实现服务的动态管理和控制。

2.1.2 注册中心实现

Eureka：是Netflix开源的服务发现框架，具有高可用、弹性、可扩展等特点，并与Spring Cloud集成良好，支持AP。
Consul：是HashiCorp开发的一种分布式服务发现和配置管理系统。它提供了服务注册、服务发现、健康检查、键值存储等功能，并支持多数据中心部署。
ZooKeeper：是Apache基金会开源的分布式协调服务，可以用作服务注册中心。它具有高可用、一致性、可靠性等特点，支持CP。
Nacos：是Alibaba开源的一个动态发现、配置管理和服务管理平台。它提供了服务注册和发现、配置管理、动态DNS服务等功能，既支持AP，也支持CP。
Etcd：是CoreOS开源的一种分布式键值存储系统。它可以作服务注册中心，具有高可用、强一致性、分布式复制等特性。

2.1.3 Eureka实现原理

服务注册与发现：当一个服务实例启动时，它会向Eureka Server发送注册请求，将自己的信息注册到注册中心。Eureka Server会将这些信息保存在内存中，并提供REST接口供其他服务查询。服务消费者可以通过查询服务实例来获取可用的服务提供者实例，从而实现服务的发现。
服务健康检查：Eureka通过心跳机制来检查服务实例的健康状态。服务实例会定期向Eureka Server发送心跳，也就是续约，以表明自己的存活状态。如果Eureka Server在一定时间内没有收到某个服务实例的心跳，则会将其标记为不可用，并从服务列表中移除，下线实例。
服务负载均衡：Eureka客户端在调用其它服务时，会从本地缓存中获取服务的注册信息。如果缓存中没有对应的信息，则会想Eureka Server发送查询请求。Eureka Server会返回一个可用服务实例列表给客户端，客户端可以使用负载均衡算法选择其中一个进行调用。

2.1.4 Eureka高可用

多实例部署：通过将多个Eureka Server实例部署在不同节点，可以实现高可用。当其中一个实例发生故障，其它实例仍然可以提供服务，并保持注册信息的一致性。
服务注册信息复制：当一个服务实力向Eureka Serve注册时，每个Eureka Server实例都会复制其它实例的注册信息，以保持数据的一致性。当某个Eureka Server实例发生故障时，其它实例可以接管其工作，保证整个系统的正常运行。
自我保护机制：Eureka还具有自我保护机制。当Eureka Server节点在一定时间内没有接收到心跳时，他会进入自我保护模式。在自我保护模式下，Eureka Server不再剔除注册表中的服务实例，以确保现有的注册信息。这样可以防止由于网络抖动原因或其他原因导致的误剔除，进一步提高系统的稳定性。

2.1.5 Nacos领域模型

模型名称	解释
NameSpace	实现环境隔离，默认值public
Group	不同的service可以组成一个group，默认值Defaule-Group
Service	服务名称
Cluster	对指定的微服务虚拟划分，默认值Default
Instance	某个具体的服务实例

2.1.6 Nacos1.x注册中心原理

使用Http发送注册。
查询服务提供方列表。
定时拉取（每10s）。
定时心跳检测服务状态（每5s）。
定时心跳任务检查。
检测到服务提供者异常，基于UDP协议推送更新。
集群数据同步任务使用Distro（AP模式）。

2.1.7 Distro协议

Nacos每个节点自己负责部分写请求。
每个节点会把自己负责的新增数据同步给其它节点。
每个节点定时发送自己负责的数据校验值到其它节点保持数据一致性。
每个节点独立处理读请求，及时从本地发出响应。
新加入的Distro节点会进行全量数据拉取（具体操作是轮询所有的Distro节点，通过向其它的机器发送请求拉取全量数据）。

2.1.8 Nacos2.x客户端探活机制

Nacos服务端会启动一个定时任务，每3s执行一次，查看所有连接是否超过20s没有通信，如果超过20s没有通信，服务端就会给客户端发送一个请求，进行探活，如果正常返回就表示这个服务正常，如果不能正常返回就将其连接删除。

2.2 配置中心

每一个服务最终都有大量的配置，并且每个服务都可能部署在多台机器上，我们经常需要变更配置，我们可以让每个服务在配置中心获取自己的配置而不需要重启服务。

2.2.1 配置中心实现

Spring Cloud Config：Spring Cloud官方推荐的配置中心，支持将配置文件存储在Git、SVN等版本控制系统中，并提供RESTful API进行访问和管理。
ZooKeeper：一个开源的分布式协调服务，可以作配置中心，具有高可用、一致性和通知机制等特性。
Consul：另一个开源的分布式服务发现和配置管理工具，也可以作配置中心，支持多种配置文件格式，提供健康检查、故障转移和动态变更等功能。
Eted：一个分布式键值存储系统，可用作配置中心，使用基于Raft算法的一致性机制，提供分布式数据一致性保证。
Apollo：携程开源的配置中心，支持多种语言和框架，提供细粒度的配置权限管理、配置变更和灰度发布等高级特性，还有可视化的配置管理界面。
Nacos：阿里巴巴开源的服务发现、配置管理和服务管理平台，也可以用作配置中心，支持服务发现与注册、动态配置管理、服务健康检查和动态DNS服务等功能。

2.3 API网关

作为微服务架构的入口，它抽象了微服务中都需要的公共功能，同时提供了客户端负载均衡、服务自动熔断、灰度发布、统一认证、限流流控、日志统计等丰富的功能，帮助我们解决很多 API 管理难题。

2.3.1 API网关主要功能

路由转发：API网关根据请求URL路径或其他标识将请求路由到相应的后端服务。通过配置路由规则，可以灵活的将请求分发给不同的后端服务。
负载均衡：API网关可以在后端服务间实现负载均衡，将请求平均分发到每个实例上，提高系统的吞吐量和可扩展性。
安全认证与授权：API网关可以集中处理身份验证和授权，确保只有经过身份验证的客户端才能访问后端服务。可以与身份提供者（如OAuth、OpenID Connect）集成，进行用户认证和授权操作。
缓存：API网关可以缓存后端服务的响应，减少对后端服务的请求次数，提高系统性能和响应速度。
监控与日志：API网关可以收集和记录请求的指标和日志，提供实时监控和分析，帮助开发人员和运维人员进行故障排除和性能分析。
数据转换和协议转换：API网关可以在客户端和服务端之间进行数据格式和协议转换，如将请求从HTTP转换为WebSocket，或将请求参数进行格式转换，以满足服务端的需求。
API版本管理：API网关可以管理不同版本的API，允许同时存在多个不同版本的API，并通过路由规则将请求正确的路由到相应的API版本上。

2.3.2 API网关实现

Netflix Zuul：是Spring Cloud早期版本提供的默认API网关。基于Servlet技术栈，可以进行路由、过滤、负载均衡等功能。然而自2020年12月起，Netflix宣布停止对Zuul 1的维护，转而支持新的API网关项目。
Spring Cloud Gateway：是Spring Cloud官方推荐的API网关，取代了Netflix Zuul。基于非阻塞的WebFlux框架，充分利用了响应式编程的优势，提供了路由、过滤、断路器、限流等特性。Spring Cloud Gateway还支持与Spring Cloud的其它组件集成，如服务发现、负载均衡等。
Kong：是一个独立的、云原生的API网关和服务管理平台，可以与Spring Cloud集成。Kong基于Nginx提供了强大的路由、认证、授权、监控和扩展能力。支持多种插件和扩展，可满足不同的API管理需求。
APISIX：基于Nginx和Lua开发，具有强大的路由、流量控制、插件扩展等功能。支持灵活的配置方式，可以根据需求进行动态路由、负载均衡和限流等操作。

2.3.3 Spring Cloud Gateway原理

Route（路由）：路由是Spring Cloud Gateway的基本构建块，它定义了请求的匹配规则和转发目标。通过配置路由，可以将请求映射到后端服务实例或URL上。路由规则可以根据请求的路径、方法、请求头等条件进行匹配，并指定转发的目标URL。
Pridicate（断言）：断言用于匹配请求的条件，如果请求满足断言条件，则会应用所配置的过滤器。Spring Cloud Gateway提供了多种内置的断言，如Path（路径匹配）、Method（请求方法匹配）、Header（请求头匹配）等，同时也支持自定义断言。
Filter（过滤器）：过滤器用于对请求进行处理和转换，可以修改请求、响应以及执行其它自定义逻辑。Spring Cloud Gateway提供了多个内置过滤器，如请求转发、请求重试、请求限流等。同时也支持自定义过滤器，可以根据需求编写自己的过滤逻辑。

2.3.4 Spring Cloud Gateway工作流程

Gateway Handler（网关处理器）：网关处理器是Spring Cloud Gateway的核心组件，负责将请求转发到匹配的路由上。他根据路由配置和断言条件进行路由匹配，选择合适的路由进行请求转发。网关处理器还会依次应用配置的过滤器链，对请求进行处理和转换。
Gateway Filter Chain（网关过滤器链）：网关过滤器链是由一系列过滤器组成，按照配置的顺序依次执行。每个过滤器可以在请求前、请求后或者请求发生错误时进行处理。过滤器链的执行过程可以修改请求、响应以及执行其它自定义逻辑。

2.4 远程调用

在分布式系统中，各个服务可能处于不同主机，但是服务之间不可避免的需要互相调用，我们称之为远程调用。

2.4.1 远程调用实现

Feign：一个声明式的Web服务端，用于简化HTTP API的调用，通信方式基于HTTP协议（是一种应用层协议）。主要强调是网络通信。
Dubbo：一个分布式服务框架，用于构建面向服务的微服务架构。通信方式基于RPC协议（是一种用于分布式系统之间的通信协议），支持多种序列化协议，如gRPC、Hessian等。主要强调的是服务之间的远程调用。

需要注意的是，Feign和Dubbo并不是互斥的关系。Dubbo可以使用HTTP协议作为通信方式，Feign也可以集成RPC协议进行远程调用。选择使用哪种远程调用方式取决于具体业务需求和技术栈的选择。

2.4.2 Feign主要特点和功能

Feign是在RestTemplate和Ribbon的基础上进一步封装，使用RestTemplate实现Http调用，使用Ribbon实现负载均衡。

声明式API：Feign允许开发者使用简单的注解来定义和描述对远程服务的访问。通过使用注解，开发者可以轻松的指定URL、HTTP方法、请求参数、请求头等信息，使用远程调用变得更加直观和易于理解。

@FeignClient(name = "example", url = "https://api.example.com")
public interface ExampleService {
    @GetMapping("/endpoint")
    String getEndpointData();
}

集成负载均衡：Feign集成了Ribbon负载均衡器，可以实现客户端的负载均衡。他可以根据服务名和可用实例进行动态路由，并分发请求到不同的服务实例上，提高系统的可用性和可伸缩性。
容错机制：Feign支持集成Hystrix容错框架，可以再调用远程服务时提供容错和断路器功能。当远程服务不可用或者响应时间过长时，Feign可以快速失败并返回预设的响应结果，避免对整个系统造成级联故障。

2.4.3 Dubbo工作原理

Provider：暴露服务的服务提供方。
Consumer：调用远程服务的服务消费方。
Register：服务注册与发现的注册中心。
Monitor：统计服务的调用此时和调用时间的监控中心。
Container：服务运行容器。

2.4.4 Dubbo负载均衡策略

随机（默认）：随机来。
轮询：一个一个来。
活跃度：机器活跃度来负载均衡。
一致性hash：落到同一台机器。

2.5 负载均衡

分布式系统中 A 服务需要调用 B 服务，B 服务在多台机器都存在，A 调用任意一个服务器均可完成功能。为了使每一台服务器都不要太忙或者太闲，我们可以负载均衡的调用每一台服务器，提升网站的健壮性。

2.5.1 常见负载均衡算法

随机：任意选择健康池的一台服务器。
轮询：为第一个请求选择健康池的第一台服务器，然后按顺序往后依次选择，直到最后一台，以此循环。
加权轮询：根据平均响应时间计算所有服务权重，响应时间越快的服务权重越大被选中概率越高。刚启动时如果统计信息不足，则使用轮询策略，等统计信息足够，切换到加权轮询。
最小连接：优先选择连接次数最少，也就是压力最小的服务器，在会话较长的情况下可以考虑采用这种方式。
散列：根据请求源的 IP 散列（hash）来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器。如果应用需要处理状态而要求用户能连接到之前相同的服务器，可以考虑采用这种方式。

2.5.2 负载均衡实现

Ribbon：Netflix开源的一个客户端负载均衡器，可以与Feign无缝集成，为Feign提供负载均衡的能力。

2.5 熔断&降级&限流

在微服务架构中，微服务之间通过网络进行通信，存在相互依赖，当其中一个服务不可用时，有可能造成雪崩效应。要防止这样的情况，必须要有容错机制来保护服务。

熔断：设置服务的超时，当被调用的服务经常失败到达某个阈值，我们可以开启断路保护机制，后来的请求不再去调用这个服务，直接返回默认数据。

降级：在运维期间，当系统处于高峰期，系统资源紧张，我们可以让非核心业务降级运行。即某些服务不处理或者简单处理（抛异常、返回null、调用mock数据、调用FallBack处理逻辑）。

限流：对进入服务的请求流量进行控制，使服务能够承担不超过自己的流量压力。

总结：为了保证集群大部分服务的可用性和可靠性，防止崩溃，牺牲小我，用户最终都是体验到某个功能不可用。熔断是被调用方故障，触发的系统主动规则，降级是基于全局考虑，停止一些正常的服务，释放资源。

2.5.1 熔断降级限流实现

Hystrix：Netflix提供开源框架，提供线程隔离、服务降级、请求缓存、请求合并等功能，可与Spring Cloud其它组件无缝集成，官方已停止维护。
Resilience：Spring Cloud推荐的轻量级服务熔断库，提供类似Hystrix的功能，具有更好的性能和更简洁的API，可与Spring Cloud其它组件无缝集成。
Sentinel：阿里巴巴开源的流量控制和熔断降级组件，提供实时监控、流量控制、熔断降级等功能，与Spring Cloud Alibaba生态紧密集成。
Dubbo：Dubbo自带熔断降级机制，可以通过配置实现服务熔断和降级，与Dubbo的RPC框架紧密集成。

2.5.2 Hystrix实现服务容错

服务熔断（Circuit Breaker）：Hystrix通过设置阈值来监控服务的错误率和响应时间。当错误率或响应时间超过预设的阈值时，熔断器将会打开，后续请求将不再发送到实际的服务提供方，而是返回预设的的默认值或者错误信息。这样可以快速隔离故障服务，防止故障扩散，提供系统的稳定性和可用性。
服务降级（Fallback）：当服务熔断打开时，Hystrix可以提供一个备用的降级方法或者返回默认值，以保证系统正常运行。开发者可以自定义降级逻辑，如返回缓存数据、执行简单的逻辑处理或者调用其他可靠服务，以提供有限但可用的功能。

public class MyService {
    @HystrixCommand(fallbackMethod = "fallbackMethod")
    public String myServiceMethod() {
        // 实际的服务调用逻辑
        // ......
    }

    public String fallbackMethod() {
        // 降级方法逻辑，当服务调用失败是会执行此方法
    }
}

请求缓存（Request Caching）：Hystrix可以缓存对同一请求的响应结果，当下次请求相同的数据时，直接从缓存中获取，避免重复的网络请求，提高系统的性能和响应速度。
请求合并（Request Collapsing）：Hystrix可以将多个并发的请求合并为一个批量请求，减少网络开销和资源占用。这对于一个高并发的场景可以有效的减少请求次数，提高系统的性能。
实时监控和度量（Real-time Monitoring and Metrics）：Hystrix提供了实时监控和度量功能，可以对服务的执行情况进行监控和统计，包括错误率、响应时间、并发量等指标。通过监控数据，可以及时发现和解决服务故障或性能问题。
线程池隔离（Thread Pool Isolation）：Hystrix将每个依赖服务的请求都放在独立的线程池中执行，避免因某个服务的故障导致整个系统的线程池资源耗尽。通过线程池隔离，可以提高系统的稳定性和可用性。

2.5.3 Sentinel限流

Sentinel通过动态管理限流规则，根据定义的规则对请求进行限流控制。

定义资源：在Sentinel中，资源可以使URL、方法等，用于标识需要进行限流的请求。

@SentinelReaource(blockHandler = "blockHandlerGetUser")
public User getUserId(String id) {
    throw new RuntimeException("getUserId command failed");
}

// 方法调用被限流、降级、系统保护的时候调用
public User blockHandlerForGetUser(String id, BlockException e) {
    return new User("admin");
}

配置限流规则：在Sentinel的配置文件中定义资源的限流规则。规则可以报考资源名称、限流阈值、限流模式（令牌桶或漏铜）等。

private static void initFlowQpsRule() {
    List<FlowRule> rules = new ArrayList<>();
    FlowRule rule = new FlowRule();
    rule.setResource(resource);
    rule.setCount(20);
    rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
    rule.setLimitAPP("default");
    rules.add(rule);
    FlowRuleManager.loadRules(rules);
}

流量监控：Sentinel会监控每个资源的流量情况，包括请求的QPS、线程数、响应时间等。

限流控制：当请求到达时，Sentinel会根据资源的限流规则判断是否需要进行流量控制。如果请求超过了限流阈值，则可以进行限制、拒绝或者进行其他降级处理。

2.5.4 限流算法

计数器算法（固定窗口）
滑动窗口
漏铜算法
令牌桶算法

2.6 链路追踪&监控

在微服务架构中，一个完整的请求可能经过十几个服务，如果某一个服务出了问题，排查起来非常困难，所以就需要进行链路追踪来帮助排查问题。通过链路追踪可以可视化的追踪请求从一个服务到另一个服务的调用情况。可以帮助优化性能、可视化依赖关系、监控服务和告警。

2.6.1 链路追踪实现

Zipkin：是Twitter一个开源的分布式实时追踪系统，Spring Cloud Sleuth提供了与Zipkin的集成。可以通过在微服务中添加相应依赖和配置，将追踪信息发送到Zipkin服务器，并通过Zipkin UI进行可视化展示和查询。

Jaeger：是Uber开源的分布式追踪系统，也被纳入了CNCF（云原生计算基金会）的维护。通过使用Spring Cloud Sleuth和Jaeger客户端库，可以将追踪信息发送到Jaeger并进行可视化展示和查询。
SkyWalking ：Apache开源的应用性能监控与分析系统，提供了对Java、.Net和Node.js等语言的支持。可以与Spring Cloud Sleuth集成，将追踪数据发送到SkyWalking服务器进行可视化展示和分析。

Pinpoint：是Naver开源的分布式应用性能监控系统，支持Java和.Net。提供了与Spring Cloud Sleuth的集成，可以将追踪数据发送到Pinpoint服务器，并通过其UI进行分析和监控。

2.6.2 监控告警实现

Prometheus：是一个开源的监控系统，具有灵活的数据模型和强大的查询语言，能够收集和存储时间序列数据。可以通过HTTP协议定期拉取微服务的指标数据，并提供可扩展的存储和查询功能。
Grafana：是一个开源的可视化仪表工具可以与Prometheus结合使用，创建实时和历史数据的仪表盘。Grafana提供了丰富的图标和可视化选项，可以帮助用户更好的理解和分析微服务的性能和状态。

2.7 分布式事务

事务解决方案

2.8 服务日志收集

2.8.1 ELK方案

Elasticsearch提供数据存储和检索能力，Logstash负责将日志收集到ES，Kibana负责日志数据的可视化分析。

Elasticsearch：是一个分布式搜索与分析引擎，用于存储和索引大量日志数据。提供了快速的搜索和聚合功能，可以高效的处理大规模的日志数据。
Logstash：是一个用于收集、过滤和转发日志数据的工具。可以从各种来源（如文件、网络、消息队列等）收集日志数据，并对数据进行处理和转换，然后将其发送到Elasticsearch进行存储和索引。
Kibana：一个用于日志数据可视化和分析的工具。提供了丰富的图标、仪表盘和搜索功能，可以帮助用户实时监控和分析日志数据，发现潜在的问题和趋势。

2.8.2 ELK流程

每个微服务中配置日志输出：将微服务的日志输出到标准输出（stdout）或者日志文件。
使用Logstash收集日志：配置Logstash收集器，通过配置输入插件（如文件输入、网络输入等）监听微服务的日志输出，并进行过滤和处理。
将日志文件发送到Elasticsearch：配置Logstash的输出插件，将经过处理的日志数据发送到Elasticsearch进行存储和索引。
使用Kibana进行可视化和分析：通过Kibana连接到Elasticsearch，创建仪表盘、图表和搜索查询，实时监控和分析微服务的日志数据。

3、微服务讨论

3.1 微服务设计原则

单一职责：让每个服务独立，有界限的工作。每个服务只关注自己的业务，做到高内聚，服务和服务之间低耦合。
服务自治原则：每个服务要能做到独立开发、独立测试、独立构建、独立部署，与其他服务进行解耦。
轻量级通信原则：让每个服务的调用是轻量级，并且能够跨平台、跨语言。例如采用RESTful风格，利用消息队列进行通信等。
粒度进化原则：对每个服务的粒度把控，其实没有统一的标准，这个得结合具体业务问题，不要过度设计，服务的粒度随着业务和用户的发展而发展。

总结：软件是为业务服务的，好的系统不是设计出来的，而是进化出来的。

3.2 服务拆分依据

系统隔离点（系统业务边界）。

3.3 高可用&高并发&高性能

高可用：集群。

高并发：分流（负载均衡、消息队列、数据库拆分）、导流（缓存、CDN）、并行/发编程。

高性能：程序处理速度。

3.4 CAP定理&BASE理论

3.4.1 CAP定理

一致性（Consistence）：在分布式系统中所有数据备份，在同一时刻是否同样的值（等同于所有节点访问同一份最新数据副本）。分布式系统中实现一致性的 rfat 算法。
可用性（Availlability）： 在集群中一部分节点故障后，集群整理是否还能响应客户端读写请求（对数据更新具备高可用性）。
分区容错性（Partition Tolerance）：大多数分布式系统都分布在多个子网络，每个子网络就叫做一个区（Partition），区间通讯可能失败。比如一台服务器部署在中国，另一台部署在美国，这就是两个区，他们之间可能无法通讯。

CAP 原则指的是，这三个要素最多只能同时实现两个，不可能三者兼顾。

3.4.2 BASE理论

基本可用（Basically Available）：基本可用是指分布式系统在出现故障时，允许损失部分可用性（例如响应时间：正常情况下搜索引擎需要在0.5s内返回给用户查询结果，但由于出现故障，比如系统断电或者网络故障，响应时间增加到1~2s；功能上的可用性：购物网站购物高峰时，比如双十一，为了保护系统稳定性，部分消费者可能被引导至一个降级页面。）。需注意的是，基本可用绝不等价于系统不可用。
软状态（Soft State）：指系统存在中间状态，而该状态不会影响系统整体可用性。分布式存储一般一份数据会有多个副本，允许不同副本同步延时就是软状态的体现。mysql replication 的异步复制也是一种体现。
最终一致性（Eventtual Consistence）：指系统中所有数据副本经过一段时间后最终能达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的特殊情况。

BASE理论是对 CAP 定理的延伸，思想就是即使无法做到强一致性（CAP中一致性就是强一致性），但可以采用适当的采取弱一致性，即最终一致性。