部署架构调整之LVS VS Consul

这是学习笔记的第 2070 篇文章

最近在做数据库方向的部署架构，在做一些性能测试的时候，算是达到了毫秒级的优化层次，按照业务的需求读延迟需要在1毫秒以内，那么奔着这个目标的优化就相对来说清晰多了，能不能达到是另外一回事。

基于LVS的架构模式，是LVS+keepalived+MyCAT的架构体系，在这三层架构里面LVS负责负载均衡，keepalive负责LVS层的高可用，从而承接了中间件层的高可用。

在这种三层架构下，所有的请求都会统一经过LVS的DR模式流转，当然LVS模式也固有一些自己的限制，比如不支持跨网段，同时对于跨机房业务来说限制也相对较大，所以在LVS模式的性能优化初具成效之后，我们可以得到一个兜底的方案作为基线，以这个基线来进行更多的对比测试。

在这种背景下，我们继续测试了基于Consul的方案，Consul的方案会略去一层数据通信，同时基于Consul的负载均衡也可以支持中间件层的水平扩展，在这种模式下，对于应用层来说对接的就是一个DNS而非VIP了。

在跨机房架构设计中尤其有效，可以通过API模式进行服务对接，或者基于域名，如下是一个简单的设计图例，异机房的节点可以作为灾备，而在需要的时候能够直接顶上去，对于应用层来说，就不需要改动接入层的配置了。

而基于LVS的负载均衡模式和基于Consul的模式，两者的差异有多大呢，我们可以通过如下的一个图来得到较为准确的状态结果。

左侧的部分是基于LVS模式，右侧的部分是基于Consul模式，两者的差异大概有10%左右，在这个场景里面，大概是0.1~0.2毫秒的差异，在一些极限的场景下这种提升还是很有必要的。

而这也能够决定我们能够走多远。