架构哲学

架构设计，是在技术基础上，综合权衡约束条件后，进行选型的一门艺术。他是为解决现实问题，提出的指导性方案，并且是可落地的。架构哲学是探讨成功架构设计应该关注的问题，以及原则和方法论。

一、知识储备

每一种架构都有其系统边界，能解决什么问题，不能解决什么问题，这是架构的先天属性。试图用一种架构解决所有问题，不是吹牛皮，就是耍流氓。作为设计者，首先要有知识广度，知道的越多，可供选择的范围越大，就越容易做出合理的选择。避免拿着锤子，看什么都是钉子的窘境。其次要有知识深度，对目标解决方案需要有足够的理解，甚至要亲自进行原型验证。在一些关键特性上，如果没有足够认识，往往会掉入深坑而无法自拔，最终导致架构无法落地。

这些知识，除了个人努力之外，往往需要一定时间的积累和验证。曾经遇到过运维、测试甚至没几年工作经验的人，在老板面前畅谈着应该如何进行架构设计，我只能面带微笑听着，心里默默地为老板感到悲哀。一个系统最终能否成功，受很多因素影响，但架构设计是其中最关键的因素，并且持续性地影响整个系统。一个没有足够经验的架构师，带给团队的，往往是灾难性后果。因此，每个架构师，都应该怀着如履薄冰，视如己出的心态来对待自己设计出来的架构。

二、现实约束

抛开一些特例，如国家垄断企业，什么都 不缺。在大多企业中，要解决现实问题，还需要在技术基础上，考虑市场、时间、人员、资金甚至包括遗留系统兼容等诸多因素。一个最简单的例子，买个商业软件要200万，但手头只能50万，还要管一班兄弟们吃饭，怎么办？很显然，开源免费方案是首选，至少在赚到钱之前，就不用想着商业软件了。这种情况在很多初创并不少见，如果没有考虑这些技术外的因素，那么设计出来的架构最终就要落空。

真实问题的分析和界定，是架构设计的前提条件，只有知道自己要解决什么问题，才能设计匹配的架构，否则一切无从谈起。这个前提是成功架构设计的基础，却是很容易犯错的地方。我见过不少夸夸其谈者，不论是否有丰富的经验，连系统都没有了解清楚，就妄议架构优劣。

三、经验陷阱

之所以说架构设计是一门艺术，因为他需要因时、因势制定合理的方案，这个过程中，需要不少创造性的活动，而不是生搬硬套的教条主义。

一种最常见的陷阱，就是引用大公司的案例。曾遇到一次有趣的争论，关于网络带宽问题。运维举例说，债券交易所的带宽都不需要这么大，因此现有架构有缺陷需要改进。当时一时没有反应过来，后来给仔细算了一下，简直就是在扯淡。债券交易所都要求配备2Mb专线，按4个交易员算，每个连接可用0.5Mb带宽。而公司现有产品接5家经纪商，2家证券交易所的债券行情，1家国债期货，共计8家行情，而且都比债券交易所活跃，频率高。以同时在线数6000个连接算，则需要2.4Gb带宽，而现有带宽500Mb，因此债券交易所的行情带宽至少是公司的48倍。

另外一种则是流行陷阱，就是采用最新或者最流行的技术。这个陷阱就像灯火至于飞蛾，让诸多架构师前赴后继，而无法自拔。在2012年的时候，为公司选择qpid为消息总线。2017年，新来的技术负责人，要将其换成rabbitmq，当下这个最流行，在券商等大机构有广泛的应用。最终在某银行竞标项目中，因吹牛过于用力，而不慎爆掉。

而其他技术陷阱也是不可胜数，适合于某个场景，在另外一个场景就不一定适用。架构师要学习控制自己，学会掌控经验，为己所用，而不是被经验所驾驭，坑了自己，也坑了同伴。

四、架构进化

没有任何事物是生而完美的，随着时间推移，现实约束会发生变化，技术会不断发展，资源条件也会出现转机，因此，对架构提出新的需求，进化时机也就随之而来。就像淘宝之初，也是买个简单网站，经过十年的不断演进，才有今天如此复杂庞大的系统，轻松应对双十一。在创业之初，钱少、人少、时间少，极简的架构设计是成功的法宝。项目都活不下来，何需谈及到未来3－5年呢。

世间唯一不变的是变化本身，因此架构进化以适应不断发生的变化是必然的选择。象深交所V4系统那样，一用14年的情况极为少见。而架构进化并不是为给失败架构设计找借口，比如将延迟敏感的场景设计成B/S架构，发现不行后，再转成C/S架构。在架构设计之初，除了满足现实约束条件来解决现实问题外，还需要在一些关键节点处留下余量，以便将来更新换代不至于大动干戈，导致系统伤筋动骨。

架构进化过程中，就像给行进中的列车更换引擎，风险极高。并行运行，平滑过渡是必须遵循的原则，蓝绿部署，滚动部署、灰度部署、金丝雀部署说法不同，各有特点，但核心原则都是类似的，小心试错，便于回滚。