你知道如何画好一幅架构图么？
用一分钟时间，你能在脑海里构造一幅你最熟悉的系统的架构图么？先别往下看，本身先想象下。html
混乱的架构图
不知道你想象中的软件架构图是怎样的，但我猜测你们画的应该跟百度或者谷歌搜索“架构图”出现的结果同样：五花八门、形状各异。程序员
致使这个现象的缘由，我的认为有如下几点：安全
- 软件架构的定义在大多数人内心不够清晰
- 软件架构是多维的，难以用简单某个维度描绘全景
- 不一样角色对于一个系统的关注点不同，所以其指望的软件架构图就会不同
- 对于软件架构图这个领域缺乏一个全软件行业通用的“领域通用语言”，致使不一样公司/人对 同一个名词的理解各有差别
本文将试图从以上几个缘由出发，理清架构图与架构的关系，让你们能画出与场景、角色相符的架构图。服务器
何谓软件架构
要画架构图，那么咱们首先须要清楚架构是什么东西。网络
维基百科中，其说明软件架构描绘的是：架构
- 构建构件及软件系统的高层规则
- 软件系统高层构件相互协做关系
软件系统中的“架构”一词引伸来源于建筑学中的“架构”，架构是一个软件系统的蓝图，其将会为后续的详细设计团队指明设计方向,也会为不一样的系统相关方提供一个快速了解系统设计的途径。负载均衡
所以架构也是一个系统的根基、骨架，其在整个软件系统生命周期中是详细设计的基础，若要改动则会伤筋动骨。运维
所以在架构设计时对各类构件的选型应综合考虑各方面的诉求，适当选择tradeoff,避免架构成为整个系统的瓶颈。微服务
软件架构的维度
咱们对一个软件系统有不少维度的要求，例如：工具
- 功能性需求
- 系统容错性(fault-tolerance)
- 向后兼容性(backward compatibility)
- 可扩展性(extensibility)
- 可靠性(reliability)
- 可维护性(maintainability)
- 可用性(availability)
- 安全性(security)
- 易用性(usability)
- ......
不一样的角色，对一个软件系统架构所关注的角度也不一样，例如：
- 用户关注的是其功能实现、易用性及可靠性
- DDD的模型设计者关注的是各个领域模型之间的关系
- 开发者关注的是使用的开发技术栈、开发是否简单
- 运维关注的是安全性、可用性、系统容错性、物理部署等
- 系统全部者可能关心的是系统的可扩展性、可维护性
咱们从上面能够看到，开发设计一个软件系统须要综合多个维度的考量，然而咱们所看见的图仅是一个二维的表示，正所谓横当作岭侧成峰，是没有办法把如此多维的信息一次过展示出来的。
所以须要完整地描述一个系统的架构必然须要从不一样的维度出发，正交分解出某个维度的关注点，并将其在二维的图中将其展现出来。
当各个维度都描述完成，在读者人脑中，对这些二维数据进行组装后，这个系统的立体形态就会被完整地呈现出来。固然不一样人关注点也不同，可能也不必每一个人都熟悉一个系统的全部视图。
回到标题所描述“画一个你最熟悉系统的架构图”时，咱们能够知道，这个问题可能并不太严谨，由于架构是多维的，一幅架构图只能从某一个维度去描绘架构。固然，这问题也有正确解，就是你从多个维度分别画出多个架构图。
软件架构的视图
正如上所说，软件架构是多维的，受限于人类的思考能力及展现工具，咱们只能选择从某个视图（角度/维度）去看一个系统，由于看一个系统的维度不少，所以不一样公司在内部诞生了不少不一样的名词：
- 技术架构
- 逻辑架构
- 物理架构
- 系统架构
- 应用架构
- 开发架构
- 运行架构
- 数据架构
- ......
不知道你们看晕了没有，反正我是看晕了。以上的各类架构的名词在不一样的公司会有不一样的含义，例如逻辑架构一词，有的公司指代的是从业务逻辑维度看的架构（DDD的模型等），有的公司可能则指代一些中间件之间的主要协做与交互。
实际上一个名词在不一样公司有不一样含义是很正常的事情，这取决于我的背景、或者更具体的——各个公司领导有没有对某个名词原有的含义产生误解（或者说名词自身就含有歧义）。
所以你们与人交流时，没必要纠结于名词自身，更没必要因名词定义而对某样事情否认，咱们在交流过程当中应该寻找名词背后的逻辑。
4+1视图
上面的各类名词混乱固然不是一个好的现象，咱们固然最好能构建一个“统一通用语言”，而4+1架构视图是一个相对流行的架构视图划分方法。
4+1：
- 逻辑视图
- 开发视图
- 物理视图
- 运行视图
- 业务场景视图
逻辑视图
逻辑视图关注的是提供给最终用户的功能，所以其描述的是各个功能相关构件之间的协做关系，主要面向用户、业务人员、开发组织。
其主要从系统的功能元素、以及它们的接口、职责、交互维度入手。主要元素包括系统、子系统、功能模块、子功能模块、接口等。
如UML中的类图、DDD中的模型，微服务中的各个服务间协做关系 等都属于逻辑视图的范畴。
开发视图
开发视图从程序员角度去描绘架构，主要关注各种软件包之间的协做关系，其不只仅包含本身写的包，还包括应用程序依赖的SDK、第三方类库、中间件等。
在DDD/MDD的理念中，在自行管理表征业务逻辑的包/代码将会和逻辑视图的模型一一对应。
软件分层图、开发技术栈图、应用与中间件协做视图 等都属于开发视图的一部分。
物理视图
物理视图是从系统管理员的角度描绘系统的。其主要关注系统软件组件在硬件层次的部署以及系统硬件之间相互协做关系。
物理视图会包含具体的物理硬件及其部署的应用，如F5及其负载均衡、应用服务器及在上面运行的应用、各种中间件服务器及其上面运行的中间件还有网络及IP等等元素
一个合理的物理架构设计，能支持通过合理设计的软件系统实现 高可用、横向扩展等特性
运行视图
运行视图侧重于描述系统运行态，关注解释系统在执行中的动做和组件如何沟通。
对于本视图，我的了解不深，也没法举例说明。往各位大佬指点。
业务场景视图
用部分关键业务场景来描述软件系统自身。这些业务场景案例能够用来走查架构设计中各个对象的协做关系，校验总体架构设计的合理性，并做为验证架构原型可用性的测试案例。
其余视图
除了4+1视图外还有一些额外的视图：
- 数据视图（数据持久化、副本策略等）
- 安全视图
如何画好一幅架构图
再次回到标题，到如今，咱们知道，要画好一幅架构图，首先须要明确的是咱们要从多维的架构里选择哪一维做为展现的重点。或者说，咱们要明确画的这幅图是给谁看的，其对这幅图所关注点是什么。
这样咱们才能够有的放矢，在其所关注的维度（逻辑、物理、运行、开发、数据等等）里，选择其关注的粒度（系统、服务、实例、接口等等）进行架构的描绘，才能得到特定阅读者赞同，于是才能成为一幅好的架构图。
而对于一幅架构图的关注点不明确/需求不明确时，咱们能给出的图必然是模棱两可，触达不到痛点的。但愿咱们能记住这一点，以此律己律人。
最后
本文是基于目前我的理解及多篇文章的参考而成，若本文对你有帮助，麻烦右下角点赞～，若文章有谬误，望不吝批评斧正！
做者简介：多年金融码农，现为某信用卡中心架构师，EasyTransaction做者，欢迎关注做者公众号：
ref: