软件架构本身是一个宏大的概念或命题，但历经过往种种，开始有些思考在脑海中，挥之不去，在此整理出来，和大家一道探寻，这是一篇关于“类比”的探寻。（鉴于笔者主要涉猎业务软件研发，本文也仅限于对业务软件的探讨范围）
业务软件架构，建筑学的“类比”
架构，乍一看很熟悉，但越看会越觉得陌生...计算机领域的architecture，源于建筑领域。提到建筑，虽然我们不是业内人，甚至砖都没真正搬过，但毕竟我们的住所，出入各种各样的建筑物，也随处可见的建筑工地、规划图，以及这个时代几乎每个人都悉心研究过的各种“户型图”...顿觉“架构”这个概念亲切起来，软件架构于建筑，实在是一个从根上就非常契合的类比了。有本《表象与本质》的书，副标题是“类比，思考之源与思维之火”（Analogy as the fuel and fire of thinking），深以为然。
沿着这个类比，我们大致模拟“架构”一个软件系统的过程：设计一栋“xx系统”的“建筑”，首先明确它的使用目的（业务目的），以及基于此进行需求分析与拆解：
- 给哪一类人（角色），在什么场景下“使用”；
- 需要哪些功能（区域）的划分，以及进一步的子划分；
- 有哪一些具体的“业务要求”或“喜好”，包括样式（界面）、功能、使用流程（动静分离？干湿分区？）；
- 涉及到用户的容量，访问（入户）方式等等也需要明确；
- 与使用场景匹配的能源的供给与消费（水电煤）、信息通路的搭建与呈现（网络，终端），数据（物品？）存取空间要求...
- 安全使用（居住）相关的需求，包括防火墙、用户识别、访问控制（门、锁、烟感，摄像头，报警...）
- 基于需求设计“架构”,并进一步更加具体方案的分析设计：
- 根据一系列条件和约束确定部署架构（周围环境）；
- 领域系分设计（功能到空间实现转换）；
- 内部的交互设计（内部互通）；
- 外部交互接口（能源、网络等的入与出）；
- 基于具体的功能与非功能需求，结合约束条件，确定包括语言、中间件、脚手架等（各种材质），确定系统内部分包分层（具体实施工艺）...；
- ...
方案反复评审，实施队伍进场，“挖坑”、“打桩”、“灌浆”...验收上线，用户开量（入住）。
完美的类比！
- 建筑学本身发展到今天，已纷繁复杂，蔚为大观，远不是文中提及如此“简单”。但主体实施脉络相对明晰且标准，尤其涉及到建筑方案的设计流程：设计任务书，建筑方案设计，初步设计，施工图设计...，贯穿始终的原则有：确定、精确、可实施；
- 曾经业务软件也流行采用“瀑布式”研发模式，其某种程度上借鉴了建筑工程等领域的思想，包含了问题定义、需求分析、软件设计、程序编码、软件测试、运行维护等软件开发的完整生命周期，对相对“面向确定性”的软件架构与研发过程的控制起到了关键作用；
图来自：TOGAF之ADM(Architecture Development Method)-有建筑那味儿
等等，故事还没结束...
业主入住不久后，添丁加口了，养了条狗，男主人最近领了个package回来要搞个工作室准备自己单干，物质生活越来越丰富，各种奇形怪状的物品需要放置并按需存取，或房子卖了换了户人要开私房菜...
- 方案1：把原来的客厅整修一下，用作它途（把原来的某个系统职责换掉？它还是它吗？）
- 方案2：把房子推翻重来（这个味道很熟悉）；
- 方案3：换房（也不陌生）；
这是业务系统经常面临的课题：需求变更。
对建筑而言，一旦建成就稳在那里了，对应的需求相对也比较“稳定”（毕竟不是天天添丁加口），即使拥有者需求偶尔变化，往往也可以“凑活”（毕竟也不可能天天拆房）。但软件系统，常常面临的是频繁的，甚至无法预期的需求变化，而要求响应的要求也可能极高--某国某支付类业务，监管突然下达整改通知，原有业务规则需要尽快（一周？）调整，否则业务下架，甚至影响整个公司在该国开展的所有业务（似曾相识）。
今天（尤其我们交付人）涉及的很多业务系统包括建设过程，面临的最大挑战（似乎没有之一）就是不确定性，客户“意愿”的不确定性，用户诉求的不确定，所处环境的不确定性（基础设施，外部依赖等)...这些不确定性往往外化或体现出来就是“需求变更”。按照建筑“架构”的思维类比，应对起来显而易见的吃力，再深入探寻一下。
一个实例化（运行着的）的软件系统，对应的支撑着一群人或组织的业务，随业务而生，随业务发展而发展，壮大而壮大，消亡而消亡...在此过程中，与之相关的如所使用的技术、所处的环境等也在相应的主动或被动的变化中，以满足或适应着变化；
其状态（无论整体的状态，还是拆解到某些部分的状态）和业务息息相关。当业务停掉，往往这个系统（至少某些服务）就能停掉，反过来系统停掉（挖断网线...)，业务也随之停滞；
相对优秀的系统，其所能承载的容量和并发度等相比较“建筑”而言，具有“弹性”， 能以相对极快的速度进行弹缩，承载极短时间内容量变化的冲击；有“韧性”：具有感知和容错能力，除了常规能探知访问量，访问行为，耗时等以外，还能够“觉察”敏感甚至恶意访问行为，并做出相应的拦截、控制、反馈等；更进一步的，可基于相关信息以及持续学习，触发“自愈”....
在阿里集团内持续的架构演进，主动或被动的应对着预期、突发、业务、技术等方方面面的各种变化与不确定性，我们与充满浓浓“建筑工程味”的“确定性”架构理念似乎开始渐行渐远，不仅如此，我们在全面探索拥抱“VUCA(volatility,uncertainty,complexity,ambiguity）”。我们长成了蚂蚁的庞大架构体系，长出了星环，端点等一系列优秀而庞大的“超级物种”。
回到交付场景中，面临千差万别的行业、形形色色的客户、多种多样的诉求时，我们努力圈定并控制需求范围，拆解、分析、设计方案，控制不确定性...有些场景我们应对下来了，项目成功“验收”，结果不错；有些场景则应对得非常吃力（曾经有个项目，由于需求变更非常不可控，一些非常基础但关键的需求点的变化导致整体技术架构方案大变，研发团队大半年内多次组织加班冲刺，但很多阶段性结果依然不理想。我们戏谑自己的三部曲：“随机化需求，常规化冲刺，规模化暴雷”...最终靠一群靠谱的兄弟硬顶住了），这背后似乎都是“需求变更”的锅。
“需求这么简单，设计这个方案，会不会过度设计”
“这是我们在集团的方案，灵活且强大，但改造成本太大，不同意用”
“隔了三个月，客户自己的决策，为什么就变了呢，签字画押都不管用”
“我们早说过这个方案要做灵活一点，结果简单写死，现在业务规则变了，改造成本极大且风险不可控，只能推到重来”
“客户的这个系统做了几期，每次都是换一拨人推到重来，为什么不考虑演进呢”
“我们做了这么多项目，沉淀和积累到底在哪里”
...
类比“建筑工程”，专业、严谨，分期、分阶段...，但以上类似声音并不鲜见，也时刻困扰着我自己，尤其作为架构设计者和实施参与者，“被锤”多次后，不免陷入苦苦思索：针对这些问题，有没有其他类比能为“我”所用，进一步更好的启发和指导我们的架构工作？面对不确定性，“架构设计思考的燃料和火焰在哪里？”
关于有机体的架构启示
维基百科：
an organism is any organic, living system that functions as an individual entity... All types of organisms are capable of reproduction, growth and development, maintenance, and some degree of response to stimuli.
“有机体”，尤其这些关键属性：“整体”、“活”、“成长”、“发展”、“维持”，面对“刺激”的“反应”，能否将其类比映射到业务系统，对我们的架构设计与实施工作带来一些新的“思维的火”？
- “有机体”或“生命”，其实质还是由基本元素所构成，其物质、能量、信息等存储、处理、交换，本质上是靠“物理现象”或“化学反应”的有序编排：如食物分解，能量存储、转化、消耗，神经指令的传导和刺激，记忆的存取...
架构启示：无论一个多么复杂的系统，其实现机制始终建立在基础技术之上。Be Back to Basic。
- 有机体从简单开始生长，越来越复杂。当发展成熟，稳定一阶段后，一定会衰退，消亡。积极来讲，每个有机体或生命个体都应存在某种“使命”或“意义”，其消亡也往往意味着“使命”的终结，但一个健康周期长，生命力旺盛的有机体一定能更好、更长久的完成其“使命”；
架构启示：业务系统的生命周期存在客观规律
a 当业务成长时，业务系统伴随成长，这个过程可能因为业务本身的节奏快慢而加速或减速，但从客观规律看，某些阶段难以逾越；
b 持续维护和治理好系统，对业务的支撑具有现实意义；
c 理性看待系统的衰退和消亡；
- 有机体成长过程中，会逐步建立、完善自身免疫体系，应对内外部风险的能力不断增强。常常也因为突发风险，导致非正常衰退或消亡，以至于无法正常完成其“使命”。
架构启示：架构治理与稳定性能力建设是实现业务价值的基础
a 系统伴随业务成长期间，其治理工作非常关键，需要有机制及时发现自身的腐化或缺陷，并积极干预，避免自我崩溃，即做好“架构治理”工作；
b 系统的问题发现、监控、告警、自愈等能力有必要结合其所处环境提前规划和实施，以应对各种风险，即构建系统稳定性相关能力；
- 特定物种在特定环境的生态链中有其特定的位置，特定的“使命”；向新生态或环境移植，往往具有高度的风险和不确定性；
架构启示：系统应明确定位，在合适的位置生长和发挥作用
a 确定系统的定位（species），所有要面临、解决的问题应与其定位相对应；
b 基于对业务发展和环境的预判，提前做能力的规划和准备；
c 慎重对待系统的“移植”：在考虑系统业务能力的基础上，同时考虑环境相容性；
...
沿着这个方向探寻
本质上讲，将架构业务系统类比“架构”有机体，相对于类比架构一栋建筑（无论这个建筑多么简单或复杂），最本质的不同在于，我们试图将系统看做一个“活”的充满生机的对象，而不是杵在原地的一堆物质（无论形式上这个死物可能多么复杂，充满工程结构之美）；这样去看系统从简单到复杂，持续不断的更迭，腐化、消亡...等等现象，瞬间变得自然顺畅。
回到“建筑”的类比时遇到的难题或困惑，从“有机”架构的角度考虑，应对基于系统定位的、一定程度的不确定性变得理所因当：当业务的诉求在系统定位的所属范畴，系统有义务、也应该有能力承担对应的诉求；一旦诉求变得越来越复杂，我们有必要去思考系统自身的生长、以及基于系统所属“领域”（类比种群？）的分化（种群内新物种的诞生机会）；但如果诉求已经明显偏离系统定位，我们有理由去分析和决策：当前系统无法有效承载该诉求，我们需要新的系统（全新的物种）；
面向“失败”来架构系统也是“有机”架构的应有之意：我们难以预知外部风险，甚至很难判断系统自身的“腐化”或其他不可知行为所带来的风险，因此一方面有必要不断投入架构治理，控制系统腐化，另一方面持续投入感知异常、发现异常、应对异常（可监控、可发现、可应急不仅仅是针对“变更”的三板斧）能力，并考虑免疫能力（系统自愈等）的建设；
我们需基于系统定位，一定程度上预判环境与业务发展趋势，提前规划，做面向未来的架构。如果一个系统总是在被救火，那它很可能活不长，或者可能根本就没有活过，只是“一栋失修的建筑”而已；
沿着这个方向思索越多，越觉得有趣（很多时候，有趣比有逻辑更重要）。但此时此刻不免要思考一下，这中间有没有什么逻辑，来支撑这个方向？否则光剩下有趣了。
现代计算机，本质上是“图灵机”（https://en.wikipedia.org/wiki/Turing_machine），其解决的是一切“可计算问题”。如限定探讨范围是“业务系统”，那它面临的命题是：对业务中的一切可计算问题的解决。而在这之前还有一个更关键的命题：业务的“可计算问题”的识别与定义。整体上可以看做以下三阶段：
业务--人或组织的生产经营活动，贯穿人类社会发展全生命周期。在业务活动参与中，计算机从一开始辅助人，发展到替代人，并逐步开始在很多方面超越人，本质是业务活动中“人”的经验知识应用。即任何业务系统，可尝试描述为：代替业务组织（中的某些人，通常是业务专家）进行信息接收、处置、表达（执行）。亦或通俗来讲，当用户在与业务软件进行交互时，就是在与一群“业务专家”交互。
以某商户签约某支付平台在某国的支付业务为例：
- Step1: 小二准备好商户材料，注册登录到入驻平台系统，首先“面对”一个业务审核专家（一系列规则检查逻辑，这些规则是基于所在国家法律法规、业务类型、业务规模、商户所属行业分类等多方面专家知识的“可计算”表达）：告知（通过动态化表单）小二需提供的材料，并加以审核；
- Step2: 初审通过，进入安全专家审核阶段（安全扫描引擎，基于客户信息，同时通过其他合法渠道、匹配获取客户相关背景信息，判断材料与相关信息有效性，进行业务安全风险等级评估）
- Step3: 根据需要，流程到反洗钱专家审核阶段（反洗钱审核，系统引擎+专家实审结合等）...
- Step4: 产品专家结合前期各种审核评估结果，开通相关产品服务能力，并告知小二（或因审核不通过，驳回申请）
从这个实际case可以更加清晰的看到，我们的系统从业务视角来看，本质上和“人”可以互相替换的。
在实际演进这个系统过程中，我们大约经历了以下阶段：
- Phase1：业务起步，没有“引擎”也没有“动态化”，从前端表单的设计到后端服务以及模型的设计实现一捅到底，快速迭代上线第一个版本；
- Phase2：业务复杂起来，某些国家的业务风险也越来越高，业务审核团队（Step1）和风控团队（Step2）等开始介入，进行人工审核，系统相应的开始分化， 并接入了叫做“流程引擎”的东西；
- Phase3：业务类型越来越多，需要支持的国家地区也多了起来，风控团队人力开始吃不消，于是考虑为Step2提速（接入安全引擎，大部分机审，随着引擎能力的进化，越来越少人审）；
- Phase4：业务类型和覆盖国家地区越来越多，且相关国家地区业务规则、法律法规变化越来越频繁（逆全球化背景），系统最初的表单、内部的信息交互服务、包括各个业务节点传递的信息规则频繁变化，系统变更成本渐渐吃不消（主要是有点废程序员），于是开始系统从前到后的动态化改造，支持从信息提交、到审核、到业务开通全链路动态化可配置；
用“有机架构”的思维来看整个过程，我们隐约看到系统背后，一些替代“人类专家”的“有机体”的存在--最初，背后真的是活生生的人。我们也看到了这些“有机体”在不断成长，相关能力不断强大、成熟。我们还看到类似人类社会的分工在软件系统中的加速出现。但同时，我们也看到这中间的“确定性”：这些有机体背后的专家角色，以及对应的专家知识的沉淀、积累，实体化到系统中成为了模型、规则、逻辑、流程...等“可计算”的形式。
探讨这个例子，是想试图从逻辑上论述（还谈不上严密的论证）一个事实：业务系统其“本质”，是人或组织在业务活动中所总结和沉淀的“专家知识”（结构化业务知识与规则）与“意志”（基于信息与规则的决策）的聚合体现。如果这个事实成立，那说明我们将业务系统作为一个“在业务场景中、可在一定程度上替代人的有机体”也合乎逻辑。
回到“有机架构”的思维上，如果我们在一开始就更多的去思考我们这个“有机体”或与之相关的“种群”，在所处环境、所处生态圈中处于什么位置，在所处生态链中处于哪些节点，我们更多的去思考它们所要去替代的“专家角色”类型，专业知识扩展和变化的维度、范围、频率等规律...我想应该会少走弯路，我们也会更加从容的应对整个系统的生长、演进历程。
有机架构思维对架构工作的指导
通过“有机物“的类比，前面罗列了一些“架构工作的启示”；通过进一步的探讨和思考，尝试总结一下：
- 架构工作需要遵循“时间”规律，敬畏客观规律：
- 架构的演进节奏，应该与业务的发展节奏有个相对匹配的关系，不要轻易过度设计，尤其涉及到系统拆分（新物种的诞生）；
- 架构工作要回顾过去（持续做总结、reivew），把控现在（维护架构基线），更要面向未来（基于系统定位，前瞻业务，提前规划）；
- 客观看待系统的消亡和被替代。
- 架构工作需要明确各方面的定位，尊重专业性：
- 首先需要确定所架构系统在业务中的位置，由此确定面临的业务问题域，抽象转化为“可计算问题”再加以解决；
- 具体从业务、到领域、到具体系统、到具体的运行调度单元，应各司其职，各守其位。这需要相对准确的“纵向”维度的职责拆解，不要轻易用“细胞”的方案，跨越“维度”直接去解“系统”的问题（熟悉的味道...）；
- 横向来讲，系统本身与其他系统，模块与其他模块，各领域之间职责同样需要清晰明确，不轻易“跨域”解问题，要么不要分化，要么就分彻底，“跨物种”违背生物的基本规律；
- 明确“有机”和“无机”的边界，沉淀确定性，拥抱不确定性：
- 业务系统，“有机”的部分，本质上是业务知识的“数字化表达”，核心包括业务的模型、业务关系、业务流程、业务规则约束，这一部分与业务强相关，随着业务变化而变化，值得持续抽象沉淀，也能够作为专家知识在同类业务系统中迁移和复用；
- “无机”的部分主要涵盖通用的、关于信息传递、存取、通用逻辑计算交互等部分，包括硬件、语言、中间件等（对应有机体内物理、化学作用的驾驭能力），也包含各种工具集、引擎；我们需要有充分驾驭这个部分的能力，同时考虑尽可能“声明式”的去对接，而不是和有机部分纠缠；
- 打牢基础，面向“失败”架构系统：
- 稳定性建设，只要成本允许，在满足业务的基础上，怎么投入都不为过（锻炼好身体，以备不时之需）；
- 架构治理是一个持续的过程，不对系统盲目自信，不轻易忽略“腐化”的部分；
- 慎待“复用”：
- 对系统的复用，本质上是“物种迁移”，需悉心评估目标环境，包括系统与其他系统，在职责链上的冲突与相容（这背后往往意味着目标环境人与组织的权责利的相互影响），确保系统存活且发挥价值；
- 对系统中模块或组件的复用，提倡系统“有机部分”的（业务模型、业务规则、业务流程、业务关系）复用，这些是沉淀的专家经验，代表相对“恒久”的领域知识，我们应该有充分信心。但我们需要谨慎评估“模块或组件”整体的复用，这里面包含了“无机”的部分，包括各种接口协议、数据协议的适配，监控体系的适配，工具集的适配等，这本质上类似“器官移植”，不要指望一个复杂系统上长出的“完整器官”能简单移植到一个简单系统中并发挥想象中强大的作用。
- 关于系统复杂度控制
- 业务的复杂化，应该类比“有机体”的生长，这种“生长”可能对应着业务本身的生长，也可能对应着我们自身对业务的理解越来越深刻；这种生长面向未来，我们重点需要控制的是“速度”，使其能匹配环境中的业务活动所处阶段；换言之，控制好节奏，这个“复杂度”就是健康的，代表着业务本质的复杂度生长；
- 相对“无机”部分的技术方案的变化，则不能孤立或简单的看做“生长”，应该理解为“替代”或“替换”比较恰当（有些时候，用看似low的技术方案来解决业务生长的问题可能更加优雅）；我们需要关注的应该是有效性，容易驾驭和维护；
...
用看待鲜活“生命”的方式，去看待所架构的系统，去热爱它。
面向未来：“云巧”
云巧，是我们目前和生态伙伴们一起持续建设的方向，也是“可组装式应用”理念真正意义上的产业化实践。个人认为，如果用有机架构思维来类比，云巧今天在做的事情，很像“生物工程”在做的事情：
在“数字化生态”的每时每刻，有无数的系统新生、成长，分化，变异，消亡...在没有云巧时，这些曲曲折折的经历除了亲历者脑中的记忆，其实“活过”或“活着”的很多信息都很大程度上遗失了--后来者很难理解，为什么在某个特定行业的业务场景中，某个模型（例如“红包”）长什么样或为什么要长这个样，而可能之前在具体项目中，业务专家和客户为此反复探讨和纠结，才最终有了这份“充满专家知识的数字化DNA”。
通过云巧这个平台，生态中每个项目的亲历者（如架构师等）都可以将所涉及的“业务”系统的数字化DNA打磨、沉淀下来。平台提供了一系列工具（云巧工坊）来支持沉淀，一簇标准（云巧组件标准）来为这些DNA的健康度进行评估打分。同时，平台还提供了“克隆”的机制以及相关能力，支持这些数字化DNA在新环境中高效下行落地落地，通过适当的改造（更多是对“无机部分”的适应性改造），激活新的环境中“新的生命”。
在这个意义上讲，云巧，应该是数字化生态中一个高质量的基因库。
如果要加速这个星球上数字化生态的建设，我想不出还有比这更加符合逻辑、更加美妙的方案。从某种意义来讲，云巧是契合“自然之道”的。
后记
再谈“建筑”的类比
在工具软件、嵌入式软件等领域，可能“建筑”工程的方式是更适合的，本质上讲，这些软件并不是“人”的替代，而是作为生产活动的器具或资料所存在，这个意义上和“建筑”没有差别：我们无法用人来代替建筑或用建筑替代人。
工具到业务的通路：当一个工具（或工具代表的生产过程）足够复杂，在人类生产活动中开始出现分工，需要新的“主体”带着专业知识参与时，这个原来仅仅靠个人拿着“工具”从事的生产活动，就演变成了基于“社会分工”的“生产经营活动”，也即“业务”，原来工具软件的内核演变（析构）为业务系统中的专业知识。
关于数字化现状的“某些诉求”探讨
当前在很多数字化场景中，其实将业务系统“工具化”、“无机化”比较常见：客户希望我们交付一个类似于excel的，但可以支持用户并行协同的“分布式工具软件”。这套工具软件能严格按照一定的功能集输出，而且“刚好”能满足他们的诉求，解决他们的问题，同时他们的诉求“似乎”也相对稳定不变。
他们的组织人员最终相对的，固定在这套工具平台上，完成各自的工作，“静好而安稳”。
逻辑上也是通的，无关对错，关键是意识到、并清晰的将这种系统定位为“工具软件”，不论它披上了多么华丽的外衣。
关于业务软件这种“有机体”的“意识”
开个脑洞。前面的讨论更多在“人”的视角，去看待系统，觉得是“人”（比如程序员，架构师，客户或用户等等）在向系统不断的“注入”知识和意志，然后塑造或创造业务系统这一类“生命”；但反过来想一想：如果系统是有意识的，或者在更大的视角下存在某种意识，它在利用业务，牵引着“人”去做所有的这些努力...这个想法也不仅仅只有有趣，至少它能够提醒我们，不轻易扮演“上帝”，心怀谦卑的做好这些工作，因为真相也许，在某种程度上，是我们在一直“被塑造”。
