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

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

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

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

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

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

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

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

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

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

End

版权归@码农神说所有，转载须经授权，翻版必究

转载可联系助手，微信号：codeceo-01