• 关于架构的一些感悟
  • 顾名思义 发表于 2016/3/9 19:45:00 | 分类标签: 架构设计 架构师 网站架构
  • 架构的本质

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

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

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

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

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

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

    架构分类和服务对象

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


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

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

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

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

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

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

    架构师的能力模型

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


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

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

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

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

    总结下,架构师的能力要求包括:
    1.兼具技术的广度(多领域知识)和深度(技术前瞻)
    2.兼具思维的高度(抽象思维)和深度(问题到本质)
    3.兼具感性(沟通)和理性(平衡)

    架构的境界

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

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

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

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

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

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

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

    个人感悟

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

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

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

  • 请您注意

    ·自觉遵守:爱国、守法、自律、真实、文明的原则

    ·尊重网上道德,遵守《全国人大常委会关于维护互联网安全的决定》及中华人民共和国其他各项有关法律法规

    ·严禁发表危害国家安全,破坏民族团结、国家宗教政策和社会稳定,含侮辱、诽谤、教唆、淫秽等内容的作品

    ·承担一切因您的行为而直接或间接导致的民事或刑事法律责任

    ·您在编程中国社区新闻评论发表的作品,本网站有权在网站内保留、转载、引用或者删除

    ·参与本评论即表明您已经阅读并接受上述条款

  • 感谢本文作者
  • 作者头像
  • 昵称:顾名思义
  • 加入时间:2013/5/21 0:00:00
  • TA的签名
  • 这家伙很懒,虾米都没写
  • +进入TA的空间
  • 以下内容也很赞哦
分享按钮