如何自底向上推导应用逻辑架构？
一、什么是架构？
对于架构的理解，每一个结构师都有一个认知丰富的过程，从企业架构的角度来看，架构可以分为业务架构、应用架构、数据架构、技术架构这几个细分类型。
既然知道自己不知道了，那么就是要追寻它，曾经我和不少业务的研发同学讨论过架构是什么，撇去基础设施架构和物理架构等视角不谈（这些视角聊起来也是篇幅很长的），我挑应用逻辑架构并从几个角度来尝试描述一下：
1.从架构的总原则的角度：尽可能简单（在当前场景下要尽可能简单便于扩展和维护），但是不能太简单（相对而言太过于简单可能在场景上有所遗漏）；
2.从架构的目的角度来考虑：既要解决过去的问题，也要解决现在的问题，还能适度解决未来的问题，这些问题既包含技术问题，更包含业务问题；
3.从形态之2维的角度来考虑：架构就是横的问题，和竖的问题。横就是分层，竖就是分区，横竖都有抽象的事情要做；
4.从形态之3维的角度来考虑：架构是三维的，在x轴和y轴上有横竖的问题，在z轴上还有粒度的问题；
5.从时间轴的角度来考虑：架构不是一层不变的，是随着业务的发展在不断变化的。
对于架构的理解，需要在特定事物的视角进行看待，虽然我试图从以上几个视角对架构进行了描述，但是显然这些描述都不够全面，都是从某个角度来看架构。从内心里我自己觉得自己的这个提炼的高度是不够的，从实践中的总结必须和业界的知识结合起来，我必须学习前人已经总结的体系。于是在不断的搜集资料的过程中，我发现在ISO/IEC 42010:20072中对架构有如下定义：
这个最顶层抽象我个人觉得非常到位，根据这个定义，显然，我们在架构中需要：
- 职责明确的模块或者组件
- 组件直接的关联关系非常明确
- 需要有约束和指导原则
这个架构的定义很简练，很实在。小到一个玩具，大到一个国家的运作都可以隐含着这样的内容。
但这是一个广义上定义的架构，经过一些总结思考，我觉得实际上具体到我们日常的工作中，在不同的层次，会有更加精细化的架构分类。
二、架构有哪些分类?
在工作中我遇到不同的职位的人从不同的角度来描述架构，但是我们鲜有能达成共识，刚开始我也不知道为啥讨论不到一块去，后来我经过一段时间的纠结和深入仔细的思考后，发现很多时候大家描述的架构都不是同一个角度的东西，于是我尝试从如下几个角度划分架构的类别，以帮助我们在不同的场景和不同的人聊天时大家可以聚焦，明确我们到底是在讨论哪种架构，以提升沟通效率，并尽快达成共识，目前这个划分已经在我们团队基本达成共识。
值得注意的是，不管下面哪种分类的架构，都符合上一节总的架构的定义：模块（组件）+ 关系 + 约束&原则。
产品功能架构 这个是产品经理最喜欢讲的架构，一般来说，讲我们有什么功能的时候，产品功能架构描述的是能做什么，受众群体一般是使用产品的同学。如果我们做软件设计时，不应该产出这玩意，而是应该产出应用逻辑架构和应用物理架构。但是一旦我们要对外宣讲我们的产品，比如我们的接口有啥用，应该怎么用，这个时候我们讲的应该是产品功能架构。
目的：指导用户使用产品，所以模块的聚合是从用户视角出发的
受众：使用产品的人
包含的内容：阐述产品个功能模块的能力：比如一辆汽车，方向盘有什么功能，方向盘的按钮上各区域的功能是什么，仪表盘分成哪些功能模块，每个功能模块有什么作用，油门踏板有什么作用，刹车踏板有什么作用。但是也不排除有些高阶用户需要明确知道变速箱的齿比等信息，所以在产品功能架构图上也可以描绘出来
命名：这里命名需要考虑如何取一个吸引人的名字（同时又能表达产品的能力）来吸引我们的用户前来使用，比如说以前经常有产品套用“纳米”，又有产品套用“绿色”等等。
业务能力架构 用来分析业务，业务概念架构是指拥有哪些业务模块，且各自的能力是什么，这张图有助于我们分析和理解业务需求，也有利于产品经理分析业务。所以业务概念架构和业务概念模型都是用在分析阶段。
目的：研发人员和业务人员理解业务内在的概念和联系
受众：研发人员和业务人员，主要是给规划业务的人使用
包含的内容：业务能力，能力中的子能力
应用逻辑架构 软件设计本身，模块，粒度，职责，复用，等等，在讲解软件设计的时候，使用的是这个架构图，这个架构图是通过系统模型和业务概念架构推导而来。所以系统模型和应用逻辑架构都是用在软件设计阶段。
目的：指导软件的研发
受众：研发人员，各层级架构师，各层级技术管理者
包含的内容：阐述架构中各模块的职责：如系统模型，技术模块，技术模块的关系，技术模块的核心抽象，如何用设计模式来让架构符合软件设计原则，等等。如果拿汽车举例，那就是发动机模块中包含了哪些子模块（活塞，曲轴，连杆，缸体，缸盖，等等）发动机模块和变速箱模块之间的关联关系是什么，如何协同工作，和底盘的关联关系是什么，如何协同工作。发动机，底盘，变速箱，电子系统在整辆汽车中的职责，关系，约束是什么。这些都是用来指导汽车研发的。而不是指导用户如何使用这辆汽车的。
命名：这里的命名需要朴实无华，精准的描述出职责，华而不实反而让技术的同学无法理解这到底是什么玩意，导致实施的时候职责放错地方，挖下大坑让后人来填。
应用物理（部署）架构 软件部署时的架构，这张图推导自应用逻辑架构，推导时重点逻辑架构如何落地，比如使用何种微服务容器，逻辑架构的模块落地时应该是package，还是应用，也有可能是一组应用，是不是要跨机房部署，甚至跨国部署等等。还需要考虑稳定性，性能，成本等话题。
基础设施架构 选择什么样的中间件，存储，监控，报警，等等之类和
三、能力和职责的区别
在日常的架构讨论中，有的同学经常谈架构的能力，有的同学经常谈架构的职责，那么能力和职责有什么区别？跟产品的同学打交道多了之后，发现产品同学很多都是讲能力，后来技术的同学也开始讲能力，而通常我们架构的同学原来讲的都是职责，两者有什么区别呢，我说说自己的理解：
1.能力（产品功能模块的能力）：是指一个产品能做什么，比如中台本身是一个产品，对使用中台的同学来说，我们应该讲中台的能力（其实是在讲中台这个产品的能力）。所以讲能力是讲给架构的使用者或者其他想了解的人来听的。
2.职责（逻辑架构中各模块的职责）：是指架构内模块的职责，用来指导开发，比如中台研发的同学，应该讲架构的职责，依赖，约束。所以讲职责是讲给研发的同学，讲给域内的架构师，讲给域内的管理者来听的，总的来说就是讲给架构的实现者来说的。
简单来说就是：能力是指产品的能力，职责是指架构内部的职责。如果架构本身也是一个产品需对外输出（如中台，或者其他技术框架作为产品输出），则对外输出时，我们应该讲这个技术产品的能力（这个时候技术的同学也就开始讲能力了）。所以当我们讨论问题的时候，如果有的人在谈产品能力，有人在谈架构内部职责，那么显然已经不是在讨论同一个话题了，请大家务必注意区分这种情况，差之毫厘，谬以千里，鸡同鸭讲啊。
比如说两个模块A和B，职责不一样，但是依赖了相同的二方库。那我们不能说某个职责在这个二方库里。这个二方库作为某个独立的技术小产品，提供了某些能力。但是履行职责的还是A模块或者B模块。
如何自顶向下构建架构？
一、问题的本质
我也在很多场合问过一个问题：什么是问题？虽然我们天天挂在嘴边，但是没有人能够给出较为合理的答复，之前我也没有想过这个问题。而且很多人对问题的理解还不太一样，一部分人认为问题就是方案中的难点，一部分认为问题是现实和目标的差距，这些解读我觉得都还不够精确，我在尝试定义无果之后查询了大量的资料，终于找到了一个比较合理的定义，目前我认为毛主席的解释是比较合理的：
问题就是事物的矛盾。哪里有没有解决的矛盾，哪里就有问题。 --毛泽东
而主管们经常问到：
1.你要解决的问题是什么？
2.这里的问题定义是什么？
其实潜台词在问，这里事物间的矛盾是什么（已经发生的矛盾，将来会发生的矛盾，可能潜在会发生的矛盾），这个矛盾如果不早点解决，可能会激化，带来很严重的后果。
其他例子
1.中国人日益增加的财富和国产商品的低劣品质就存在矛盾，这个矛盾就是个问题（已经发生的矛盾）。所以我们要提倡中国质造。
2.如何利用新技术，更快更准的帮助消费者找到其最需要的商品，提升幸福感（将来会发生的矛盾，在矛盾发生之前，我们应该将之解决，在这个过程中，一堆友军会被改造）。
上面几个问题的定义都是社会级问题，而且都是公司层面在解决的问题，在我们技术同学的手头的工作中应该也存在各种问题，比如说QPS太低，RT太高，不稳定，研发效率低，等等，这些问题的定义稍微常见一点，基本上大家只要解决问题，而不用定义问题。
二、准确定义问题是成功的开始
这么多年来笔者review过很多技术方案，而且也经历混沌混乱的模块设计，大部分糟糕的设计基本上是莫不清楚自己到底要解决什么问题，总是觉得这个问题我要解决，那个问题我也要解决，甚至不是问题的问题我也要解决。然后设计出了一个能解决所有“问题”的方案。但是实际情况是有些问题根本不是问题，有些问题确实是问题但是却又不是核心问题，有些问题是核心问题，但是又不是当下最核心的问题。我相信类似的方案有很多在review的时候被挡下了，但是还有很多应该已经上线了。如何尽可能减少这方面的损失？那就是要开始阶段就要准确的定义问题，这也是这么多思想家推崇问题定义的原因。
著名思想家杜威如是说道：
'A problem well-defined is a problem half solved.' - John Dewey
爱因斯坦如是说道：
提出一个问题往往比解决一个问题更重要，因为解决问题也许仅能是一个数学上或实验室上的技能而已。而提出新的问题、新的可能性，从新的角度去看旧的问题，都需要有创造性的想象力，而且标志着科学的真正进步。 - by 爱因斯坦
那么准确定义一个问题要考虑哪些维度呢？我粗粗的列了一个表格，只是代表我自己的理解，未必是正确或者全面的，大家批判的阅读：
主要问题 次要问题 紧急问题 不紧急问题第一阶段
第二阶段
第三阶段
第四阶段
这里应该是一个三维的图形，有时间维度，主次要维度，紧急不紧急维度
对这个主要次要，紧急不紧急是不是眼熟，没错，在很多如何高效工作上都有类似的方法，把要做的事情分成重要紧急，重要不紧急，不重要紧急，不重要不紧急。
其实我不太认同将事情划分成重要或者不重要，紧急或者不紧急，我建议大家将自己手头要解决的问题划分为重要或者不重要，紧急或者不紧急，因为事情只是一种方案或者手段，区分问题本身的重要度和紧急度才是思考的源头（包含问题的升层思考）
要填满这张表格必须结合对业务的理解，和对产品的理解，尤其是业务理解，如果没有业务理解，很难准确的刻画问题。
可是什么叫问题的重要度呢？我也思考了很久，终于得出了一些较为自洽的解释。
三、问题的严重程度
问题严重程度的定义 当我们明确的定义问题之后，我们就要设定目标来解决这个问题，但是现状是残酷的，我们目标和现状之间可能存在巨大的落差，这个落差的程度就是问题的严重程度，所以说：
问题的严重程度是希望（目标）与现实的落差！
有些书或者文章里这样定义问题：问题 = 目标 - 现状，这个定义是模糊的，因为目标-现状和这张图一样，往往表示的是落差，落差往往让人想起差距，用差距来形容问题是含糊不清的，很难让人一下子就明白问题的本质。
我们拿性能问题举例，我们的目标是RT<1秒的请求占比大于98%，当前的现状是RT<1秒的请求占比为80%，那么这里的差距就是98%-80%=18%，这18%就是问题严重的程度，但是这18%绝对不是问题本身，这18%是问题的严重程度。
衡量问题严重程度的挑战
要区分问题的严重程度有两个挑战：
1.现状：对现状有准确的认知，比如该例中某系统RT<1秒的请求占比为80%
2.期待（目标）：问题解决后的状态有个清晰的表述，比如该例中某系统RT<1秒的请求占比大于98%
对于数值型的现状，我们要搞清楚这个数值是容易的，只要将你的目标值减去现状的值就可以得到问题的严重程度了。 对于难以量化的现状，那要摸清楚问题的严重程度，可能需要一些案例，需要一些数据统计，比如说架构现在不合理是个问题，这个问题严重到什么程度，那可以计算一下最近半年的需求在实现的过程中，花费了多少工时，如果架构合理的情况下哪些工时是可以节省掉的。或者现在的架构上迭代需求故障和bug的情况是怎么样的，评估一下重构之后故障和bug率会降低到多少。
只要现状和目标有一个没清晰，那我们就很难判断出问题的严重程度在哪里。
FBI warning： 如果你不能确定问题的严重程度（现在的或者将来的），不要贸然行动去沉迷于方案的设计。
而不定义问题，不评估问题的严重程度，往往是很多工程师的常见思维习惯，大家可以对号入座。
而问题的紧急度和重要度的评估类似，不再赘述，大家自行脑补。
四、问题的分类
基本上看这三类问题的字面意思就可以知道这三类问题的区别了：
1.恢复原状型：原本就应该是这样的，但是现在不是，比如说原本轮胎就应该是充满气的，但是现在扎了个钉子，所以我们要让轮胎恢复原状，这就属于恢复原状型问题。
2.风险防范型：问题可能发生，也可能不会发生，但是一旦发生，带来的危害是巨大的，所以我们不得不废大量的精力来防止这样潜在的问题发生。在安全和可用性方面，很多工作都是属于风险防范型。这里的尴尬之处是做了对数字指标可能没什么提升，但是不做可能会发生特别严重的事故，带来极其负面的影响。
3.追求理想型：知道未来会发生的矛盾是什么，提前解决未来必然会发生的矛盾。
如果将这三个问题映射到架构上，那么应该是如下的描述：
1.解决架构上未来会遇到的问题：已经明确预知到未来的业务问题，并且可以转换为未来的架构问题，提前做架构准备（功能性&非功能性）。我根据自己的理解又将其划分成两类：
•目标是非常明确且可以用数字衡量的：比如性能问题是可以准确定义一个指标来衡量问题当前的具体的量化值的，RT要到降低到多少毫秒，QPS要提高到多少，稳定性要提升到几个9等等，基本上非功能模块都可以用数字来衡量，比如我们系统中出现的数据搬移的功能，都是目标明确，且可以用数字来衡量的。或者比如系统的可扩展性要达到什么程度，是否满足95%以上的需求下不需要进行大量重构。
•目标是不明确的：比如将来要走哪个方向，要做什么样的技术准备，很多的类似的场景是很难直接评估出一个度量指标的。可能只有一个愿景和使命，根据这个愿景和使命来分解问题，然后我们才能设定通往这个理想的问题的路径，而探寻到这个理想的过程是相当的复杂，要考虑的因素实在太多，我只能说这个东西我的经验真的不多，我只能尝试用我所学的内容来进行自顶向下的推导，而以目前的功力实在很难保证结果的正确性。
2.解决架构上当前已经发生的问题：架构上的问题已经发生了，要对架构当前的问题进行识别，定义，以及解决（功能性&非功能性）。
3.解决当前架构合理迭代的问题：我们在架构上进行大量迭代，迭代过程中往往容易给架构挖坑埋雷，我们应该尽可能避免这样的情况发生（功能性&非功能性）。
这三大问题正是各线任意一个粒度的架构师需要明察，并时刻提醒团队的三大问题。如果无法定义这三大问题，那么这里可能就是最大的问题。
这里还要阐述一个问题：即使是未来的架构，我们还有分类，一类是你走在最前面，一种是你跟着别人，你跟着别人要怎么跟上去。
这里应该有个决策分支，告诉我们遇到什么场景的时候应该用什么样的思考方法，不过这只是个人总结，每个人脑海里应该都有一套类似的方法，而且这套方法是在不断的突破和修正的。
五、问题定义中的常见问题
1.误把方法/手段当“问题”
接下来，我编了三个小故事，大家从故事中感受一下手段和问题的区别，以及我们如何才能避免把手段当做问题。
案例一：鲧治水着重在堵的方法上，毕生精力都在思考如何更好的堵
•老师：请问这里的问题定义是什么？
•小明：这里的问题是如何堵！
•老师：其他同学也说说这里的问题定义是什么？
•小红：这里的问题是洪水和生命财产的矛盾！堵只是解决这个问题的方法或手段。
•老师：如果问题的定义是问题是洪水和生命财产的矛盾，堵只是方法，那么还有什么方法可以解决这个问题？
•小王：还可以用疏通的方法来治水。
•小白：我们还可以搬走，以避免水患
•老师：恩，这也是一个思路
案例二：如果我问我们的客户他们想要什么，他们会告诉我他们需要一匹更快的马 by 亨利福特
•老师：请问这里的问题定义是什么？
•小明：这里的问题是如何让马跑的更快！
•老师：还有其他同学能说说这里的问题定义是什么吗？
•小红：这里的问题定义是如何更快的到底目的地，马只是一种手段
•老师：是的，如果马只是一种手段，而不是问题的定义，请问还有什么什么手段可以解决我们提到的问题
•小王：根据目的地的距离的不同，我们可以选择坐飞机，做火车，开汽车
•小明：老师，我不知道自己不知道，我不知道有汽车，火车，飞机，我只知道马，所以我想到的就是如何让马跑的更快
•老师：是的，我们的局限往往是受限于我们的认知，这种情况不可避免，唯一的方法就是不断的学习，提升自己的认知。
案例三：如何做好资金防控？
•老师：请问这里的问题定义是什么？
•小明：这里的问题是如何做好资金防控，怎么防，怎么控。
•老师：还有其他同学能说说这里的问题定义是什么吗？
•小红：这里的问题定义是如何避免公司产生资金上损失，防控只是手段
•小白：资损防控解决直接问题是避免公司产生资金和名誉的损失，这个问题背后更深层次的是社会信任的问题
•老师：小白，你的名字虽然叫小白，但是你的思考一点都不小白，显然你在思考问题定义时使用了升层思考的方法，看到了问题背后的问题
•小明：老师，为啥我每次思考的时候，都是在思考解决问题的手段，都没有看到问题定义呢？
•老师：那你可以尝试自问自答，比如你可以问自己资损防控是手段吗？自己给个回答，如果回答是yes，那么再问自己：如果资损防控是手段，那么资损防控是解决什么问题的呢？通过这样的自问自答的方式，基本上我们可以较为准确的找到问题的定义
•小白：老师，我在想资损防控解决的是社会信任的手段之一，但是解决社会信任问题的手段不止一种啊
•老师：小白，你在思考问题时使用了升层思考，在思考解决方案时使用了升维思考，给你32个赞
•小白：谢谢老师，此时此刻我有点开心啊
•老师：保持心态的平稳，可以看到更多的东西，谦卑的态度没了，那自己的局限也就到了。
•小白：谢谢老师提醒，我记住了。
三个故事看完了，总结一下，这三个故事的核心在于：
1.准确区分手段和我们要解决的问题本身，这种情况非常非常非常常见，我review的很多技术方案之所以有问题基本都是问题定义没有搞清楚，所以解决方案的也就不符合需要了。
2.思考问题背后的问题时使用升层思考，在思考问题包含的子问题时使用升维思考
3.当升层思考之后，之前的问题可能会变成手段/方法。比如说用堵解决生命财产问题，堵是方法。升层思考之后，生命财产问题背后的问题是民生问题，此时保护生命财产就是解决民生问题的一个手段/方法。
当然当我们无法准确的分辨问题的时候，我们还可以不断缩短描述问题句子，比如提炼主谓宾，如果还不能清晰的描述那么在这几个词里再找出最最最关键的词，尤其是主语或者宾语中的词汇非常重要，它有可能就是重点，只是我们无情的忽略它了。
把手段或者方案当问题，或者把技术方案中的挑战当做问题是很多同学遇到的问题，请大家
2.误把挑战当"问题"
当我们明确定义出问题之后，我们开始解决方案的升维思考，可以从各个角度来给出解决方案，这些解决方案就是我们前面说的手段/方法。
举例：如果快速到达目的地是目标，而马，汽车，飞机，火车只是手段/方法，那么如何让马跑的更快，如何让汽车跑的更快，如何让飞机飞的更快，如何让火车开的更快就成了挑战。
此时如果你说“让马跑的更快也是个问题啊”，确实，广义上也可以这么理解，但我不建议这样做，原因是这样我容易将问题和手段/方法搅混。
所以这里我尝试给他们一个定义，以明确他们出现的场景：
•问题：事物之间在某个时期存在的矛盾，在本文的语境中尤其是指企业的客户和某种事物，趋势之间的矛盾。
•挑战：解决矛盾的方案中最困难的几个地方
接下来我们回到上述的几个案例中，来看看挑战和
•回到用堵治水的案例上：
•问题定义：洪水和人民生命财产安全的矛盾
•手段/方法：堵水
•挑战：获取息壤，以筑三仞高堤，这是手段/方法的挑战
•回到福特的案例上：
•问题定义：如何让人更快的到达目的地
•手段/方法：造汽车来让人们更快的到达目的地
•挑战：设计出更高的扭矩，更高的功率的引擎，更平顺智能的变速箱等等
这样我们在沟通的时候，就能明确的知道对方到底是在产生客户的问题定义，还是在阐述方案中的难点和挑战。
3.思考问题时缺少时间维度
单个问题在时间轴上的不同时期的严重程度是不一样的，比如说闭关锁国公元后1500年-1700年是看不出太大的问题的，但是，300年后的1800年，闭关锁国的弊端就开始浮现了，当然我们都是事后诸葛亮。
所以任何一个问题的严重程度都有一个时间轴，也许过了某个时间点之后，问题便不再是个问题。比如外卖兴起之后，如何更好的制作一包方便面以满足用户的口味需求就不是一个问题了。
时间维度是一个及其重要的维度，任何事情理论上都必须考虑在时间维度上的影响，所以即使在定义问题上，时间维度是一个不能不考察的维度。所以才需要一个roadmap的路线图，标注不同阶段要解决什么样的问题。
六、升层思考及升维思考
我们不能用问题发生时的同一层次思维来解决问题。 原文:The significant problems we face cannot be solved at the same level of thinking we were at when we created them. - by 爱因斯坦
爱因斯坦阐述了思维存在层次这一现象，这里我发表另外一个观点：
我们不能只局限于问题本身，还需要看到问题背后的问题，然后才能更容易的找到更多的解决方案
我把这种方法叫做问题的升层思考，接下来我会简称之升层思考，我在网上搜索了一下，之前没有人提起过这个词，所以这个词目前版权在我这里哈，如果你想说服谁需要用这种思考方式，不妨把我这篇文章发给他。
当问题升层思考之后，前面的问题会变成手段/方法，比如说洪水和人民生命财产的矛盾背后的问题是社会的稳定性问题（1和2是升层思考），而升维思考洪水和人民生命财产的矛盾的时候就会发现用疏通治水或者搬走都是方案（3是升维思考）。
这就是升层思考问题，升维思考手段/方法。不过这张图中每个问题到底严重到什么程度，还没有给出量化，不过我们在工作中，我们是要量化这个严重程度，而且要放在时间轴上来进行量化，因为有些问题当前可能并不严重，但是数月后可能会变成大问题。
值得注意的是这里思考的升层是依赖认知升级的，就像一个小朋友，也许也能升层思考，但是其认知的程度决定了他思考能到的层度，所以历史，社会科学，哲学也是我们的必修课，有助于我们认知到更高的层次的存在。当问题的层次不断提升的时候，往往最终会归结为社会问题和人性问题。
重要的话说三遍： 缺乏升层思考的升维思考是不完整的自顶向下 缺乏升层思考的升维思考是不完整的自顶向下 缺乏升层思考的升维思考是不完整的自顶向下
网上实际的案例来进行升层思考和升维思考 接下来我拿一些网上横向思考的案例，来使用升层思考和升维思考的方式获得相应的解决方案
•例一：游客有时会从帕台农神庙的古老立柱上砍下一些碎片，雅典当局对此非常关心，虽然这种行为是违法的，但是这些游客仍旧把它作为纪念品带走。当局如何才能阻止这一行动呢？
•问题定义：如何给客户提供纪念品
•升层思考：客户需要纪念品的背后是想解决什么问题？是不是解决客户的旅游纪念的需求。
•对背后的问题升维思考：要满足客户的旅游纪念的需求有没有其他方法
o明信片：明信片也可以做为一种纪念的方式，有了明星片做纪念，游客敲石柱的比例可能会下降
o现场照片：可以安排现场拍照的摄像师，选择特别的角度为这些想要留念的客户拍摄特别的照片，游客敲石柱的比例可能会下降
o帕台农神庙模型：可以制作各种帕台农神庙的模型，让客户购买，以满足客户纪念的需求，游客敲石柱的比例可能会下降
•对原问题升维思考：
o在地上洒上大理石碎片：让客户以为这是帕台农神庙的大理石，客户会捡起地上的大理石碎片带回去留念【这是网上的标准答案】
o进入神庙时寄存各种金属物件：让用户无法用金属去砍古老立柱，缺点是成本高，效率低，需要排队检测金属物件
o把柱子围起来，让用户只能在一米开外的距离观看：用户碰不到柱子，自然无法去砍柱子，成本比较低，也比较容易实现
o写标语，在入口处，以及门票上明确指出破坏文物是违法行为，会受到法律的制裁
o等等
网上的标准答案是在柱子旁边洒上大理石碎片（其他的都是我使用升层思考和升维思考瞎想出来的，你也可以想出很多）。让游客以为这是神庙已有的碎片。不过这种方案经不起逻辑思维的推敲，比如开放了这么多年，地上的碎石为什么还没有被捡光？于是游客就知道这是人为洒在上面的，那么有些游客会继续破坏石柱。
我想说的是，这里的升层思考，和不同层次的升维思考会给我们带来很多种方案，如果集合全团队的力量，我们甚至还可以想出更多更多的idea。
•例二：在美国的一个城市里，地铁里的灯泡经常被偷。窃贼常常拧下灯泡，这会导致安全问题。接手此事的工程师不能改变灯泡的位置，也没多少预算供他使用，工程师应该怎么办？
•问题定义：如何不让窃贼拧下灯泡
•升层思考：不让窃贼拧下灯泡是为了解决什么问题？是为了解决预算不足的问题
•对背后的问题升维思考：解决预算不足有没有其他方案？增加预算？募捐？防止窃贼拧下灯泡。
•对原问题升维思考：不让窃贼拧下灯泡可以从哪些维度进行考虑
o焊住：缺点是灯泡坏了之后很难更换
o反向螺纹（窃贼在拧下灯泡的时候其实是在拧紧）：缺点时窃贼只要使用逆向思维就能破解【反向螺纹是网上的标准答案】
o特别的螺纹（特别螺纹让窃贼拿到灯泡之后也无法在其他地方使用）：缺点是需要定制，成本高
o摄像头：缺点是增加了设备，需要更大量的投入
o把灯安装在更高的位置：窃贼得用梯子才能去盗窃灯泡，要看线路是否支持
o在灯泡上印上地铁专用标志：别人不敢买这种灯泡，窃贼无法销赃，缺点是多一道工序，灯泡的成本变高
o等等
在这个案例中，反向螺纹是标准答案，缺点是窃贼只要使用逆向思维就能破解。其他都是我自己通过升层思考和升维思考想出来的，其实你也可以想出很多，这里跟逻辑无关。我想说的是通过升层思考和升维思考，我们就会发现很多种创新答案。而不会沿着某个答案一直往下走。
这两个例子是关于横向思维（和升维思考类似）的例子，但是通过我们会发现如果加上升层思考，在每个层次上再进行升维思考，我们会得到很多创新的idea。如果让整个团队使用这一的思考方式，我们就可以得到更多更多idea。
七、是新问题还是新技术解决老问题？
我们做架构的时候，一般都会根据当前流行的技术趋势来解决问题，这些流行的技术趋势其实手段的更新，并不是问题的更新。
尤其是在一些社会性问题以及人性问题上，几千年来问题都没有变化过，只是新的技术手段可以更好的解决这些问题而已。
比如人类有沟通需求，数百年前是通过书信，后来是电报，后来是电话（音频），后来是视频等等。都是技术的革新来更好的解决已有的问题。这就要求我们随时关注新技术，并和当前自己手头的工作产生一定的联想，不同对象之间的联想能力此刻变的无比重要。
当然在一些问题特别明确的领域，比如说数据库领域，要解决的问题基本没有变过，但是问题转换成的指标的值却在一直提升，比如支持的数据量越来越大，插入的速度越来越快，查询速度越来越快，比如最近就有很多通过AI来做自动tunning和AI索引优化的，都属于此列。
类似的例子还有很多，比如Mobile流行的时候，消息的更实时触达是改造各种消息通道的一个契机，会产生新的产品，比如微博，微信，等等。地理位置可以获取之后，也出现一堆新的应用，改造了老的产品。
所以我对自己提了一个要求，任何新技术，哪怕是很小的新技术，都要联想一下可能对现在的工作，以及现在工作的产业链路上下游有咩有什么帮助，这种联想可能不只是个人要做的，而是要驱动团队展开讨论的。目前眼前被提到的新技术有AI，区块链，IOT，5G等等，这些也许可以跟我们的业务产生链接。可以组织团队进行发散型思考。
不过这个事情我自己做的也一般，想多跟大牛们学习学习。
八、小结
- 区分手段和问题
- 明确问题定义
- 对问题背后的问题进行升层思考
- 对问题的分解进行升维思考
升层思考和升维思考有时候是创新的核心，比如鲧用堵治水，他毕生都在思考如何堵，所以他是从堵这个顶点向下思考的，如果对堵进行升层思考之后再进行升维思考，你会发现除了堵水，还可以用疏通的方式，还可以搬走等等。所以创新的关键在于升层思考和升维思考。
我们团队已经在很多场合使用这些思考模式进行了技术上的创新，只是这块和行业相关，不够通用，所以我找的例子都是以不需要背景技术知识就能理解案例为主。如果需要技术上使用升层思考和升维思考的案例，可以钉钉联系我。
而接下来的的一些业务思考中，我将会阐述如何将升层思考运用于业务分析中。
此处说明一下，因为升层思考的方式是我个人的一些总结，所以其必有不完善的地方，如果大家看出其有不合适的地方，请务必提出质疑，助我提升，谢谢。即使没有看出有问题的地方，也请大家辩证的来看升层思考。
