架构的本质

架构的本质

原文作者王庆友,前 1号店首席架构师,先后就职于 ebay、腾讯、1号店、找钢网,精通电商业务,擅长复杂系统业务建模和架构分析,目前在中国 B2B 第一电商公司找钢网担任首席架构师,微信号Brucetwins。原文连接,读后笔记,全部重新敲了一遍,有一定删减,侵删

目前讨论架构实操(术)的文章较多,而讨论架构理念(道)的较少,本文基于作者在大型电商系统架构方面的一些实践和思考,推进大家对架构的认识。

道与术,道是事物发展的本质规律,术是事物发展的具体途径。规律只有一个,途径很多,条条大道通罗马,如果事先知道罗马在哪,那么遍地是路。架构也是如此,如果能够领悟架构的本质,就不会拘泥于现有的实践和理论框框,而以最直接的方式解决问题,无招胜有招。本文的内容包括架构的本质、架构的服务对象、架构师能力模型、架构的境界。

架构的本质

一个软件系统随着功能越来越多,调用量急剧增长,整个系统逐渐碎片化,越来越无序,最终无法维护和扩展,所以系统在一段时间的野蛮生长后,也需要及时干预,避免越来越无序。

架构的本质就是对系统进行有序化重构,不断减少系统的“熵”(意为无效性,无序性,不可控等),使系统不断进化。

那架构师如何实现无序到有序的呢?基本的手段就是分和合,先把系统打散,然后重新组合。

分,则合理定位;合,则有机整体

架构的本质_第1张图片

分的过程是把系统拆分成各个子系统/模块/组件,拆的时候,首先要解决每个组件的定位问题,然后才能划分彼此的边界,实现合理的拆分。

合就是根据最终要求,把各个分离的组件有机整合在一起,相对来说,拆分更难。

架构分类和服务对象

架构一般可以分为业务架构、应用架构、技术架构(侧重领域/视图不一样),那么他们分别解决什么问题,服务于谁呢?首先看一下系统落地过程:

架构的本质_第2张图片

对于负责开发的人来说,怕的是业务太复杂,代码逻辑太乱,超出了他能理解的范畴,系统无法维护。因此开发的需求是系统整体概念清晰,容易理解,方便扩展。

对于负责运行的机器来说,怕的是业务并发量太大,系统核心资源不够用(如数据库连接)。它希望在业务量增加的时候,系统能个支持水平扩展,支持硬件容错(如避免单点故障)。

开发的痛点主要是由业务架构和应用架构解决,业务架构从概念层面帮助开发者理解系统(动态的包括业务流程/节点/输入输出,静态的包括业务域/业务模块/单据模型)。

应用架构从逻辑层面帮助开发者落地系统(应用类型/应用形式/数据交互关系/交互方式等),整个系统逻辑上容易理解,最近大家谈的比较多的SOA即属于应用架构的范畴。

机器的痛点主要由技术架构解决,如技术平台的选型(操作系统/中间件/设备等),部署上希望支持多机房,水平扩展,无单点等

强调一下,系统是人的系统,架构首先是为人服务的,业务概念清晰,应用逻辑合理,人好理解是第一位的(即系统有序度高)。现在大家讨论更多的是技术架构,如高并发设计、分布式事务处理等,只是因为这个不需要业务上下文背景,比较好相互沟通。具体架构设计时,首先要关注业务架构和应用架构,这个新手需要特别注意

架构师的能力模型

架构师只做分和合的事情,但综合能力要求很高,通过下图典型的架构方式介绍一个架构师的能力要求:

架构的本质_第3张图片

在此基础上,架构师要有技术的广度(多领域知识),又有深度(技术前瞻),对主流公司的系统设计非常了解,知道优劣长短,碰到实际问题,很快有多种方案可供评估。

抽象思维是架构师最重要的能力,架构师要善于把实物概念化并归类。比如面对一个大型的B2C网站,能够迅速抽象为 采购->运营->前台搜索->下单->履单这几大块,对系统分而治之,庖丁解牛,早已目无全牛。

抽象思维是往高层次的总结升华,由实转虚;透过问题看本质则是由虚到实,往深层次地挖掘。比如看到一段java代码,知道它在JVM如何执行;一个跨网络调用,知道数据是如何通过各种介质到达目标(操作系统内核/网卡端口/电磁介质等)。透过问题看本质使架构师能敏锐地发现底层子真实,系统性、端到端地思考问题,识别木桶的短板并解决之。

能落地的架构才是好架构,良好的沟通能力确保各方对架构达成共识,愿意采取行动;良好的平衡取舍能力能确保架构在现有资源约束下是最合理的,理想最终照进现实。

总结下,架构师的能力要求包括:

  1. 兼具技术的广度(多领域知识)和深度(技术前瞻)
  2. 兼具思维的高度(抽象思维)和深度(问题到本质)
  3. 兼具感性(沟通)和理性(平衡)

架构的境界

架构师从境界上由浅到深分为四层:看山不是山,看山是山,看山不是山,看山是山

刚接手项目时,对业务不了解,时时被业务方冒出的术语弄得一愣一愣的,如果把现有问题比作山,则是横看成岭侧成峰,根本摸不透,此时看山不是山

经过对于业务梳理和对系统的深入了解,可以设计出一个(水平不高)的方案,把各个系统串起来,解决但是问题,对此,以为能看看清楚全貌,此时能够做到看山是山。

通过进一步抽象,发现问题本质,原来这个问题是共性的,后续还会有很多类似的问题,设计上进行总结和升华,得出一个通用的方案,不光能解决但是问题,还可以解决潜在问题。此时看到的已经是问题本质,看山不是山。

最后回到问题本身,去除过度的抽象,给出设计简洁明了,增一分嫌肥,减一分嫌瘦,即解决当前问题,又保留最基本的扩展,此时问题还是那个问题,山还是那个山。

虽然非要往 禅 方面靠,有点牵强,但还是将几个需要注意的点提炼清楚了:
第二境界,只解决了表面问题,往往设计不够,碰到其他问题或者类似问题,需要重复工作
第三境界,需要主要房子过度设计,不要太过追求抽象和概念化,以免造成系统难以落地,无序度增加,过犹不及

所以给出第四种境界:在了解问题本质的基础上,同时考虑现状,评估未来,不多做,不少做

个人感悟

做技术久了,涉及到的技术领域也会越来越多,毕竟现在技术更新迭代频繁,技术知识日新月异,加之很多大牛都慢慢将先进的理念、先进的技术开源出来(例如阿里),以前很多技术上的难点都可以轻而易举地解决掉。现在办公室里面还挂着一副大壁贴:能用技术解决的问题就不是问题。目前我所处的状态,是属于技术应用而非技术研究(不是研究新技术,而是借助已有技术解决一些问题罢了)。对于新需求新问题,一看已经知道该怎么怎么做,没有更多地去了解问题本质,也没有去考虑现状评估未来,总之就是没有去多思考。

说个小例子:去年前我们需要上线一个后台系统,能够对公司所有的设备进行管控(实际需求是boss需要做产品演示用),用技术惯性的思维,其实无外乎一套web系统,我们不仅做了,还把权限管理做了一整套。但是到后来,公司业务方向从B2C转向B2B(当时是有这趋势),甚至可以做OEM,所以这个后台系统不仅需要支撑自己公司,还需兼顾 项目需求、大客户需求、OEM需求,原有的权限管理就相当于白做了。所以在业务方向还不明了,需求还不够明确清晰时,在满足需求的前提下,尽可能做简单,否则很容易浪费资源。在做全局架构设计时,也需要多思考将来系统的发展趋势,考虑长远

遇到问题时,能去了解问题的本质,多思考,评估下未来

你可能感兴趣的:(架构的本质)