我的架构感悟：从美国宪法学习架构设计原则
文章正文
2017年1月20日注定是一个会在历史上留下记录的日子，美国第45任总统Donald Trump宣誓就职。他的就职宣誓词非常简短：
I do solemnly swear that I will faithfully execute the office
of President of the United States, and will to the best of my
ability, preserve, protect and defend the Constitution of the
United States.
令人惊讶的是，自从1787年美国宪法在费城制宪会议通过以来，在宪法第二条第一款中规定的总统宣誓词，竟然历经230年，从未变化。
从一个架构师的角度来看：合众国宪法作为美国这个国家的基础架构，从发布到现在200多年，美国也从13个州发展成50个州，人口从380万增长到3.2亿，时代早已发生剧变，但是美国政治的核心架构基本未变，这个系统的运行状况堪称良好。当年那群“架构师”，实在是了不起。（虽然他们当年的底气相当不足，华盛顿认为，这部宪法能维持20年就不错了）
如果，我们想要设计出这样的一个架构，能够长期适应需求与环境变化，能够历久弥新并始终稳定可靠，那么了解一下美国宪法的制定过程，其实是一件非常有价值的事情。
重构都是被逼的
有几个时间点，现在看来，其实颇为令人诧异：1776年7月4日，美国以发布《独立宣言》为标志宣布独立。1783年9月3日英美签订《巴黎和约》，独立战争结束。但是一直到1787年9月15日，一众国父们才在费城签署了《美利坚合众国宪法》。也就是说：一个独立的国家，在运行了11年后，才有了自己的宪法！而且又过了2年，直到1789年这部宪法获得各州的批准之后，华盛顿才被依法选为第一任美国总统。
可以说，在长达13年的时间里，这个国家没有总统，没有中央政府，没有一点国家的样子。我们不禁要问一句：早干嘛去了？打仗期间忙不过来，尚且可以理解。战争结束之后的6年，他们在干嘛？
事实上，1777年11月19日大陆会议通过的《邦联条例》，可以算是这个国家的beta版架构。但在上线运行10年之后，实在是撑不住了。首要的问题，是因为钱，独立战争结束，各州拖欠了士兵数百万美元的军饷，同时还拖欠了一些欧洲国家的钱，但是，这个国家一穷二白没办法还钱（还记得技术债务吗？）。这个国家也没有全国性的货币体系，在不同的州，一美元的价值竟相差4倍！由此引发的，是很多人破产甚至被投入监狱。退伍士兵谢司领导了一场起义，兵力甚至高达1万5千人，虽然最后被镇压了。但是，整个国家都陷入了严重的恐慌，一个新兴的、刚刚独立的国家，是不是就要完蛋了？
用架构师的语言描述就是：一个临时性的架构勉强上线运行，如果再不做架构改造，推出新版本，这个系统就要彻底宕机了。虽然大家都不清楚新版本应该是什么样子，但是必须得有一个新版本了！然而当时的美国各州，都喜欢去中心化的、互不相干的分布式架构，对于可能出现的集中式架构，深感警惕。要他们商量出一个一致同意的新架构，将会异常艰难……
但是，另一个值得思考的问题是：拥有先见之明的天纵奇才、提前制定出明见万里、高瞻远瞩式的架构，真的靠谱吗？
显而易见的观点，可能并不正确
当时的欧洲，有很多人也在关注这次大会。按照欧洲人的看法：民主共和的政体，只适合于像瑞士那样的小国家。对于美国这么大的国家而言，只能是选择君主制。因此，那些美国人之所以要关起门来讨论，估计是在商量：到底是请哪一位君主到美国去当国王，会比较合适。更有好事者，连候选人都想好了：要么是普鲁士的亨利王子，要么是英国的弗雷德里克·奥古斯塔斯王子。
当时的美国人，有很多人抱着完全相反的另一种观点：不要有国王，甚至连中央政府都最好没有！他们之所以打了一场独立战争，就是为了从英国的统治下，解放出来。在获得了自己的独立、自由之后，他们立马就各回各家了。过自己的日子不挺好吗？为啥还要立宪？还要成立一个凌驾于各州之上的中央政府？大家受到英国的奴役，还不够吗？
对于提议召开此次大会的组织者而言，尤其是对于美国宪法之父，已经准备好了弗吉尼亚方案的詹姆斯·麦迪逊而言，美国这个国家，已经到了最危险的时候，必须有一个强有力的中央政府，十三个州政府再也不能像过去一样，一盘散沙了。时年35岁的麦迪逊，已经通读了当时几乎所有的政治相关著作，并且在去开会前，带上了几百本书和报纸，准备回答可能遇到的一切疑问和质询。
事情当然没有那么简单，一场大会从5月25日开到了9月17日，整整116天！期间有无数次，某些代表、甚至所有的与会代表，都深感沮丧和绝望，感觉这个会开不出结果来了。究其原因，实在是因为问题太过复杂，代表们的分歧太大造成的。事实上，他们所做的事情，是要写出人类历史上的第一部成文宪法。而且这个国家，与历史上的任何国家，都大不相同。就好比我们打算做一个架构设计，却几乎找不到任何可供参考的案例。任何已经存在的方案，显而易见的观点，各种类比与参考，都无法理所当然的直接借鉴。
换言之，我们在开始一个架构设计时，最需要警惕的，恰恰是那种显而易见的观点和方案，因为很可能是错误的。
会议程序的价值
在阅读制宪会议的这段历史时，最令我感兴趣的，是他们的一些会议程序设计，非常有意思。
5月25日，开会第一天，大会选举了乔治·华盛顿为大会主席。然后，在5月29日大会决定采取全体委员会的形式，另选了一个人，做了全体委员会的主席。此后，华盛顿便只在每天开会和散会时，上台就主席座，宣布会议开始与会议结束。其余时间，他都坐在弗吉尼亚代表团的桌子旁，以普通代表身份参加讨论。
这种会中会的玩法，据说是能够给讨论，留下缓冲的余地。
第二个程序设计，是代表们一致同意，在大会过程中有权改变决议，而不是讨论投票表决，就结束了。任何代表都可以要求对任何议题或决定进行重新讨论，而且他们经常这么做！整个大会，一共有569次表决，很多议题会被反复讨论。例如关于总统选举的办法，就一共有60次投票表决。因此，他们又制定了一个保密规定，任何人，不得对外透露大会的事情。
为何要采用这样一种反复讨论、表决，而且对外保密的做法？在40年后，麦迪逊才解释了原因：如果大会对外公开的话，任何代表之后都不会改变自己的主张，这样做就意味着公开承认自己原来是错误的。如果这样，那么这次大会，就可能会失败。
第三个程序设计，也是一个会中会的形式。在会议遇到重大分歧时，他们会另外任命一个小型的、专门的委员会，首先让这个委员会在小范围里讨论出推荐方案，表决通过，再提交大会讨论和表决。下文将会介绍“伟大的妥协”，就是一个委员会的努力工作的产物。
追根溯源来说，这些开会的艺术，其实是英国政治文化的优秀遗产。一群无论是智力还是见识，都仅仅只能算平庸的人，要想把一个非常复杂的问题讨论清楚，只能尽可能保持耐心、保持克制、充分讨论、反复表决，只有这样，才有可能达成共识，也才有可能获得尽可能好的结果。
虽然，我们不能想象一个系统的架构设计，也像这样一口气开3~4个月的会。但是：在讨论问题的过程中，集思广益，反复权衡，参与争论的各方，也能够心平气和、就事论事、不翻旧帐（你昨天不还是反对的吗？上次你那个设计就有问题！）对于获得良好的架构，也应该会有很大的帮助。
妥协（不埋雷）的艺术
在架构设计的过程中，我们通常会面临各种复杂的、甚至是相互矛盾的需求，在追求设计的品质时，理想主义与现实主义也会存在冲突。如果紧紧守住自己的意见，毫不妥协，通常连一个架构方案都拿不出来。但是，在权衡与妥协的时候，一味的期望消弭冲突，或者求同存异，都可能会埋下地雷，在系统上线运行之后，日积月累、酿成大祸！
在这次的制宪会议上，代表们达成了很多的妥协。其中“有名有姓”、载入史册的重大妥协有三项：关于大州和小州之间在议会中席位数多寡的妥协，这项妥协干脆就被史家们称做“伟大的妥协”（The Great Compromise）；其次是南方州和北方州之间关于奴隶是否有选举权的妥协，“五分之三妥协”（The three-fifths compromise）；再者是与南、北方经济利益冲突相关的、关于国会管理新大陆商业贸易权限的妥协，“商业妥协”（The commerce compromises）。
很多讨论美国宪政史的文章，都会单挑一个“伟大的妥协”来讲，大书特书妥协的意义，例如某篇文章中的这么一段：“妥协是民主政治的灵魂。没有妥协，就没有民主，就没有大邦与小邦的联合，就没有新美国，也就没有强大的美国政府。”
但事实上，五分之三妥协，也出于同样的目的。按照当年立宪会议代表们的说法：如果没有这样的妥协，南方就不会加入，美国就无法建立起来了。但是，在多年以后，也有很多专家认为：在美国这个号称自由的国度，竟然能够容忍奴隶制，这本来就违背了国家建立的前提。这是美国创始人们的“原罪”！或者说，这是他们最大的错误，即使不能马上摆脱奴隶制，也应该有一个明确的、长期的计划，最终摆脱奴隶制。
为什么会犯下这样的原罪？因为在当时，即使像国父华盛顿、宪法之父麦迪逊这样的伟人都拥有奴隶，要让他们在宪法中正视这一点，也太难了。所以在宪法中以“所有其他人口”指代奴隶。还有一个原因，大概也是因为穷，北方虽然不实行奴隶制，但是他们进口奴隶卖给南方，每个奴隶国家能够收到10美元的税！
要如何才能恰当的妥协，却不至于埋下隐患呢？一场75万士兵死亡，40万士兵伤残的美国内战，实在是非常巨大的代价！是否有可能避免呢？就算按照专家们的马后炮，制定一个长期的计划，又该如何制定呢？
实话实说，我们几乎无法做到。或者说，立宪代表们百般警惕，左躲右防，已经尽力避开了大部分的政治风险了，难免还是会有坑，难免还是会栽，这也是没办法的事情。
如何才能追求可靠性
架构设计中，一个很重要的目标是系统的可靠性。如果说可靠性设计，有什么诀窍的话，那么就一句话：一切都是靠不住的！
在美国宪法中，非常鲜明的体现了这种“可靠性设计”的思想。如果系统架构被设计为一种自上而下的金字塔结构，一旦顶层（总控层）出现故障，则一切稳定性皆无从谈起。
在当时，1748年法国孟德斯鸠在《论法的精神》中系统性的提出的三权分立之原则，已经被普遍接受。因此，在美国宪法中，设置三权分立，已经是顺理成章的事情了。只是具体而言，如何限制某一分支独大？三个分支如何分工协作？如何互相制约？则是非常复杂的问题。需要考虑各种细节。行政分支，要不要设立总统？是一个还是二个、三个？是终生制，还是有限任期？由谁来选举？能不能连选连任？如果总统出了问题，能不能弹劾？如何弹劾？由谁来弹劾？由谁来批准弹劾？其他的两个分支，也一样要面临一堆的细节问题。
举几个有趣的小例子，参议员任期6年，却规定每2年改选其中的1/3。就是为了避免在长达6年的时间里，同一批参议员形成某种意见共同体。（感觉很有某种分代回收，避免一次回收全部垃圾造成性能下降的意思）
另外还规定了总统要是“免职、死亡、辞职或丧失履行总统权力和职责的能力”时，责任移交给副总统。再不行，就移交给国会指定的某一官员。（感觉这是多重灾备的设计思路啊，事实上，如果细读1967年通过的宪法第25条修正案，这个灾备设计就更加完善了。）
还有非常重要的宪法修正案，当时就有马萨诸塞州、马里兰州、维吉尼亚州、纽约州、北卡罗莱纳州，强烈要求，宪法必须加上的十条宪法修正案，以保障基本的公民权力。其中的第一条：国会不得制定关于下列事项的法律：确立国教或禁止宗教活动自由；剥夺言论或出版自由；剥夺人民和平集会和向政府诉冤请愿的权利。这是一个非常厉害的修正案：不得立法！以此来确保公民的监督权，在任何强权之下，都不可被剥夺。（系统监控的重要性，由此可见一斑）
其他的各种细节，这里不再一一细聊，总而言之，大型分布式系统的架构设计，每一个细节，都需要投入良苦用心呀。
恰当的前瞻性
做架构，当然需要有前瞻性。如果仅仅考虑眼前的烦恼，很难做出长远的规划。另一方面，一群意见分歧很大的人，需要达成各种一致的意见，也需要“一起向前看”。在制宪会议上，原本各不相属的州，代表们要想达成一致意见，就非常困难。因为，他们在意识上，常常觉得自己不过是纽约人、宾州人，不是一国的。但是宾西法尼亚代表古弗尼尔·莫里斯却对大家说：当费城会议的代表去世以后，我们的子孙将不再想到他们是宾夕法尼亚人或者纽约人或北卡罗来纳人。相反，他们会认为他们是美国公民。我们这一代人会死去，我们的后代就是美国人。
这种远见（其实也不算太远），对于消弭代表们的分歧，有巨大的价值。但是，在制宪会议上，另外一名大大有名的代表：亚历山大·汉密尔顿，可能是最有远见的一位。在会议上，汉密尔顿曾经发表了一个长达5个小时的演讲，在弗吉尼亚方案与新泽西方案之外，独立提出了一套方案。汉密尔顿确信：当美国逐步强大时，现有的政治体制将无法适应需要。他认为美国应该追随英国的政治体制。他说这是世界上最好的政体。
但是，在会上，代表们经过投票，否决了新泽西方案，而对于汉密尔顿的方案，甚至没有发起表决。大家默默的听他说完，既不打断，也不反驳，就让这事过去了（据说是因为天气太热了）。可以说，在最终成文的美国宪法中，虽然融合了众多的不同观点，但是对于汉密尔顿的观点，却吸收得很少。
在历史上，汉密尔顿也被称为美国最伟大的财政部长。后代的学者们相当关注他的那些在当时被主流政治忽视甚至攻击，而在后世却逐渐显现出其高瞻远瞩性的部分，并对其进行当代意义上的重估。例如他提交国会的《关于制造业的报告》，最终未获得通过，却体现了发展制造业的前瞻性思想，并为美国后续发展起到了指引作用。
正好我最近在看的《罗马人的故事》，有一段话非常有意思：
后世很多研究者在分析格拉古兄弟改革失败的原因时，将其归结为“过于超前”。
的确，人是关注短期行为的动物，超越大多数人认识水平的改革不容易成功。
马基雅弗利有一句名言：“没有武力做后盾的先行者，难以避免失败的命运。”
但是，在我看来，过于超前的架构，即使有武力作为后盾（你自己就是CEO+CTO+总架构师），也可能难免失败的命运。不仅大州与小州的妥协非常重要、南方与北方、工业与农业、公平与效率的妥协，甚至理想主义与现实主义、前瞻与务实的妥协，也非常重要！
还是那个问题：拥有先见之明的天纵奇才、提前制定出明见万里、高瞻远瞩式的架构，真的靠谱吗？
架构落地与看护同样是艰难的工作
在宪法的文字全部敲定，所有的制宪会议代表签名同意之后（55位参会代表，只有39位签字），这只能算是架构设计工作完成。至于架构落地，还需要付出巨大的努力。
首先是当时一共13个州，需要一一投票表决，接受这部宪法。从第一个特拉华州在1787年12月7日以30:0的全票通过，接受宪法，到最后一个罗德岛州在 1790年5月29日以34:32微弱多数通过，接受宪法，前后一共耗时差不多2年半！
如果我们去细看这2年半中发生的各种故事，会发现更多的“惊人细节”。在制宪会议上拒绝签字的代表，一回到自己的州，就发动一切力量，企图阻止投票通过。在纽约，约三分之二的代表反对新宪法。这种局势使得汉密尔顿、麦迪逊和杰伊不得不亲自动手，在报纸上连续刊登为新宪法和联邦制辩护的文章，即后来被认为是对美国宪法最佳阐释的《联邦党人文集》。（汉密尔顿的伟大也在这里，这部宪法他并未完全同意，但是却毅然签署，并全力推行，实在是功莫大焉）
除了言论上的争吵，还有更多“暴力”的情节，有强行绑架人去投票的，有游行示威、焚烧宪法、甚至又打又砸的。最艰难的是罗德岛州，从一开始就没有派人参加制宪会议。到最后也是联邦参议院通过了联合制裁法案，禁止罗德岛与合众国的海上和陆地贸易往来，还要求该邦限期偿还国债。最后才以微弱多数通过宪法。
即使在13个州全部通过并接受宪法之后，这部宪法也还不能算落地了。具体该如何执行这部宪法，是非常考验国父们的能力与品格的。在林达的《如彗星划过夜空》中，有这么一段话：
美国“精英执政”时期，是特指在美国建国初期、非常特殊的、一批具有古典
共和主义精神的绅士执政的情况……这些制度的最初实践者，就是制度的制定
者，他们的思维方式和这个制度是基本一致的，它相对也就更容易在实践中
成功……宪法实践的最初阶段，正是这些国父们自己在亲手操作、完善、修补
它的漏洞，在完成宪法实践的那一半任务。
举两个例子说：最初的宪法规定，选举总统，得票第一的是总统，第二的是副总统。在具体实践的过程中，就发现第一与第二的两位总统，可能存在重大的政见分歧，要想在一起搭班子干活，会非常别扭。到了1804年的宪法第12修正案，变更了选举程序，变成总统与副总统分别选举，避免了这种现象的再次发生。
另一个例子，则是发生在1803年的《马伯里诉麦迪逊案》，一个普通法官马伯里状告当时的国务卿詹姆斯·麦迪逊（后来的美国第四任总统），最终官司在最高法院的大法官约翰·马歇尔那里得以解决。最高法院历史上第一次宣布，联邦法律《1789年司法条例》第13款因违宪而被取消。由此，最高法院实际上确立了有权解释宪法、裁定政府行为和国会立法行为是否违宪的制度，对美国的政治制度产生了重大而深远的影响。
总结以上的历史，我们可以发现：架构师在架构落地与架构看护时的重大责任，在设计架构完成之后，如何推行（软硬兼施）、如何落实（自己Coding）、如何改进（能认错，能改正）、如何防微杜渐（在小问题上确立大原则），都是需要勇气与智慧的。
架构的安全性是永远的难题
200多年前，美国是一个非常落后的地方。那个时候的制宪会议代表，从新罕布什尔州骑马到费城，要2周的时间。1783年美国打赢独立战争时，只有43张报纸。直到1790年的纽约，才出现了印数达到1000份的报纸。另一方面，当时的美国，绝大多数人并不识字，而且还有源源不断的不懂英语新移民，来到美国。
请注意：美国总统的选举办法，是在那个时候，就确立下来的。200多年过去，美国成为世界头号强国，美国的互联网也成为世界上最发达的互联网。信息高速公路首先出现在美国，资讯爆炸首先出现在美国。在这种情况下，美国总统的选举办法，还是差不多像原来的那样。
当我们考虑一个系统的安全性时，首先需要注意的，就是他暴露于外界的情况。每天有多少外部访问？来自多少独立IP？一共有多少种不同的访问（攻击）类型？在外部攻击无法避免时，还需要考虑多重防备的手段。从访问拦截、输入校验，到传输加密，甚至备份恢复。
正好在最近，我看到了一篇文章《2016年的黑客活动对政治造成了哪些影响｜FreeBuf年终策划》，其中提到了一个叫Pawn Storm（APT28）的组织，2016年在美国、德国、乌克兰、土耳其和黑山共和国，发起了至少8例针对政治党派的重要网络攻击活动。使用的手段包括：0day漏洞、恶意代码、钓鱼邮件、虚假新闻、发布泄密内容等等。用这些手段操纵民意、影响大选结果。在同一篇文章里，还提及一个叫Andrés Sepúlveda的人，去年3月，他首次向《彭博商业周刊》中透露，自己曾参与操作了9个拉美国家的民主选举，手段包括窃取数据、安装恶意软件、在社交媒体上伪造大规模支持或反对的民意。
用安德烈斯的话来说，黑客已经掌握了现代政治选举的运作规律，例如进行
广告攻击、研究反对者或者设法压制对手得票率。他发现选民总是天真的信任
社交媒体上的人物，因此他便利用社交媒体虚假账户伪造照片、介绍。他写了
一个被称为“社交媒体捕食者”的软件程序，管理并指导推特上的僵尸账户。软
件可以让他迅速变更用户名称、资料、照片和介绍，最后他发现他可以轻而易
举操纵公众辩论，“我意识到自己有权利让人们相信几乎任何东西”。
由此看来，美国现在的选举人制度，只怕还是存在不少安全隐患的。正如我的朋友霍炬所说：“要是在英国的议会制度下，特朗普这样的人，就很难被选出来了。”
当然，这篇文章的主题，是系统架构设计能够从美国宪法中学习些什么。只是我也在想，也许政治体系的设计，也可以从现代IT系统的架构设计中，借鉴到一些什么……吧。
结束语
作为一篇接近7000字的文章，写这么长的内容，已经几乎耗尽了我的全部真元了。结束语，就简短一些吧：
- 复杂系统的长期平稳运行，需要优秀的架构支撑。
- 设计一个复杂的系统架构，是超高难度的工作。
- 作为IT软件系统的架构师，了解一些其他系统的架构（及其设计过程），也会很有价值。
对话实录：架构设计，可以学美国制宪；架构改造，可以学中国改革
问： 1）架构中对合作博弈的机制设计是否重要？如果是，则如何设计引入？老架构的调整中，如何破解纳什均衡中的“锁定效应”和“路径依赖”等问题？2） 美国宪法架构设计中，如何处理经费预算的问题呢？或者是预算问题是否是架构问题的先决条件？或者别的某些先决条件属于必要的存在？
答： 1）先引用一段评论。钟晖说：“以前，看过一篇IT同仁用苹果、安卓等操作系统来解释伊斯兰教、基督教等宗教的文章，喻示法灵活显，直白易懂，让大家明白了伊斯兰教是什么鬼。”
那篇文章，我也看过，但是：说实话并不喜欢。因为一旦深入了解各个宗教与各种操作系统，就会发现，简单类比是非常危险的。或者说，仅仅是基于某种固有印象的类比。
另一个希望避免的倾向，是那种“讽喻”，借着IT架构的某某特征，来暗讽某种政治制度。不仅仅因为这样危险，而且也很可能是错误的。其中最大的一个区别，就在于：IT系统里的各种组件，都是人类编写的程序，目前还不会有自行造反的可能性。而人类社会中的各种角色，都是有智力、有目的、有情绪的人。所以，对于人可以讨论博弈论。对于各个模块、组件，就很难去讨论他们之间的博弈关系。
所以，在收到关于纳什均衡相关的问题时，我思索了片刻，感觉很难回答。因为不容易类比过去。当然，在决策过程中，我们的确会发现各种“路径依赖”的现象。因为过去的思路如此，在后续的改进或变更过程中，很难跳出那个圈子去思考。这是人之常情，也可以说是人类共通的弱点。
2）在我的文章里，提到了因为美国政府没钱，所以才会在奴隶制方面有一个3/5妥协。另外，就是每个奴隶，美国政府能够收10美元的税。这就是经济原因导致的，政治决策。另一好玩的例子，我的文章里没有提。在制宪会议过程中，因为争吵太过激烈，富兰克林提议，是不是找一个牧师，来带着大家祈祷。然后，人家告诉他：没有钱请牧师…
问：三权分立，怎么玩是否可以详细说说？
答：这也是个很难的问题，因为在架构上，我们很难找到简单的类比：A、B、C正好是一个架构里的三个要素。虽然，我们会说三层架构、或者MVC架构，但是这种简单的类比，可能是错误的。或者说，我们如果因为想要比对上三个要素，结果就忽略了系统中的第四、第五个要素，就很危险了。
当然，如果要深入的讨论三权分立的思想精神，可以说它是基于一个要点：假设某个部分出了问题，我们可以如何制衡它？从这个角度而言，我们针对系统中的每个部分，都可以再问一问：如果这个部分出问题了，我们该如何办？就像美国人说“总统是靠不住的、国会也是靠不住的、法官也是靠不住的”，而对于我们的架构来说：架构中的任何一个组件，都是靠不住的。至于是不是一定会是三个部分，互相监督，倒是未必。
问： 在公司多产品平台上的架构重构，需要的周期比较长。对现有产品影响稳定周期较长，一般都是小调整，怎么实施较大重构，老庄的策略及自己操刀过成功的案例有么？ 架构眼花时候的充分向下兼容会导致维护比较重，是否尝试过比较激进的策略？就是为了加快产品进度而一定程度放弃向下兼容，中早期产品迭代获取用户才是最关键的。
答：其实，我们可以泛泛的问题：架构变更（演进），应该依据什么原则？我先引用一段美国宪法的文字：“第五条国会应在两院各2/3议员认为必要时，提出本宪法的修正案，或根据全国2/3州议会的请求召开公议提出修正案。以上任何一种情况下提出的修正案，经全国的州议会或3/4州的制宪会议批准，即成为本宪法的一部分而发生实际效力；采用哪种批准方式可由国会提出。但在1808年前所制定的修正案不得以任何形式影响本宪法第一条第九款之第一、第四两项；任何一州，未经其同意，不得被剥夺它在参议院中的平等投票权。”
这段文字，规定了什么样的修改，可以成为宪法修正案。2/3议员提议；3/4的州通过；可以说，这是一个非常非常难以达到的条件。因为有了这条规则，所以才会有：美国宪法230年，只有27条修正案的结果。
那么，这个规则到底是不是好事呢？
假设，一家公司有一个架构师委员会，2/3架构师提议；3/4架构师同意，才能够对架构实施变更。那么，基本上我们可以认为，这个架构的变化可能性会很小。当业务快速增长、产品快速迭代时，这种搞法，是要出问题的。
在我的文章里，其实也提到了一些。比如美国的总统选举办法，在200多年的时间里，有上百次的修改提议，但是却始终没有能够获得通过。所以，总统的选举办法，还是这个老样子。说实话，是有些危险的。当然，从长治久安的角度来说，随随便便，就可以推出一部新宪法，也不是个事儿。我国的宪法：在60多年的时间里，制定和施行了四部宪法。即1954、1975、1978、1982宪法。1982宪法颁行后，又于1988年、1993年、1999年、2004年四度修正宪法。总觉得，也不太妥当。当然，世界变化太快，也是原因之一。比如说：在希特勒上台之后，在二战结束之后，其实美国人也反省了一下，比如修改了总统选举法。原来的总统不能第二次连任，只是华盛顿立下的潜规则。但是之后的宪法第22修正案，就明确规定只能连任一次了。
还是正面回答一下，如何操刀一次架构变更的问题。说实话，我有成功的案例，也有失败的案例。失败的例子，现在我反省下来，还是当时自己太年轻，资历不够，说服力不强导致的。至于成功的案例，本质上是靠我的鼓动力（说服力）。能不能够说服其他同事，同意我的架构变更方案，至关重要。作为一个会自己coding的架构师，总会有一种冲动：我自己上，把关键的代码给写出来了。看他们还能把我怎么样？这就好比军人干政。我手里有武装力量，就带兵杀进去，造成既成事实。当然，这样肯定是很糟糕的做法。“政治不正确。”
我儿子曾经问过我一个问题：爸爸，你想过变成一个美国人吗？你觉得做中国人好，还是做美国人好？
我当时是这么跟他聊的。美国人有他们的自豪感。中国人也有他们的自豪感。但是，这两种自豪感大不相同。美国人的自豪感，是他们的成就，上升、上升，直到现在成了世界第一。而中国人的自豪感，是“咱们都经历过”。不仅经历过辉煌，也经历过衰落，甚至近乎灭顶之灾。中国人的自豪感在于：几千年风风雨雨，咱们这个民族，都挺过来了。不仅经历过温和的渐变，也经历过毁灭后的重生。所以，在美国人，可能无法想象：把现在的美国宪法，全部推倒重来。但是，在中国历史上，全部推翻，重新搞一套的次数，已经太多次了。所以，在中国历史领域，有一个词叫做：“超稳定结构”，这个架构，可以说更加神奇。全部机器都炸光，还能再build一套，接着run。
所以，针对激进的架构变更策略，其实也没啥。只要公司没有倒，还是可以跑起来的。（当然，风险自负。）
问：讲讲架构的对具体实现的指导和约束机制吧。另外我想说明的是，架构师需要了解整个代码的痛点，才能有效地针对这种痛点做相应的反应。所以，架构师是需要经常触碰代码的，以便整个架构跟随着应用宝氧化而演化。
答：架构对于现实约束，其实是很困难的问题。很多时候，我感觉架构师一定要是一个很好的布道师。将自己对架构的理念与思考，灌注到其他团队成员的心里。然后，才能引导他们，写出我希望看到的代码。从这个意义上来说：汉密尔顿等三位，写的《联邦党人文集》，就是在做这样的说服工作。
另一方面，法制意识也很重要。如果你已经投票同意了这个宪法，是不是就愿意去遵守这个宪法？如果最高法院判你违宪，你是不是立刻就停止种种动作，而不是坚持自己的观点，一意孤行？将法制意识，类比到研发工作中，就是一个开发者的职业素养。在讨论架构的时候，大家各诉己见。在具体的开发过程中，是否能够严格遵守？
问：当组织架构不支持系统架构产品架构的时候有什么办法促进架构的演进和最优化？
答：这个问题，可以说很简单，也可以说很难。简单说：什么挡路就推开什么呀。既然是组织架构的问题，那就想办法改造组织架构呀。而难点在于：如果你的力量不够（不过是个架构师），你根本没有能力，改造组织架构。老板让你做个架构，你告诉他：要变革组织。你让老板怎么想？所以，问题还是回到架构师的说服力。看起来是个架构问题，其实是一个政治问题。你能不能推动某种程度上的变革？与你的手段高低，密切相关。
之前有一段时间，我很喜欢看中国改革开放的那段历史，其中推动变革的技巧，非常值得学习。
问：1）美国的架构应是其政治体制，如三权分立 州联邦 州议会选举等，而宪法应是其brd prd（业务需求文档产品文档）一类的，这些架构也早已借鉴到IT系统中，如选举、联邦等，请问下一步去中心化的架构应如何架设？ 2）IT架构的演进也如政治体制的演进，从君权神授到选举、从集权到民主，其实it的演进比政治快，请问IT架构的演进一般有什么样的节奏？3）利益各方的权衡正如性能、稳定、成本的协调，恰如云计算的发展，性能 稳定 成本可以自动动态调整，请问如何构建自适应的架构？
答：我觉得，宪法的文本，不是产品需求文档。如果一定要类比的话：独立宣言，可以算是需求文档。讨论：我们要变成什么样，人人应该生而平等。这种口号，是产品经理的活。如何落实到宪法中，是架构师的工作。
首先：我不太认同你的问题里面的潜台词：政治制度，是逐步进化的，所以君权神授之后，就应该进化到民主制度。
有两段历史，都是反方向的。一段是美国从《邦联条例》进化成《联邦宪法》，事实上权力变得更加集中了。另一段历史，我最近正在看的罗马史，也是从共和制，走向了“帝制”。不能简单说，这种演变是对还是错。但是，的确是这么变过去了。
去中心化的分布式架构，未必就是未来的架构进化方向。就好像现在大家都在聊的微服务，似乎你们的系统有100个微服务，我们的系统有1000个微服务。你们明显就不够牛。本质上，不应该追求这个。回到我的文章的第一节：重构都是被逼的，并非：有一个人人都认可的，先进的，注定正确的方向。抛开实际的业务场景，抛开具体的困难与目标，泛泛的谈架构演进的方向，是很危险的。 再聊聊演进的节奏问题，这个我现在最认同的观点，是精益企业的观点。首先有数据，然后才能正确的判断该如何演进。既然是在IT架构上谈演化，那么对于IT架构目前的现状，就完全可以不凭感觉，而是凭数据说话。
问：架构有没有不能妥协的最小原则？
答：其实，没有什么不能妥协的。只要老板还有钱，还肯让你接着弄。总是可以变来变去的。当然，这是一种很没有追求的回答。另外一个较为有深度的说法是：架构师可以有主见，但是不能有成见。所以，在我的工作中，唯一不能容忍的架构决策是：凭借猜测，做出的判断。你可以有A观点，也可以有B观点，但是你不能说：咱们试试吧，说不定这样就好了！
问： 如果一个架构团队，有一个架构师无视集体决议，利用自己编码速度快，在公司统一框架下夹带私货，如何应对？举个例子哦，其它架构师都同意把token或者权限验证签名放在HTTPheader里传递，可这个架构却把这些安全参数放在requestbody的json字符串中，并且都已经上生产环境了，其余架构是否可以强制下线该项目或功能？
答： 这个架构师，缺乏职业素养，先开掉吧。然后再慢慢的收拾他制造的残局。因为，你无法确保，他会不会做出其他出格的事情，比如拖库、删库。
问：传统企业，但由于历史原因，架构都不一样，但公司也要互联网话，公司领导也支持架构重构，人也相对够用，目前所有业务量都不算大，但对架构的基本要求，比如了扩展，高可用，稳定，监控等，重构后希望统一技术，提高开发效率，想问下这种场景下一般要怎样设计架构呢，有什么建议呢？
答：目标不应该是“互联网化”，而是“架构优化”。从实际出发，分析该如何改进。不是“以扩展、高可用、监控”，甚至容器、微服务之类的时髦词汇为目标。而是：当前的系统，有啥问题。痛点在哪里？然后，找一下业界的成熟实践，看看有没有可以引进的方案。小步慢跑，再逐步的快起来。尤其是不要心血来潮，搞休克疗法。说实话，领导支持云云，不是因为这样的改造是必须。只是因为它听起来“更先进了”。
可以简单的总结一下我的观点：设计架构，可以学习美国制宪；改造架构，可以学习中国改革。