架构应该如何来理解？ | 芋道源码 —

阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 zhuanlan.zhihu.com/p/141027477 「知乎用户G0K17q」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

最近要多带一个架构团队做一个新版本，我写一些基本逻辑来给团队建第一层策略建模，以便我们后面的讨论有基础，由于这种问题是普适的，也不会涉及什么具体的保密问题，所以我公开来写。

架构是一个充满了自由度的工作，是一个最不适合用过去的成功指导下一波策略设计的领域，无论你过去的领域和这个领域有多相像，你过去的成功经验都只能拿来参考，不适合用来拷贝。

因为即使是完全相同的领域，时间已经不同了，行业生态，技术发展已经不同了，你面对的人不同了，业务的瓶颈已经不同了，生态的各个利益体的投资已经不同了，成熟的领域人员可能减少，当初的绩优股可能已经失败，你面对的是一个新的领域，我们做架构，永远不能被过去的“定义”，左右了我们的判断。所以，做新的架构设计，你可以参考过去的成功pattern，但你的分析，必须建立在现在的条件上，不能离开对现在问题的调查，直接打算使用过去的模式。

这是我对我们进行产品战略设计的第一个建议。

架构设计是一个非常微妙的设计领域，它是完全建立在形而上的逻辑上的，它是抽象的，非具象的。但这种抽象必须要以可以实施为底线，否则就沦为纸上谈兵了。所谓高以下为基，贵以贱为本。所以，我们不要出现“架构上我们应该如何如何，但我们现在人力不足啊”这样的思维角度，这是废话，架构就是建立在准备实施这个角度上的，你不能把架构设计和实施隔离，说一堆“我们要如何如何，只是某某条件不成熟。”这样的鬼话，如果某某条件不成熟，你就不该做出这个设计来浪费我们的时间。

架构设计是实施团队的一部分，没有独立于实施的架构设计。架构设计90%的工作是辅助实施团队实施架构战略和挑战架构战略，不是实施之外的独立设计。把人分离出来是为了保证投入，不是为了让这个团队成为实施团队的竞争者。

但反过来说，你不能说我们现在只有多少多少人，我们就做一个基于现在有多少人的方案，因为事情是变化的，在架构设计初期，给你很多的人，你也用不了，人力多了是个累赘，看在财报上每个月花出去的钱就让人害怕，但如果你的设计只是现在有多少人，那后面开始展开了，你根本就发展不了。没有准备，未来有可能给你补人你也接收不了。如果人力不是这样从小到多的一个变化过程，我们也不需要架构设计，架构设计必须可以响应这种人力，资源，市场等各方面的变化。

所以，我们从一开始就做好了做这种多步的策略的打算，考虑整体目标的时候，要用整个市场域的机会作为我们发展的上限，在实施的时候，要考虑好怎么一步步增强投资者和市场的信心，从而可以有序扩大整个业务，不要用“我的架构没有错，错的是市场，错的是人力资源没给够人，错的是……”来给自己做理由。架构设计包括对这些“别人的错”的预判。架构设计和实施是和整个产品的所有其他力量（开发，销售，维护，财务，法务等等）融合在一起的，没有独立于这些开发力量的架构设计。

这是第二个建议。

但对于这个建议，我有个直接的工作技巧可以分享。当我们确切落笔写一个架构设计的时候，要考虑：以客户为目标，以工程为准绳。

什么意思呢？就是说，你在架构设计的第一个部分，要明确说你打算卖一个什么样的东西到市场上去，你的客户打算买你的东西，这个决定的控制要素是什么？有这样一个标准在最前面，我们中间的所有变化，遇到的障碍，我们都知道往哪里绕。也知道我们绕完了，应该继续向什么方向走。

而在你的架构设计的最后一段，你要把你的所有设计落实为“版本”和“项目”。所有的人力管理，都是以项目为基础的，因为项目有确切的目标和人力资源投入，而不是“小李你去帮帮他们”这种尽力而为的东西，架构策略一旦展开，所有人都会面对无限的要求，没有确切的资源分割，凡是长远的东西都会被忽略和放弃。所以，要把架构策略得以实施的希望建立在人力资源管理上，不要建立在“期望”，“正义”，“道德”，“道理”这些依赖上。所谓子非不辨也，老子忙起来谁都不认也。

当然，我这里说的项目，是广义的项目，不一定是你流程中说的那个项目。

而项目，要输出确切的版本，你有硬件，有软件，有插件，这些都是有版本的，不要说什么做一个my-wonderful-app，里面支持这特性，那特性的。

你的软件上了市场，遇到一堆的客户，这些客户的要求都会不一样，你是用一个版本还是用多个版本去响应他们？产品是会有Bug的，是要有新特性开发的，修复Bug和增加新特性是会引入新的Bug的，所以，客户可能可以接纳升级你修复他的Bug的版本，可不一定肯接纳你发布的修复其他人问题的版本的。

这样，你在市场上就会有很多版本，这是天然的，版本一多，开发，测试，维护，管理的成本会大幅上升，这是一个重要的工程控制要素。你用my-wonderful-app这一个概念来考虑你的设计，你实施的时候就会怎么搞怎么不正常，因为你以为你开发的是my-wonderful-app，其实你开发的是my-wonderful-app-v1、my-wonderful_app-v2、my-wonderful-app-v2.1、my-wounderful-app-v2.1-without-tso-llvm_v7_specific-edition……你对人力和项目的预判都是错误的，当然执行不下去了。

所以，很多人其实不明白“开源交付”是个什么东西，开源交付其实是一种减少版本的方法，一个源代码树是可以编译出很多二进制版本的，我给你源代码，编译产生多个版本的的维护成本就是你的了，很多人以为交付源代码是对用户友好，是为行业做贡献——那得看客户是想当你的竞争对手，还是想解决他的问题了。（但即使你用“源代码交付”，如果是商业交付，你的测试还是需要落实到一组二进制版本上的，而且你必须很清楚，这些二进制版本都是会升级的，死版本支持的生态是死的生态）

但无论如何，架构设计一个基本的要求，高以下为基，不要离开你的工程成本想得天花乱坠，只要涉及工程，什么美好想法都得给我从天上掉下来。

第三个建议：调查和设计也是要结合起来的。架构设计初期，我们有无数的“未知”：竞争对手的战略是什么？客户的期望是什么？研究机构有什么新的突破？市场份额的预测是什么？国家政策的走向是什么？……

如果你要调查完这些东西才做决定，你就永远都不用做了。所以，进行架构设计，要勇敢进行“猜”，“预判”，哪怕错了，你也要“猜”，因为这是架构设计工作的基础。你的决策要同时决策：使用猜这个结论和再调查一下，哪个投资收益比更低？然后就要去实施。我在这个专栏中经常强调“守弱”，其本质就是这个：架构本身就是一种猜，我们在猜的基础上执行，如果你非要维护面子，在执行的时候收到当时猜错了的反馈，你死要面子不肯调整，那这个架构执行就失败了。

所以，做架构不能要面子，你眼中只能有产品的最后成功，到成功的时候，你坐在那里，旁边的人说什么，你都可以冷冷看着他，由他讲他的道理，你根本不用在乎。

这样就要提到第四个建议了：你不要指望实施团队会很喜欢你，你做的所有事情，都是为了未来让他们“绕路”走，你的结论他们不会喜欢的。你可以用你所有的个人魅力去尽量soften这种冲突，你可以下去和他们一起分担开发调试的压力，让他们没有那么恨你，但你要知道，如果实施团队很舒服，你的架构设计肯定变成在旁边说胡话了，根本没有设计效果。

所以，你决定来做架构了，就不要期望你有多nice。这是这个工作的特性，不能调和的。不要为了实施团队的一般抱怨就去改变你的设计去迎合，否则产品失败的时候，就没有人跟你抱怨了。吾之所以有大患者，为吾有身，及吾无身，何患之有？你应该多听实施团队的抱怨，但你要分清楚哪些是真正在反馈问题，哪些只是你战略实施的成本。

最后一个建议：架构团队来自不同的领域，不要用“领域代表”看待自己。不要说我只是做芯片设计，我只是做安全的，我只是做内核的，我只是做数据库的。架构团队存在的目的，就是为了设计那些多个模块互相甩锅的Gap，然后所有模块和协同起来，达到最优的效率。你尽然进来架构组了，你就不是某个模块的“甩锅代表”，你就是整个产品。

大部分投资者都是不懂技术的，就算他们来自技术背景，他们对你实施的这个技术也是外行，因为细节只是我们知道，否则他就不用你来做了，他自己做就好了。这些人决策的方式就是“多方确认”。

如果架构组自己都达不成共识，各说各话，那怎么说服投资人（其实包括准备用你的客户），所以，架构组每个人都应该对整个架构策略都很熟悉。我不要求做芯片的人就会写程序，但我需要做芯片的人知道软件部分的构架要求，在解决方案中所处的地位。你不要告诉我你只懂UEFI，不懂Kernel是怎么做的，我需要你知道ACPI表那些信息是给Kernel的哪个模块看的，你不是在做实施，等着别人给要求，你是那个负责知道少给一张EINJ表，Kernel会不会起不来的人。

推广起来说，作为一个产品的架构团队，你也不能只管“我的产品如何如何”，你必须从整个产业生态上开始设计。狼吃羊，羊吃草，你不能说你是狼，不管羊的死活。没有羊了，狼也死了。做架构设计的人，必须知道狼可以吃多少羊，吃到什么时候就要开始收手了。

所以，对于一个产品的架构师，必须知道整个生态链是怎么运作的，要为了整个生态的平衡，不怕把自己部分自己的业务让给其他产品，其他企业，也不怕自己背上别人不肯实施的业务，这样你才会有掌控生态的力量。

大概就是这样一些吧，再往下，就是具体业务怎么做的问题的。但当我们碰到困难的时候，不妨回头来看看我们的总体思路，也许觉得无路走的时候又发现有路了，觉得很顺利的时候，说不定就是危机的开始了。