首席架构师眼里的架构本质精选.pdfVIP

首席架构师眼里的架构本质 目前讨论架构实操 （术 ）的文章较多 ，讨论架构理念 （道 ）的较少 ，本文基于作 在大型电 商系统架构方面的一些实践和思考 ，和大家聊聊架构理念性的东西 ，希望能够抛砖引玉 ，推 进大家对架构的认识。 什么是道 ，什么是术 ？道是事物发展的本质规律 ，术是事物发展的具体途径。 规律只有一个 ，途径很多 ，条条大路通罗马 ，罗马是道 ，大路是术。道为本 ，术为途 ，如果事先知 道罗马在哪里 ，那么遍地是路 ，路路相通。架构也是如此 ，如果能领悟架构的本质 ，就不会拘泥于 现有的实践和理论框框 ，而以最直接的方式解决问题 ，无招胜有招。 本文的内容包括 ： 架构的本质 架构的服务对象 架构师能力模型 架构境界 架构的本质 任何系统 ，自然情况下 ，都是从有序到无序 ，这是有科学依据的 ， 按照热力学第二定律 ，自然界的 一切自发过程都有方向性 ，一个孤立系统会由有序变为无序 ，即它的熵会不断增加 ，最终寂灭。但 生物可以通过和外界交互 ，主动进行新陈代谢 ，制造“负熵”来保证自身有序 ，继续生存。 同样 ，一个软件系统随着功能越来越多 ，调用量急剧增长 ，整个系统逐渐碎片化 ，越来越无序 ，最 终无法维护和扩展 ，所以系统在一段时间的野蛮生长后 ，也需要及时干预 ，避免越来越无序。 架构的本质就是对系统进行有序化重构 ，不断减少系统的“熵” ，使系统不断进化。 那架构是如何实现无序到有序的呢 ？ 基本的手段就是分和合 ，先把系统打散 ，然后重新组合。 分的过程是把系统拆分为各个子系统/模块/组件 ，拆的时候 ，首先要解决每个组件的定位问题 ，然 后才能划分彼此的边界 ，实现合理的拆分。合就是根据最终要求 ，把各个分离的组件有机整合在 一起 ，相对来说 ，第一步的拆分更难。 拆分的结果使开发人员能够做到业务聚焦、技能聚焦 ，实现开发敏捷 ，合的结果是系统变得柔性 ， 可以因需而变 ，实现业务敏捷。 举个例子 ，在Web 1.0时代 ，一个A SP或JSP页面里 ，HT ML和脚本代码混在一起 ，此时脚本代码 越多 ，系统越混乱 （即熵增加 ），最终连开发 自己都无法理解。此时就需要对系统重新架构 ，办 法是引入view helper模式 ，分离HT ML和脚本 ，HT ML成为view ，脚本成为帮助类。然后再简单整 合在一起。通过重新分和合 ，整个系统层次清晰 ，职责明确 ，系统的无序度降低 ，容易扩展。同时 不同技能的开发人员 ，如UED和程序员 ，可以负责不同部分 ，有效提高开发效率。 好的架构就像一篇优美的散文 ，形散神不散 ，表面看无序 ，实则高度有序。 架构分类和服务对象 架构一般可分业务架构、应用架构、技术架构 ，那么它们分别解决什么问题 ，服务于谁呢 ？ 我们首 先看一个系统落地过程 ： 对于负责开发的人来说 ，怕的是业务太复杂 ，代码逻辑太乱 ，超出他能理解的范畴 ，系统无法维护 。因此开发的需求是系统整体概念清晰 ，容易理解 ，方便扩展。 对于负责运行的机器来说 ，怕的是业务并发量太大 ，系统核心资源不够用 （如数据库连接 ）。它希 望在业务量增加时 ，系统能够支持水平扩展 ，支持硬件容错 （如避免单点故障 ）。 开发的痛点主要由业务架构和应用架构解决 ，业务架构从概念层面帮助开发理解系统 （动态的包括 业务流程/节点/输入输出 ，静态的包括业务域/业务模块/单据模型 ）。 应用架构从逻辑层面帮助开发落地系统 （应用种类/应用形式/数据交互关系/交互方式等 ），整个系 统逻辑上容易理解 ，最近大家谈的比较多的SOA 即属于应用架构的范畴。 机器的痛点主要由技术架构解决 ，如技术平台选型 （操作系统/中间件/设备等 ），部署上希望支持 多机房 ，水平扩展 ，无单点等。 强调一下 ，系统是人的系统 ，架构首先是为人服务的 ，业务概念清晰、应用逻辑合理、人好理解是 第一位的 （即系统有序度高 ）。现在大家讨论更多的是技术架构 ，如高并发设计 ，分布式事务处 理等 ，只是因为这个不需要业务上下文背景 ，比较好相互沟通。具体架构设计时 ，首先要关注业务 架构和应用架构 ，这个架构新手要特别注意。 架构师能力模型 架构师只做分和合的事情 ，但综合能力要求很高 ，要求内外兼修 ，下得厨房 ，上得厅堂 ，下图通过 典型的架构方式介绍一个架构师的能力要求 ： 一个驾校教练 ，必定开车技术好 ，一个游泳教练 ，必定游泳水平好 ，因为这些都是实践性很强的 工作。书上学来终觉浅 ，梅花香自苦寒来 ，架构师亦如此 ，他必定是一个出色的程序员 ，对代码和 系统有