架构师成长系列 - 能力认知（2）
架构师认知
在上一篇文章中，我解释了能力的体现是认知的不同，一个高级开发和架构师，最核心，最本质的能力应该是体现在认知能力上的。
那么，架构师应该具备什么样的认知，或者核心思考模式应该是什么样的呢？
是什么
我从阿里的job model里面抽离出来关键字（没必要因为阿里喷我，我相信对于架构师的定义其实都差不多）
系统性&体系化思考，知其然知其所以然
- 从一些危害讲，业务系统处理业务请求，如果使用多线程模型并且使用了sync，非常容易导致请求hang死，并且不利于我们的并发。
- 从线程技术上来说，默认是unbound。这会导致很多的内存溢出，并且使用多线程，服务器重启会导致业务处于不可知的状态
- 从使用原因来说：业务中使用多线程（有别于Tomcat这种容器中间件）是为了提高并发能力，或者是异步化业务能力。而这两种都有其他的方案来替代。比如高并发，我们可能会进行一些拆分操作，比如异步化，会使用消息队列等
- 怎么做呢，比如异步化，我们用消息队列。如果是资源共享，那么尽量做到读，而不是写。如果是共享写，那么根据业务场景尽量拆分，然后归拢业务职责。这也是架构设计中聚合的重要性。很多框架比如netty，都有无锁设计。
我上面简单的说了一下，实际上，阿里内部的研发规范就是不允许使用java线程池的，并且我们业务代码中也不允许请求处理维度使用sync。这体现了哪些方面呢。
体系化
比如我在回答这个问题的时候，很随意的拆分成了几个维度来回答：坏处，技术难点，使用场景，最佳实践。
这就是当我们回答一个问题的时候，自然而然的按照一定的模型思考，然后进行回答。
无论这个模型是什么，他都是体系化的一种。
比如直接回答：1.为什么要用多线程？2.不用多线程有没有别的方案 等等，这些都是思考的一个模型，按照这些维度进行拆分，这些维度进行汇总。就是体系化。
很有趣，读到这里又可以停下来了。
我们可以思考一个事情：如何从一个研发人员成为一个架构师？大家能否想到多个维度的回答？
如果仅仅是聊一下框架或者技术（kafka，redis）这肯定是远远不够的。
我们能否按照一个维度拆分？比如我这个文章，就是一个拆分的维度。而开始思考维度，就是架构师需要的一个认知，这也是体系化&系统化思考的表现。
知其然知其所以然
为什么体现了这个呢，其实很简单，就是一个能力：多问一个why。
这个能力是及其重要的，往往我们对于问题的定义高度，就决定了我们的架构高度。
比如刚才的例子：如何处理线程安全问题？
多问一个why：为什么要处理线程安全问题？
可能这个时候就发现：是因为多线程并发访问共享资源问题。
那么我们的方案是不是就可以变成：不访问，主要是不写入共享资源，是不是就没有线程安全问题了？
此外，也可以问：为什么要用多线程？
可能回答是：要处理多任务并行能力，或者任务异步化能力降低请求耗时问题。
那么是不是有别的技术方案可以解决？消息队列。可靠消息异步化能力。
这点非常非常非常重要，重要到应该形成我们的本能。甚至不仅仅是技术方面。
技术上，任何一个框架，都要问，这个框架解决了什么问题。
上面就是整体架构师需要具备的能力认知部分。
希望大家一定要深刻理解结构。这两个字。
关键不在于结构是什么，关键在于要有结构
怎么做
可以从认知结构上和行为习惯上来说我们怎么做到成长。
也可以直接给出答案，我们应该做什么具体的事情。
我还是从这两个维度来描述这个问题。
有没有发现，我说的内容都是总分结构？其实这是非常常用的一个方式。
认知结构
怎么做很简单，就是要多想一点，要知道用什么方法多想一点，多思考一点。而这个方法就是怎么做，思考出来的过程，就是认知结构，做到了这点，就会很快的成长。
我会简单的解释一些分析方法。
首先金字塔模型里面说的一个：MECE原则
总结来说就是两个维度：无重复，无遗漏 我们描述一个问题或者事情，应该做到不重复。
比如我们说什么是人类，可以说两个维度：生理性别男，生理性别女（政治正确太可恨了） 这两个维度是不重复的（这里不讨论假定性别问题）。并且是不遗漏的。
如果我们划分是：少年，青年，老年 这就不是一个很好的维度，因为年龄可能存在交叉。
5w2h这个维度思考。
5w其实就可以划分成 2w（分析维度）：why what。回答 为什么 和 是什么这个问题。3w（属性维度）：when who where 1h ：how to do 核心本质怎么做 1h ：how much 核心成本，也是ROI。决策的核心维度，投入产出比。（这个非常核心，没有最好的架构，只有最合适的架构）
我讲解5w2h的这个过程，就是自然而然的对5w2h进行维度拆分的过程：分析维度，属性维度，关键方案，关键ROI。我不断的重复这个事情，就是想让大家理解，这些维度都是一个个的方法。我们要形成自己拆维度的习惯。
3why方法
很简单，对于任何问题，我们追问3个为什么。这样就能定义问题的本质，直面我们具体要解决什么问题。
比如：我们为什么要获得架构师offer？可能是我们想获得成长和一个好工资。
（这里就明白我们本质需要，我们是看重工资还是真的成长空间？如果是成长，可能是找到几个良师益友，也不一定是换公司）
我们为什么要获得一个好工资？可能是想有更好的生活。
（这里就会发现，其实我们还是回到了生活本质，可能会引入wlb这个问题，可能架构师就不是这么重要了）
什么是更好的生活？可能是自我价值的体现。
（这里可能就会更好的认识自己，所以认知的升级，也是不断加深自我认知的一个过程）
还有很多很多，比如swot，四象限等等。关键是帮助大家打开一个门。这个门就是：我们要多想想，并且我们是要按照一定的方法多想想。
具体的事情
这里我都会在后面详细的解释。对于我们技术人员来说。在日常工作和学习中，可以做下面几个事情。
- 抽象
我感觉这也是架构的基础，哪怕从架构的第一阶段：框架，开始，都是解决某一类的特定问题。比如ORM框架解决db和java代码之间的映射关系等问题。在我们的实际业务代码中，我们尽量能对我们要实现的功能，多问一个why，也就是多抽象一点。比如一个活动参与次数的功能，我们抽象定义成一个通用的计次服务。这样可以多业务场景复用。比如我们处理业务报错之后的特殊逻辑，可以用AOP+异常处理流程。来做一个通用的框架，可以解决所有分支链路和主业务链路的解耦问题。
- 分层定义
按照清晰的维度，进行明显的层次划分。不同的层次有不同的特性和符合这一层次的关键职责。
在具体的工作中，有个习惯大家可以试试：我们总归有一层设计，是没有业务语义概念的。比如完整的一个insert操作。这个insert sql肯定没有业务语义，完全不理解这是一个什么场景需要insert。它只专注于实现insert功能。按照这种方法。我们就可以不断的抽象出不同的功能。在具体的架构方法里面我会介绍的详细一些。
3.思考业务问题，业务本质与业务价值
要思考我们为什么写代码，是实现某个功能，这个功能最终怎么产生的业务价值，那么对我们的功能就有什么要求？对我们代码的抽象，是架构，对业务本质的抽象，也是架构。业务价值最终决定着我们的架构价值。