微服务架构原理与治理实践｜ 青训营

_毕晓晴的博客
104 阅读7分钟

引言

随着云计算和容器技术的发展，微服务架构在软件开发领域变得越来越流行。与传统的单体应用相比，微服务架构具有更高的灵活性、可扩展性和可维护性。然而，微服务架构也带来了一些挑战，如服务发现、负载均衡、故障处理等。本文将深入探讨微服务架构的原理，并分享一些实践中的治理策略。

系统架构演变历史

image.png

单体架构

优势:
1.性能最高
2.冗余小
劣势:\
1.debug 困难
2.模块相互影响
3.模块分工、开发流程

image.png

垂直应用架构

按照业务线垂直划分
优势:1. 业务独立开发维护
劣势:1.不同业务存在冗余2.每个业务还是单体 image.png

分布式架构

抽出业务无关的公共模块
优势:1. 业务无关的独立服务
劣势:1.服务模块bug可导致全站瘫痪
2.调用关系复杂
3.不同服务冗余

image.png

SOA架构(Service Oriented Architecture)

面向服务
优势:1. 服务注册
劣势:1.整个系统设计是中心化的
2需要从上至下设计重构困难

image.png

分布式架构

彻底的服务化
优势:1.开发效率
2.业务独立设计
3.自下而上故障隔离
劣势:1.治理、运维难度
2.观测挑战
3.安全性
4.分布式系统 image.png

微服务架构概览

从组件的维度去看看微服务架构的整体视角 image.png

微服务架构的原理

  1. 服务拆分：将应用程序拆分为一组小型、独立的服务，每个服务负责特定的业务功能。
  2. 服务通信：微服务之间通过轻量级的通信机制进行交互，如RESTful API、消息队列等。
  3. 服务自治：每个微服务都是独立部署、独立扩展和独立维护的，可以使用不同的技术栈和开发语言。

微服务治理的挑战

  1. 服务发现与注册：如何让服务能够自动发现和注册到服务注册中心，以便其他服务能够找到并调用它们。
  2. 负载均衡：如何在多个实例之间分配请求负载，以确保每个实例都能够平均处理请求。
  3. 故障处理：如何处理服务的故障，包括超时、重试、熔断等机制，以提高系统的可用性和稳定性。
  4. 日志和监控：如何收集和分析微服务的日志和指标数据，以便及时发现和解决问题。

微服务治理的实践策略

  1. 服务注册与发现：使用服务注册中心，如Consul、Etcd等，实现服务的自动发现和注册。
  2. 负载均衡：使用负载均衡器，如Nginx、HAProxy等，将请求分发到多个实例上。
  3. 故障处理：使用断路器模式和熔断器，如Hystrix、Resilience4j等，处理服务的故障情况。
  4. 日志和监控：使用ELK（Elasticsearch、Logstash、Kibana）或Prometheus等工具，收集和分析微服务的日志和指标数据。

核心服务治理功能：

流量治理：流量治理是指如何管理和控制微服务架构中的流量。通过使用负载均衡器，如Nginx、HAProxy等，可以将请求分发到多个实例上，以实现流量的均衡分配。此外，还可以使用限流、降级等策略来控制流量，以保护服务的稳定性。

服务均衡：服务均衡是指如何保持微服务架构中各个服务的负载均衡。通过监控服务的负载情况，可以动态地调整服务的实例数量，以确保每个服务都能够平均处理请求。同时，还可以使用自动扩展机制来根据流量的变化自动调整服务的实例数量。

稳定性治理：稳定性治理是指如何处理微服务架构中的故障情况。通过使用断路器模式和熔断器，如Hystrix、Resilience4j等，可以处理服务的故障，包括超时、重试、熔断等机制。此外，还可以使用容错机制来保护服务的稳定性，如使用消息队列来处理异步任务，避免因服务故障而导致的数据丢失。

字节服务治理实践--重试

重试的意义：

重试是一种应对系统错误或不稳定性的常见技术手段。当发生错误或某个操作失败时，重试机制可以尝试重新执行该操作，以增加成功的机会。重试的目的是提高系统的可靠性、容错能力和稳定性，保证关键任务的完成，并减少对用户的负面影响。

降低错误率
假设单次请求的错误概率为 0.01，那么连续两次错误概率则为 0.0001。
重试可以避免掉偶发的错误，提高 SLA (Service-Level Agreement)

func RemoteFunc(ctx context.Context,x int) (int, error){
	ctx2,defer_func := context.WithTimeout(ctx, time.Second)
	defer defer_func()
	res, err := grpc_client.Calculate(ctx2,x *2)
	return res, err
}
func RemoteFuncRetry(ctx context.Context, x int) (res int, err error) {
	for i := 0;i < 3;1++ {
		if res, err = RemoteFunc(ctx, x); err == nil {
			return}
		}
return
}

降低长尾延时
对于偶尔耗时较长的请求，重试请求有机会提前返回。
容忍暂时性错误
某些时候系统会有暂时性异常 (例如网络抖动)，重试可以尽量规避
避开下游故障实例
一个服务中可能会有少量实例故障 (例如机器故障)重试其他实例可以成功。

重试的难点

  1. 并发问题：当多个请求同时发生错误时，重试策略需要合理控制同时发起的重试请求，避免过载或竞争条件等问题。
  2. 错误识别：准确判断错误类型对于选择合适的重试策略很重要。有些错误是不可恢复的，需要避免无效的重试。
  3. 重试时间间隔：重试时，需要合理设置重试间隔，避免过频繁地尝试，减轻系统负担并降低错误积累的风险。
  4. 重试次数：需要根据错误类型和重试结果，设置适当的重试次数。太少的重试次数可能导致错误无法得到解决，而过多的重试次数可能会增加系统的延迟。重试的意义

重试策略

一种常见的策略是指数退避，即每次重试之间的时间间隔逐渐增加，以避免过于频繁地重试。
另一种策略是限制重试次数，当达到设定的次数后停止重试。还有一种策略是结合错误信息和上下文进行智能判断，例如根据错误类型、失败原因等因素来决定是否重试。
Hedged requests 对于可能超时(或延时高)的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应。

image.png

重试效果验证

image.png

结论

微服务架构的原理和治理实践对于构建可扩展、可维护的应用程序至关重要。通过合理的服务拆分和有效的治理策略，可以充分发挥微服务架构的优势，并提高系统的可用性和稳定性。在实践中，我们还需要根据具体的业务需求和技术栈选择合适的工具和框架来支持微服务架构的开发和运维工作。希望本文能够提供一些有用的思路和实践经验，帮助大家更好地理解和应用微服务架构。

avatar
文章
阅读
粉丝