架构图的目的A picture is worth a thousand words （一图胜千言）。架构图是架构师、产品经理、开发工程师、测试工程师等各种角色之间进行沟通的语言和桥梁，让整个团队更能有效地协调工作。设计图不单单是架构师要掌握的，在一个产品的开发过程中，任何一个环节和角色都可以通过掌握不同的设计图来完成沟通。
如何画架构图5.1 架构图的大方向思路：分层、分治、抽象思维。 横向分层构建：按照功能处理顺序划分应用，比如把系统分为 web 前端/中间服务/后台任务，这是面向业务深度的划分。纵向是模块划分和跨层统一相关规范流程：规范流程一般是放具体的标准、规范等，比如安全管理、质量管理、技术标准规范、开发运维规范等。抽象思维：架构构图中的层次如何划分？边界在哪里？应用模块边界如何确定，怎样才能做到高内聚，低耦合。这些都需要抽象思维。架构抽象有两种方法，一种是自顶向下，另一种是自底向上；
业务建模，是从小到大，从局部到整体，自底向上的归纳、演绎的抽象过程；
系统建模，是从大到小，从整体到局部，自顶向下的拆解、切分的抽象过程；
但不绝对，自上而下和自下而上，往往在过程中是随意切换的。
来自于《Thinking in UML》：5.2 架构图核心要素：分层、分模块、分功能横向分层，纵向切分模块。分层：分层也是我们应对和管理复杂性的基本思维武器，目的是为了解耦。将业务按照层级区分，每个层级为独立的逻辑模块层，每一层专注解决某个领域的问题。下层更抽象，上层更具体 。层级需要有逻辑上的关联，如下层为上层服务或者提供能力支撑。分模块：是在同一逻辑层中，有哪些独立模块。一个模块代表一个完整的业务或者同类型的业务聚合。每个模块之间相互独立，且模块之间也会存在依赖或者关联。分功能：在同一个模块内，将独立的功能划分出来，该功能可以代表一个业务入口，简单理解就是一个模块体系中的功能，比较具有代表性，用户比较关注的功能抽象出来。在画架构图前，有必要对整个业务体系进行系统性思考，将穷举所有涉及到的应用、功能、系统、模块、能力、平台罗列出来。然后进行提炼、归纳、分类、总结，然后分类构建代替框架思路，最后按照分层、分模块、分功能的维度将具体的内容填充。5.3 画图的细节总体思路：
保持架构图的结构一致性和语义一致性：架构图之间应该在方框、形状、边框、线条、颜色等方面保持一致。架构图的结构外观应该是一样的，团队不同成员创建的架构图不应该给任何一个利益相关者造成理解上的障碍。理想情况下，可以在所有项目里使用相同的建模工具。从语义角度来看，所有的架构图与最新的代码变更之间以及架构图与架构图之间都应该定期保持同步，因为一个架构图的变更可能会影响到其他架构图。同步可以通过手动进行，也可以通过建模工具自动触发。通过建模工具自动触发会更好一些，不过这也取决于具体的项目。最终的目的是要保持架构图和代码之间的一致性，至于使用什么样的方法或工具可以自行决定。Simon Brown 说，“如果架构图与代码失去了联系，那么就无法用来改进架构”。他的话其实是在强调保持语义一致性的重要性。方框、圆角方框、圆球形、椭圆形、圆角方框：可以参考 E-R 图也称实体-联系图方框：一般表示实体功能，可以用来表达层次。圆角方框 ：一般是加工处理、应用服务、流程规范的模块。圆形：一般表示连接点。椭圆形：表示一种状态或者一种活动过程。 也可以表示模块或者实体的属性。虚线和实线、箭头：一般实线框表示的关系强烈程度高于虚线框，虚线框更重于逻辑上的关联。线条或箭头可以被理解为数据流（比如从系统 A 到系统 B 的数据流）或元素间的关系（比如组件 A 依赖组件 B）。
应用架构图应用架构承接业务和技术，是对整个系统实现的总体架构：描述应用程序的逻辑结构和组成，以及各个功能模块之间的关联和交互关系，用于更好地理解应用程序的设计和实现。主要内容：应用原则：应用架构设计原则或者开发原则。系统分解：横向分层：明确系统的层次结构设计。纵向功能分解：系统各个层次包含的哪些应用服务。在进行系统耦合性拆分时，要平衡业务和技术的复杂度，保证系统形散神不散。系统采用什么样的应用架构，则受到业务复杂度的影响，包括企业的发展阶段和业务特点；同时受技术复杂度的影响，包括 IT 技术的发展阶段和内部技术人员的水平。业务的复杂度（包括业务量大）必然带来技术的复杂度，应用架构的目标是在解决业务复杂度的同时避免技术太复杂，确保业务架构落地。7.1 应用之间的协作（1）稳定原则：
一切以稳定为中心。
架构尽可能简单、清晰，追求小而美，不要大而全。
不过度设计。
（2）解耦
将稳定部分与易变部分分离。
将核心业务与非核心业务分离。
将电商主流程和辅助流程分离。
将应用与数据分离。
将服务和实现细节分离。
（3）抽象
应用抽象化：应用只依赖服务抽象，不依赖服务实现的细节和位置。
数据库抽象化：应用只依赖逻辑数据库，不需要关心物理库的位置和分片。
服务抽象化：应用虚拟化部署，不需要关心实体机的配置，动态调配资源。
（4）松耦合
跨域调用异步化：在不同的业务域之间尽量异步解耦。
非核心业务尽量异步化：在核心业务和非核心业务之间尽量异步化。
在必须同步调用时，需要设置超时时间和任务队列的长度。
（5）容错设计
服务自治：服务能彼此独立修改、部署、发布和管理，避免引发连锁反应。
集群容错：应用系统集群部署，避免单点服务。
多机房容灾：多机房部署、多活。
应用架构图可以分为应用功能/模块架构图和单个应用技术架构图。7.2 应用功能架构图站在整个系统的视角，描述整个系统逻辑架构。简单来说应用功能架构需要的是体现出应用有哪些业务模块，有哪些具体的业务功能点，而不是关心应用实现的技术内容。可以按照功能处理顺序划分应用层次。如果系统比较复杂，包含的应用可能有几百上千个，如果把所有的应用都在一张图里面展示出来，信息太多太密，可能会导致架构图都看不清。这种情况下，应用架构一般都是按照子域来画应用架构图。7.3 单个应用技术架构图应用技术架构描述的重点不是讲清楚应用有哪些功能，而是要说清楚应用中的每一个功能是如何通过技术分层来实现的。比如你需要先定义数据库结构，开发数据访问接口，然后编写业务规则逻辑，最好实现前端界面展现设计，再将所有分层内容连接起来。所以应用技术架构更多是应用实现技术层面的内容，而不是去关心应用实现用的底层 IT 基础设施资源。在应用技术架构里面一般不会涉及到底层具体的资源或平台，如果应用技术架构在底层增加了类似 IT 基础设施，存储等内容，就显得不伦不类了。7.4 时序图，也称为顺序图、序列图描述应用程序模块之间的每一步调用过程。有时候某个业务功能的流程会比较复杂，涉及到多种角色或者模块，这时就可以使用时序图来梳理这个业务逻辑。这样会使业务看起来非常清晰，代码写起来也是水到渠成的事情了。
一般是加工处理、应用服务、流程规范的模块。
文章评论