转载

设计架构，可以学美国制宪；改造架构，可以学中国改革

2017年2月6日周一晚8点30分，GitChat团队迎来了华为公司内源社区平台架构师、开源社理事庄表伟“从美国宪法学习架构设计原则”主题交流。以下是主持人赫阳整理的问题精华，记录下了庄老师和与会者之间对代码提交的问答精彩片段。

问： 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字符串中，并且都已经上生产环境了，其余架构是否可以强制下线该项目或功能？

答：这个架构师，缺乏职业素养，先开掉吧。然后再慢慢的收拾他制造的残局。因为，你无法确保，他会不会做出其他出格的事情，比如拖库、删库。

问：传统企业，但由于历史原因，架构都不一样，但公司也要互联网话，公司领导也支持架构重构，人也相对够用，目前所有业务量都不算大，但对架构的基本要求，比如了扩展，高可用，稳定，监控等，重构后希望统一技术，提高开发效率，想问下这种场景下一般要怎样设计架构呢，有什么建议呢？

答：目标不应该是“互联网化”，而是“架构优化”。从实际出发，分析该如何改进。不是“以扩展、高可用、监控”，甚至容器、微服务之类的时髦词汇为目标。而是：当前的系统，有啥问题。痛点在哪里？然后，找一下业界的成熟实践，看看有没有可以引进的方案。小步慢跑，再逐步的快起来。尤其是不要心血来潮，搞休克疗法。说实话，领导支持云云，不是因为这样的改造是必须。只是因为它听起来“更先进了”。

可以简单的总结一下我的观点：设计架构，可以学习美国制宪；改造架构，可以学习中国改革。

在此感谢本文作者庄表伟为本场Chat的获奖读者提供了《费城风云》一书。

设计架构，可以学美国制宪；改造架构，可以学中国改革