漫画 | 架构设计中的那些事

发布于: 2020 年 07 月 10 日
漫画 | 架构设计中的那些事

刚进入架构师角色的时候会有很多迷惑不解的地方,不同于以往做开发,架构师关注点会更上层一些,需要提前识别出问题,并制定解决方案。因此不仅仅需要技术的深度和广度,还有有些行业业务的阅历和经验,才能准确判断和做到有利取舍。优秀的架构师能给团队的主心骨,反之将是绊脚石。

不能是跟风为了纯粹追求技术而做架构,架构是为了解决由于某些复杂度带来的问题的,复杂度来源比如三高:高性能、高可用、高扩展,如果实际中没有这些需求不设计架构反而更有效率。很多创业公司起步的时候一个单体应用搞定全部,单刀直入,求的是快,天下武功唯快不破,而商机一闪即逝!

做架构及做人,需要克服人性的弱点,新手设计架构时都有点好大喜功、追求技术上新潮而不能脚踏实地、化繁为简!恨不得集百家架构之长于一身,设计出世界上最牛逼的架构,殊不知架构的目的就是为了解决实际中的问题,同时还要考虑到投入的性价比,如果没有那么牛逼的业务而强行设计技术上看似很牛逼的架构,这本身就是种浪费和不靠谱。不是身处在阿里、腾讯高复杂度的环境中是无法设计出他们那样的架构的,因为你凭空是想象不到他们遇到那么复杂的问题。

CPU等硬件决定了单机性能的上限,而操作系统决定了其性能的下限,进程和线程模型又影响操作系统性能的主要因素。我们都知道当今流行的操作系统都是分时系统,及时有线程和进程也并不能真正做到并行,只是轮流使用CPU的时间片而已,于是引来了多核CPU诞生。但无论单机性能有多强甚至于大型机,对于现在的互联的需求都很难单兵作战,分布式集群方案应运而生。

集群可以解决性能问题,但它带来的复杂度就是如何分配任务,比如我们熟知的DNS负载、LVS负载、NG的反向代理等都属于任务分配的范畴,当然还有硬件如F5等。他们都实现了任务分配的标准算法如随机、轮询、加权、哈希等等,除了这些算法外,任务本身也可以进行分组处理,比如按CPU密集型型、IO密集型等分类,这样可以让提高性能更有的放矢。当请求量巨大时,任务分配(负载均衡)器也会成为瓶颈,也需要集群,这样复杂度又提升一个量级。

通过CAP理论可知,数据一致性和可用性二者只可满足其一。而数据+逻辑=业务,数据不一致会导致业务表现也不同,因此高可用不仅仅是集群的事情,更多的是数据存储的问题。

在高可用的设计中,是否可用的状态是判断依据的基础,如果判断依据不准确,那么会导致整个的设计是失败的。独裁模式是指所有的节点都向决策者汇报自己的状态,最终是由决策者统一管理状态,有点类似中央集权。选举式就比民主,类似于zookeeper的leader选举,但这种方式容易造成脑裂。而协商式一般用于准备的方式,在大型集群中比较少用。但无论那种模式都有利弊,需要根据自己特有的环境进行选择。

对待可扩展性需要把握住两点:正确的预测变化和完美封装变化。但在需求多变的情况下,导致预测变化也是件困难的事,不仅仅对业务要通透,最好还能参与售前方案的探讨,这样才能更好地提高前瞻性的能力,还可以适当的引导。而封装变化更多变现为技术侧的技巧,设计模式、面向对象、面向接口、面向组件、面向无服务目的之一都是为了解耦,从而把可变和不可变分开,提高扩展性。

架构设计还会涉及到安全、成本和规模的方方面面,这些相对三高的迫切性相对较弱些,需要在实践中摸索和磨练。

最新、更多漫画请关注微信公众号:码农神说。转载开白可联系助手,微信号:codeceo-01

相关阅读

发布于: 2020 年 07 月 10 日 阅读数: 54
用户头像

码农神说

关注

欢迎关注公众号【码农神说】 2018.11.09 加入

图解码农技术,大话码农故事,漫画感悟码农人生,助力码农翻身!

评论

发布
暂无评论
漫画 | 架构设计中的那些事