架构的本质
架构的本质
原文作者王庆友，前 1号店首席架构师，先后就职于 ebay、腾讯、1号店、找钢网，精通电商业务，擅长复杂系统业务建模和架构分析，目前在中国 B2B 第一电商公司找钢网担任首席架构师，微信号Brucetwins。原文连接，读后笔记，全部重新敲了一遍，有一定删减，侵删
目前讨论架构实操（术）的文章较多，而讨论架构理念（道）的较少，本文基于作者在大型电商系统架构方面的一些实践和思考，推进大家对架构的认识。
道与术，道是事物发展的本质规律，术是事物发展的具体途径。规律只有一个，途径很多，条条大道通罗马，如果事先知道罗马在哪，那么遍地是路。架构也是如此，如果能够领悟架构的本质，就不会拘泥于现有的实践和理论框框，而以最直接的方式解决问题，无招胜有招。本文的内容包括架构的本质、架构的服务对象、架构师能力模型、架构的境界。
架构的本质
一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。
架构的本质就是对系统进行有序化重构，不断减少系统的“熵”（意为无效性，无序性，不可控等），使系统不断进化。
那架构师如何实现无序到有序的呢？基本的手段就是分和合，先把系统打散，然后重新组合。
分，则合理定位；合，则有机整体
分的过程是把系统拆分成各个子系统/模块/组件，拆的时候，首先要解决每个组件的定位问题，然后才能划分彼此的边界，实现合理的拆分。
合就是根据最终要求，把各个分离的组件有机整合在一起，相对来说，拆分更难。
架构分类和服务对象
架构一般可以分为业务架构、应用架构、技术架构（侧重领域/视图不一样），那么他们分别解决什么问题，服务于谁呢？首先看一下系统落地过程：
对于负责开发的人来说，怕的是业务太复杂，代码逻辑太乱，超出了他能理解的范畴，系统无法维护。因此开发的需求是系统整体概念清晰，容易理解，方便扩展。
对于负责运行的机器来说，怕的是业务并发量太大，系统核心资源不够用（如数据库连接）。它希望在业务量增加的时候，系统能个支持水平扩展，支持硬件容错（如避免单点故障）。
开发的痛点主要是由业务架构和应用架构解决，业务架构从概念层面帮助开发者理解系统（动态的包括业务流程/节点/输入输出，静态的包括业务域/业务模块/单据模型）。
应用架构从逻辑层面帮助开发者落地系统（应用类型/应用形式/数据交互关系/交互方式等），整个系统逻辑上容易理解，最近大家谈的比较多的SOA即属于应用架构的范畴。
机器的痛点主要由技术架构解决，如技术平台的选型（操作系统/中间件/设备等），部署上希望支持多机房，水平扩展，无单点等
强调一下，系统是人的系统，架构首先是为人服务的，业务概念清晰，应用逻辑合理，人好理解是第一位的（即系统有序度高）。现在大家讨论更多的是技术架构，如高并发设计、分布式事务处理等，只是因为这个不需要业务上下文背景，比较好相互沟通。具体架构设计时，首先要关注业务架构和应用架构，这个新手需要特别注意
架构师的能力模型
架构师只做分和合的事情，但综合能力要求很高，通过下图典型的架构方式介绍一个架构师的能力要求：
在此基础上，架构师要有技术的广度（多领域知识），又有深度（技术前瞻），对主流公司的系统设计非常了解，知道优劣长短，碰到实际问题，很快有多种方案可供评估。
抽象思维是架构师最重要的能力，架构师要善于把实物概念化并归类。比如面对一个大型的B2C网站，能够迅速抽象为 采购->运营->前台搜索->下单->履单这几大块，对系统分而治之，庖丁解牛，早已目无全牛。
抽象思维是往高层次的总结升华，由实转虚；透过问题看本质则是由虚到实，往深层次地挖掘。比如看到一段java代码，知道它在JVM如何执行；一个跨网络调用，知道数据是如何通过各种介质到达目标（操作系统内核/网卡端口/电磁介质等）。透过问题看本质使架构师能敏锐地发现底层子真实，系统性、端到端地思考问题，识别木桶的短板并解决之。
能落地的架构才是好架构，良好的沟通能力确保各方对架构达成共识，愿意采取行动；良好的平衡取舍能力能确保架构在现有资源约束下是最合理的，理想最终照进现实。
总结下，架构师的能力要求包括：
- 兼具技术的广度（多领域知识）和深度（技术前瞻）
- 兼具思维的高度（抽象思维）和深度（问题到本质）
- 兼具感性（沟通）和理性（平衡）
架构的境界
架构师从境界上由浅到深分为四层：看山不是山，看山是山，看山不是山，看山是山
刚接手项目时，对业务不了解，时时被业务方冒出的术语弄得一愣一愣的，如果把现有问题比作山，则是横看成岭侧成峰，根本摸不透，此时看山不是山
经过对于业务梳理和对系统的深入了解，可以设计出一个（水平不高）的方案，把各个系统串起来，解决但是问题，对此，以为能看看清楚全貌，此时能够做到看山是山。
通过进一步抽象，发现问题本质，原来这个问题是共性的，后续还会有很多类似的问题，设计上进行总结和升华，得出一个通用的方案，不光能解决但是问题，还可以解决潜在问题。此时看到的已经是问题本质，看山不是山。
最后回到问题本身，去除过度的抽象，给出设计简洁明了，增一分嫌肥，减一分嫌瘦，即解决当前问题，又保留最基本的扩展，此时问题还是那个问题，山还是那个山。
虽然非要往 禅 方面靠，有点牵强，但还是将几个需要注意的点提炼清楚了：
第二境界，只解决了表面问题，往往设计不够，碰到其他问题或者类似问题，需要重复工作
第三境界，需要主要房子过度设计，不要太过追求抽象和概念化，以免造成系统难以落地，无序度增加，过犹不及
所以给出第四种境界：在了解问题本质的基础上，同时考虑现状，评估未来，不多做，不少做
个人感悟
做技术久了，涉及到的技术领域也会越来越多，毕竟现在技术更新迭代频繁，技术知识日新月异，加之很多大牛都慢慢将先进的理念、先进的技术开源出来（例如阿里），以前很多技术上的难点都可以轻而易举地解决掉。现在办公室里面还挂着一副大壁贴：能用技术解决的问题就不是问题。目前我所处的状态，是属于技术应用而非技术研究（不是研究新技术，而是借助已有技术解决一些问题罢了）。对于新需求新问题，一看已经知道该怎么怎么做，没有更多地去了解问题本质，也没有去考虑现状评估未来，总之就是没有去多思考。
说个小例子：去年前我们需要上线一个后台系统，能够对公司所有的设备进行管控（实际需求是boss需要做产品演示用），用技术惯性的思维，其实无外乎一套web系统，我们不仅做了，还把权限管理做了一整套。但是到后来，公司业务方向从B2C转向B2B（当时是有这趋势），甚至可以做OEM，所以这个后台系统不仅需要支撑自己公司，还需兼顾 项目需求、大客户需求、OEM需求，原有的权限管理就相当于白做了。所以在业务方向还不明了，需求还不够明确清晰时，在满足需求的前提下，尽可能做简单，否则很容易浪费资源。在做全局架构设计时，也需要多思考将来系统的发展趋势，考虑长远
遇到问题时，能去了解问题的本质，多思考，评估下未来