很多大公司都是从小公司起步的，往大做的时候，往往会受到很多制约因素。架构选择不对造成的问题很多，所以很多小公司都在架构选择上精打细算。其实架构问题，在公司规模小的时候，更大程度上是一个行政问题而不是一个技术问题。

小公司的特点是人少，往往就那么几个人。这种情况下，与其说是你选架构，不如说你看看有什么可用的架构。通常来说，你要考虑的问题是。

1.你有没有可以信任的核心工程师？

2.能不能找到足够的人手做大部分的事情？

3.能不能在你要求的时间范围内把事情做掉？

4.这个架构有没有成功的例子，能不能支持大规模的访问？

当这些问题都没问题的时候，你才应该考虑，这个架构性能够高么？容易扩展么？

如果你没有可信的人作为核心工程师，项目管理和控制根本无法进行。就算要评估一下手下这些人是不是真的需要这些时间来做事，得到的结果都是不可靠和不可信的。如果找不到足够的人手做事，那除非你的核心团队能够一个人或者几个人把网站整个做出来，例如豆瓣的阿北，否则项目做做就没人，就玩不下去了。如果架构很好，但是无法在要求的时间内做出事情来，等于没用。满足了上述几点，你还得兼顾考虑一下，这个架构如果没有成功案例，是否存在隐性的风险。如果不支持大规模访问，将来的扩展问题。

好吧，作为一家小公司，我相信你考虑完以上几点后，能凑出一个框架来已经很不错了。往往是你的核心团队没有一个核心工程师，大家会几种不同的架构，而且没人能保证评估结果。

这时候，不要废话，先找个核心工程师，然后用最土的，被无数人验证过的技术来把你想做的事情做掉。

除非你的核心团队有且仅有一个核心工程师，并且这个工程师的技术能力很强，管理者和投资人也支持他冒风险。否则大部分使用激进架构选择都会带来不良的结果，毕竟大部分公司都不是以开发框架和研发技术为最终目地的公司。