消除单点，一篇搞定 | 架构设计篇

系统架构中，为什么会存在单点？

(1)存在设计缺陷，出现了单点；

(2)能大大简化系统设计，有意为之，设置单点；

 

典型互联网高可用架构，哪些地方可能存在潜在单点？

典型互联网高可用架构：

(1)端，通过DNS，由域名拿到nginx的外网IP；

(2)反向代理，nginx是后端入口；

(3)站点应用，典型的是tomcat或者apache；

(4)服务，典型的是dubbo提供RPC服务调用；

(5)数据层，典型的是读写分离的db架构；

在这个互联网架构中，站点、服务、数据库的从库都容易通过冗余的方式来保证高可用，但：

(1)nginx是一个潜在的单点；

(2)数据库写库也是一个潜在的单点；

 

哪些例子，因为设计需要，有意设置的单点？

先看GFS（Google File System）架构的例子：

GFS的系统架构里主要有这么几种角色：

(1)client，就是发起文件读写的调用端；

(2)master，这是一个单点服务，它有全局视野，掌握文件元信息；

(3)chunk-server，实际存储文件的服务器；

在GFS系统里，master是一个单点服务。

Map-reduce系统里也有类似的角色，协调全局的master就是单点，它的存在，能够大大的简化系统架构设计。

 

不管是设计缺陷，还是有意为之，像nginx，db-master，GFS-master这样的单点服务，会存在什么问题呢？

两个大问题：

(1)高可用问题：单点一旦发生故障，服务就会受到影响；

(2)性能瓶颈：单点不具备良好的扩展性，单点的性能上限往往就是整个系统的性能上限；

 

“高可用”问题通常怎么优化？

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

shadow-master，顾名思义，它只是单点master的一个shadow(影子)：

(1)master工作时，shadow-master只备份；

(2)master出现故障时，shadow-master会自动变成master，继续提供服务；

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

 

以GFS的master为例，master正常时：

(1)client会连接正常的master，shadow-master不对外提供服务；

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

(3)master与shadow-master有相同的虚IP；

 

当发现master异常时：

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

 

除了GFS与MapReduce系统中的主控master，nginx和数据库的主库master亦可用类似的方式来保证高可用：

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

(2)平时只有一个主库提供服务；

(3)异常时，虚IP漂移到另一个主库，shadow-master变成主库继续提供服务；

关于高可用，更多详细的内容，可参考《究竟啥才是互联网架构“高可用”》。

 

“性能瓶颈”问题通常怎么优化？

有时候，单点设计是有意为之，此时单点的性能（例如GFS中的master）有可能成为系统的瓶颈，那么，减少与单点的交互，便成了存在单点的系统优化的核心方向。

如何来减少与单点的交互，有两种常见的方法：

(1)批量写；

(2)客户端缓存；

如何利用“批量写”减少与单点的交互，提升整体性能？

举一个单点“ID生成器”的例子，很多公司会利用数据库的auto-inc-id，来作为一个严格递增的ID生成工具。

其交互流程是：

(1)调用方需要ID；

(2)插入记录，利用auto-inc-id来生成和返回ID；

此时，ID生成的并发上限，取决于单点数据库的插入性能上限。

如何利用“批量写”提升性能呢？

 

优化如下：

(1)增加一个服务，每次从DB拿出100个id；

(2)调用方需要ID；

(3)服务直接返回100个id中的1个，100个分配完，再访问DB；

这样一来，每分配100个才会写数据库一次，分配id的性能提升了100倍。

 

如何利用“客户端缓存”减少与单点的交互，提升整体性能？

还是举GFS文件系统的栗子。

GFS文件读取的流程如下：

(1)GFS的调用客户端client要访问shenjian.txt，先查询本地缓存，miss了；

(2)client访问master问说文件在哪里，master告诉client在chunk3上；

(3)client把shenjian.txt存放在chunk3上记录到本地的缓存，然后进行文件的读写操作；

(4)未来client要访问文件，从本地缓存中查找到对应的记录，就不用再请求master了，可以直接访问chunk-server；

 

这类缓存的命中非常非常高，在99%以上（因为文件的自动迁移是小概率事件），这样与master的交互次数就降低了100倍。

批量写，客户端缓存，对性能的提升也有极限，单点性能优化还有没有其他方法？

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

水平扩展，才能够无限的提升系统性能。

以nginx为例，如何来进行水平扩展呢？

第一步的DNS解析，只能返回一个nginx外网IP么？

通过DNS轮询，在DNS-server，一个域名可以配置多个IP，每次DNS解析请求，轮询返回不同的IP，就能实现nginx的水平扩展，扩充负载均衡层的整体性能。

 

数据库单点写库也是同样的道理，在数据量很大的情况下，可以通过水平拆分，来提升写入性能。

 

关于性能扩展，更多详细的内容，可参考《究竟啥才是互联网架构“可扩展”》。

 

总结

今天的内容很多，希望行文有逻辑：

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

(2)shadow-master是一种常见高可用方案；

(3)减少与单点的交互，是单点系统优化的核心方向，常见方法有：批量写，客户端缓存；

(4)水平扩展，才能做到理论上的无限性能；

思路比结论重要。

架构师之路-分享可落地的技术文章

推荐阅读：

《究竟啥才是互联网架构“一致性”》

《究竟啥才是互联网架构“高可用”》

《究竟啥才是互联网架构“可扩展”》