敲开通往架构师的门

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

什么是架构师

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

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

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

架构设计的真正目的?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

架构设计原则

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

合适原则

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

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

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

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

演化原则

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

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

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

简单原则

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

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

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

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

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

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

你可能感兴趣的:(敲开通往架构师的门)