一、架构的作用

可能对于很多的公司，其实架构本身的重要性并不大。大家一定明白这回事，架构在实际的开发，在大多数的场景下其实用处并没有书籍和资料中讲的那样重要，甚至是可有可无。这样讲是不有些可笑？是不是觉得挺意外的？但这就是事实。大家可以看看网上对架构师的一些抨击就明白了。那么为什么会这样呢？有以下几个原因：

大多数的公司和和大多数的项目都规模较小，架构的优势无法体现或者说体现不明显。这就导致架构的意义无法被大家重视。一个只有几千行代码的小程序，大多数情况下，架构能有多大的优势？
现实的工期太短。往往很多项目不光规模小，开发时间还特别紧，都不愿意甚至不安排架构设计
开源的依赖。很多公司，特别是中小公司，往往习惯于找个开源的项目，在上面改改，然后就推出了。开源的架构就是项目的架构（没毛病）
PPT架构师的误导。在一些公司，特别是大厂中，存在着不少的PPT架构师，他们的主要作用就是把各种高大上的技术和架构以及思想杂合（而不是有机的融合），搞一个看上去很炫但实际没啥用的架构。它们的目的不是做设计，是为了做宣传
那架构到底有没有用呢？当然有用，而且非常大。项目规模越大，软件越是复杂，架构越能体现它的优秀之处。不过，不能因循守旧，僵化应用从而形成本本主义和教条主义。要因地制宜，实事求是来进行架构的选型和设计。

二、架构的选型

假如面临一个项目由自己来确定一个架构，如果这是第一次自主进行架构设计，那么第一件事，就是在需求确定的情况下，如何进行架构的选型。正如上面所分析的，要因地制宜，实事求是的进行选择。这话说得，正确而没啥用。那就说一点有用的，来解释下这句话。

根据项目的大小来选择
这个最容易选择，如果一个规模较小的程序，比如几千行代码或功能很少的程序。架构的意义一般来说不大。怎么简单怎么来，怎么方便怎么干。
要根据需求的特点来选择
这个很容易理解，以一个网站为例，并发是多少？数据量有多大？数据读多还是写多或者都多等等，从而确定相关的架构选型。举一个简单的例子，公司只是做一个展示形象的网站，那基本就可以不考虑架构，做得漂亮一些就可以了。如果数据量很在并且读多写少，就可以使用缓存架构，使用Redis或其它内存型数据库。
根据公司的开发人员的情况来选择
这个就是根据开发人员的现在技术能力和水平和选型，比如都是菜鸟，如无必要就不必上一些微服务之类的复杂的架构。另外使用消息架构时，公司的开发人员更熟悉哪个就用个。最典型的就是网络开发，是使用同步还是异步架构？同步简单但异步对开发人员能力要求高。
根据适当的扩展预期来选择
公司的业务在未来两到三年，会有一个什么样的发展，公司的发展方向是什么？就可以适当的选用一些容易扩展的架构来实现设计。比如公司是做软硬件一起的项目，那么软件就需要把未来几年可能的公司的相关的硬件都要预留一些扩展，比如使用工厂+库的架构设计。
根据项目的总成本确定
比如公司的可投入的人力成本和时间成本以及相关的软硬件成本等。举个例子，公司开发人员挺多，技术水平也高，但公司只给这个项目一个人，时间还紧，钱也少。就得考虑使用简单的架构先完成功能。然后有时间再进行重构甚至重写。

但实际情况是，往往一个项目不是上面一种条件确定的，它一定是全部或几种共同来确定架构的选型。同时，这其中可能每个条件的权重还有所不同，甚至可能随着时间这些权重还是变化，这就需要架构师来动态进行调整了。

三、选型的原则和验证

在上面分析了很多架构选型的方法，那么如何应用他们呢？有以下几个原则，当然这个原则是个人推荐，不是书籍资料上的公认的，算是私有原则：
1、如果架构选型可大可小，就选小
比如开发一个网站，从单体架构到垂直架构到分布式到微服务等等，选择的话，在条件允许的情况下，越简单越好。不要问为什么。
2、如果架构选型可保守可适度可激进，尽可能选择保守。
这里说的是实际的项目而不是一些实验性质的或半实验性质的。说白了就是能简单则简单，不要自己给自己找麻烦。等多做几次架构设计就都明白了
3、如果对未来扩展模楞两可，尽量不选扩展型架构
这种事情，不多说，明白的都明白，不明白的做几回就明白了。说句真心的，大概率是用不上的
4、如果可控范围内，设计者想选用新架构新技术就用
老人常说：“谁拿锄谁定苗”，想怎么舒服就怎么来
5、如果多种选择可选择，哪个方便哪个简单选哪个
不要自己难为自己，也不要难为手下兄弟们
当然，这些私有原则不能拿到台面上，但实际是很有用处的，至于对错，见仁见智吧。

最后，如何能够认为选型是正确的呢？其实就是项目完成的复盘结果，如果基本达到项目的目的，选型就算成功了。对，基本达到项目要求，或者说达到项目最低要求就算成功了。很多项目，包括大公司也一样，在整个开发过程，它们的架构会有一个不断调整的过程。所以，如一个架构基本能坚持到最后并达到了基本的需求，就算成功了。