【架构师从入门到进阶】第一章：架构设计基础——第一节：架构设计的目的

本篇文章我们来学习架构设计的目的，我们从两个角度去分析，第一个就是架构设计的误区，然后再分析目的。

误区

我们先来说误区。

我们都知道做软件开发的时候需要架构设计，但是为什么要做架构设计呢，目的是什么，很多人可能没有思考过，就在我们工作当中，有这么几个大家常见的误区。

• 误区一：因为架构很重要所以要做架构设计，每个系统都要做架构设计
• 误区二：为了达到高性能高可用高扩展，所以要做架构设计
• 误区三：一味的去追求大公司的解决方案
• 误区四：最新的技术才是最好的
• 误区五：用技术去解决所有的问题

误区一：因为架构很重要所以要做架构设计，每个系统都要做架构设计

第一个是，因为架构很重要所以要做架构设计，每个系统都要做架构设计。

听着好像很对，但是也不完全对。难道不做架构设计我们的项目就运行不了了吗？经历过创业公司或者一些小公司的同学应该深有体会，只要产品设计好，大家稍微一讨论，就开始编码了，根本没有正经的架构设计，也许这么做产品开发的还快，上线后运行好像也没有什么问题，因为最初的用户少。

做了架构设计就能提高开发效率吗？不一定，有时候一个特别简单的功能采用最简单的开发方案反而是最好的，反而效率是最高的，因为架构设计毕竟需要投入时间、投入人力、投入资源，如果把投入的这些东西这些资源，用来编码的话也许会更快一些。

误区二：为了达到高性能高可用高扩展，所以要做架构设计

第二个是，为了达到高性能高可用高扩展，所以要做架构设计，很多架构设计其实都是冲着高性能高可用高扩展去的，但是不能为了单纯的去追求这三个目标，单纯的去追求三高这个目标去做架构设计有时候会带来一些不好的影响。

比如说，有的架构师不管什么业务，包括一个很简单的查询业务，上来先要求三高，查询使用的用户也就几千个或者说上万个，他一上来就要三高，就要做出很复杂的设计，最后会导致项目的落地遥遥无期，团队天天吵架，产品催，老板催，然后技术又很烦，就这么一个简单的功能废了九牛二虎之力让系统上线了，但是却由于系统太复杂经常出问题，或者说出问题了很难排查，因为找个错误都得跨好几个系统，还有就是以后要加一个小功能都需要很长的时间，因为系统多，调用的链路比较长，需要的开发的时间就会比较多。

误区三：一味的去追求大公司的解决方案

一味的去追求大公司的解决方案，这什么意思呢？

大公司的成功有它的光环效应让无数的人去效仿，一些小公司从大公司挖来的一些人，他们在讨论技术架构的时候，总是说阿里就这么做的，淘宝就这么做的，谷歌就这么做的。

我们一想，那些大公司这么做又能怎么着？大公司的成功经验固然是值得我们学习和借鉴的，但是我们也要结合自己的实际情况，不要杀鸡用牛刀，适合才是最好的。

误区四：最新的技术才是最好的

我们做的任何软件系统，都有它要解决的业务问题，脱离业务而强调技术架构，一味的去追求一些时髦的技术，很可能将系统引向技术的崎跷小道，设计架构就会走偏，我们要把握一点，技术是为业务服务的。

误区五：用技术去解决所有的问题

还有一个就是可能做技术的，想着用技术去解决所有的问题。

其实不是这样的，有的问题需要技术解决，因为技术本来就是用来解决业务问题的。同样，业务的问题也可以通过业务去解决。

大家想一下，在2012年的时候，12306系统刚上线，买票经常买不到，系统经常崩溃，当时各路神仙不管是专业的还是非专业的都说，12306的系统如果交给某某公司做就不会有这些问题了。

其实12306的问题不在于技术架构，而在于业务架构。12306不应该让几亿人在一票难求的情况下卖票，因为那个并发全世界都没有人能扛得住。因为这个业务特殊，我买一个票，需要把我买票的这个点的数据同步到全国各地成千上万个火车站点，或者说数据节点，你买一个票同步到那么多地方，还要保证全国的同步，并且此时的并发还这么高，几亿人，几乎全国，比淘宝双十一用的人还要多，因为淘宝双十一可能有一些人是不会去抢的，比如农民工不会去抢，但是如果说放一张票，可以说是全民都在抢票。

这种业务，应该调整它的业务结构，比如说换卖票的方式，引入排队机制，采用分时段放票去售票，不要集中在一个点去放票，通过这种分散的方式控制住了并发。这样，这个问题就会解决好很多。

目的

知道这几个误区之后，我们来看一下架构设计的真正的目的是什么。

我们往前倒一下，以史为鉴。最开始用计算机的时候，用机器编码，后来有了汇编，有了高级的语言，高级语言出现之后就解放了程序员。但是好景不长，随着软件规模和复杂度的增加，典型的表现就是软件质量低下；项目无法如期完成；项目严重超支；因为软件太复杂导致重大的事故，比如说在六三年美国水手一号火箭发射失败就是因为代码错误导致的。

那么为了解决刚才所说的这些问题，诞生了软件工程这么一个词，但是软件工程也只是在一定程度上缓解软件的危机，同时还提出了结构化程序设计，有了我们常说的“自顶向下，逐步细化”、“模块化”这种指导思想，通过这个思想将软件的复杂度限定在一个范围内。

将一个大而复杂的东西拆分成小而简单的东西，原来要通盘考虑整个系统的复杂度，现在将系统切割抽象每个模块，再当成一个独立的系统去设计，如此循环，从而从整体上，简化了软件开发。

从上面的描述来看，我们可以给架构设计定一个目标：随着系统规模越来越大，架构设计是为了应对软件系统的复杂度而提出的解决方案。

有的同学会有疑问：就复杂度这么简单吗？那高性能、高可用、高扩展就不考虑了吗？我们来一个一个解释。

高性能复杂度：拆分系统

不管是人类的发展，还是软件的发展，一直都是对高性能的追求。

举个例子，火车最开始的时候，蒸汽机车每小时二十公里，到现在的电气机车是每小时三百五十公里。软件也一样，随着从二十公里到六十公里，随着软件效率的提升，就像火车的内部构造一样，电气机车肯定比蒸汽机车复杂不知道多少倍。所以说随着性能的提升，软件的复杂度也提升，这就是追求高性能的复杂度。

解决高性能复杂度，一个核心的思想是拆分，高性能复杂度的解决是拆分系统。业务本来需要一台机器去承受，现在把它拆成两台机器去承受，并且可以无限的拆分。无限的拆分，理论上意味着性能无限的提升，虽然实际并不是这样的。

高可用的复杂度：备份冗余

高可用就是说系统永远可用，无中断提供服务的能力，就是说系统在这跑着，它不会中断服务。但是话又说回来，无论硬件还是软件都不可能不出问题，硬件会老化，软件会有bug，会停电，会有地震，火灾泥石流也会导致系统的不可用。

为了避免这种不可用，高可用的解决方案就是备份。一个系统放在这，如果停电了，它就不能用了，那么我备份一个，这样的话，就解决了高可用。

如果通过备份冗余去解决，它又会带来复杂度。大家想一下，如果是一台出问题，我们用两台，两台出问题呢，我们用四台，可是用了四台机器，如果在一个机房里，机房一停电，四台全部不能用，所以说这个时候又得用到多机房，用了多机房，又怕这个城市会有一些大的自然灾害，比如说地震，那么这个时候又得需要异地多活这。就是通过备份和融余，应对高可用的时候带来的复杂度。

高扩展的复杂度：正确预测变化，完美封装变化

高扩展的复杂度解决是什么呢？高扩展是为了应对将来需求变化，而提高的一种扩展能力。

系统为了应对将来某一个变化，要有一种扩展能力，当有新的需求时候，或者当有新的性能要求的时候，我们的系统仅需少量的修改就能支持，无需重新建造整个系统，无需重新开发一遍，这样就具备了良好的扩展性。这个需要两方面的考虑。第一方面是正确的预测变化，第二个方面呢是完美的封装变化。正确预测变化，就是说我要预知到未来会有什么变动；完美的封装变化，就是说有了变化，要把它限制限定在一定的范围内。

正确预测变化，不是说每一个点每一个功能都会有变化，还有一个就是预测出错了怎么办，对架构师来说，预测变化的程度和提升预测结果的准确性都是很复杂的事情。这个是没有固定答案的，退一万步讲，就算预测对了，是否意味着我们的预测就能很好的落地实现呢，这就涉及到了完美封装变化这一点。

我们就需要将变化封装在一个变化层，也就是说把变化限定在一个小小的范围之内，将不变的封装在稳定层，同时我们还要确定稳定层和变化层的接口，这时候又会涉及到接口的设计是否合理。

成本、安全、规模

除了这些，在企业开发中，还有成本、安全、规模等。

企业肯定是希望通过设计减少成本，用最少的成本来实现最大的收益。比如说有两个方案，第一个方案是a方案需要有一万台机器，第二个方案是b方案需要八千台机器，a方和b方案就差了两千台机器，如果一台服务器算一万块钱的话，也是两千万的费用。所以说从成本的角度考虑机器越少越好，而从高性能和高可用的角度考虑机器是越多越好，因为越多才能越多的进行拆分，越多才能越多的进行备份。

解决这个解决高性能高可用和成本之间冲突的问题，有两个方式，第一个引入新的技术，第二个创造新的技术。比如说淘宝最开始发展的时候，曾经引入IOE，I就是ibm的机器，O就是oracle数据库，E是一个存储的公司。随着后来系统的发展，IOE的成本太高了，如果一直用他们的这些机器，迟早是给ibm打工。所以后来就需要去IOE，那么这个就需要创造新技术，先引入新技术解决一些问题，然后再创造新技术。无论是引入新技术还是创造新技术，都是非常复杂的事情，引入新技术的复杂度在于学习新技术以及让新技术兼容我们的老系统，创造新技术的复杂度在于自己要去创造一些理念和技术。

还有安全，包括功能上的安全和架构上的安全。功能上的安全通过编写代码来实现，架构上的安全基本上通过隔离。当发生不安全的情况的时候,不能让这种负面的影响扩大,所以说隔离就是一种手段。可以将网络、服务、存储进行分区，这样的话就涉及到区域之间数据的共享和同步，又涉及到了复杂度。

还有规模带来的复杂度，一句话就是量变引起质变，当数据量超过一定的阈值，复杂度就会发生质的变化。举一个例子，一个小的饭店可以容纳两桌人吃饭，老板一个人全部搞定，老板又能收银又能做饭又能搞卫生又能上菜，但是一旦扩大规模，比如把这两桌人的饭店扩大成两千人的饭店，那么这个就复杂了，老板一个人就搞不定了，需要有专门的收银员，需要有专门搞卫生的，甚至连厨师都需要好几个，还有冷菜、热菜、切菜、炒菜这些环节怎么顺利的衔接，这样复杂度就上来了，这就是规模变大带来的复杂度。