消除单点,一篇搞定

系统架构中,为什么会存在单点?

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

思路比结论重要。

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

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20181101B1P4PT00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券