grpc

在过去的几年中，随着微服务的增长，gRPC在这些较小的服务之间的相互通信中获得了很大的普及,在后台，gRPC使用http/2在同一连接和双工流中复用许多请求。 使用具有结构化数据的快速，轻便的二进制协议作为服务之间的通信介质确实很有吸引力，但是使用gRPC时需要考虑一些因素，最重要的是如何处理负载均衡。 gRPC使用粘性连接 gRPC连接是粘性的。这意味着当从客户端到服务器建立连接时，相同的连接将被尽可能长时间地用于许多请求（多路复用）。这样做是为了避免所有最初的时间和资源花费在TCP握手上。因此，当客户端获取与服务器实例的连接时，它将保持连接。 现在，当同一客户端开始发送大量请求时，它们都将转到同一服务器实例。而这正是问题所在，将没有机会将负载分配给其他实例。他们都去同一个实例。 这就是为什么粘性连接会使负载平衡变得非常困难。 以下是一些负载均衡gRPC相互通信的方法，以及每种方法的一些细节。 1.服务器端 当在服务器端完成负载均衡时，会使客户端非常精简，并且完全不知道如何在服务器上处理负载： 网络负载均衡器 网络负载均衡器在OSI (Open Systems Interconnection) 模型的第4层运行。因此，它非常快，可以处理更多的连接。当出现新的TCP通信连接时，负载均衡器将选择一个实例，并且在连接有效期内将连接路由到该单个实例。 现在请记住

👆 这是第 43 篇 不掺水的原创 ，想要了解更多 ，请戳上方蓝色字体： 政采云前端团队 关注我们吧～ 本文首发于政采云前端团队博客：五分钟看懂 Nginx 负载均衡 https://www.zoo.team/article/nginx 前言 对于电商平台而言，随着业务的不断发展壮大，网站访问量和数据量也随之急剧增长，该情况的产生给服务器带来了一定的负担。从用户体验层面而言，由于服务器端数据处理带来的时延，往往导致页面的响应速度过慢、操作流畅性受阻等问题。这在某种程度上甚至会潜在影响平台的成交量。提供高效率，高质量的服务成为亟待解决的问题。负载均衡策略的出现和发展成为缓解上述问题的有效途径。本文将带你了解基于 Nginx 实现的负载均衡。 什么是负载均衡 负载均衡（Load Balance），它在网络现有结构之上可以提供一种廉价、有效、透明的方法来扩展网络设备和服务器的带宽，并可以在一定程度上增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性等。用官网的话说，它充当着网络流中“交通指挥官”的角色，“站在”服务器前处理所有服务器端和客户端之间的请求，从而最大程度地提高响应速率和容量利用率，同时确保任何服务器都没有超负荷工作。如果单个服务器出现故障，负载均衡的方法会将流量重定向到其余的集群服务器，以保证服务的稳定性。当新的服务器添加到服务器组后

作者 | 于雨 来源| 阿里巴巴云原生公众号 本文源自 2020 年 12 月 20 日作者在云原生社区 meetup 第二期北京站演讲 《Apache Dubbo-go 在云原生时代的实践与探索》的部分内容，如果对演讲完整内容感兴趣请访问： https://www.bilibili.com/video/av245840877 自从以 2013 年开源的 docker 为代表的的容器技术和以 2014 年开源的 K8s 为代表的容器编排技术登上舞台之后，相关技术从业人员从认知和体感上接受，云原生时代真的到来了。 当然也有很多资深技术人员认为，云原生时代要从 2010s 时以 OpenStack 为代表的虚机编排时代开始。当然，也有人说其实云原生技术诞生很早，可以从巨型机时代在巨型机上虚拟出若干小型机开始追溯。 在云原生时代，不变镜像作为核心技术的 docker 定义了不可变的单服务部署形态，统一了容器编排形态的 k8s 则定义了不变的 service 接口，二者结合定义了服务可依赖的不可变的基础设施。有了这种完备的不变的基础设置，就可以定义不可变的中间件新形态 -- 云原生中间件。 云原生时代的中间件，包含了不可变的缓存、通信、消息、事件(event) 等基础通信设施，应用只需通过本地代理即可调用所需的服务，无需关心服务能力来源。 微服务框架 从最早的单体应用时代到分布式技术时代