敲开通往架构师的门

最近学习了一些关于架构设计的知识想分享给大家。俗话说得好，不想当架构师的程序员不是好厨子。那么如何成为一名架构师呢？接下来就聊一聊我的一些想法。

什么是架构师

之前有同学问我，做了几年技术，应该转管理还是转架构师？对于这位同学，我给他的答案是，你要先踏踏实实做好现在的工作。因为就他提的问题来看，应该是刚入行不久或者是在校学生。

专心做技术的，都想做架构师。但架构师并不是说技术做时间长了可以转的。随着你的知识深度和广度的增加，在工作中会扮演更重要的角色，承担更大的责任，最终自然而然就会接触到架构设计的工作。

而架构师的主要工作，其实是利用架构设计知识以及丰富的工作经验，在设计架构时，结合实际情况，在不同的选项中做出取舍。

架构设计的真正目的？

为什么要进行架构设计？因为架构设计很重要？可是为什么重要呢？似乎说不清楚。

因为可以提升开发效率吗？也不一定，因为只有简单的设计才会使开发效率更高。而架构设计出于多方面考虑，不得已会引入一些复杂度，因此架构设计并不一定能提升开发效率。

是为了大多数口中的“高可用”、“高性能”、“可扩展”吗？其实也不是。我们的系统可能并不一定需要这些。

那架构设计的真正目的是什么呢？我认为架构设计的真正目的是与系统复杂度做斗争。

系统复杂度的来源有：高性能、高可用、可扩展性、低成本、安全、规模。

前面我们聊到有些系统可能不需要高可用、高性能。有些同学可能不理解，这些难道不是软件开发最基本的要求吗？这样的说法是存在一定偏差的。我们举一个简单的例子说明一下。

如果让你为一所学校设计一个学生信息管理系统。针对上述几个复杂度的来源，你会做出怎样的取舍？我们来逐条分析一下。

首先是高性能，学校的学生最多也就几万人，而且平时也不可能几万人同时用系统。因此我们并不需要考虑高性能。数据的CRUD直接用关系型数据库就足够了。

然后是高可用，对于学生系统而言，即使宕机几个小时，影响也不会太大。不过数据的可靠性还是要保证的，如果大量数据丢失而又没有备份的话，数据修复将会是一项繁重的工作。所以这里需要做一些数据高可靠的设计。

接下来是可扩展性，学生管理系统一般比较稳定，不会出现需要扩展的情况。因此我们也不太需要考虑可扩展性。

至此，我们在设计系统时习惯考虑的高可用、高性能和可扩展，在这个系统中都不需要过多关注了。我们再来看看剩下的几个复杂度来源。

关于低成本，由于我们并不需要高可用和高性能的设计，所以几台服务器的成本对于学校来说也不足为虑。

安全性而言，学生信息需要一定的安全保证，但也不必做到金融级安全。所以只需要做好数据库权限管理，登录密码管理就足够了。

最后是系统规模，学生管理系统往往不会很复杂。也不会迭代出许多功能。因此规模是比较固定且比较小的，不会带来很多的复杂度。

从我们的分析中可以看出，学生管理系统是一个并不复杂的系统，我们真正需要着重考虑的就只有数据高可靠和数据安全两方面。面对复杂的系统，我们也应该按照这个步骤来思考并设计出合理的架构。在合理的情况下，尽量减少系统的复杂度。

架构设计原则

前面我们提到，架构师的工作其实就是在多种选项中做出合理的取舍，取舍没有对错之分，只有是否合适一说。为了更好的做出选择，架构设计应该遵循三个原则：合适原则、简单原则、演化原则。下面我来一一介绍这三个原则。

合适原则

我们一直在说，架构设计中架构师要做出取舍，选择合适的架构。之所以一直强调合适，是因为我们在架构设计过程中需要结合实际情况来考虑。

那么脱离实际情况的设计通常是怎样发生的呢？不知道大家在开发时有没有遇到过这样的需求：“我们决定做一个电商网站，就按照淘宝做一个一模一样的吧。“这时作为开发的你一定是黑人问号脸，心里也会万马奔腾。

在架构设计时也是一样，最忌讳的就是不顾实际情况，盲目的使用业界最优的架构设计。有同学可能不太理解，使用最优设计有什么错呢？

这里我们所说的实际情况就是你的业务。试想如果你的业务刚刚起步，QPS刚过百，这时，你设计的架构是能支持1000QPS还是3000QPS对于系统来说没什么区别。但对于开发成本来说就提升了不止3倍。而对于这样的业务体量来说，开发团队一般只有十几人或几十人这样的规模。要让这样的团队来开发的话，大概率是无法完成的。

演化原则

聊完了合适原则，我们再来聊一聊演化原则。就像北京的城市规划一样，它一定是先有二环，慢慢向外扩建，才逐渐有了三四五六环。而我们现在所使用的大多数软件，也都是经过了许多版本的迭代才有了现在的功能。

对于一名合格的架构师来说，我们首先要遵循合适原则，然后再逐步演化。切不可想着一步到位，从而引起过度设计。当业务发展到一定阶段时，我们不可避免的会需要对架构进行扩展、重构甚至重写。在这一过程中，我们应该保留下好的设计，对不好的设计进行完善。就像淘宝的架构一样，它是经历了多次“双十一”之后，才有了现在这样能支撑每天上千亿成交额的架构。

因此，我们在设计架构时要遵循的第二个原则就是循序渐进的演化原则，而不是追求一步到位。

简单原则

最后再来说简单原则。前面我们也说了，架构设计其实是在和系统的复杂度做斗争。为什么要有简单原则？我认为原因主要有两点。

第一，复杂的架构开发成本更高。在开发资源有限的情况下，如果我们的架构设计很复杂，势必会提升开发成本。而对于当今飞速发展的市场来说，时间就是生命。如果你设计的架构开发周期非常长，那么公司也许就会放弃这个项目，那么架构也就没有存在的意义了。

第二，复杂的架构往往会带来更多的故障。举个栗子，电动牙刷和普通牙刷相比，坏的概率一定会高一点，电动牙刷可能出现刷头磨损，电路问题，充电故障等等，而普通牙刷只会出现刷头磨损的情况。也就是说，系统的组件越多，系统出现故障的概率也就越大。在此基础上还有一个问题就是，一旦出了故障，定位问题的速度而言，简单系统相较于复杂系统也有着很大的优势。

至此，架构设计的三个原则我们都已经聊完了。细心的同学可能注意到了，我在详细介绍时的顺序和最开始提到的顺序并不一致。这不是我不注意细节。而是我在详细介绍时，对这三个原则的重要程度排了一个顺序。这也是作为架构师的一种取舍，当三种原则无法同时满足时，应该以哪个为重？这里我的答案是合适>演化>简单。

关于架构设计，我已经有了一个大体的认识，不知道在读完本文以后你是否也有同样的感觉。如果有任何困惑，欢迎和我一起讨论交流。

最后，架构师是需要有很深的技术积累的，而我在这方面做得还不够。所以后面还是要以技术积累为主，同时也会尝试将架构设计的知识引入到日常工作中。后续有什么新的体会我会继续和大家分享。