架构设计的三个原则 | 张逸说

标签: | 发表时间:2021-07-27 22:15 | 作者:
出处:http://zhangyi.xyz

在进行架构设计时,我认为需要遵循如下原则:

  • 一致原则
  • 简单原则
  • 演进原则

一致原则

一致性是软件架构质量原则的根基,遵循一致原则的软件架构可以有效地保证整个架构解决方案的清晰直接,降低了解决方案的复杂度。尤其对于一个大规模系统,往往需要多个团队共同开发完成,如果不遵循一致原则,就会导致整个平台的建设缺乏完整性和规范性,各个子系统各自为政,业务功能重复开发,技术实现五花八门,服务集成复杂低效,信息冗余制造出知识壁垒。

一致原则具体体现为:

  • 架构风格的一致性:针对相同的业务复杂度和技术复杂度,要形成统一的架构风格。例如,对外公开的业务能力采用微服务架构风格,保证各个服务的高内聚低耦合,确保了整个系统的可扩展能力;数据采集、治理和分析业务采用基于Lambda架构模式的大数据架构风格,为数据的处理建立批处理层与速度处理层,满足不同业务场景的数据需求;服务之间的异步消息协作采用事件驱动架构风格,保证服务之间消息传递的高效性与实时性,提高整个系统的响应能力;
  • 技术选型的一致性:针对相同或相似的问题,应采用相同的方案和技术,从而使得开发人员在掌握了其中一种解决方案后,针对相似的问题,可以推导出相同的解决方案,降低了方案的复杂度,规避了重复开发,降低了代码的维护成本。以微服务架构为例,技术选型涉及的内容主要包括微服务组件、日志处理、权限管理、分布式事务、数据库访问、消息通信机制、缓存技术、安全策略、开发语言、框架版本、监控运维,同时,还要求开发团队遵循一致的编码规范。

简单原则

软件架构的目的就是为了控制软件系统的复杂度。分析软件系统的复杂度成因,主要来自规模、结构和变化。

对于规模引起的复杂度,可以通过“分而治之”的思想来解决,也就是将整个系统按照业务维度拆分为多个细小而简单的模块(组件或服务),每个服务的规模都是团队或团队成员可以控制的。

结构引起的复杂度取决于参与协作的模块(组件或服务)的数量,数量越多,模块之间的关系就越复杂,因为协作产生的依赖很容易让整个系统变得混乱而无序,增加了开发和维护的成本。要降低复杂度,就需要清晰地定义模块的边界,合理地分配职责,以减少不必要的依赖关系;同时,定义一致而稳定的协作接口,让模块之间的协作变得有序,清晰地体现彼此之间的调用链,明确消息数据的传递方向。

需求的变化总是会带来解决方案的调整,最终使得持续变化的解决方案变得越来越复杂。如何有效地应对需求变化?一方面需要团队提前识别出可能发生变化的热点功能,另一方面也需要注意避免对未来做出过度设计。若能识别出变化的热点功能,就能通过封装或抽象的设计原则,让实现方案尽可能具有可扩展能力,将变化产生的影响降到最低。然而,未来的变化总是不可预测的,如果不能确定未来是否会发生变化,则不要引入太多的间接和抽象,形成过度设计,增加了解决方案的复杂度。

遵循简单原则的架构体现为:

  • 引入领域驱动设计的限界上下文模式帮助合理地识别微服务,明确微服务之间的协作模式,确定业务需求与微服务之间的映射关系,减少不必要的微服务协作;
  • 采用前后端分离,避免了前端用户体验复杂度与后端业务复杂度之间混合导致的复杂度叠加,也可以保证前、后端开发团队明确前后端协作的接口,进行并行开发;
  • 保持模块之间接口的松耦合,从架构上考虑数据分析场景与业务处理场景的分离,以定义数据平台的边界,驱动出数据交换的接口,确定数据平台和业务服务之间的协作方式;
  • 识别复用的业务能力:站在产品高度和全面视角分析业务能力,将满足单一职责的业务能力封装为高内聚的服务或组件,完成功能的复用,降低系统的代码规模,保证了系统的简单性。

演进原则

架构设计不是一蹴而就的,由于需求会不断发生变化,架构设计也需要针对变化的需求做出调整。由于架构做出的设计和决策往往是一个软件系统最为重要的部分,对架构做出的调整成本和难度都比较大,因此,在进行架构设计时,应考虑解决方案的演进能力,即能够随着需求的变化以最小的修改成本实现架构方案的不断演进。

遵循演进原则的架构应满足:

  • 响应变化的能力:演进能力的一个体现是响应变化的能力,一个设计原则是将变化产生的影响控制到最小范围。这一原则确定了架构方案需要按照变化的方向进行模块的划分,从而顺应变化,同时,保证业务复杂度与技术复杂度的正交关系,避免业务的变化影响到技术实现的变化,反之亦然。我们可遵循企业架构的设计思想,根据不同的观察视角将整个系统架构划分为业务架构、应用架构、数据架构和技术架构。其中,为了降低变化影响,让系统的应用架构和数据架构对准业务架构,即按照业务能力对系统的模块(组件或服务)进行职责划分,同时保证每个应用模块中的领域模型与数据模型对应;对于技术架构,则通过分层架构模式将业务与技术分离,保证二者的松散耦合;
  • 职责分配与合理抽象:识别和设计微服务的质量直接影响到系统的演进能力,整个系统需要针对领域进行分析,从业务能力的角度进行功能的职责分配,保证每个微服务是内聚的,同时,通过有效识别变化的热点,对其利用抽象降低彼此之间的耦合,保证了具体实现的可扩展能力与可替换能力;
  • 架构模式的运用:对于业务系统而言,通过采用微服务架构模式、事件驱动架构模式和分层架构模式,尽可能保证整个业务系统的松散耦合,提高系统架构的演化能力;对于数据平台,可采用基于流处理的管道-过滤器模式,通过将数据处理功能拆分为一个个过滤器(processor),然后在管道中自由组合这些过滤器,满足整个数据处理流程的需要。这一模式保证了功能的复用性和可扩展性。

相关 [架构 设计 原则] 推荐:

分层架构设计原则

- - 博客园_首页
通常一个软件系统都包含不同部分互相交互耦合,我们希望设计能够将系统划分为有意义的各个部件,各个部件能够独立的开发、演进、部署. 这时整体性的设计已经无法满足这些挑战,这就需要我们对系统进行合理清晰的划分. 通常我们为待开发的系统定义多个层次,每一层完成独立的功能. 1:系统分为多层,每层完成独立的功能,层内部继续细分子模块,每层能够独立演进、部署.

实战解析Android架构设计原则

- - 移动开发 - ITeye博客
关注微信号:javalearns   随时随地学Java. 经过一段时间收集了大量反馈意见后,我认为应该来说说这个话题了. 我会在这里给出我认为构建现代移动应用(Android)的好方法,这会是另一番体味. 开始之前,假设你已经阅读过我之前撰写的文章“ Architecting Android…The clean way ?”.

架构设计的三个原则 | 张逸说

- -
在进行架构设计时,我认为需要遵循如下原则:. 一致性是软件架构质量原则的根基,遵循一致原则的软件架构可以有效地保证整个架构解决方案的清晰直接,降低了解决方案的复杂度. 尤其对于一个大规模系统,往往需要多个团队共同开发完成,如果不遵循一致原则,就会导致整个平台的建设缺乏完整性和规范性,各个子系统各自为政,业务功能重复开发,技术实现五花八门,服务集成复杂低效,信息冗余制造出知识壁垒.

Android设计原则

- - 所有文章 - UCD大社区
译者按: 在 iOS HIG已经强大经典了N年之后,Android终于推出了一套比较系统的 HIG(大概是为了配合Android 4.0 Ice Cream Sandwich). 仔细比较两套HIG的“设计原则”部分,发现完全是截然不同的两种风格. iOS HIG走的是更专业型的路线,描述严谨且有不少的专业词汇(比如Metaphors、Consistency之类的).

设计指导原则

- - 企业架构 - ITeye博客
避免在循环内部new一些没有必要每次都new的对象. 所有与IO相关的操作,都需要考虑性能问题,一般采取的措施是连接池,缓存,减少调用次数,合并请求. 每个业务都要分析整个请求链路,找到瓶颈,通过压测的方式确认问题及验证解决方案. 根据业务情况,使用异步化和最终一致性. CPU,内存,网络IO,磁盘IO这些瓶颈,需要知道在合适的场景牺牲什么换取什么.

MySql 之表设计原则

- - 互联网 - ITeye博客
1) 不应该针对整个系统进行数据库设计,而应该根据系统架构中的组件划分,针对每个组件所处理的业务进行组件单元的数据库设计;不同组件间所对应的数据库表之 间的关联应尽可能减少,如果不同组件间的表需要外键关联也尽量不要创建外键关联,而只是记录关联表的一个主键,确保组件对应的表之间的独立性,为系统或表 结构的重构提供可能性.

设计模式和设计原则

- - 编程 - 编程语言 - ITeye博客
26.1  设计模式和设计原则. 26.1.1  设计模式和设计原则的关系. 面向对象的分析设计有很多原则,这些原则大都从思想层面,给我们指出了面向对象分析设计的正确方向,是我们进行面向对象分析设计应该尽力遵守的准则.        而设计模式已经是针对某个场景下某些问题的某个解决方案. 也就是说这些设计原则是思想上的指导,而设计模式是实现上的手段,因此设计模式也是应该遵守这些原则的,换句话说,设计模式就是这些设计原则的一些具体体现.

软件架构设计

- - 企业架构 - ITeye博客
软件架构设计尚没有万灵的方法论支持,还是个非常新兴的行业,给出个人理解的行业软件架构设计过程,受个人水平有限,仅供参考:. 1.业务分析:针对目标行业的业务战略、蓝图、业务功能及流程进行分析,提出其中部分功能可以使用信息化进行处理,通过分析可以得出信息化要解决的问题. 2.解决方案设计:根据业务战略,形成行业信息化解决方案.

架构设计-逻辑层

- - 人月神话的BLOG
知乎看到一个问题,也是当前在软件设计开发中普遍存在的一个问题,如下:. 现在要开发一个业务逻辑比较复杂的项目,但是在网上看了设计模式的思想后感觉自己以前写的东西扩展性都不好,接口定义也不合适,都是一个实体类一个接口,项目施工也感觉不合理,感觉项目施工中应该先集中定义好接口,并完成业务逻辑,然后在具体实现接口,不知道这样想是不是正确.

秒杀架构设计

- - IT瘾-dev
最近在部门内部分享了原来在电商业务做秒杀活动的整体思路,大家对这次分享反馈还不错,所以我就简单整理了一下,分享给大家参考参考. 通俗一点讲就是网络商家为促销等目的组织的网上限时抢购活动. 比如说京东秒杀,就是一种定时定量秒杀,在规定的时间内,无论商品是否秒杀完毕,该场次的秒杀活动都会结束. 这种秒杀,对时间不是特别严格,只要下手快点,秒中的概率还是比较大的.