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

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

(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) 水平扩展 ，才能做到理论上的 无限性能 ；

思路 比结论重要。

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

推荐阅读：

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

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

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