【架构】1.2浅谈架构基础-架构设计的目的

架构设计的目的

谈及架构设计，应该IT从业者都很经常听到，然而对于架构设计的目的，可能每个人都有自己的理解，例如：

1. 因为现在的系统大家都会做架构，所以我们也要做架构设计；
2. 因为大公司的系统都有架构设计的流程或要求；
3. 因为我们有架构师，不然架构师的工作是做什么呢?
4. 因为我们要做的系统比较复杂，或者高可用的要求比较高；
5. 因为架构设计好了系统健壮性也就好了，能更好的支持后期的扩展；
6. 因为我们要降低成本；
7. 因为我们的系统要平台化，要为了以后各大的用户量做提前布局；
8. 。。。。。。等等，
   babalala各种原因，当然上面的原因可能都是考虑的方面，毕竟对于架构设计，可能每个人都有自己的理解。然而想真的了解一个规范或者设计出现的原因，可能要从软件发展的历程去找些源头。因为一个事物不会凭空出现，架构设计也不是突然产生的，从历史背景中可能更好的理解它出现的目的或原因。

软件发展历程

软件开发语言经历了机器语言、汇编语言、高级语言的三个阶段，使得软件开发从晦涩难懂，专业性要求极强到目前的软件开发者无需再关注机器的底层结构和逻辑，使用面向对象的思想就可以轻松实现一个软件程序，软件开发相关从业者遍地开花。然后随着软件的规模和复杂度的增加，因为软件开发而带来的新问题随之而来。

1. 第一次软件危机（20世纪60年代——20世纪70年代）
   美国水手一号事件、IBM操作系统事件，等因为软件开发而造成的巨大损失惨不忍睹，有兴趣的可以看下《人月神话》一书，里面有更多的案例介绍。第一次软件危机提出了结构化程序设计的思想，采用从上向下，逐步细化的思想将程序模块化，进而一定程度上降低了程序开发的复杂性；
2. 第二次软件危机（20世纪80年代）
   随着计算机硬件以及业务需求的发展，软件所能解决的问题远远的低于前者的要求，是的软件的扩展性/适应性变得困难，面向对象的思想成为了软件开发新的流程思想；
   经历了以上阶段，可以看出，软件的发展历程与其他事物的发展历程都很相似，更多的要求或者说是更高的复杂度造成了二次的软件危机，同时也推动了软件架构发展，软件架构思想被更多的人关注和思考：架构设计的主要目的就是为了解决复杂度带来的问题。

如何识别软件的复杂度

作为一名从业者，架构设计不可能所有的方面都能考虑到，也不需要这么做。我们应该根据所做系统的实际业务需求和自身情况，进行识别所存在的主要复杂度，并进行考虑，有针对性的解决问题，这才是真正的架构设计。日常中，我们常见的复杂度来源主要有以下几个方面

高性能

高性能是我们在日常开发中常听说的关键词，什么高并发、多线程、大集群等等，为准求高性能带来的软件复杂度主要体现在两个方面：计算复杂度和集群复杂度；

1. 计算复杂度
   随着计算机硬件和发展和客户对于更低的延迟、更快的处理速度等要求的增加，多进程，多线程，批处理等应允而生，但是多进程、多线程、高并发等带来的通信、数据一致性等方面的程序计算复杂度随着增加；
2. 集群复杂度
   日常工作中，如果我们的问题采用多进程、多线程等还不能解决增加办呢？最简单的想法可能就是堆机器，一台不够，二台、三台、四台。。。。。。多个服务器的堆积其实我们暂且简单理解为集群。然而通过堆积数量而来的集群确实能提升我们处理问题的能力和速度。然而也会带来新的问题：多台机器如何调度，任务如何分配，如何能够保证唯一性，大量的服务如何维护等等；

高可用

软件的高可用方式有很多，但核心的思想与通过堆积机器数量来提升性能类似，就是通过投入更多的设备“冗余”来提升高可能，简单来说就是：一台不可用，还有第二台，第二台也不可用还有第三台。。。

1. 计算高可用
   计算高可用和高性能里的问题类似：引入更多的计算节点，如果能保证任务的分配、节点的维护、数据的一致性等；
2. 存储高可用
   存储高可用常见在数据库问题上，为了保证数据的完备性和安全性，常见的就是两地三中心等，然而存储高可用的真正难点不在于冗余的数据备份，而在于如何避免或者减少多数据源带来的数据一致性问题造成的影响。最经典的理论就是CAP理论，三者不可同时满足，只能为了更好而取舍到相对更好的方案；
3. 网络高可用
   网络高可能虽然不是程序开发中需要考虑的，然而却是以上2个高可用中都会考虑的问题点，无论是网络供应商、DNS、F5、NGINX等等都是网络高可用常用的策略；

可扩展

软件开发一个很大的特点就是变化，相信每一个开发者都会遇到需求变更的问题，并深受其害，甚至深恶痛绝。软件系统各类各样，需求也是各类各样，唯一不变的就是变化。软件架构设计如果有越好的扩展性，哪后期需求变化对软件的影响可能就越小；然而可扩展性的复杂也正在与此：架构师不可用每个设计点都考虑扩展性，也不能完全不考虑扩展性，而所有的需求变化都是不确定的不可能都会被考虑。如何把握扩展的程度和预测设计的准确性本身就是一件很复杂的事情，申请和彩票中奖是一样。
对于软件的扩展性我们可以简单的将程序分为两层：抽象层和稳定层。抽象层应对变化，稳定层是不变的；亦或是抽象层和实现层，抽象层复杂规范不变，实现层根据需求负责定制的任务。实际中我们更多的解决方案是引入合适的设计模式来提升软件的可扩展性，例如：工厂模式，观察者模式等等；

成本价值

在架构设计中，成本往往是企业进行架构设计重要考虑的部分，然而实际架构设计时，成本并不是架构设计的首要目标，而是附件约束，更多的情况下，我们是在一定的成本的前提下进行架构的设计，已找到架构设计的更优解满足更低的成本更高的成本价值。当然针对专门“降本”为目标的架构设计要特殊考虑。

安全因素

在互联网时代，安全越来越重要，“安全”一词在架构设计中需要考虑的因素也越来越多，大体主要有功能上的安全和架构上的安全；功能上的安全主要是通过预制的通用编码来实现，例如SQL注入、XSS攻击等绕过式的攻击。架构上的安全则更多关注破坏式的攻击，例如DDOS等网络层面的拦截、监控、告警等。

总而言之，软件的架构设计的目的其实就是和软件复杂度的博弈，随着软件规模和数据的不断增加，软件的复杂度呈指数式的增长，架构设计的难度越来越高，软件架构是软件系统的顶层架构，不同人会有不同的认知，架构设计需要从实际问题和情况出发，把握核心问题，没有最好的架构，只有更适合的架构。

---

codeing change the world，keep working…