返回顶部

OutOfMemory.CN技术专栏-> wiki-> 七牛李道兵谈“架构坏味道”

七牛李道兵谈“架构坏味道”

更多

软件架构在成功的软件交付中扮演着重要角色,好的架构可以兼容不同类型的业务和算法,并且相安无事,而架构设计不当就需要不断地进行整体的更替,以适应业务的变化和新算法的需求,甚至影响最后架构整体的稳定性、容量等。事实上,架构的很多方向性问题是可以在设计初期就避免的。因此,七牛首席架构师李道兵结合多年的实践经验,在本文中详细总结出了以下七类具有明显“坏味道”的架构影响因素。

架构对容量数据不敏感

设计架构时对于常规的一些基础架构元素容量不清晰,比如前端的Nginx、后端标准的业务服务器、数据库及缓存的容量等方面。Nginx整体容量比较大,一般不需要担心。如果是下载类型的需求,那么需要注意机器的网卡。到业务逻辑这一段,每种语言、每个并发连接都有内存消耗,会导致单台服务器能支撑的并发数目是有限的。在数据库领域,系统容量跟磁盘的IOPS相关,因此最好知道普通的SATA盘和SSD盘的IOPS是多少?做RAID10或者是RAID5对IOPS的影响究竟是怎样的(因为IOPS对数据库的性能影响很大)。还有缓存层,但缓存层更重要的是容量的设计(即内存总量),因此,要对各个架构元素容量的数据有一定了解,才能保证构造出的架构在容量上不会出问题。

未考虑高可用

如果架构设计的时侯只想着怎样实现业务逻辑,完全没有考虑主机宕机了怎么解决,那么迟早会遇到事故。因此,架构需要从入口层、业务层、缓存层和数据库层构建高可用和可伸缩系统。例如,在入口层使用Keepalived;业务层不要有状态,将状态存储到缓存层或数据库;缓存层考虑挡住绝大部分服务请求以提升系统整体容量,但同时也要考虑高可用的问题;数据库层做一个主从模式 《七牛李道兵:高可用可伸缩架构实用经验谈》 一文有详细讲述。架构设计重要的是有考虑高可用的意识,有意识以后再考虑如何实现就会比较容易。

用Hash来避免机器宕机时影响到所有用户

这个问题主要由于想做高可用,但却用了错误的方法。比如有很多用户,根据用户的Hash把它们分到不同的服务器,这样单台服务器宕掉的时侯就不会影响到所有的业务。但这种方法并不够好,因为即使小部分用户的体验受到了影响,也已经构成事故。另外,如果服务分很多层,这层做高可用漏掉一部分客户,另一层漏掉另外一部分客户,那么整体的可用性会变得很差,出故障的概率就是各层出故障概率之和。目前有很多更简单的方式来做高可用,所以没有必要使用Hash这种方式。另外,用Hash来分散请求比较容易导致压力不均,反而降低了整个系统的容量。

缓存节点数太少

很多人认为缓存是一个可选的环节,在设计上就比较随意,但这会带来一定的问题。比如一个缓存节点宕掉,将导致这个缓存节点的压力压到数据库上面。如果系统的容量原本就是靠缓存支撑,缓存又只分布在两台机器上,那么宕掉一台对后面的数据库的压力很大,数据库响应变差,那么宕掉缓存节点也就意味着服务真的宕机。因此,建议将缓存尽量分开,比如和业务服务器混合部署,当业务服务器在增长时,缓存也在增长,这时保证缓存节点多一点,单台缓存机死机了压力到了数据库也不会导致数据库宕机。当然,Codis这类自带高可用的缓存系统也是一个很好的选择。

有容灾无容错

首先,应分清容灾和容错的差别。容灾指,出了事故(如单磁盘故障、单数据故障、机柜故障或者机房故障)时的保障措施。容错则指,操作失误(如运维的错误操作),这种错误操作导致了数据丢失,或者别人通过SQL注入的方法删除了数据库。身边有一个真实的例子,一家公司用MongoDB数据库,由于MongoDB的ReplicaSet机制,所以觉得不用做备份了,就未做备份。但这里他们没有考虑到,如果有人失手删除了数据库该怎么办,这时所有数据都丢掉了,是一件非常恐怖的事情。

架构失配的问题

MongoDB支持文件存储,但它并不擅长,容量会受到很大的限制,一旦上传量增大就可能会引发事故。因此,最好在各个环节找一些最恰当的方式。例如,Redis擅长的是缓存而不是数据库,那么用Redis做数据库就必然会出现架构失配的问题;而MongoDB擅长的是OLTP,用MongoDB去支撑数据仓库就不太合适;像MySQL这类事务型数据库也可以去做一些离线计算,但如果要做很多离线计算的工作,就需要用最好的工具去做(如Hadoop、Hive、Spark等),在每一个架构环节都要有最合适的架构组件,避免出现一些架构失配的问题。

数据流太长

这种情况常出现于存储领域。数据流太长就很难保证响应,如果一份数据中转了10次,与中转3次相比,内网的带宽需求相差好几倍,整个系统的容量明显下降,更容易出现内网阻塞。在这种情况下,将数据流缩短,就可以得到比较显著的性能提升。缩减数据流长度的方式非常有效,值得考虑。此外,还可以利用一些数据流优化方法。例如,一份数据需要写三份,一种做法是由发起机器并发地发三份数据到三台对应的机器上,但是这种方法对发起机器来讲,流量压力比较大。反之,如果要将数据发到A、B、C三台机器,先发给A,然后由A转发给B,再由B转发给C,虽然架构上会复杂一些,但是性能和容量提升也都很可观。

以上是架构设计时常出现的一些问题,关于“架构坏味道”还有更多细节的点和总结值得探讨,希望此文能给开发者们带来一定的帮助,也望以后能与大家做更充分的交流。

推荐阅读:
支持

0

反对

0

牛小七:七牛团队博客

您可以通过下面的社交媒体联系/了解作者的更多信息:

发表评论