# Message-Based Load Balancing Date: 2022-04-01 最近工作中涉及到一些负载均衡一些知识这里今天这篇文章是F5的 Message-Based Load Balancing。 这是2009年发布的一篇文章，后续F5已经建议从MBLB迁移到MRP功能模块。 原文链接： https://www.f5.com/services/resources/white-papers/message-based-load-balancing Migrating MBLB Functionality to MRPF Functionality https://techdocs.f5.com/kb/en-us/products/big-ip\_ltm/manuals/product/bigip-mblb-to-mrf-migration-12-0-0/2.html 在高可用可扩展性应用场景中，经常能看到负载均衡身影，有硬件设备也有软件实现，由于Web应用广泛应用负载平衡也变得更加适用于HTTP这些协议。 与HTTP不同也会有一些异步的协议：Diameter，RADIUS and SIP，由于大多数负载的设计针对同步消息传输环境，这使得原有的负载难以分发这些协议。 文中主要提到SIP协议的复杂性，SIP是一种基于文本的协议，它的语法和消息非常类似于HTTP协议，不同之处在于SIP不仅可以用TCP,也可以用UDP封装， 对移动业务支持比较好。 如果举一个更好理解的例子， 由于在金融机构工作，一些系统使用长连接异步的通讯方式，比如银联CUPS系统卡接口， 使用的是异步长链接模式，如何做到在前端接入和后端系统均为长连接情况下做到，报文级别的负载？ #### **挑战** - Asynchronous Messaging 异步消息 下面是同步场景，客户端发送一个请求同步等待一个响应。 ![](https://garlicspace.com/wp-content/uploads/2022/04/aa59d49dab03de6d26e6ba8cb98e95c.png) 下面是异步场景，客户端发送n个请求，服务端返回n个响应。 ![](https://garlicspace.com/wp-content/uploads/2022/04/82a6626bc99fb2b9e70e372b01a20ee.png) 这种场景下没有明显的客户端服务端之分，可以看到右边的服务也可能主动发起请求到左边的服务。 - Long-Lived Sessions 长连接 在传统负载中，每次会话或连接基础上完成。在同一会话中收到的所有请求都是相同服务器的负载平衡。当通信完成时，会话终止。 长连接场景中导致流量无法均匀分配到指定服务上。 - Message-Oriented Communication 消息处理 传统负载均衡维护请求和服务器端连接之间的1：1关系， 针对这种异步长连接场景，就需要做到1：n。也就是需要将请求均匀发送到后端的服务上。这时候就需要区分服务边界，需要多报文进行标识处理。 > 这里文档中提到AVP， 对AVP的理解，就是报文的标识，也就是需要从报文中找到唯一能标识他的信息。 #### **解决方案** 也就是MBLB （Message-Based Load Balancing）。 MBLB使Big-IP LTM能够以交钥匙方式实现特定协议支持，同时仍通过iRules实现客户和环境特定的自定义。 ![](https://garlicspace.com/wp-content/uploads/2022/04/de63c76131cb02fa063e21989855caa.png)   可以看到他提取A报文中的AVP代码根据负载策略送到上面服务器， 提起B报文的AVP送到下面服务器。 #### **总结** F5 TMOS架构提供了F5能够快速实现基于消息的协议， 保持通过iRules翻遍实现了各位异步并进行双向通信的协议适配。   #### **参考及引用** 文中图片来自原文 封面图片from [陳丁光](https://www.facebook.com/groups/474930279315210/user/100010173011046/?__cft__[0]=AZX1zTGTiRcuH1HkTQzBE5ML17mtmmvLTyG8cAnMzLF1rV1xMYeeRM-VWYKRRqpG6taHuXQD36y5oQPrbLP5hlfAvirQxum6gxBI9PcVmRQrUoiMRK9f-22SpT_7eGGIDcdiZZd6BYbfAiodbeJVeLRvKvUIip5keF8oXESMlIsgPxEfPcl7WM4Jb3ksgu43_IA&__tn__=-UC*F)