如何做架构设计?

如何,架构设计 · 浏览次数 : 495

小编点评

## 总结 本文提供了一个软件架构设计的重要思考角度,包括以下几点: **1. 设计的重要性** * 设计是创造和改善事物的重要过程。 * 设计决定最终结果,甚至决定着事物的长期的发展。 **2. 架构设计的目的是什么** * 解决软件系统复杂度带来的问题。 * 确保业务和研发效率的敏捷。 * 让应用的易变部分能够频繁地变化,对应用的整个生命周期都有影响。 **3. 架构设计文档的需要** * 包含架构师参与的所有环节。 * 包含架构师的思路和想法。 * 包含业务模型、技术方案、可扩展性等方面的详细描述。 **4. 架构设计中需要考虑哪些因素** * 业务需求 * 技术需求 * 可扩展性 * 可维护性 * 等等 **5. 如何才能做更好的架构设计?** * 学习和使用领域驱动设计。 * 在业务领域建模和在产品方案阶段介入、推动领域知识的传递、为后续做好铺垫。 * 积累业务能力和洞察力,识别关键部分与辅助部分、预料可扩展部分与不变部分。 * 对于架构设计产物,不要只画图,多辅以文字表述图中内容。 **6. 需要掌握哪些知识?** * 业务架构 * 现状架构 * 愿景架构 * 高性能 * 高可用 * 扩展性 * 等等 **7. 如何评价架构设计?** * 根据业务需求和技术能力进行评估。 * 考虑方案对业务影响、技术需求、可扩展性和安全性等方面的评估。 **8. 总结** 软件架构设计是一个复杂的工程,需要考虑很多因素,才能得到一个有效的架构设计。建议使用领域驱动设计等方法,在业务领域建模和在产品方案阶段介入,推动领域知识的传递,为后续的设计做好铺垫。

正文

也许您对软件设计存在一些疑惑,或者缺乏明确思路,那么本文将非常适合您。

1、设计很重要

我们可以看一下周边的事物,那些好的东西,他们并不会天然存在,都是被设计出来的,因此设计就是创造和改善事物的重要过程。设计的重要之处在于,最初的设计往往决定最终的结果,甚至决定着事物的长期的发展。例如两个品牌的手机之间,他们可以使用同一个代工厂,但他们差异在设计时就已经决定了。

架构设计也是如此,我见过很多的软件系统,他们经过了很多年的演进,在没有完全重构的情况下,始终无法改变最初设计模样,最初的设计决定了长期的发展。而对于业务深度耦合的系统,重构成本非常高,风险也非常大,变化也更加不确定,所以要更加重视设计。

我们要寻求更好的技术方案,推动架构的良性演进,每一步都是经过深度思考的,而架构设计方法就是帮助我们思考的框架。

通过做架构设计,我们应该提升软件的质量和效率,降低风险和成本。

2、架构设计的目的是什么?

是为了解决软件系统复杂度带来的问题(架构的目标是用于管理复杂性、易变性和不确定性,以确保在长期的系统演化过程中,一部分架构的变化不会对其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷,让应用的易变部分能够频繁地变化,对应用的其它部分的影响尽可能地小。)

要解决复杂度问题,首先需要识别复杂度的来源,主要集中在以下三个方面:

业务复杂度:流程多,参与者多、状态和变量多等;由业务本身决定,但业务复杂不代表软件系统复杂,例如工作流引擎并不复杂,但他可以做非常复杂的业务,在面对复杂业务时,我们常使用抽象思维,不要让软件逻辑与业务逻辑绑定在一起。

技术复杂度:高性能、高可用、高可扩展、安全,成本、规模等;这部分复杂度常常由技术本身决定,也应该由技术本身解决,通常是采用更合理的框架和工具;避免这些技术特性穿透到应用层。也可以有所取舍,在不同业务情况下,采用不同的实现程度。

设计复杂度:职责不是最小的完备的、概念不清晰的、层次不清的、业务逻辑与技术实现绑定的,组件过多以及关联依赖复杂的;这部分是由设计不合理导致的,也是对业务系统影响最大的一部分,要通过良好的设计来解决。

3、架构设计的主要内容是什么?

找到系统中的元素并搞清楚他们之间关系(如果我们不知道系统是怎么运行的,那么他一定是很复杂的。对于庞大的软件系统,如何才可以被掌控?这就需要将大系统分解为很元素,每个元素需要足够简单,并且元素与元素之间的关系清晰)

软件架构是一种结构,结构中包含了一些元素和元素之间的关系描述;

元素的种类:系统、子系统、模块,组件、服务、类、接口...

关系的种类:层次关系、数据关系、调用关系、影响力关系...

"架构表示对一个系统的成型起关键作用的设计决策,架构定系统基本就成型了,这里的关键性可以由变化的成本来决定。"-- Grady Booch.

"Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." -- Grady Booch.

4、架构设计有什么原则?

合适原则:“合适优于业界领先”。 真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的,能够合理地将资源整合在一起并发挥出最大功效,并且能够快速落地。

简单原则:“简单优于复杂”。 优先使用直接的不复杂的方案解决问题;

演化原则:“演化优于一步到位”。软件需要根据业务的发展不断地变化,架构要不断地在实际应用过程中迭代,在某个阶段必定有所取舍,但架构的演化必须是低成本的,当业务发生变化时能够最高效的迭代;在这个过程中修复缺陷的设计,积累优秀的设计;

5、架构师的职责是什么?

业务分析:梳理对业务和技术的理解和判断、形成业务领域知识、明确的业务目标和本质的业务诉求;

系统建设:降低系统复杂性、规划系统远期架构、推动架构的合理演化;

技术方案:选择合适的技术、提供对业务的解决方案,把控全局,包括质量、效率、成本、风险;

关键问题:攻克难点,解决关键问题,指导研发落地;

知识沉淀:以体系化的表达方式,面向不同人员的视图语言,持续完善知识系统;

6、架构设计过程如何?

过程:全局分析业务 → 设计方案 → 概要设计 → 详细设计 → 补充设计

视角:业务级 → 系统级 → 应用级 → 模块级 → 技术级 → 代码级 → 实施级;

架构师的协作链路较长,每一个过程都应该留下资料,越下游的角色往往需要更全面的资料;架构设计文档应该包含架构师参与的所有环节,以及这些环节产生的图文说明;不仅仅是空洞的结果,应该包含架构师的思路和想法;

全局分析阶段

这阶段需要对业务需求进行全面分析,需要将名词罗列出来,区分名词是功能、流程、名词、参与者的哪一种。再通过分析业务的本质并找到其中的关键名词,关键的名词被称之为领域,可以围绕关键的领域构建业务模型;

在这个过程中,需要统一语言、识别核心领域、按照相关性将功能归属到对应的领域,对领域之间的关系做出必要的描述,输出物是名词与解释、领域以及拥有的能力,业务架构。

名词的概念必须是清晰的,领域的职责必须是明确的,领域拥有的能力必须是相关的;

其中业务架构可按照场景层、功能层、领域层、依赖层划分,例如下图;

设计方案阶段

在完成全局分析之后,我们应该设计技术方案,尽可能提供多个备选方案的图文说明。需要对备选方案做充分的优劣分析,最终取舍一项最合适的方案,没有被选择的方案(或者取舍的部分)也要被说明;

我们需要找到各项约束条件(时间、人力、硬件等),评估在约束条件允许的情况下,哪个备选方案更合适,我们可能考虑如下方面:

方案对业务影响:主要判断需求覆盖程度、实现业务的短期目标、考虑业务的长期目标;

方案的技术需求:安全是否满足、性能是否满足、规模是否满足、可维护性;

方案的可扩展性、方案的复杂程度、方案是否能够演进、方案演进成本如何(高成本的 慎重考虑)、方案的影响力传播如何(对上下游影响较大的 慎重考虑);

架构设计阶段-应用架构

用以说明当前系统的元素(系统、子系统、模块,组件)以及他们之间的关系(层次关系、依赖关系)

重点是将可复用的组件抽象后下沉,越往下层越是稳定和通用,由上层承接不稳定的业务;

应用架构图体现了层次关系,以及不完全体现了依赖关系,依赖只能是上层依赖下层,示例如下图

架构设计阶段-部署架构

用以说明支持应用所需要的硬件能力、以及外部中间件、网络、机房等情况;可参考下面两张图;

架构设计阶段-数据架构

描述数据资产结构、存储、流转、灾备的情况;最常用的是ER图;

架构设计阶段-技术架构

描述一些关键技术的说明,比如性能、安全、交互等;

描述技术选型和代码框架的说明,比如DDD推荐的菱形对称架构,文字和图片描述都可以;

7、有什么方法能做的更好?

学习和使用领域驱动设计,使用正确的方法梳理和理解业务,并落实到架构过程;

尽早的介入,从业务领域建模和在产品方案阶段介入、推动领域知识的传递、为后续做好铺垫;

积累业务能力和洞察力,需要识别关键部分与辅助部分、预料可扩展部分与不变部分,识别水平能力与垂直扩展;

对于架构设计产物,不要只画图,多辅以文字表述图中内容;

8、还需要掌握什么知识?

业务知识:业务架构(是对当前业务、领域、能力、流程、参与者、场景的介绍),现状架构(是对当前架构的描述,可以包含应用架构、技术架构、部署架构、数据架构等),愿景架构( 是架构应该演进到的完美情况),存在问题(现在面对的痛点、无用部分、缺陷部分)

高性能:多线程、队列、缓存、分片、异步化,前置化、静态化、预处理;

高可用:限流、降级、冗余、灾备、回滚、灰度;

扩展性:多态、防腐,依赖反转(业务身份、扩展点、SPI),抽象化(比如流程引擎、规则引擎等)、事件驱动、设计模式;

本文部分图片来源于互联网

作者:京东科技 董健

来源:京东云开发者社区

与如何做架构设计?相似的内容:

如何做架构设计?

我们要寻求更好的技术方案,推动架构的良性演进,每一步都是经过深度思考的,而架构设计方法就是帮助我们思考的框架。通过做架构设计,我们应该提升软件的质量和效率,降低风险和成本。

突破传统监测模式:业务状态监控HM的新思路

在系统架构设计中非常重要的一环是要做数据监控和数据最终一致性,这里主要讲如何去补偿?补偿的方案哪些?这就引出来数据监控系统了。有小伙伴会问了,为什么业务状态监控系统可以做补偿?别急,且看本文。

突破传统监测模式:业务状态监控HM的新思路

在系统架构设计中非常重要的一环是要做数据监控和数据最终一致性,关于一致性的补偿,已经由算法部的大佬总结过就不再赘述。这里主要讲如何去补偿?补偿的方案哪些?这就引出来数据监控系统了。有小伙伴会问了,为什么业务状态监控系统可以做补偿?别急,往下看。

如何让技术架构师具有预知未来业务发展的能力?

大家好,今天我们来分享业务架构,但是我们并不是以产品经理角度讲述一个业务架构是什么以及如何做?而是以一个技术架构师的角度,讲述如何承接业务架构或在没有业务架构的时候,如何判断业务变化趋势而对系统架构提前做出反应。

海量监控数据处理如何做,看华为云SRE案例分享

摘要:openGemini的设计和优化都是根据时序数据特点而来,在面对海量运维监控数据处理需求时,openGemini显然更加有针对性。 IT运维诞生于最早的信息化时代。在信息化时代,企业的信息化系统,主要为了满足企业内部管理的需求。通常是集中、可控和固化的烟囱式架构。传统IT运维,以人力运维为主,

手动实现BERT

本文重点介绍了如何从零训练一个BERT模型的过程,包括整体上BERT模型架构、数据集如何做预处理、MASK替换策略、训练模型和保存、加载模型和测试等。 一.BERT架构 BERT设计初衷是作为一个通用的backbone,然后在下游接入各种任务,包括翻译任务、分类任务、回归任务等。BERT模型架构如下

如何实现一个简单易用的 RocketMQ SDK

2018 年,做为架构负责人,接到一个架构需求:实现一个简单易用的 RocketMQ SDK 。 因为各个团队 RocketMQ 原生客户端配置起来千奇百怪,有的配置存在风险,各团队负责人都需要一个简洁易用的 RocketMQ SDK 。 我立马调研相关开源的方案,当时 RocketMQ-Sprin

一条SQL如何被MySQL架构中的各个组件操作执行的?

摘要:一条SQL如何被MySQL架构中的各个组件操作执行的,执行器做了什么?存储引擎做了什么?表关联查询是怎么在存储引擎和执行器被分步执行的?本文带你探探究竟! 本文分享自华为云社区《一条SQL如何被MySQL架构中的各个组件操作执行的?》,作者:砖业洋__。 1. 单表查询SQL在MySQL架构中

[转帖]k8s发布Spring cloud+eureka架构服务优雅启动停止方案

本文转载自昆仑枫的简书https://www.jianshu.com/p/6d393cbb694a Spring cloud+eureka是目前微服务主流解决方案之一,kubernetes则是广泛应用的发布工具,两者结合使用很常见。而两者结合时如何优雅启停从而实现无感发布很关键。下面将从不做特殊处理

Azure DevOps(一)基于 Net6.0 的 WPF 程序如何进行持续集成、持续编译

一,引言 我们是否正在为如何快速的编译、部署客户端应用程序而烦恼?这也是博主最近遇到的问题。目前博主所在公司主要做项目级的定制化开发,多以 C/S 架构的 WPF 程序为主,每次到了协助开发团队给实施团队编译好的要测试程序包时,就会出现多人协助,编译、打包好的二进制程序包 pull 最新代码 ,以及