通过使用 Ribbon 等工具在客户端和使用 Nginx 在服务器端确保适当的聊聊负载分配，可以增强系统可扩展性和弹性。使用
译自Improve Microservices With These New Load Balancing Strategies，负载作者 Dhruv Kumar Seth。均衡
从单体架构到微服务的策略转变已成为当代软件开发工作流中的一种实践。尽管创建和启动单体系统看起来很简单，改进但随着时间的微服务推移，它们在扩展和管理复杂应用程序时会造成重大障碍。聊聊
另一方面，使用微服务提供了一种更模块化的负载方法，使各个元素能够自主开发和部署。均衡但是策略，在多个节点上分布计算会带来新的改进挑战，尤其是微服务在可扩展性、效率和可靠性方面。聊聊实施有效的负载均衡策略对于解决这些问题至关重要。建立负载均衡技术对于有效应对这些挑战至关重要。
管理流量使公司能够利用微服务的好处，与旧的单体系统相比，提供更具可扩展性和可靠性的 API。本文探讨了通过高级负载均衡技术克服这些挑战的策略。IT技术网
从单体架构到微服务的转变在可扩展性和效率方面带来了障碍，同时努力实现最佳性能提升。在单体系统中，所有组件都是相互连接的，这使得初始设置更加简单，但随着应用程序的扩展，灵活性受到限制。另一方面，微服务采用了一种策略，允许每个服务独立地进行扩展和部署。
这种转变带来了自己的一系列关键挑战：
通信变得更加复杂：在微服务架构中，服务通过网络进行通信，通常跨越基础设施边界。这引入了网络延迟和额外的负载，而这些负载仅存在于所有组件在内部进行交互的单体系统中。负载均衡挑战：与负载均衡相对简单的单体系统不同，微服务需要智能流量分配以确保高可用性和高效的资源利用。传统负载均衡器可能需要充分了解微服务的动态特性，从而导致流量路由效率低下、实例利用率不足以及潜在的服务中断。管理可扩展性和负载分配：随着微服务的扩展，服务器租用确保跨服务的均匀负载分配变得更加复杂。负载均衡器必须处理服务的动态扩展以维持性能、防止瓶颈并确保系统可靠性。资源开销：微服务中的有效负载均衡需要额外的基础设施，例如 API 网关和服务发现工具，以正确路由流量。这种增加的复杂性会导致更高的资源管理和运营成本。正确理解这些挑战对于在保持最佳负载均衡的同时最大化微服务的好处至关重要。确保顶级可用性和性能的一个关键方面是使用负载均衡技术，该技术可以在服务之间有效地分配流量。组织必须克服这些障碍才能利用微服务的可扩展性和适应性。通过实施负载均衡方法，企业可以创建可扩展且高效的系统。
在微服务设置中进行负载均衡既棘手又至关重要，因为它直接影响系统可用性和性能级别。为了确保没有一个实例因用户请求而过载，并保持操作，即使一个实例遇到问题，在各种服务实例之间分配最终用户请求至关重要。这涉及利用服务发现来精确定位动态负载均衡的情况，b2b供应网以适应负载变化，并实施容错健康检查以监控和将流量从故障实例中重定向，以维持系统稳定性。这些策略共同作用，以保证微服务设置的稳固和高效。
Eureka 与 HashiCorp
功能/方面
Eureka（Netflix）
Consul（HashiCorp）
集成
与 Spring Cloud 和 Ribbon 强集成，用于客户端负载均衡。
专为更广泛的环境设计，支持多数据中心设置。
灵活度
灵活度较低，主要适用于 Spring Cloud 环境。
高度灵活且功能丰富，支持各种基础设施。
服务发现
主要专注于客户端服务发现和负载均衡。
提供服务发现和基于 DNS 的解析，使其更通用。
运行状况监控
内置运行状况监控，但某些安全配置需要其他工具。
包括集成运行状况监控，使其适用于详细的服务发现管理。
DNS 支持
没有本机 DNS 支持。
服务的本机 DNS 解析，简化了服务发现。
最佳用例
适用于基于 Spring 的微服务生态系统。
适用于具有多数据中心和多云环境的大型企业。
微服务架构旨在将应用程序划分为独立的服务，以进行单独的部署和扩展。然而，这种分散的方法对处理服务之间的流量提出了挑战。动态负载均衡方法在微服务架构中发挥作用，通过确保将请求分发到正确的服务实例，从而增强可扩展性、可靠性和对故障的弹性。
API 网关用作入口点，所有用户都可以通过该入口点提交其请求并根据请求的内容将其路由到微服务。它处理与其他问题相交的各种任务，如安全检查、身份验证速率限制问题和监控能力
Kong 是一个著名的开源 API 网关。以下是如何快速入门：
a) 要安装 Kong，请使用软件包管理器，如 brew（适用于 macOS）或 apt（适用于 Ubuntu）。b) 设置数据库：默认情况下，Kong 使用 PostgreSQL。更新 Kong 的配置文件并设置数据库。c) 运行迁移：执行kong migrations bootstrap以配置数据库架构。d) 启动 Kong：要启动网关，请键入run kong start。e) 添加服务：要添加新服务，请使用 Kong 的 Admin API。
复制curl -i -X POST http://localhost:8001/api_uri \ --data name=my-service \ --data url=http://app-service-domain:port1.2.3.f) 添加路由：将服务链接到路由：
复制curl -i -X POST http://localhost:8001/api_uri/app-service/routes \ --data paths[]=/my-route1.2.现在，对/my-route的请求将转发到您的服务。
速率限制保证公平使用并有助于阻止 API 滥用。在 Kong 中：
激活限制速率的插件：
复制curl -i -X POST http://localhost:8001/api_uri/my-service/plugins \ --data "name=rate-limiting" \ --data "config.minute=5" \ --data "config.hour=1000"1.2.3.4.通过此配置，客户端可以每分钟向my service发出最多 5 个请求，每小时最多发出 1000 个请求。如果超过这些限制，Kong 将返回 HTTP 状态代码（通常为 429 请求过多）以指示已达到速率限制。高级节流插件可以根据各种条件应用限制，以满足更复杂的速率限制需求，从而对请求处理提供细粒度控制。此插件允许根据用户角色、IP 地址和时间窗口等因素进行配置，从而进一步帮助优化和保护 API 使用。
在微服务设计中，异步通信可以显著提高可扩展性和性能。
RabbitMQ 非常适合传统消息模式。但是，Kafka 更适合事件流：
使用 Docker 或包管理器安装 RabbitMQ。建立队列：使用 RabbitMQ 的客户端库或管理界面。设置请求者： 复制ConnectionFactory factory = new ConnectionFactory(); factory.setHost("localhost"); try (Connection connection = factory.newConnection(); Channel channel = connection.createChannel()) { String replyQueueName = channel.queueDeclare().getQueue(); String corrId = UUID.randomUUID().toString(); AMQP.BasicProperties props = new AMQP.BasicProperties.Builder() .correlationId(corrId) .replyTo(replyQueueName) .build(); channel.basicPublish("", "rpc_queue", props, message.getBytes()); <em> // ... wait for response on replyQueueName</em> }1.2.3.4.5.6.7.8.9.10.11.12.13.14.15. 实现响应者： 复制ConnectionFactory factory = new ConnectionFactory(); factory.setHost("localhost"); try (Connection connection = factory.newConnection(); Channel channel = connection.createChannel()) { channel.queueDeclare("rpc_queue", false, false, false, null); channel.basicQos(1); Object monitor = new Object(); DeliverCallback deliverCallback = (consumerTag, delivery) -> { AMQP.BasicProperties replyProps = new AMQP.BasicProperties.Builder() .correlationId(delivery.getProperties().getCorrelationId()) .build(); String response =<em> // ... generate response</em> channel.basicPublish("", delivery.getProperties().getReplyTo(), replyProps, response.getBytes()); channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false); synchronized (monitor) { monitor.notify(); } }; channel.basicConsume("rpc_queue", false, deliverCallback, consumerTag -> { }); while (true) { synchronized (monitor) { try { monitor.wait(); } catch (InterruptedException e) { e.printStackTrace(); } } } }1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.在实际场景中实现这些模式时，这些模式可以帮助开发人员提高其在微服务上运行的 API 的效率和性能，以有效管理预期的增加的流量。API 网关作为入口点，允许服务之间的通信方法，从而取代同步通信方法。
单体应用程序通常采用集中式缓存方法，其中数据在单个级别上硬件化。对于简单的架构来说，这是可以的，但随着参数增加，速度会变慢。另一方面，微服务使用分布式缓存，其中缓存位于每个服务附近。这种分散化提高了数据可访问性，降低了延迟，并增加了缓存内聚性和一致性问题。因此，如果要扩展实际应用程序而不因性能不佳而遭受损失，分布式缓存非常重要。
一些软件定义网络具有单体结构，其中负载均衡器的概念是僵化的，固定在核心。另一方面，微服务使用客户端和服务器端负载均衡，并且流量可以在服务的不同实例之间均匀分布。这使得扩展微服务、在出现拥塞时创建新实例以及提高系统的功能和鲁棒性变得容易。
随着 API 变得更大，性能也可能成为单体应用程序中的问题；每个请求都必须经过所有层。它的响应时间是单体结构的两倍，因为请求可以被定向到相应且经过优化的服务。在微服务架构中，吞吐量通常甚至高于单体应用程序，因为流量不会像大量单个服务那样高度集中，从而可以有效利用资源，并且在高流量情况下不太可能出现宕机。
方面
单体架构
微服务架构
缓存效率
集中式缓存，其中所有软件都缓存在一个位置。适用于小规模应用程序，但随着系统扩展，它可能会出现问题。
分布式缓存为每个服务创建了许多本地定制的缓存，从而提高了数据可用性并降低了延迟。但是，它也可能引发一致性和连贯性问题。
负载均衡
静态、集中式负载均衡。灵活性有限，在高负载下可能导致潜在瓶颈。
动态负载均衡，既有客户端（例如 Ribbon）又有服务器端（例如 Nginx）。支持自主服务可扩展性，提高系统稳健性和灵活性。
API 响应时间和吞吐量
由于 API 查询涉及完整的堆栈遍历，因此延迟会随着应用程序大小而增加。由于单体结构无法同时管理多个请求，因此吞吐量受到限制。
API 引导用户使用特定且经过优化的服务。通过增强的缓存和负载均衡，系统可以管理更大的吞吐量，提高性能，更有效地利用可用资源，并减少宕机。
表 1. 基于缓存效率、负载均衡和 API 响应时间比较微服务和单体架构的性能。
以受控方式从单体架构迁移到微服务架构可以实现多种好处。本文讨论了平衡负载的方法，例如利用 Consul 进行服务发现、使用 Nginx 进行负载均衡以及使用 Ribbon 进行客户端负载均衡。涵盖的其他主题包括设置 API 网关和实现通信模式，为高效的微服务创建基础。
这些技术、API 网关实现和异步通信模式构成了高效微服务的有力基础。借助分布式缓存、智能负载均衡和事件驱动的系统设计，微服务在性能、可扩展性和弹性方面优于当今的单体架构。后者在资源利用和响应时间方面效率更高，因为可以根据需要扩展各个组件。
但是，必须记住，此处引入的性能改进类型意味着更高的复杂性。其实现是一个复杂的过程，需要反复监控和优化。如果实施得当，最终产品可以承受更大的容量，并且可以进一步扩展，并且比单体类型具有更好的工作负载和用户界面适应性。展望未来，微服务架构正在稳步发展。新的云形态和卓越的 AI 优化解决方案可能会进一步坚持建立有机、高效、可扩展且响应迅速的 API 平台。
本文是 The New Stack 的贡献者网络的一部分。对影响开发人员的最新挑战和创新有见解吗？我们很乐意听取您的意见。通过填写此表格或向mattburns@thenewstack.io发送电子邮件，成为贡献者并分享您的专业知识。
亿华智慧云
