架构设计方法论-思维导图梳理

汪超

已于 2023-02-01 21:51:13 修改

阅读量442

点赞数

分类专栏：方法论文章标签：架构 Powered by 金山文档

于 2023-01-14 18:38:36 首次发布

本文链接：https://blog.csdn.net/wangchaodee/article/details/128687561

版权

方法论专栏收录该内容

9 篇文章 0 订阅

订阅专栏

一、文章概要

本文主要对Java技术栈的架构设计理论及重要特性场景进行系统性的总结梳理，内容较多，按不同内容贴思维导图，持续更新中。

二、思维导图

- 设计模式及UML

设计模式及UML

设计模式的设计原则对进行系统的功能设计起指导作用，提倡高内聚低耦合的方式来实现功能，封装变化应对不同场景，提高功能及组件的复用；关于应对需求变化及可扩展性方面，设计模式提供了个原则不过度设计，也就是说适当的留一点应对变化的可能性设计就好了，先期也不比特别的纠结考虑；

UML 是一种通用的进行功能设计表达的图形化方法，我只是罗列了我常用的一些图示，在需求分析中常常会用到用例图静态的表示用户期望的功能；用类图、包图、组件图分别的痛细粒度到粗粒度来表示代码开发过程的代码类关系、层级划分和模块划分等，当然也常用类图表示业务领域模型，用组件图来表示系统的逻辑架构等；活动图中的时序图常常是为了能够从时间角度动态的表达请求的处理逻辑；状态机图则是为了表示某功能对象在不同的状态下会具备哪些功能动作或者是哪些动作会导致变化，比如TCP的状态转换就是个状态机图，很好的表达连接状态及不同响应操作的关系；活动图通常会包含多业务角色或者是不同组件来协作处理一些业务，往往会有一些事务性。

2、架构演进

我觉得单体架构向SOA系统的演进是业务规模进一步提升，需要更多的节点系统协作解决业务问题，设计理念上存在按照单体模式系统化解决非功能性问题，但最终由于这些解决方法的复杂度超出大多数开发者的理解和应用水平，随着微服务以更简便易懂的方式来解决共性的非功能性问题后，SOA自然而然的逐步退场，随着微服务的逐步发展，自动化的运维诉求增加及应用条件成熟，集群化管理应运而生。SpringCloud是将共性问题以应用服务的方式提供给开发人员开发和使用，K8s和ServiceMash 则更偏向于将共性问题封装到底层以给SRE去使用和解决，对业务开发者进一步透明化，后者应该是趋势，不过从技术能力成长的角度还是需要多关注些底层原理和技术实现，否则能力范围会被进一步压窄。

3、场景问题

a、远程调用和RESTful接口设计

远程调用是为了解决内部通信场景的问题，集群内的通信往往更侧重性能，调用也会尽量使用直连方式（也就是不加代理），RESTful 往往是对外的通信场景，通过结合HTTP的语义规范可以简化接口设计也更方便对接沟通。

b、事务处理

怎样能更好的理解事务处理呢？我觉得关键是要理解数据一致性问题，单机角度内存和磁盘也是不同的角色，磁盘才能保证数据一直，但是磁盘写入慢（随机写入相对顺序写入更慢），所以单机事务的处理有以日志的方式顺序写数据，另外由于多核CPU和线程切换的原因会存在并发的场景，为了保证事务间不相互影响需采取隔离措施即用锁来进行控制，当然了为了在可用性和性能之间权衡，有了不同的控制策略。

分布式事务相对本地事务的最大差异是多节点之间网络通信的不可靠，多了更多的协调工作，这个时候理解需要将单个节点本地的事务过程当成透明的，重点理解多节点如何进行协调统一工作的，同步的场景是要全部投票通过，然后再次执行，所以至少是两个阶段，同步的优势是能够达成强一致性，但性能低。异步方式或者说允许系统采用最终一致性，此种方式有重试机制、取消机制等来确保事务被处理。