单点系统架构可用性与性能优化

1. 缘起

单点master的设计会大大简化系统设计，况且有时候避免不了单点。

先看一个典型互联网高可用架构：

（1）客户端层：是浏览器或App，第一步先访问DNS-server，由域名拿到nginx的外网IP；

（2）负载均衡层：nginx是整个服务端的入口，负责反向代理与负责均衡工做；

（3）站点层：web-server层，典型的是tomcat或apache；

（4）服务层：service层，典型的是dubbo或thrift等提供RPC调用的后端服务；

（5）数据层：包含cache和db，典型的是主从复制读写分离的db架构。

在这个互联网架构中，站点层、服务层、数据库的从库均可以经过冗余的方式来保证高可用，但至少：

（1）nginx层是一个潜在的单点

（2）数据库写库master也是一个潜在的单点

2. 单点架构存在的问题

单点系统通常来讲存在两个很大的问题：

（1）非高可用：既然是单点，master一旦发生故障，服务就会收到影响；

（2）性能瓶颈：既然是单点，不具有良好的扩展性，服务性能总有一个上线，这个单点的性能上限每每就是整个系统的性能上限。

3. 解决单点高可用

3.1 shadow-master

shadow-master（影子master）是一种很常见的解决单点高可用问题的技术方案。

shadow-master：顾名思义，服务正常时，它只是单点master的一个影子，在master出现故障时，shadow-master会自动变成master，继续提供服务。

shadow-master它可以解决高可用的问题，而且故障的转移是自动的，不须要人工介入，但不足是它使服务资源的利用率降为50%，业内常用keepalived+vip的方式实现这类单点的高可用。

 

（1）client会链接正常的master，shadow-master不对外提供服务；

（2）master与shadow-master之间有一种存活探测机制；

（3）master与shadow-master有相同的虚IP（virtual-IP）；

当发现master异常时：

shadow-master会自动顶上成为master，虚IP机制能够保证这个过程对调用方是透明的。

nginx与数据库的主库master可用相似的方式来保证高可用，只是细节上有些地方要注意。

传统的一主多从，读写分离的db架构，只能保证读库的高可用，是没法保证写库的高可用的，要想保证写库的高可用，也可使用上述的shadow-master机制。

（1）两个主库设置相互同步的双主模式；

（2）平时只有一个主库提供服务，言下之意，shadow-master不会往master同步数据；

（3）异常时，虚IP漂移到另外一个主库，shadow-master变成主库继续提供服务。

须要说明的是，因为数据库的特殊性，数据同步须要时延，若是数据尚未完成同步，流量就切到了shadow-master，可能引发小部分数据的不一致。

3.2 减小与点点的交互，是存在单点的系统优化的核心方向

既然知道单点存在性能上限，单点的性能有可能成为系统的瓶颈，那么，减小与单点的交互，便成了存在单点的系统优化的核心方向。

怎么减小与单点的交互，提供两个常见的方法：

3.2.1 批量写

批量写是一种常见的提高单点性能的方式。参考https://www.cnblogs.com/lujiango/p/9376796.html#_label7

3.2.2 客户端缓存

客户端缓存也是一种下降与单点交互次数，提高系统总体性能的方法。

3.3 水平扩展时提高单点系统性能的好方案

不管怎么批量写，客户端缓存，单点毕竟是单机，仍是有性能上限的。

千方百计水平扩展，消除系统单点，理论上才可以无限的提高系统性能。

以nginx为例，若是来进行水平扩展？

第一步的DNS解析，只能返回一个nginx外网IP么？No，DNS轮询即时支持DNS-server返回不一样的nginx外网IP，这样就能实现nginx负载均衡层的水平扩展。

DNS-server部分，一个域名能够配置多个IP，每次DNS解析请求，轮询返回不一样的IP，就能实现nginx的水平扩展，扩展负载均衡曾的总体性能。

数据库单点写库也是一样的道理，在数据量很大的状况下，能够经过水平拆分，来提高写入性能。

可是，并非全部的业务场景均可以水平拆分。

4. 总结

（1）单点系统存在的问题：可用性问题，性能瓶颈问题；

（2）shadow-master是一种常见的解决单点系统可用性的问题的方案；

（3）减小与单点的交互，是存在单点的系统优化的核心方向，常见方法是：批量写，客户端缓存；

（4）水平也是提高单点系统性的好方案。