《从 0 开始学架构》精华总结-架构基础

声明：学习完李运华《从 0 开始学架构》，有一种醍醐灌顶，豁然开朗的感觉。为了能够对其概念有一个深入的理解，并且掌握其总结的方法论。特意对本课程做一个提炼，形成自己的知识体系。毕竟能给别人讲清楚了，才能说明自己真的掌握了。本文的引用仅限自我学习如有侵权，请联系作者删除。

架构到底指什么？

       软件架构指的是软件系统的顶层结构。软件设计过程中，模块、对象、组件本质上是对一定规模软件在不同粒度和层次上的“拆分”方法论，软件架构是一种对软件的“组织”方法论。一分一合，其目的是为了软件研发过程中的成本、进度、质量得到有效控制。但是，一个成功的软件设计是要适应并满足业务需求，同时不断“演化”的。设计需要根据业务的变化、技术的发展不断进行“演进”，这就决定了这是一个动态活动，出现新问题，解决新问题，没有所谓的“一招鲜”，但是“行业最佳实践”可以作为指路明灯。

模块和组件有什么区别？

       模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。从逻辑的角度拆分系统，得到的单元就是模块；从物理的角度拆分系统，得到的就是组件。

架构和框架有什么区别？

        框架提供基础功能的产品，是组件的规范。框架关注的是“规范”，架构关注的是结构。

软件架构如何描述？

       著名的“4+1”视图：逻辑视图、开发视图、物理视图、进程视图、场景视图

    场景视图：它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。描述现实中的一个系统运用场景的过程，把其中牵涉到的对象，服务和操作都展示出来

架构设计的历史背景是什么？

        随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题；当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列新的设计问题。

软件开发最本质的挑战是什么？

       复杂和变更，而软件的价值是保证业务的响应力，而与之相对的是开发资源的有限，而各种的软件开发方法论，也都是在研究有限的资源下，如何应对这两个挑战，寻找平衡点，实现业务目标，因为是在寻找平衡点，就说明是有取舍的，所以就没有所谓的万能架构存在。

架构设计的目的是什么？

        架构设计的主要目的是为了解决软件系统复杂度带来的问题。

复杂度的来源有哪些？

        高性能、高可用、可扩展性、低成本、安全、规模。

1、高性能

         软件系统中高性能带来的复杂度主要体现在两方面，一方面是单台计算机内部为了高性能带来的复杂度；另一方面是多台计算机集群为了高性能带来的复杂度。

       单机复杂度：操作系统发展到现在，如果我们要完成一个高性能的软件系统，需要考虑如多进程、多线程、进程间通信、多线程并发等技术点，而且这些技术并不是最新的就是最好的，也不是非此即彼的选择。在做架构设计的时候，需要花费很大的精力来结合业务进行分析、判断、选择、组合，这个过程同样很复杂。举一个最简单的例子：Nginx 可以用多进程也可以用多线程，JBoss 采用的是多线程；Redis 采用的是单进程，Memcache 采用的是多线程，这些系统都实现了高性能，但内部实现差异却很大。

       集群复杂度： 通过大量机器来提升性能，并不仅仅是增加机器这么简单，让多台机器配合起来达到高性能的目的，是一个复杂的任务。需要考虑如何进行任务分配和分解，将引入复杂度。

        那为何通过任务分解就能够提升性能呢？简单的系统更加容易做到高性能，可以针对单个任务进行扩展。当各个逻辑任务分解到独立的子系统后，整个系统的性能瓶颈更加容易发现，而且发现后只需要针对有瓶颈的子系统进行性能优化或者提升，不需要改动整个系统，风险会小很多。

         虽然系统拆分可能在某种程度上能提升业务处理性能，但提升性能也是有限的，不可能系统不拆分的时候业务处理耗时为 50ms，系统拆分后业务处理耗时只要 1ms，因为最终决定业务处理性能的还是业务逻辑本身，业务逻辑本身没有发生大的变化下，理论上的性能是有一个上限的，系统拆分能够让性能逼近这个极限，但无法突破这个极限。因此，任务分解带来的性能收益是有一个度的，并不是任务分解越细越好，而对于架构设计来说，如何把握这个粒度就非常关键了。

          

2、 高可用

            系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。这个定义的关键在于“无中断”。但是除了硬件和软件本质上无法做到“无中断”，外部环境导致的不可用更加不可避免、不受控制。所以，系统的高可用方案五花八门，但万变不离其宗，本质上都是通过“冗余”来实现高可用。高性能增加机器目的在于“扩展”处理性能；高可用增加机器目的在于“冗余”处理单元。

              计算高可用引入复杂度：无论在哪台机器上进行计算，同样的算法和输入数据，产出的结果都是一样的。比如单机变高可用集群架构需要增加任务分配器，选择合适的任务分配器也是一件复杂的事情，需要综合考虑性能、成本、可维护性、可用性等各方面因素。任务分配器和真正的业务服务器之间有连接和交互，需要选择合适的连接方式，并且对连接进行管理。例如，连接建立、连接检测、连接中断后如何处理等。任务分配器需要增加分配算法。例如，常见的双机算法有主备、主主，主备方案又可以细分为冷备、温备、热备。

            存储高可用引入复杂度：对于需要存储数据的系统来说，整个系统的高可用设计关键点和难点就在于“存储高可用”。存储与计算相比，有一个本质上的区别：将数据从一台机器搬到到另一台机器，需要经过线路进行传输。无论是正常情况下的传输延迟，还是异常情况下的传输中断，都会导致系统的数据在某个时间点或者时间段是不一致的，而数据的不一致又会导致业务问题（数据 + 逻辑 = 业务）；但如果完全不做冗余，系统的整体高可用又无法保证，所以存储高可用的难点不在于如何备份数据，而在于如何减少或者规避数据不一致对业务造成的影响。

             高可用状态决策：无论是计算高可用还是存储高可用，其基础都是“状态决策”，即系统需要能够判断当前的状态是正常还是异常，如果出现了异常就要采取行动来保证高可用。

            （1）独裁式

           （2）协商式：协商式决策指的是两个独立的个体通过交流信息，然后根据规则进行决策，最常用的协商式决策就是主备决策

           （3）民主式：民主式决策指的是多个独立的个体通过投票的方式来进行状态决策。例如，ZooKeeper 集群在选举 leader 时就是采用这种方式。

综合分析，无论采取什么样的方案，状态决策都不可能做到任何场景下都没有问题，但完全不做高可用方案又会产生更大的问题，如何选取适合系统的高可用方案，也是一个复杂的分析、判断和选择的过程。

3、可扩展性

        可扩展性指系统为了应对将来需求变化而提供的一种扩展能力，当有新的需求出现时，系统不需要或者仅需要少量修改就可以支持，无须整个系统重构或者重建。 在软件开发领域，面向对象思想的提出，就是为了解决可扩展性带来的问题；后来的设计模式，更是将可扩展性做到了极致。得益于设计模式的巨大影响力，几乎所有的技术人员对于可扩展性都特别重视。

        设计具备良好可扩展性的系统，有两个基本条件：正确预测变化、完美封装变化。 第一种应对变化的常见方案是将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”；第二种常见的应对变化的方案是提炼出一个“抽象层”和一个“实现层”。抽象层是稳定的，实现层可以根据具体业务需要定制开发。

4 低成本

         低成本本质上是与高性能和高可用冲突的，所以低成本很多时候不会是架构设计的首要目标，而是架构设计的附加约束。低成本给架构设计带来的主要复杂度体现在，往往只有“创新”才能达到低成本目标。创造新技术复杂度更高，因此一般中小公司基本都是靠引入新技术来达到低成本的目标；而大公司更有可能自己去创造新的技术来达到低成本的目标，因为大公司才有足够的资源、技术和时间去创造新技术。

5 安全

       安全本身是一个庞大而又复杂的技术领域，并且一旦出问题，对业务和企业形象影响非常大。技术的角度来讲，安全可以分为两类：一类是功能上的安全（常见的 XSS 攻击、CSRF 攻击、SQL 注入等），一类是架构上的安全（访问控制策略）。

6 规模

规模带来复杂度的主要原因就是“量变引起质变”，当数量超过一定的阈值后，复杂度会发生质的变化。常见的规模带来的复杂度有：

（1） 功能越来越多，导致系统复杂度指数级上升

（2）数据越来越多，系统复杂度发生质变（添加索引会很慢，可能需要几个小时、修改表结构和添加索引存在类似的问题，耗时可能会很长、即使有索引，索引的性能也可能会很低，因为数据量太大、数据库备份耗时很长）

架构设计的原则是什么？

        合适优于业界领先、简单优于复杂、演化优于一步到位。

架构设计的流程是什么？

（1） 识别复杂度

（2）设计备选方案、

（3）评估和选择备选方案

（4）详细方案设计

我是快乐的一只，一只快乐的我。如果我的文章对你有所帮助，请随手点个在看吧，您的鼓励将是我坚持创作下去最大的动力。

公众号请搜索：“快乐的一只”

码云社区地址：

https://gitee.com/renchunlin66