演进式架构

这篇具有很好参考价值的文章主要介绍了演进式架构。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

  • 演进能力是一种元特征和保护其他所有架构特征的架构封装器
  • IEEE 的软件架构定义中的4+1
    视图模型。它关注不同角色的不同视角,将整个系统划分成了逻辑视图、开发视图、进程视图和物理视图
  • 架构师确定了可审计性、数据、安全性、性能、合法性和伸缩性是该应用的关键架构特征。随着业务需求不断变化,每个架构特征都通过适应度函数来保护其完整性。
  • 康威描述道,在设计的最初阶段,人们首先需要高瞻远瞩地思考如何将职责划分为不同的模式。团队分解问题的方式会左右他们之后的选择,这便是康威定律。
    康威特别提醒软件架构师,不要只关注软件架构和设计,还应关注团队之间委派、分配和协调工作的方式。
  • 演进式架构主要由三方面构成:增量变化、适应度函数和适当的耦合

适应度函数:

  • 全系统适应度函数允许架构师通过统一的机制思考不同的问题,捕捉和保留重要的架构特征。
  • 原子适应度函数与整体适应度函数、触发式适应度函数与持续式适应度函数、静态适应度函数与动态适应度函数、自动适应度函数与手动适应度函数\临时适应度函数、针对特定领域的适应度函数
    尽早确定 适应度函数、预设式高于应急式、审查适应度函数

实施增量变更:

只有成功完成了架构设计、实现、升级和无法避免的变更后,甚至当架构能够经受由前期未知的未知因素引起的反常事件(第6 章将介绍)带来的考验时,架构师才能评价架构的长期有效性
驱动敏捷软件方法论的引擎是内置的反馈环,如测试、持续集成和迭代等。然而包含应用程序最终用户的反馈环已经脱离了团队的控制。使用假设驱动开发,我们能以一种前所未有的方式将最终用户纳入构建流程,从他们的行为中学习并构建出对其真正有价值的系统

架构耦合:

  • 模块化-模块意味着逻辑分组,而组件意味着物理划分。
  • 架构的量子和粒度-架构量子则是具有高功能内聚并可以独立部署的组件,它包括了支持系统正常工作的所有结构性元素。在单体架构中,量子就是整个应用程序,每个部分都高度耦合,因此开发人员必须对其进行整体部署。微服务架构在架构元素之间定义了物理限界上下文,封装了所有可能变化的部分。这种架构就是为了增量变更而设计的。
  • 不同类型架构的演进能力
    -大泥团-非结构化单体、分层单体、模块化的单体架构、微内核架构、事件驱动架构
  • 微服务架构通常遵循以下七个原则:
    1-围绕业务领域建模,微服务的目标是创建有用的限界上下文,而不是让开发人员构建更小的服务
    2-隐藏实现细节,微服务的技术架构封装在基于业务领域的服务边界中。每个领域形成一个物理限界上下文。服务间通过传递消息或资源来集成,而不是通过暴露实现细节集成
    3-自动化文化,支持持续交付
    4-高度去中心化,微服务形成了一种无共享架构,其目标是尽可能地减少耦合。通常重复好于耦合
    5-独立部署,可以独立部署每个服务(包括基础设施),反映了服务间的物理限界上下文
    6-隔离失败,每个服务都应该处理合理的错误场景并在可能的情况下将其恢复。
    7-高度可观察
  • 微服务的主要目标是通过物理限界上下文来隔离领域及理解问题领域。因此,它的架构量子就是服务,这使得它成为了演进式架构的优秀示例
    常用于迁移的架构是基于服务的架构,有三个明显的区别,分别是服务粒度、数据库范围和集成中间件。
    更大的服务粒度、数据库作用域、集成中间件
  • 基于服务的架构内在的演进能力肯定比ESB 驱动的SOA 架构要好。开发人员偏离限界上下文的程度决定了架构量子的大小和破坏性耦合的数量。
  • “无服务”架构-BaaS(后端即服务)是那些明显或从根本上依赖于第三方应用或云端服务的应用、FaaS(功能即服务)

演进式数据:

  • 是经过检验的、版本化的和增量的
  • 架构师必须考虑应用的所有耦合特征,其中包括类、包/ 命名空间、库、框架、数据库模式,以及事务上下文。在架构演进时,忽视其中任一维度(或维度间的交互)都将产生问题。
  • 在将单体架构迁移到某种更精细的架构时,应该从分离少量较大的服务开始。当构建一个全新的微服务架构时,开发人员应该尽量限制服务和数据上下文的大小。然后,不要仅按字面意思来理解微服务,对每个服务而言,小并不是必需的,能捕获有用的限界上下文才是关键。
  • 数据的年龄和质量,识别真正有用的数据并将其保留下来,将旧数据作为参考但不将其纳入演进式开发的主流。

构建可演进的架构:

  • 演进机制-通过下面三步来构建演进式架构
    识别受演进影响的架构维度、为每个维度定义适应度函数、使用部署流水线自动化适应度函数

  • 赋予现有架构演进能力取决于三个因素:组件耦合度、工程实践成熟度,以及开发人员构建适应度函数的难易程度。

  • 团队可以通过多种划分方式将单体应用分解成服务。业务功能分组、事务边界、部署目标

  • 演进模块间的交互-拆分共享的依赖、通过JAR文件共享依赖、复制共享的库以消除耦合点。共享就是耦合的一种形式,在微服务架构中这是非常不可取的

  • 演进式架构构建指南-去除不必要的可变性、让决策可逆、演进优于预测、构建防腐层、服务模板、构建可牺牲架构、应对外部变化,传递依赖管理被视为有害的、更新库与更新框架、持续交付优于快照、服务内部版本化

  • 演进式架构的陷阱和反模式-
    为供应商为王反模式-无论从技术还是从业务流程的角度来看,将外部工具或框架置于架构的核心会严重限制架构的演进能力

  • 陷阱:抽象泄漏 底层抽象破坏会导致意外的灾难,即原始抽象泄漏,它是技术栈日渐复杂带来的副作用之一。

  • 反模式:最后10%的陷阱 在抽象范围的另一端存在着另一种复用陷阱,它隐藏在套装软件、平台和框架中。

  • 反模式:代码复用和滥用-开发人员为实现可复用所添加的钩子越多,对代码的基本可用性损害越大。

  • 微服务避免代码复用,遵循重复优于耦合的理念。

  • 当耦合点妨碍了演进或其他重要的架构特征时,通过分叉或重复来打破耦合点。
    架构师必须持续评估架构特征的适应度,保证它们仍在提供价值,避免沦为反模式。

  • 陷阱:简历驱动开发 不要为了架构而构建架构,构建架构是为了解决问题。在选择架构前,要始终理解问题域,不要本末倒置。

  • 增量变更 反模式:管理不当

  • 当开发人员构建单体架构时,管理决策将影响所有项目。因此,在选择数据库时,架构师必须了解每个项目需要的能力,并考虑最复杂的情况。

  • 陷阱:发布过慢 ,一个项目的生产周期决定了架构的演进速度。换句话说,演进速度和生产周期成正比

  • 业务问题 陷阱:产品定制 为每个客户定制、永久的功能开关、产品驱动定制化

  • 反模式:报表

  • 陷阱:规划视野文章来源地址https://www.toymoban.com/news/detail-650460.html

实践演进式架构:

  • 以领域为中心的团队应该是全功能的,这意味着每个项目角色都由该项目组成员承担
  • 架构师设计架构来消除不当耦合,以简化增量变更。、全功能团队的目标之一便是消除协调摩擦
  • 围绕业务能力组织团队:按照业务能力而非职能来组织团队
  • 产品高于项目
  • 团队成员间的连接数:尽量减少开发团队之间的连接数。
  • 团队的耦合特征-文化、事不过三,三则重构
  • 试验文化-从外部吸收想法、鼓励明确的改进、进行探针试验并稳定下来、创造创新时间、采用基于集合的开发方式、连接工程师和最终用户
  • 公司为何决定构建演进式架构
    可预测性与可演进性、规模、高级业务能力、以生产周期为业务指标

到了这里,关于演进式架构的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 快速理解DDD领域驱动设计架构思想-基础篇 | 京东物流技术团队

    本文与大家一起学习并介绍领域驱动设计(Domain Drive Design) 简称DDD,以及为什么我们需要领域驱动设计,它有哪些优缺点,尽量用一些通俗易懂文字来描述讲解领域驱动设计,本篇并不会从深层大论述讲解落地实现,这些大家可以在了解入门后再去深层次学习探讨或在后续进阶

    2024年02月09日
    浏览(42)
  • 前端面试:【系统设计与架构】前端架构模式的演进

    前端架构模式在现代Web开发中扮演着关键角色,它们帮助我们组织和管理前端应用的复杂性。本文将介绍一些常见的前端架构模式,包括MVC、MVVM、Flux和Redux,以及它们的演进和应用。 1. MVC(Model-View-Controller): MVC是一种经典的架构模式,最早用于桌面应用程序开发。它将应

    2024年02月11日
    浏览(48)
  • 【架构师成长之领域驱动开发】

    项目中的“坏”味道 可维护性差:大量的第三方模块影响核心代码的稳定性 可扩展性差:业务逻辑与数据存储相互依赖,无法复用 可测试性差:庞大事务脚本与基础设施强耦合,无法单元测试。 最后的结果:业务发生几次迭代后,这段代码就将成为一个可怕的黑洞。 高内

    2024年02月01日
    浏览(73)
  • 《从零开始学架构》读书笔记(下)

    书接上文 高可用的理论 CAP 在一个分布式系统(指互相连接并共享数据的节点的集合)中,当涉及到 读写 操作时,只能保证 一致性(Consistence) 、 可用性(Availability) 、 分区容错性(Partition Tolerance) 三者中的两个,另外一个必须被牺牲 一致性 对某个指定的客户端来说,

    2023年04月09日
    浏览(58)
  • 领域驱动设计——DDD领域驱动设计进阶

    进阶篇主要讲解领域事件、DDD 分层架构、几种常见的微服务架构模型以及中台设计思想等内容。如何通过领域事件实现微服务解耦?、怎样进行微服务分层设计?、如何实现层与层之间的服务协作?、通过几种微服务架构模型的对比分析,让你了解领域模型和微服务分层的作

    2024年01月15日
    浏览(49)
  • 读程序员的README笔记16_构建可演进的架构(上)

    3.1.1.1. 致软件依赖于其他的API或代码行为 3.1.1.2. 依赖性显然不可避免,甚至是可取的,但必须取得平衡 3.1.1.3. 高依赖性的系统很难修改 3.1.1.3.1. 它们有紧密的耦合性和高度的变更放大效应 3.1.1.3.2. 紧密的耦合性是指那些严重依赖彼此的模块,它们导致了更高的变更放大的

    2024年02月04日
    浏览(51)
  • 读程序员的README笔记17_构建可演进的架构(下)

    1.3.3.1. 开发人员可以只专注于和自己相关的字段,因为它们会继承其他字段的默认值 1.3.3.2. 默认值可使大型API在感觉上很小巧 1.4.1.1. OpenAPI通常用于RESTful服务 1.4.1.2. non-REST服务则使用Protocol Buffers、Thrift或类似的接口定义语言(interface definition language,IDL) 1.4.1.3. 接口定义工

    2024年02月04日
    浏览(55)
  • Serverless架构:无服务器应用与AWS Lambda-读书笔记

    好的架构可以成就软件,缺乏架构则会破坏软件。 在典型的Web应用程序中,服务器接受前端的HTTP请求并处理请求。在保存到数据库之前,数据可能会经过多个应用层。最终,后端将生成一个响应——它可以是JSON形式或完全渲染的标记语言的形式——该响应将被发送回客户端

    2024年02月03日
    浏览(45)
  • 《领域驱动设计》:从领域视角深入仓储(Repository)的设计和实现

    一、前言 “ DDD设计的目标是关注领域模型而并非技术来创建更好的软件,假设开发人员构建了一个SQL,并将它传递给基础设施层中的某个查询服务然后根据表数据的结构集取出所需信息,最后将这些信息提供给构造函数或者Factory,开发人员在做这一切的时候早已不把模型看

    2024年02月08日
    浏览(80)
  • 领域驱动设计四论

        经过多年的研究与思考,实践与总结,本人逐渐对 DDD 有所领悟,本文以一个较短的篇幅,提纲挈领地梳理出 DDD 的核心脉络,希望与各位做一探讨。 1776 年亚当斯密发表《国富论》,标志着经济学的诞生。2004 年,一本名为《领域驱动设计·软件核心复杂性应对之道》的

    2024年02月08日
    浏览(49)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包