架构是演进的

这周的两次直播的名称是【互联网分布式系统架构演化】和【分布式系统架构案例】，主要就是讲解了架构是一个演进的过程，架构从来就不是一蹴而就的，而分析了淘宝以及新浪微博的架构演进过程，更加证明了这一点。



我们在学习如何做架构的时候也一定要秉持这一点，架构设计是不具备银弹的，也没有标准答案，我们做架构设计是是需要切合业务的实际情况，以及实际问题，来设计架构的。



架构设计往往是为了解决系统中存在的某些问题而进行的，而不是为了架构而架构，也许谈到架构我们就会想到，高性能、高可用等等，但是真的每一个系统真的都需要这种东西么？



淘宝需要高性能是因为它真的有那么多用户，它需要高可用是因为它真的24个小时都有人在不间断的使用这个系统，但并不是每一个系统都需要这样设计。



案例

最近在极客的一个架构相关栏目上也看到一个有趣的例子，说的是要设计一个学校信息系统，其基本功能包括登录、注册、成绩管理、课程管理等。



当我们对这样一个系统进行架构设计的时候，首先应识别其复杂度到底体现在哪里。

我们逐步分析：

• 性能

一个学校大概一万到两万人，学生访问管理系统的频率也不高，因此性能并不复杂，就算学校的学生历年积累起来，十年下来也最多20几万数据，而且已经毕业的学生是访问不来管理系统的，所以毕业的学生数据是可以归档的，只要给学校提供偶尔查询的功能即可。而且一个管理系统能使用十年以上的概率是极小的。所以系统的性能压力几本上不存在。

• 可扩展性

这类系统的需求往往是固定的，在系统开发前就已经清楚的知道有哪些功能，未来产生改变的可能性也比较小，所以扩展性也不复杂。

• 高可用

学生管理系统即便宕机一两个小时，对于学生管理工作影响也不大，最多稍晚一点录入成绩，或者学生稍晚一点才能选课，或者查询到成绩，这都是可以接受的。这不像淘宝，宕机一两个小时就代表用户流失，就代表金钱损失等等。学生管理系统就这一个系统，你没有选择。所以系统高可用也不必考虑。

但是由于是学校的信息管理系统，数据是非常重要的，你可以两个用不了，但不能说突然数据丢失了一部分或者全部丢失，这对学校会是致命的打击，所以数据的高可用和备份是必备的，我们要保证在数据库物理机可能损坏的前提进行数据的备份，甚至考虑在机房损毁的前提在在不同机房准备备份，从而保证数据的高可用。



那么这一来架构的需求也就清晰了，一个基本的管理系统单节点就能够满足用户的使用需求，甚至可能都不需要提供nginx这种东西做负载均衡或者反向代理，但数据库层面的备份却有必要，可能需要选则不同的物理机进行同步复制，甚至选择不同机房进行物理复制。



也许这个架构不如淘宝、微博这样的系统架构高大上，但是这个架构能够满足我们的管理系统的需求，这就是一个好架构。



架构设计的真正目的



所以我们学习当一个架构师就一定要真正理解架构设计的真正目的。

架构没有最好的，架构只有最适合的。

淘宝的架构师设计的好，但是用在刚才的管理系统上适合么，并不适合，有点高射炮打蚊子的感觉吧。



所以架构师就是一个做取舍的角色，架构师要掌握很多能力，但更要懂得这些能力的运用场景。

就像是打苍蝇我们通常用苍蝇拍、打仗才会用高射炮一样。



架构设计的主要目的是为了解决软件系统复杂度带来的问题。这句话是极客的架构专栏里讲的，我引用一下。

这个准则虽然简洁，但说出来架构设计的真正目的，架构师解决软件复杂度所带来的问题，而识别出软件的复杂度，并且找出合适的技术来解决这个复杂度带来的问题才是架构师应该具备的能力。



别人的架构可以参考，但不能照搬，参考别人的架构也是要理解他们的架构为什么这样设计，为了解决什么问题，我们才能从中得到启发，假如我们的系统也有跟别人框架一样的问题，也许它的部分设计就是可以用来借鉴使用的。这样的设计也才是真正被我们消化的。