01_初识微服务

文章目录

一、微服务概述
- 1.1 什么是微服务
- 1.2 对比微服务架构与单体架构
- 1.3 微服务设计原则
- 1.4 微服务开发框架
- 1.5 简单理解分布式部署与集群部署
二、微服务的核心概念
- 2.1 服务注册与发现
- 2.2 微服调用（通信）
- 2.3 服务网关
- 2.4 服务容错
- 2.5 链路追踪
- 参考链接

一、微服务概述

1.1 什么是微服务

微服务架构是一种软件架构风格。它将一个大型的、复杂的应用程序拆分成一组小型、独立的服务，每个服务都围绕着具体业务功能进行构建，并独立地开发、测试、部署和运维，服务之间通过一些轻量级的通信机制进行通信。

1.2 对比微服务架构与单体架构

单体架构所有模块全耦合在一起，代码量大，复杂度高。而微服务将应用程序拆分为多个独立的服务，每个服务相当于一个独立的项目，代码量和复杂度都明显减小了。
单体架构一般使用同一个数据库（多数据库可以实现，比较麻烦），存储方式单一。而微服务中不同服务可以使用不同的数据库，存储方式也可以不一样（如redis，mysql，sqlserver）。
单体架构只有一个应用程序，该程序内的所有模块使用的开发技术都一样。采用微服务架构后，各个服务都可以灵活地选择合适的开发技术，开发模式灵活。
单体架构因为代码庞大，部署就会非常慢。而采用微服务架构后，各个微服务可以独立地部署，这些微服务的部署要快得多。

1.3 微服务设计原则

单一职责：每个微服务只需要实现自己的业务逻辑。
服务自治原则：每个微服务的开发、测试、运维、部署都是独立的，可以当成一个独立的项目来对待。
轻量级通信原则：通信的语言要非常的轻量，且需要是跨语言、跨平台的。
接口明确原则：由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活。

1.4 微服务开发框架

SpringCloud：一系列框架的集合，用于帮助开发者在Spring Boot应用中快速实现常见的微服务模式。
Kubernetes（K8s）：一个容器编排平台，用于自动化、容器化应用的部署、扩展和管理。对于微服务架构，Kubernetes 提供了服务发现、负载均衡、自动扩缩容等功能，是大规模部署和管理微服务的理想选择。
Apache Dubbo：阿里巴巴开源的一款高性能、轻量级的Java RPC框架，专为高性能和分布式系统设计。它提供了服务注册与发现、负载均衡、监控等功能，特别适合构建高性能的微服务系统。
gRPC：一个高性能、开源和通用的RPC框架，支持多种语言，非常适合构建跨语言的微服务架构。

1.5 简单理解分布式部署与集群部署

如果一个系统用到了多个服务器，如应用程序、数据库、消息队列分别使用一个服务器部署，或者应用程序部署到了多个服务器上，这种情形就是分布式部署。分布式部署可以有效提高系统性能，还能实现高可用性。

集群部署是分布式部署的一种。在微服务架构中，通常将一个服务运行在多个服务器上，这些服务实例组成了一个集群。集群中的一个服务实例称为一个节点，单个节点故障时仍能通过其他节点提供服务，实现了高可用性。多个节点来分摊请求，可以降低单个节点的负荷，提高了系统的整体性能。

二、微服务的核心概念

在这里插入图片描述

2.1 服务注册与发现

服务注册指服务提供者在启动时将其自身的信息（如服务名称、地址、端口等元数据）注册到一个中心化的注册中心的过程。这个注册中心可以是Eureka、Consul、Zookeeper、Etcd等专门的服务发现与配置管理组件。

服务发现指服务消费者在需要调用某个服务时，能够从服务注册中心查询到该服务的实际地址（包括IP地址和端口号），然后根据这些信息建立连接并进行通信的过程。

服务的注册与发现带来了如下好处：

解耦合：服务之间通过注册中心间接通信，而不是硬编码对方地址，实现了服务间的松耦合。
负载均衡：服务发现机制通常与负载均衡策略结合使用。
故障容错：及时发现并移除故障或不可达的服务实例。
集中监控：作为集中监控服务状态的入口，收集服务实例的健康状况、性能指标等信息。
动态配置：服务实例可以在运行时动态地注册和注销，无需手动配置服务地址。
易于扩展：水平扩展时只需启动新的服务实例并自动注册到注册中心即可。

2.2 微服调用（通信）

同步调用：Restful API（基于HTTP，性能低但灵活度高），RPC（基于TCP，性能高但灵活度低）
异步调用：MQ

2.3 服务网关

在微服务架构中，一个系统会被拆分为多个微服务，这样就带来了一些问题：

前端需要维护大量微服务的地址。随着项目的迭代，后端可能需要重新划分微服务，此时前端需要进行相应的调整。
每个微服务都需要进行一些重复的工作，如认证、鉴权、处理跨域问题。

为了解决上述问题，微服务引入了网关的概念。网关作为客户端的统一入口，负责将请求路由到具体的微服务。网关还可以实现一些业务无关的公用逻辑，如认证、鉴权、处理跨域、路由转发、安全策略（SQL注入，Web攻击，黑白名单）、流量控制、日志监控，证书/加密解密等处理等。

2.4 服务容错

微服务架构中的服务容错是一个至关重要的设计原则，旨在确保系统在部分服务出现故障时仍能继续提供服务，保持整体的稳定性和可靠性。以下是一些常用的服务容错策略：

服务降级：当某个服务因故障无法正常响应时，服务降级机制允许系统以一种简化的形式继续提供服务，即使这意味着牺牲部分功能或性能。例如，可以返回默认数据、缓存数据或者一个友好的错误信息，而不是完全失败，以此来保证基本的用户体验。
服务熔断：受电路断路器启发，服务熔断机制用于防止服务链路中的故障传播。当调用某个服务的错误率超过预设阈值时，熔断器会“跳闸”，后续对该服务的调用将不再执行，而是直接返回一个错误或者默认结果。这样可以防止持续尝试访问有问题的服务导致资源耗尽。熔断器通常还会有一个自我恢复机制，即在一段时间后尝试重新建立连接，判断服务是否已恢复正常。
限流：为了保证核心服务的稳定性，随着访问量的不断增加，需要为系统能够处理的服务数量设置一个极限阀值，超过这个阀值的请求则直接拒绝。
超时设置：为服务调用设定超时限制，以防因个别服务响应慢而导致整个请求链路阻塞。一旦超时，调用方将立即得到反馈，可以选择进行重试、降级或其他补偿措施。
重试机制：自动对失败的操作进行重试，通常结合退避策略（如指数退避）以减少短时间内对同一故障服务的重复冲击。合理设置重试次数和间隔可以有效提高请求的成功率。
负载均衡：将请求分发到不同实例上，避免单个服务实例成为瓶颈或故障点，同时也可以确保系统的整体可用性和响应时间。
异步通信与消息队列：采用异步处理和消息队列解耦服务间直接调用，提高系统的响应速度和容错能力。即使某个服务暂时不可用，消息也能暂存并在服务恢复后处理。
隔离：使用容器、虚拟机或线程池等技术隔离服务，防止一个服务的问题波及到其他服务。例如，线程池隔离可以限制服务内部特定操作的资源使用，防止资源耗尽。
健康检查与自我修复：定期对服务实例进行健康检查，及时发现并隔离不健康的服务实例。结合自动化部署工具，实现故障服务的自动重启或替换，加快系统恢复速度。
监控与警告：实时监控服务的健康状况和性能指标，及时发现并响应问题。配合告警系统，可以在问题发生初期通知（短信，邮件，电话）运维人员介入处理。