概念、演进与设计目的一、程序员的架构师之梦几乎每个程序员内心都拥有成为架构师的理想。但很多人在走向架构师的路上会遇到重重困惑。很多技术能力扎实、业务理解到位的工程师往往会卡在架构设计这一关。作者结合自身经历发现从接触架构设计到初步掌握架构设计需要数年实战沉淀。这并非个人天赋问题而是架构设计本身具备三个显著特征思维模式差异巨大程序开发核心是逻辑与实现架构设计核心是判断与取舍。很多开发人员做架构时依旧沿用写代码的思维容易陷入困境。缺少体系化训练资料高校几乎没有专门的软件架构课程市面上大部分书籍只讲解某一个技术点缺少完整、体系化的方法论学习者只能自行摸索效率低下。大量普遍认知误区很多人觉得架构师需要极高天赋、必须充满创造性认为架构一定要追求高大上系统必须天然做到高性能、高可用。这些误解让不少技术人员还没开始实践就心生畏惧。架构学习不是背诵一堆中间件与技术名词而是掌握一套通用的方法论。无论业务场景、编程语言如何变化都可以依靠这套方法论完成架构设计、评审、分析工作。专栏知识体系主要分为五大模块架构基础、高性能架构模式、高可用架构模式、可扩展架构模式、架构实战。通过学习可以理清架构相关概念掌握通用设计原则、标准设计流程理解各类成熟架构模式学会架构演进与开源系统使用技巧。二、厘清核心概念到底什么是软件架构日常工作中 “架构” 一词被高频提及但多数人无法给出清晰准确的定义。要理解架构先要区分三组极易混淆的概念系统与子系统、模块与组件、框架与架构。2.1 系统与子系统系统由一批相互关联的个体组成遵循既定规则运行能够产生单个个体无法实现的全新能力。三个关键点存在关联、遵循运行规则、具备整体涌现的新能力。子系统本质也是系统只是观察层级不同。一个大系统可以拆分为若干子系统而子系统内部还可以继续拆分更小的子系统。举例微信是完整系统聊天、登录、支付、朋友圈属于它的子系统朋友圈子系统内部又可以拆分评论、点赞、动态子系统。2.2 模块与组件二者都是系统拆分出来的单元拆分视角不一样模块逻辑视角拆分目标是职责分离按照业务逻辑进行划分。例如登录注册模块、成绩管理模块。组件物理视角拆分目标是单元复用代表可独立、可替换的物理单元。例如 Nginx、MySQL、Redis。案例学生信息管理系统逻辑拆分模块登录注册模块、个人信息模块、成绩模块物理拆分组件Nginx、Web 服务、MySQL 数据库。2.3 框架与架构框架代表规范同时提供基础实现。MVC、MVP 属于规范Spring MVC 是落实 MVC 规范、附带基础功能的开发产品。架构代表系统的结构描述系统如何组织、各部分如何协作。同一个系统可以从多个不同维度描述架构业务逻辑维度、物理部署维度、开发规范维度这也就是 RUP“41 视图” 思想的来源。2.4 架构重新定义软件架构指软件系统的顶层结构。这个定义包含三层含义明确系统由哪些子系统、模块、组件等个体构成明确各个个体之间的协作、交互、运行规则“顶层结构” 用来区分不同层级避免混淆系统架构、子系统架构。【此处插入图 1 MVC 架构示意图】图题MVC 架构逻辑示意图思考题你之前理解的架构是什么对比本定义存在哪些差异三、软件架构设计的历史演进软件架构不是凭空诞生它是软件开发发展到一定规模之后的产物。梳理编程语言与软件工程的演进能够理解架构出现的底层动因。机器语言1940 年代前直接二进制编码缺点难写、难读、难修改调试成本极高。汇编语言1940 年代助记符替代二进制指令。虽然可读性提升但依旧绑定 CPU 硬件需要熟悉底层硬件细节不同处理器代码不能复用。高级语言1950 年代起Fortran、LISP、Cobol 相继诞生。开发者不用关心硬件细节聚焦业务问题一份代码可编译运行于多种硬件平台。第一次软件危机催生结构化程序设计60‑70 年代软件规模快速膨胀出现质量低下、项目延期、预算超支等大量问题代表案例 IBM System/360 操作系统项目该项目的经验催生经典著作《人月神话》。应对方案软件工程思想结构化程序设计抛弃 goto采用自顶向下、逐步细化、模块化思路。诞生 “模块” 的概念用来管控逻辑复杂度。第二次软件危机催生面向对象80 年代硬件飞速迭代业务需求持续变化。结构化编程能够处理逻辑复杂但难以应对业务持续扩展带来的变更问题。面向对象思想迎来大规模普及C、Java 推动其成为主流开发范式诞生 “对象” 概念解决业务扩展的复杂度。软件架构正式流行90 年代当软件规模继续变大算法、数据结构不再是最大难题真正的问题变成大量组件如何组织在一起系统耦合过重、改动牵一发而动全身、排查修复故障困难。卡内基梅隆大学研究观点当系统由大量部件组成时系统整体组织方式也就是软件架构带来了全新的设计挑战。发展脉络总结60 年代危机 → 结构化编程模块80 年代危机 → 面向对象对象90 年代大规模系统 → 软件架构组件。本质上三者都是软件的拆分手段只是随着系统复杂度上升拆分粒度变得越来越粗层级越来越高。软件行业不存在 “银弹”没有任何一种技术、方法论可以一劳永逸解决所有软件问题每种方案都只是对应特定时代、特定问题的解法。四、架构设计真正的目的对抗软件复杂度很多人对架构设计存在不少认知误区误区 1因为架构很重要所以要做架构设计。反驳小型创业项目没有专门架构设计也可以快速上线运行架构设计本身要投入人力时间盲目做架构反而拖慢进度。误区 2所有系统都必须完整做架构设计。反驳盲目照搬大厂架构很容易出现水土不服削足适履反复重构。误区 3架构设计就是要做到高性能、高可用、高扩展。反驳不分业务场景一味追求各种 “高”会造成架构过度复杂项目落地遥遥无期。架构设计真正目的架构设计核心目的就是解决软件系统复杂度带来的各类问题。这条原则可以指导架构师的绝大多数决策面对繁多需求优先识别业务系统的复杂点针对复杂点开展设计不需要面面俱到参考业界方案要理解别人架构要解决的是什么复杂点对比自己业务的复杂点再决定是否借鉴而不是直接复制抵制技术炫技不能单纯为了使用新技术、追赶潮流引入架构方案如果业务并不存在对应的复杂度引入就是多余负担。实战案例学生管理系统以一所大学学生管理系统举例分析它的复杂度分布性能访问量很低MySQL、Nginx 就足够性能不是复杂点可扩展性业务功能稳定扩展需求少高可用服务短暂宕机 2 小时对业务影响不大但是学生数据绝对不能丢失存储可靠性是核心复杂点安全性具备隐私但不属于金融级强保密做好账号权限、访问控制即可成本服务器数量少成本压力很小。因此本系统架构重点解决存储可靠性设计 MySQL 主备 跨机房备份策略不需要引入缓存、负载均衡、异地多活等复杂组件。【此处插入图 2 学生管理系统架构图】图题学生管理系统参考架构主机房 备份机房 MySQL 主备方案架构没有绝对好坏只有是否适配业务的复杂度。架构师最重要的工作就是识别业务主要矛盾针对性取舍而不是堆砌高大上技术。五、小结架构师的核心思维是取舍判断区别于普通开发聚焦逻辑实现分清系统 / 子系统、模块 / 组件、框架 / 架构是理解架构的基础软件架构是系统的顶层结构软件工程演进历史本质就是人类不断对抗软件复杂度的历史模块‑对象‑组件代表不同时代的拆分思想不存在万能银弹架构设计的根本目的解决软件系统复杂度一切脱离业务复杂度的架构设计都是过度设计。思考题拿你现在工作接触的业务系统按照 “识别系统复杂度” 思路做一次分析思考哪些是真正复杂的地方哪些属于多余的设计。