1、至少找到2个备选方案 + 多维度对比 + 对比总结 + 最佳实践
对比维度包括但不限于：数据安全 商务合规 功能实现成本 可扩展性 稳定性（"1-5-10"）性能 安全 成本 体验 工作量投入 协同方 自闭环；
站在不同人的角度：用户、产品运营、业务BD SA、数据、测试、运维、交付、PM；
2、所谓的“必达” “XX成功率 100%” 代表着有一套完整的闭环的体系
3、作为业务应用层的“技术-应用-研发&架构”，大部分场景是“使用”技术
技术-应用-研发&架构，更多考虑是用技术去解决业务问题，考虑的是组合方案；
虽然大部分时间工作在业务应用层，但是还是要去了解掌握上下游，上到产品设计、业务、商业化，下到所依赖的中间件原理、云底座、底层网络、操作系统，不用做到源码级掌握，做到了解级、熟练的“调包侠”级即可；不懂底层原理也没关系，资源整合、组合方案也是很重要的能力；
4、所谓“设计”就是拆解问题，把一个“宏大叙事”的问题逐层拆解
比如牛逼哄哄的单元化3.0 异地多活其实拆解到最后就是跨机房调用、流量路由等等，都不是什么新的东西，都是已有的能力组件，只能难在怎么整合、攒出来一个完整的设计方案——把“高大上”的问题慢慢细化到“我行我也上”；
5、无论哪种“设计”都有缺点，只有结合业务场景才能权衡判断
6、“高并发”就是找到单点，然后改造去除单点依赖
例如网关去中心化，就是随着业务发展流量变大，网关成为了单点隐患，去中心化，就是想办法去单点；
7、“高可用”的本质就是冗余和备份
8、“稳定性”四板斧：容量、限流、预热、预案
9、耦合不可能被完全消除，只能治理为最小合理耦合
10、复杂性不会消失，只会被转移和转嫁
例如配置探针、请求搭车等一些特殊技巧，其实就是把复杂性转移到接入层和客户端，核心业务Domain里面是简单了，但是其他地方复杂了，运维交付的成本也变高了
11、所谓“设计”就是ROI 价值“取舍” Tradeoff
没有一个系统能完美解决所有问题、兼顾所有方面，但是这个“取舍”难就难在实际工作中没有所谓的一眼“正确”和“错误”的选择，只有“简单”和“困难”的选择；价值有业务价值、技术价值、阶段性价值、长期价值；
取舍的依据：概率 + 理论&实际 + 业务价值；
考虑概率的差异，不能为了1%的场景，把整个设计都搞复杂了，对于这个1%为了考虑整体方案的简单性（复杂是万恶之源，需求的复杂性、设计的复杂性等等），如果不做后果影响是什么？是否有办法（包括非技术手段）避免
12、大组织下不存在“上帝”架构师
“上帝”架构师：拥有上帝视角知道所有“屎山”设计的前世今生、面对问题能给出完整的解法
13、架构设计是向上汇报用，详细方案设计是向下开工用
架构设计是要能画出一个系统的蓝图、规划和设计，具备Lv0层的视角能力、看全局、做规划给Leader 画饼
14、“边界”就是搞清楚“谁”来怎么调用“谁“
15、决策机会是一种消耗性的非常珍贵的资源
16、所谓“设计”就是通过推演过程代替人工试错
架构师更像是一台计算设备，通过文档来驱动架构活动参与者的思想实验，通过理论推演来提升思考质量，而不是通过写代码、发布、线上试错来完成架构方案的迭代；
17、抽象会提升系统的复杂度，自动削弱系统的迭代效率和稳定性
抽象这件事情可以后置，等业务稳定了、看清楚了再说，而隔离则不能等，要尽早做，核心都在于不用过分抽象， 但必须要隔离；
18、没有架构设计最后酿成架构事故的恶果参考：yjk tianzhou zyd
发展到最后已经无法识别出关键问题，谁都无法确定是否解决这个所谓的“关键问题”就能治标治本；
19、架构设计作为0层设计需要使用对应的0层的问题考虑方式
例如站在整体层面考虑文档重新生成docUuid的问题，本质就是bizId和docUuid的一个绑定，解除绑定就可以重新生成了；从更高一层的技术层面，明确这个组件的职责边界，在更高一层的逻辑上进行思考，屏蔽多余的复杂性细节，直击方案；
设计方案讨论的时候多个问题是杂糅的，聚焦分析问题时要看单个问题，最后整体链路整体多个问题一起看；
20、好的架构设计就好比是汽车的发动机，各组件职责清晰，结构合理，高效交互协同
21、架构设计是为了解决系统复杂度不是为了追求高性能、高可用、可扩展性等单一目标
复杂度：变更放大（Change amplification），认知负荷（Cognitive load），未知的未知（Unknown unknowns）
最终决定业务处理性能的还是业务逻辑本身，业务逻辑本身没有发生大的变化下，理论上的性能是有一个上限的，系统拆分能够让性能逼近这个极限，但无法突破这个极限。
22、要对自己owner的系统有绝对的掌控度，而不是面对一些外部因素就失控
23、架构是选择的艺术，一旦选择就会预埋一些“影响深远”的东西
这些东西会在后续的流程中——设计，开发，编码，测试，交付、上线、运维、运营等“发作”
24、架构就是解决方案，解决方案是通过产品功能的组合，来解决客户特定问题的一套逻辑
25、出现一对多"1:N"依赖关系的时可以考虑加层，核心Domain内保持"1:1"的简单关系依赖
26、生产环境，核心应用Pod（8C16G）数 2W+ 小意思
27、方案设计有优点就一定有缺点，优缺点都要考虑，不要顺着别人思路被忽悠
28、动态化是最大的伪命题，集群化了就没必要再考虑动态化（by 毕大师）
29、“需要的是能走得比我们更远的人，告诉我们哪些路是错的，哪些要坚持去做——眼界、视野，抄google就对了”（by 毕大师）
30、设计需要考虑的“细节”——谁怎么调用谁、核心数据结构...，不需要考虑的细节——ORM框架是用mybatis还是hiberanate，是tk.mapper还是，mybatis-generateor ...
31、边界划分是如何最终影响效率的？
边界划分 -> 职责划分 -> 模块划分 -> ... -> 迭代开发频率、变更发布频率，最终划分的职责会影响代码层面模块、应用的划分，从而会影响业务的研发效率、发布频次等等生产效率；
32、架构设计问题识别区分是业务问题、产品问题、管理规范问题、流程机制问题 or BUG
33、对问题有一个“顶层的思路”，然后基于这个思路配套各种设施
34、设计找想法先脑暴想到啥是啥，然后“收”——可以落地么？值得落地么？
35、设计思考后一定要动手把自己想的东西、调研的东西，整理成文档写下来
不管能写成什么样子，更不要想着想着感觉进行不下去了就停了，这样的结果是啥结果都没有；写下来至少也算是一个阶段性成果，或者下个阶段的起点。
36、先自底向上、归纳演绎、足够多的用例（先用自底向上熟悉，再用自顶向下进阶处理）
37、当无法按照严格的逻辑、梳理论证的时候，“ROI”、“业务需求实践调研、总结归纳”、“设计原则”等就是帮你把逻辑圆过去的“好借口”
38、方案设计“见路不走”的本质是第一性原理 + 升高一个纬度对问题形成降维打击解决问题
一切核心就是为了更全面的思考和审视问题，扩大解空间范围，形成多个备选方案；
也不要被现状所局限，打破思维的墙，不要像现状低头：没有相关的接口，怎么才能有？能否向合作团队提需求？怎么做才更好更合理？
“见路不走”说起来简单，实际写方案的时候不知不觉就会又顺从自己的惯性思维，并且更可怕的是自己无法感知到这个惯性和墙，自己都没意识到自己处于惯性之中，需要借助外部的力量，比如他人的“一语惊醒”或者一些事件而“醍醐灌顶”、“豁然开朗”；
“见路不走”，在这棵决策树的root上去思考解决方案，而不是局限在B看不到ACD以及更高维度的解法；
39、衡量方案设计是否“假大空”的一个做法
能从0层设计推导演绎到具体的详细设计，关键细节都能识别出来，干活的同学看了方案文档知道该怎么开工干活；
40、方案设计通用逻辑推导步骤：“概念有定义、因果有逻辑”
首先明确当前所要推理的问题的重点和当前命题所在的层面，先明确这些再去继续推导；
业务现状：当前业务使用场景上的痛点，例如跳转多个系统来完成一个场景的操作；
用例：从用例反推；
业界标准：所设计的功能/系统在行业内的定义，例如OSI参考模型；
理论推导：产品基本常识+技术基本原则（设计模式，架构原则等），对做的设计进行推演；
反套：从结果逆向推，结合业务场景，看看要做些什么，具体可以从自己积累的方法论、业内的标准、目标的效果，逆向套用到现状
41、方案落地后复盘
落地后回头看一下，这个方案当时的关键设计点是否切入正确？是否有遗漏？为什么遗漏了？如果再来一次该怎么做？
42、技术方案设计实现业务功能、业务功能组成产品、产品支持业务场景、场景下最佳实践沉淀为解决方案
43、做好方案设计的前提，你要能看到“有的选”
你所在的分工的层级上，做事情的时候都是有选择的，而对应的如果你看不到有多个选项，那就说明你的视野、认知是有问题的；扩大解空间范围，让做事的时候有的选；
44、方案设计“随机应变” or “不变应万变” 的本质
本质就是：理解事物本质内核后，任何事情、各种场景都能权衡利弊、不局限于固有思维、想出最佳的解决方案
45、设计的方案要确定讨论的问题范围、功能规格、能力范围
什么做得了、什么做不了，不要给人你的方案是万能的，因为就不存在万能的方案
46、如果要进行方案评审先思考写的方案大家是否能看懂，讲方案的时候也考虑听众感受
47、方案设计一定要有一部分考虑如何“自证清白”--问题排查、可观察性、数据指标报表
48、想法这种东西是最不值钱的
其实就像马伯庸说写作这回事一样：“想法”这种东西，在落实到笔端之前，都是一团混沌暧昧的思想雾气。你只能模模糊糊地感应到随时会变化的云。你可以短暂地凝结出几句台词， 浮现出几段精妙的描写，甚至构思出一个有趣的人设或桥段，但你不可能精确地在脑海里描摹出理想作品的每一个细节。 这有点像薛定谔的猫。它只有在纸上或屏幕上被写出来的瞬间，才会坍缩成确定的、凝结的文字。你脑海中的想法才会因此固定下来，让一个故事开始生长。 无论是作品还是工作，它必须生长于坚实的土地，落根下来，而不是在虚无缥缈的云端。—— by 某位同事
49、不要“迷恋”高性能，不是“高性能”才叫技术，技术更不是只有“高性能”
不要强行迷恋单机1000+ qps，如果达不到就集群化横向扩展加机器，合理扩容是正常的解决高性能、高并发的手段；
要权衡多个维度、安心性、体验、可用性等等，实事求是的评估这些天然和性能矛盾的点到底会带来多少的性能损耗，然后放到台面上和各方势力权衡，取舍的标准就是价值和ROI最大化，例如：增加新流程新机制但是流程增加带来的rt，但rt消耗 <<< 新流程新机制带来的便利性，就还是值得搞新流程；
50、逻辑推演在方案设计中是必要的，推演的场景的广度和细节的深度构成了一棵逻辑树，这个棵树越大层次越深，证明你对事情的认知和把控越深
51、如何让自己的方案价值最大化？
1、寻找业务落地的“明星”应用场景；
2、想办法让周围人有很强的获得感，产生影响力，例如把体验上的一些小BUG修复包装成体验和效能专项上升到提高生产效率的层面去讲这个事情
52、做好依赖管理（依赖别人 and 被别人依赖）
引入依赖要谨慎，1、2、3方的依赖都很危险；
依赖的传递性，例如你本来没有被P0链路所依赖，结果首页相关业务调用你的接口了，而且还是强依赖，结果你瞬间就变成P0
53、警惕不可控的BadCase：发出去的二方包、客户端APP包、Open API规范修改
这些属于泼出去的水，一旦贸然做了，后面很难有修改的余地，例如发出去的二方包要升级，只能拉一个二方包升级群一个个人肉贴身处理；
54、方案设计完反问下自己，灵魂拷问
问题是什么？
这么做真的能解决问题吗？
谁来用，系统使用的角色是谁？
这个技术解决了业务什么问题，能给业务带来什么价值？
不做的话，最坏的影响后果是什么？
55、概念摆在同一级别去讨论，关键问题聚焦不要发散，搞清楚当前的重点
不要几件事情掺和杂糅在一起讨论，先单独讨论聚焦再联系起来看
56、明确要解决的问题，不要****认为自己要解决所有的问题
只解决确定的问题，对于其他不确定的问题可以先不实际去解，是知道后续对应的解法也是可以的，避免出现想的问题太多了，真的要解决的问题反而没解决的情况，做到了第二层“把事儿想复杂”后需要更近一步把事情想简单；
