精华内容
下载资源
问答
  • 软件架构设计-面向服务的架构设计

    千次阅读 2021-06-12 16:34:35
    一、面向服务的架构SOA SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元(服务)模型的方法。 SOA 并不是一个新鲜事物,而只是面向对象模型的一种替代。虽然基于 SOA 的系统并不排除使用 OOD 来构建单个...

    一、面向服务的架构SOA

    SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元(服务)模型的方法。 SOA 并不是一个新鲜事物,而只是面向对象模型的一种替代。虽然基于 SOA 的系统并不排除使用 OOD 来构建单个服务,但是其整体设计却是面向服务的。由于 SOA 考虑到了系统内的对象,所以虽然 SOA 是基于对象的,但是作为一个整体,它却不是面向对象的。

    SOA 系统原型的一个典型例子是 CORBA,它已经出现很长时间,其定义的概念与 SOA 相似。SOA 建立在 XML 等新技术的基础上,通过使用基于 XML 的语言来描述接口,服务已经转到更动态且更灵活的接口系统中,CORBA 中的 IDL 无法与之相比。

    在这里插入图片描述

    在 SOA 模型中,所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务通过服务总线或流程管理器来连接。这种松散耦合的架构使得各服务在交互过程中无需考虑双方的内部实现细节,以及部署在什么平台上。

    SOA三大特点:松散耦合、粗粒度、标准化接口

    SOA有6个服务类型:

    1. 连接服务
      连接服务又称连通服务,是面向服务架构的骨干,在完成服务的接入,服务间的通信和交互基础上,还提供安全性、可靠性、高性能的服务能力保障。连接服务的一个典型实现就是企业服务总线(Enterprise Service Bus,ESB)。
    2. 协作服务
      协作服务通常由通信代理和Web服务代理两部分组成。通信代理与连通服务中的通信代理实现内部有效的数据通信,Web服务代理与外部的公共注册中心交互,注册本平台对外开放的Web服务以及查找所需要访问的外部Web服务。协作服务既可以实现组织之间(如供应链的合作伙伴之间)的交互通信,也可以实现组织内部(如跨地域的分支机构之间,并有防火墙进行保护的情况)之间的交互通信。
    3. 业务服务
      业务服务指为新建服务提供的特定运行支持环境。新建服务包括单个服务以及合成服务,不包括流程化的服务。合成服务一般由应用编码实现,它可以调用其他的服务(包括:单个服务、合成服务和流程化的服务)。业务服务与连通服务相联接,其中的新建服务与其他服务的通信和交互通过连通服务来实现。业务服务的运行信息由运行管理服务保存,业务服务也接受并执行运行管理服务的管理和控制命令。
    4. 业务流程服务
      流程服务是业务流程的运行环境,提供流程驱动、服务调用、事务管理等功能。流程服务是为业务流程的运行提供的一组标准服务。业务流程是一组服务的集合,可以按照特定的顺序并使用一组特定的规则进行调用。业务流程可以由不同粒度的服务组成,其本身也可视为服务。
    5. 交互服务
      交互服务实现人与服务之间的交互功能。人可以是服务的消费者,也可以是服务的提供者。人不能直接消费服务,也不能直接提供服务,需要通过相应的程序实现代理操作(即人通过操作程序实现与服务的交互)。交互服务就是需要提供一组完整的功能,以实现人与服务的交互,并能够方便地进行交互。人员需要请求服务时,向连通服务发送消息请求,由连通服务查找服务,并将请求消息传递给服务提供者。
    6. 信息服务
      信息服务特指为上层应用系统、同层的其他服务等提供数据访问及资源访问服务。其目标是使应用系统能够统一、透明、高效地访问和操纵位于网络环境中的各种分布、异构的数据资源,为实现全局数据访问、加快应用开发、增强网络应用和方便系统管理提供支持。

    二、Web Service

    由服务请求者、服务提供者、服务注册中心三个角色构成, 支持服务发布、查找和绑定。

    在这里插入图片描述
    动态绑定(调用地址从注册中心获取)与静态绑定(调用地址写死)。
    关键技术: UDDI / WSDL / SOAP / REST /XML。
    在这里插入图片描述

    UDDI(universal description,discovery,intergration)统一描述、发现和集成:用于 Web 服务注册和服务查找;

    WSDL(web service description language)web服务描述语言:用于描述 Web 服务的接口和操作功能;

    SOAP(simple object access protocol)简单对象访问协议:为建立 Web 服务和服务请求之间的通信提供支持;

    BPEL(business process execution language) 企业过程执行语言:用来将分散的、功能单一的web服务组织成一个复杂的有机应用.

    REST(representational state transfer)表述性状态转移:REST是一种使用HTTP、XML技术进行基于web通信的技术,它将网络中所有的事物抽象为资源,每个资源对应唯一的统一资源标识符URI。客户端通过URI获取资源的表述,并通过获得资源的表述使得其状态发生改变。REST将资源/资源的表述/获取资源的动作三者进行分离。

    三、企业服务总线 ESB

    在这里插入图片描述

    ESB 是由中间件技术实现并支持 SOA的一组基础架构,是传统中间件技术与 XML、 Web Service 等技术结合的产物,是在整个企业集成架构下的面向服务的企业应用集成机制。

    主要支持异构系统集成。ESB基于内容的路由和过滤,具备复杂数据的传输能力,并可以提供一系列标准接口。

    1. 监控与管理 (服务注册和命名)
    2. 消息路由
    3. 消息增强 (支持多种消息传递规范)
    4. 消息格式转换
    5. 传输协议转换
    6. 服务位置透明性
    7. 安全性

    四、微服务

    在这里插入图片描述

    微服务顾名思义,就是很小的服务,所以它属于面向服务架构的一种。通俗一点来说,微服务类似于古代著名的发明,活字印刷术,每个服务都是一个组件,通过编排组合的方式来使用,从而真正做到了独立、解耦、组件化、易维护、可复用、可替换、高可用、最终达到提高交付质量、缩短交付周期的效果。

    从专业的角度来看,微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 协议的 RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。

    微服务的核心特点为:小, 且专注于做⼀件事情、轻量级的通信机制、松耦合、独立部署。

    微服务的优势:

    1. 技术异构性

      在微服务架构中,每个服务都是一个相对独立的个体,每个服务都可以选择适合于自身的技术来实现。可以混合使用多种编程语言、开发框架以及数据存储技术.

    2. 弹性

      弹性主要讲的是系统中一部分出现故障会引起多大问题。在单块系统中,一个部分出现问题,可能导致整体系统的问题。而微服务架构中,每个服务可以内置可用性的解决方案与功能降级方案,所以比单块系统强。

    3. 扩展

      单块系统中,我们要做扩展,往往是整体进行扩展。而在微服务架构中,可以针对单个服务进行扩展。

    4. 简化部署

      简单的服务更容易部署, 每个服务的部署都是独立的, 单个服务出问题不会导致整个系统的故障。

      在大型单块系统中,即使修改一行代码,也需要重新部署整个应用系统。这种部署的影响很大、风险很高,因此不敢轻易地重新部署。而微服务架构中,每个服务的部署都是 独立的,这样就可以更快地对特定部分的代码进行部署。

    5. 与组织结构相匹配

      为服务强调模块化的结构, 可以将架构与组织结构相匹配,避免出现过大的代码库,从而获得理想的团队大小及生产力。

    6. 可组合性

      在微服务架构中,系统会开放很多接口供外部使用。当情况发生改变时,可以使用不同的方式构建应用,而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。

    7. 对可替代性的优化

      在单块系统中如果删除系统中的上百行代码,也许不知道会发生什么,引起什么样的问题,因为单块系统中关联性很强。但在微服务架构中,我们可以在需要时轻易地重写服务,或者删除不再使用的服务。

    五、MDA 模型驱动架构

    在这里插入图片描述

    使用模型完成软件的分析、设计、构建、部署、维护等各开发活动。MDA起源于分离系统规约和平台实线的思想。

    MDA的主要目标:Portability(可移植性)、Interoperability(互通性)、Reusability(可重用性)。

    MDA的3中核心模型:

    1. 平台独立模型(PIM):具有高抽象层次、独立于任何实现技术的模型。
    2. 平台相关模型(PSM):为某种特定实线技术量身定做,让你用这种技术中可用的实线。
    3. 代码Code:用源代码对系统的描述(规约)。每个PSM对象被变成代码。

    六、ADL架构描述语言

    ADL是这样一种形式化语言,他在底层语义模型的支持下,为软件系统的概念体系结构建模提供了具体语法和概念框架。基于地城语义的工具体系结构的表示、分析、演化、设计过程等提供支持。

    ADL的三个基本元素:

    1. 构建:计算或数据存储单元。
    2. 连接件:用于构件之间交互建模的体系结构构造块及其支配这些交互的原则。
    3. 架构配置:描述体系结构的构件于连接件的连接图。

    ADL主要的架构描述语言:
    Aesop、MetaH、C2、Rapide、SADL、Unicon、Wright。

    七、DSSA特定领域架构

    以一个特定问题领域为对象,形成由领域参考模型、参考需求、参考架构等组成的开发基础架构,其目标是支持一个特定领域中多个应用的生成。

    1.活动阶段
    在这里插入图片描述

    (1)领域分析:主要目标是获得领域模型。即通过分析领域中系统的需求(领域需求),确定哪些需求是被领域中的系统广泛共享的,从而建立领域模型。

    (2)领域设计:这个阶段的目标是获得 DSSA,它是一个能够适应领域多个系统的需求的一个高层次的设计。由于领域模型中的领域需求具有一定的变化性,DSSA 也要相应地具有变化性,它可以通过表示多选一的、可选的解决方案等来做到这一点。

    (3)领域实现:主要目标是依据领域模型和 DSSA 开发与组织可复用信息。这些复用信息可以是从现有系统中提取得到的,也可能通过新的开发得到。这个阶段可以看作复用基础设施的实现阶段。

    2. 参与人员
    在这里插入图片描述

    领域专家: 主要任务包括提供关于领域中系统的需求规约和实现的知识,帮助组织规范的一致的领域字典,帮助选择样本系统作为领域工程的依据,复审领域模型、DSSA等领域工程产品。

    领域分析人员: 主要任务包括控制整个领域分析过程,进行知识获取,将获取的知识组织到领域模型中,根据现有系统、标准规范等验证领域模型的准确性和一致性,维护领域模型

    领域设计人员: 主要任务包括控制整个软件设计过程,根据领域模型和现有的系统开发出DSSA,对DSSA的准确性和一致性进行验证,建立领域模型和DSSA之间的联系

    领域实现人员: 主要任务包括根据领域模型和DSSA,或者从头开发可重用构件或者利用再工程的技术从现有系统中提取可重用构件,对可重用构件进行验证,建立 DSSA 与可重用构件间的联系。

    3. DSSA系统模型
    在这里插入图片描述

    展开全文
  • 软件架构作为软件开发过程的一个重要组成部分,有着各种各样的方法和路线图,它们都有一些共同的原则。基于架构的方法作为控制系统构建和演化复杂性的一种手段得到了推广。 引言 在计算机历史中,软件变得越来越复杂...

    摘要

    软件架构作为软件开发过程的一个重要组成部分,有着各种各样的方法和路线图,它们都有一些共同的原则。基于架构的方法作为控制系统构建和演化复杂性的一种手段得到了推广。

    引言

    在计算机历史中,软件变得越来越复杂。也提出了许多方法来解决不同层次的复杂性,例如“结构化编程”[1],以及Fred Brooks的“概念完整性”思想[2]。软件生命周期的设计阶段通常分为高层设计和详细设计。架构将有助于描述软件,这就产生了“软件架构”一词。软件架构的概念已经成为解决高度复杂问题的设计方案。在1994年底,Denning和Dargan为一个新的软件学科提出了“软件架构”[3]。Garlan和Shaw在1996年指出“明确关注架构作为软件设计的一个独立层次是相对较新的”,因此他们的书的副标题是“对一门新兴学科的展望”[4]。面向服务的架构(SOA)是一种模块化服务的架构。然后,可以将这些服务的集合与业务流程协调起来,可以以各种形式重新组合这些服务,以实现新的或改进的业务流程。SOA的新颖之处在于,它能够更灵活地为服务提供者和使用者选择技术实现。抽象服务接口还允许供应商和消费者独立发展,只要接口保持稳定[5]。SOA的好处主要来自于:接口服务的稳定性。与系统更改的总百分比相比,这种稳定性在实现服务的开发过程中将服务与使用者隔离开来。这种隔离限制了变更的范围和后续修订的成本。如果能够重用现有的服务,就可以借用更多的优势。重用避免了重新实现或修改封装在服务中的功能[5]。

    软件架构

    软件架构是设计系统、解决问题或满足需求的“第一步”。软件架构的真正含义是,它实际上是一种计划资产,用于指导企业信息基础设施的选择、构建、修改和完美使用,以实现所需的业务未来状态。架构涉及架构元素的选择、它们之间的相互作用以及对这些元素及其相互作用的约束,它还可以被视为用于解决问题框图和线条图。

    • 框定义系统的元素或“组件”。
    • 线定义了零件之间的相互作用。
      要提供一个框架,以满足要求,并作为设计的基础。设计的一般含义是,设计涉及到设计元素的模块化和详细的接口,它们的算法和过程,以及支持架构和满足需求所需的数据类型[6]。因此需要考虑一下内容:
    • 业务的当前和未来愿景。
    • 包括投资选择在内的质量决策。
    • 以符合业务运营的经济高效的方式使用软件。
    • 减少冗余。
    • 重用信息和软件组件。
    • 利用新的技术解决方案。
    • 共享系统和数据。
    • 跨企业集成。
    • 共同标准。
    • 减少应用程序接口的数量。
    • 缺失数据的识别和规划。

    软件架构通常在需求和实现之间起着桥梁的作用(见图1)。通过提供系统的抽象描述,架构公开某些属性,同时隐藏其他属性。软件架构至少可以在软件开发的六个方面发挥重要作用[7]。
    在这里插入图片描述
    图1

    • 理解:软件架构简化了我们理解大型系统的能力,方法是将它们呈现在一个抽象的层次上,在这个层次上,系统的高级设计很容易理解。
    • 重用:架构描述支持多层次的重用。当前关于重用的工作主要集中在组件库上。此外,架构设计既支持大型组件的重用,也支持将组件集成到其中的框架。
    • 构造:架构描述通过指出主要组件及其之间的依赖关系,为开发提供部分蓝图。
    • 演化:软件架构可以揭示系统演化的维度。通过明确系统的“承重墙”,系统维护人员可以更好地理解变更的后果,从而更准确地估计修改的成本。
    • 分析:架构描述为分析提供了新的机会,包括系统一致性检查[8]、[9]、与架构样式施加的约束的一致性[10]、与质量属性的一致性[11]、依赖性分析[12]以及针对特定样式中构建的架构的特定领域分析[13]。
    • 管理:经验表明,成功的项目将实现可行的软件架构视为工业软件开发过程中的一个关键里程碑。对架构的批判性评估通常会导致对需求、实现策略和潜在风险的更清晰理解[14]。

    在导致架构不成功的各种因素有,缺乏足够的架构能力和/或经验,在架构设计和分析上花费了足够的时间,无法恰当地记录和传达架构,认识到“标准不能替代软件架构”,充分理解架构和实现之间的直接关系,随着架构的发展更新文档等[15]。

    面向服务的架构

    SOA是一种按需连接业务和计算资源(主要是组织、应用程序和数据)的设计,以实现服务使用者(可以是最终用户或其他服务)所需的结果。OASIS1[16]将SOA定义为:一种组织和利用分布式功能的范例。它提供了一种统一的方法来提供、发现、交互和使用能力,以产生符合可测量的前提条件和期望的预期效果。
    面向服务的架构(SOA)是20世纪90年代基于组件的架构、基于接口的设计(面向对象)和分布式系统的发展,如DCOM[17]、CORBA[18]、J2EE[19]和Internet。

    在分析SOA的细节之前,首先探讨软件架构的概念是很重要的,它由软件的粗粒度结构组成。软件架构描述了系统的组件以及它们在高层的交互方式。这些组件不一定是实体bean或分布式对象。它们是作为一个单元部署到带有其他组件的服务器上的抽象软件模块。组件之间的交互称为连接器。组件和连接器的配置描述了系统的结构和行为方式,如图2所示。
    在这里插入图片描述
    图2

    面向服务的架构是一种特殊的软件架构,具有许多独特的特点。对于服务设计者和开发人员来说,理解SOA的概念非常重要,这样他们就可以在自己的环境中最有效地使用Web服务。SOA是一个相对较新的术语,但与软件服务相关的术语“服务”至少在20世纪90年代初就出现了,当时它在Tuxedo中被用来描述“服务”和“服务过程”[20]。图3显示了可以使用其他技术来实现面向服务的架构。
    在这里插入图片描述

    图3

    每个系统的软件架构反映了设计者使用的不同原则和权衡。面向服务的软件架构具有以下特征[21]:

    1、可发现和动态绑定:SOA支持服务发现的概念。需要服务的服务使用者在运行时根据一组条件发现要使用的服务。服务使用者要求注册中心提供满足其需要的服务。

    2、自包含和模块化:服务是自包含和模块化的。SOA最重要的方面之一是模块化的概念。服务支持一组接口。这些接口应该是内聚的,这意味着它们都应该在模块的上下文中相互关联。在设计支持应用程序的服务时,应该遵循模块化原则,这样服务就可以很容易地聚合到具有一些众所周知的依赖关系的应用程序中。因为在创建服务时这是一个非常重要的概念,所以我们将解释模块化的一些原则,特别是它们如何应用于服务的创建。Bertrand Meyer[22]概述了确定组件是否具有足够模块化的以下五个标准。当确定服务是否足够模块化时,这些标准同样适用。

    • 模块化可分解性:服务的模块化可分解性是指将一个应用程序分解为许多更小的模块。每个模块负责应用程序中的一个单独的、不同的功能。这有时被称为“自顶向下的设计”,在这种设计中,较大的问题被迭代地分解成较小的问题。可分解性的主要目标是可重用性。服务设计的目标是确定可在不同上下文中重用的最小软件单元。
    • 模块化可组合性:服务的模块化可组合性是指软件服务的生产,这些服务可以作为一个整体与其他服务自由组合以生产新的系统。服务设计人员应该创建足够独立的服务,以便在完全不同的应用程序中重用,而这些应用程序与它们最初的目的完全不同。这有时被称为自下而上的设计。
    • 模块化可理解性:服务的模块化可理解性是一个人在不了解任何其他服务的情况下理解服务功能的能力。例如,如果银行应用程序实现了一个支票账户服务,该服务不实现存款功能,而是依赖于客户机使用一个单独的存款服务;这将降低该服务的模块化可理解性。
    • 模块化连续性:服务的模块化连续性是指一个服务中的更改对其他服务或服务使用者的影响。如果接口没有充分隐藏服务的实现细节,则在需要更改时会产生多米诺效应。当服务的内部实现发生更改时,它将需要更改使用该服务的其他服务和应用程序。每个服务都必须隐藏有关其内部设计的信息。公开此信息的服务将限制其模块化的连续性,因为内部设计决策是通过接口公开的。
    • 模块化保护:如果服务中的异常情况没有级联到其他服务或使用者,那么服务的模块化保护就足够了。

    3、互操作性:面向服务的架构强调互操作性,即使用不同平台和语言的系统相互通信的能力。

    4、松散耦合:耦合是指模块之间依赖的数量。联轴器有两种类型:松式和紧式。松散耦合的模块有一些众所周知的依赖关系。紧耦合模块有许多未知的依赖关系。每个软件架构都力求实现模块之间的松散耦合。面向服务的架构促进了服务使用者和服务提供者之间的松散耦合,以及消费者和提供者之间的一些众所周知的依赖关系。

    5、位置透明性:位置透明性是面向服务架构的一个关键特性。服务的使用者直到在注册表中找到服务时才知道它的位置。运行时对服务的查找和动态绑定允许服务实现在客户端不知情的情况下从一个位置移动到另一个位置。移动服务的能力提高了服务可用性和性能。通过使用负载均衡器将请求转发到多个服务实例而服务客户机不知情,我们可以获得更高的可用性和性能。

    6、可组合性:服务的可组合性与其模块化结构有关。模块化结构允许将服务组装到开发人员在设计服务时不知道的应用程序中。使用预先存在的、经过测试的服务极大地提高了系统的质量,并且由于易于重用而提高了投资回报率。服务可以用三种方式组合:应用程序组合、服务联合和服务编排。

    • 应用程序:通常是服务、组件和应用程序逻辑的集合,它们将这些功能绑定在一起以实现特定的目的。
    • 服务联合:是在更大的服务域中一起管理的服务集合。例如,支票账户服务、储蓄账户服务和客户服务可以组成更大的银行账户服务。
    • 服务编排:是执行影响组织中一个或多个服务的单个事务。它有时被称为业务流程。它由多个步骤组成,每个步骤都是服务调用。如果任何服务调用失败,整个事务应该回滚到事务执行之前的状态。

    对于要组合到事务应用程序、联合或编排中的服务,服务方法本身应该是子事务的。也就是说,它们不能自己执行数据提交。

    7、自我修复:随着现代分布式应用程序的规模和复杂性,系统从错误中恢复的能力变得越来越重要。自愈系统是一种在执行过程中无需人工干预就能从错误中恢复的系统。

    可靠性实际上衡量系统在受到干扰时的性能。在面向服务的架构中,服务将不时地上下浮动。这对于通过互联网上多个组织的服务组装的应用程序尤其如此。系统自愈的程度取决于几个因素。可靠性取决于硬件从故障中恢复的能力。网络还必须允许在运行时动态连接到不同的系统。现代互联网网络协议固有地提供了这种能力。

    一种人工智能平台架构

    在这里插入图片描述

    结论

    在过去的十年中,软件架构作为一门学科正在兴起[7]。系统软件架构在较高的层次上描述了它的粗粒度结构和属性。只要该技术考虑到这些结构和属性,就可以使用该技术实现架构。例如,Jini是一种支持面向服务架构的技术,因为SOA的属性。充分利用软件架构这一新技术的概念对于应用软件架构是非常重要的。面向服务的架构是通过Web服务和其他技术实现的,但是由于Web服务的出现,这些术语和概念最近得到了广泛的应用。例如,二十年来,计算机行业一直被用来描述各种平台。SOA的一些特性得到了一些比其他技术更好的支持。

    参考文献
    [1] O. J. Dahl, E. W. Dijkstra, and C. A. Hoare, Structured Programming. Academic Press, 1972.
    [2] F. P. Brooks, The Mythical Man-Month: Essays On Software Engineering, Anniversary Edition. Addison-Wesley, 1995.
    [3] P. J. Denning and P. A. Dargan, “A discipline of software architecture,” interactions, vol. 1, no. 1, pp. 55–65, 1994.
    [4] M. Shaw and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline. Prentice- Hall, 1996.
    [5] P. Brown, Implementing soa: total architecture in practice. AddisonWesley Professional, 2008.
    [6] D. E. Perry and A. L. Wolf, “Foundations for the study of software architecture,” ACM SIGSOFT SOFTWARE ENGINEERING NOTES,
    vol. 17, no. 4, October 1992.
    [7] D. Garlan, “Software architecture: a roadmap,” in ICSE ’00: Proceedings of the Conference on The Future of Software Engineering. New York,
    NY, USA: ACM, 2000, pp. 91–101.
    [8] R. Allen and D. Garlan, “Formalizing architectural connection,” in ICSE’94: Proceedings of the 16th International Conference on Software Engineering, Sorrento, Italy, May 1994, pp. 71–80.
    [9] D. C. Luckham, L. M. Augustin, J. J. Kenny, J. Veera, D. Bryan, and W. Mann, “Specification and analysis of system architecture using rapide,” IEEE Transactions on Software Engineering, vol. 21, no. 4, pp. 336–355, April 1995.
    [10] G. Abowd, R. Allen, and D. Garlan, “Using style to understand descriptions of software architecture,” in SIGSOFT ’93: Proceedings of the 1st ACM SIGSOFT symposium on Foundations of software engineering. New York, NY, USA: ACM, 1993, pp. 9–20.
    [11] P. Clements, L. Bass, R. Kazman, and G. Abowd, “Predicting software quality by architecture-level evaluation,” in Proceedings of the Fifth International Conference on Software Quality, Austin, Texas, October 1995.
    [12] J. A. Stafford, D. J. Richardson, and A. L. Wolf, “Aladdin: A tool for architecture-level dependence analysis of software,” University of Colorado at Boulder, Technical Report CU-CS-858-98, April 1998.
    [13] L. Coglianese and R. Szymanski, “Dssa-adage: An environment for architecture-based avionics development,” in AGARD’93, 1993.
    [14] B. Boehm, P. Bose, E. Horowitz, and M. J. Lee, “Software requirements negotiation and renegotiation aids: A theory-w based spiral approach,” in ICSE ’95: Proceedings of the 17th international conference on Software engineering. New York, NY, USA: ACM, 1995, pp. 243–253.
    [15] L. Northrop, “Software architecture and product quality,” Presentation for the Boston SPIN, Software Engineering Institute, Carnegie Mellon University, May 2003.
    [16] Organization for the advancement of structured information standards. [Online]. Available: http://www.oasis-open.org
    [17] Distributed component object model. [Online]. Available: www.microsoft.com/com
    [18] Corba basics frequently asked questions. [Online]. Available: www.omg.org/gettingstarted/corbafaq.htm
    [19] Java EE at a glance. [Online]. Available: http://java.sun.com/j2ee
    [20] P. Herzum, “Web services and service-oriented architectures,” Cutter Distributed Enterprise Architecture Advisory Service, Executive Report, 2002.
    [21] G. Bieber and J. Carpenter, “Introduction to service-oriented programming,” Online whitepaper: www.openwings.org/download/specs, 2001.
    [22] B. Meyer, Object Oriented Software Construction, 2nd ed., ser. International Series in Computer Science. Prentice-Hall, 1997.
    [23] United nations centre for trade facilitation and electronic business. [Online]. Available: http://www.unece.org/cefact

    展开全文
  • 面向服务的架构及其应用

    千次阅读 2020-12-18 18:38:26
      声明:本文为本人在软考...经过这次面向服务的架构应用的方法和实施的效果后,我也看到了自己身上的不足之处,在未来还会不断地更新知识,完善本系统的架构设计,使整个系统能够更加好用,更有效地服务于高校师生。

      声明:本文为本人在软考系统架构设计师备考期间的练手写作,不保证内容的原创性与正确性,仅供参考,请勿照抄和用于学术论文等正规场合,因不当使用产生后果一律自负。

    摘要

      2019年3月,我单位联合某高校研发了《程序在线评测比赛考试系统》。系统以程序代码在线提交自动评测功能为核心,分为题库模块、评测机模块、实验作业模块、考试模块、比赛模块、抄袭判定模块、用户管理模块等,支持对接教务平台。在项目中我担任系统架构师,负责架构设计工作。
      本文以该系统为例,主要论述了面向服务的架构在项目中的具体应用。系统划分为前端Web服务、平台保障服务、业务服务。前端Web服务由Nginx负载均衡与服务器集群结合,解决前台界面的并发问题;平台保障服务以Eureka为中心,分为API网关、服务注册中心、监控平台,用以实现基础服务框架;业务服务基于Spring Cloud开发,分为多个服务,实现具体业务功能,解决协同问题。最终系统顺利上线,获得用户一致好评。

    正文

      笔者在一个专为高校建设计算机专业智能教学一体化平台的单位任职,过往成果有《计算机组成原理仿真实验系统》等。2019年3月,我单位联合某大学研发了《程序在线评测比赛考试系统》项目(以下简称为“OJ系统”),以取代原有传统的编程上机考试平台。
      系统以程序代码的在线提交自动评测功能为核心,主要分为题库模块、评测机模块、实验作业模块、考试模块、比赛模块、抄袭判定模块、用户管理模块等。题库模块主要负责试题和测试用例的管理,用户根据试题要求编写程序代码提交到系统,系统将测试用例与程序代码发送给评测机模块,由评测机自动编译、执行、判分,并将结果发送给其他相关模块进行统计;实验作业模块用于在线布置作业,从题库中选取试题,设置截止日期等要求;考试模块用于学生在线考试,按教师预先设置的参数自动从题库随机抽题生成试卷,以及向教务平台上传考试成绩;比赛模块主要用于ACM竞赛的培训;抄袭判定模块用于鉴定代码与他人代码雷同率;用户管理模块负责用户信息的管理。在这个项目中,我担任了系统架构师的职务,主要负责系统的架构设计相关工作。
      我们使用面向服务的架构(SOA)来设计OJ系统。SOA技术参考架构包含6类服务:业务逻辑服务、控制服务、连接服务、业务创新和优化服务、开发服务、IT服务管理。业务逻辑服务用于实现和执行业务逻辑,包括业务应用服务、业务伙伴服务、应用和信息资产;控制服务实现人、流程和信息的集成以及执行集成逻辑;连接服务通过企业服务总线,实现在各服务间的连接件;业务创新和优化服务用于监控业务系统运行时的业务性能,并采取措施适应变化的市场;开发服务贯彻整个软件开发生命周期的开发平台,提供全面的工具支持;IT服务管理支持业务系统运行的各种基础设施管理能力或服务,如安全服务、目录服务、系统管理和资源虚拟化。
      系统以基于Spring Cloud框架的微服务架构作为SOA的实现方式,使用Java语言开发,将平台服务划分为三类,分别为前端Web服务、平台保障服务、业务服务。下面针对这三类服务展开具体说明。

    1. 前端Web服务

      前端Web服务主要提供给用户使用的界面,分为前置Nginx负载均衡服务器、前端网站Nginx集群。当用户通过网络访问系统时,首先会访问到前置的Nginx负载均衡服务器,负载均衡服务器会将请求转发到前端网站的Nginx集群,前端网站通过发起Http请求来和后端交互,具体是通过Ajax方式来调用后端REST API接口。用户访问网站通过前置的Nginx负载均衡服务器来转发到前端网站集群,以起到将用户请求进行分流的作用。当前端网站集群中的部分服务发生故障时,系统仍可正常地对外提供服务。前置Nginx负载均衡服务器使用软件反向代理的方式来实现负载均衡,部署为路由模式,系统内部网络与外部网络分属于不同的逻辑网络,以实现系统内部与外部网络的隔离。在负载均衡算法的选择上,使用最小连接法,每当用户的请求来临时,任务分发单元会将任务平滑分配给最小连接数的前端网站节点,这样的架构以廉价且透明的方式扩展了服务器和网络的带宽,可以大大提升系统的并发量,同时保证网站前端整体的稳定性和可靠性。

    2. 平台保障服务

      平台保障服务用以实现后端业务服务的基础框架,包括API路由网关、服务注册中心、服务监控组件。API网关收到前端的请求,不会直接调用后端的业务服务,而是首先会从服务注册中心根据当前请求来获取对应的服务配置,随后通过服务配置再调用已注册的服务。当后端服务存在多个实例时,将采取负载均衡的方式调用。服务注册中心是整个后端服务架构体系的核心部分,由Spring Cloud的Eureka组件来实现,专门提供服务的注册和发现功能,涉及三种角色:服务提供者、服务消费者和服务注册中心。API路由网关、所有业务服务,以及服务监控平台组件都注册到服务注册中心。通过服务注册中心两两互相注册、API路由网关向服务注册中心注册多个实例等方式,来实现后端整体服务的高可靠性。服务监控平台通过注册到服务注册中心,获取所有注册到服务注册中心的后端业务服务,从而监控到所有后端业务服务的运行状态信息,最后收集并展示整个后端服务系统的运行状态,更进一步保证整个后端的服务质量。

    3. 业务服务

      业务服务按系统业务模块,相应划分为题库服务、评测机服务、实验作业服务、考试服务、比赛服务、抄袭判定服务、MQ队列服务等。服务间协同工作,通过松耦合的服务发现机制,来动态调用对方的REST API接口。其中,对于压力较大的服务,如评测机服务、抄袭判定服务等,将部署为多实例集群。以在线考试功能为例,用户进入考试时,考试服务核验考生信息通过后,根据预先设置的参数,调用题库服务,题库服务返回试题信息,由考试服务组合为试卷,返回前端显示。用户交卷时,提交的程序代码到达考试服务,考试服务拆分后分发给题库服务,题库服务将程序代码和测试用例送入MQ队列排队。然后由负载均衡机制,依次将队列中排队的待评测程序分发给空闲的评测机服务编译、执行、判分,评测机服务完成评测后,将结果返回给题库服务和考试服务,题库服务进行试题通过率统计,考试服务进行成绩统计,以及向前端显示成绩。在这期间服务请求者无需了解其他服务对数据如何具体处理和分析。

    总结

      系统自2019年10月正式上线已运行一年有余,在学校的日常教学考试和竞赛培训中投入使用,截至目前已有3000以上的学生用户、评测了70000条以上的程序代码,获得了单位同事领导和学校教师们的一致好评。在开发和试运行过程中,主要遇到了两个问题。一是跨域问题。OJ系统前后端分离,前端通过Ajax访问后端服务。由于浏览器同源策略的限制,导致前端UI无法正常访问不同端口和IP的后端服务。我们利用Spring Boot后端的Cors跨域机制解决了该问题。二是评测机宕机问题。评测机服务需要执行用户提交的代码,但由于部分用户短时间内提交了大量不安全代码,导致所有评测机服务全部宕机。我们引入心跳机制、快照回滚机制,以及基于机器学习技术的预判断机制,使评测服务宕机时能够在10秒内自动重置恢复运行,最终解决了该问题。
      实践证明,OJ系统项目能够顺利上线,并且稳定运行,与系统采用了合适的架构设计密不可分。经过这次面向服务的架构应用的方法和实施的效果后,我也看到了自己身上的不足之处,在未来还会不断地更新知识,完善本系统的架构设计,使整个系统能够更加好用,更有效地服务于高校师生。

    展开全文
  • SOA是一种软件的应用架构方法,它基于面向对象,但又不是面向对象,整体上是面向服务的架构。SOA由精确的服务定义、松散的构件服务组成,以及业务流程调用等多个方面形成的一整套架构方法。 这话是不是听起来,让人...

    SOA是一种软件的应用架构方法,它基于面向对象,但又不是面向对象,整体上是面向服务的架构。SOA由精确的服务定义、松散的构件服务组成,以及业务流程调用等多个方面形成的一整套架构方法。
    这话是不是听起来,让人觉得有点晕,我们就细细品读一下。

    SOA的架构思想

    (一)SOA架构是面向服务的,只不过是基于面向对象

    SOA继承了很多面向对象的特点,比如说面向对象的封装,经常代表很多类封装成一个模块,为其他对象调用者提供接口调用,良好的面向对象设计就是暴露接口,隐藏实现,类比到SOA的设计,SOA也需要精准明确地定义好服务接口,具体服务内部的逻辑实现都是隐藏在背后的,只不过有两个很大的区别:

    • (1)面向对象的实现都是基于同一个编程语言或平台(同构),但SOA服务彻底隐藏了实现上用何种语言平台的具体细节(异构)
    • (2)面向对象的实现其实大部分都是本地方法之间的调用,当然也具备分布式远程方法调用,但SOA是纯粹提供了独立的服务,面向分布式的远程服务调用。

    (二)SOA的服务定义是精确的

    这个怎么理解呢?因为SOA的服务一旦发布出来,那么就会有很多其他的异构平台服务进行调用,这时候的服务接口修改就不像一个人或者一个小团队之间协作那么容易了,可能涉及到一个大型企业多部门的信息协作,或者对构件已经形成依赖的生态链条。因此这就牵扯出了SOA另外一个特征,那就是服务接口的粒度一般要设置得比较粗。若提供过多的服务接口,服务又定义得很细粒度,那么频繁修改是在所难免的。这一点上就注定了SOA架构适合在较重量的环境下存在。

    那什么是较重量的环境呢?(1)体系健全、制度稳定的重管理型企业,(2)业务逻辑复杂,服务的独立性,开放性需求又大,服务的稳定性也是刚需。例如:医院信息化系统架构。

    (三)SOA是由松散的构件服务组成

    为什么是松散的呢?由上述我们可以了解到SOA的服务接口是粗粒度的,而且组成服务的构件都是独立部署并具有独立的上下文环境,这种形态就是为了降低与其他构件之间的强依赖性。让每个构件尽可能一次性为客户提供足够的其领域范围的服务。

    例如:通知服务,客户端只要传递过来通知内容即可,到底是通知短信、微信、站内信等等,这是通知服务与配置库、用户关系库的内部逻辑关系,也可以通过消息从其他服务中获取。因此SOA服务更倾向于前期就配置好通知渠道、通知用户组的逻辑关系,这种形式就是客户端轻,管理端重

    上述这种松散的、粗粒度的构建服务例子,就非常符合SOA架构的胃口,可以让每个服务的独立性看起来很不错,提供一个简单的接口外观,而且越少的接口参数,频繁更改的接口的几率就越低,又满足了服务接口的精确要求,以及服务更偏重管理的特点。

    ESB、BPM在SOA中的实现方式

    SOA架构可以按业务流程调用各个构件服务,这是个什么概念?想要弄清楚这个概念,我们要站在上帝视角去俯视SOA架构了!

    file

    如上图所示:这是一种SOA架构的解决方案,与ESB和BPM的基础中间件结合,BPM作为一个业务流程管理平台,很好的将SOA服务通过流程建模的形式,与业务流程逻辑联系在一起。那么这个过程中,BPM支撑SOA架构的业务流程协作问题,ESB支撑SOA架构的数据交换问题。这个架构体系是不是看起来就比较完整了!

    例如:应急指挥系统中,我们制定一个流程预案,可以由BPM工具进行建模,进行不同独立运行的SOA构件服务进行流程执行调度,并形成流程执行库。应用执行端,一般就是客户端手动或定时器自动,启动流程引擎实例,流程引擎读取流程模型库,并配合应用管理端的操作,对构件服务实现访问调度,流程引擎调度的这个过程中,SOA的服务构件始终围绕在ESB周围,交换过程数据。进行物资服务调度、医疗资源服务调度、通讯设备服务调度、对外信息披露服务调用等。

    那么这种架构例子中,大家是不是看得出来非常适合复杂应用系统整合、协作,因为很有可能通讯设备服务提供了C++网络通讯包,物资服务是Java平台运行,医疗资源服务又是.Net平台运行,但是大家基于统一的服务规约,提供精确而风格一致的服务接口,那么对于BPM也好,ESB也好,就极大的减少了适配集成的复杂过程,让各种业务和通讯系统,都变成了一项服务,作为SOA整体调度与管理的一枚棋子而存在。这其实就有点SOA的精髓了。

    WebService的实现方式

    往往很多人不太了解SOA的情况下,就会认为Webservice就是SOA,所以这就是为什么先把上面的SOA思想以及架构实现讲讲,大家就能对SOA有个整体全面的理解。Webservice只是实现SOA构件服务的一种手段,若将其中的换成基于RestFul风格的实现,也是没有问题的。

    WebService又依赖于几种具体的技术规范和协议了,具体描述我就直接引用吧:

    SOAP(Simple ObjectAccess Protocol,简单对象访问协议) 定义了服务请求者和服务提供者之间的消息传输规范,SOAP 用 XML 来格式化消息,用 HTTP 来承载消息。通过 SOAP,应用程序可以在网络中进行数据交换和远程过程调用(Remote Procedure Call, RPC)。

    WSDL(Web ServiceDescription Language,Web 服务描述语言) 是对服务进行描述的语言,它有一套基于 XML 的语法定义。WSDL 描述的重点是服务,它包含服务实现定义和服务接口定义。

    UDDI(Universal DescriptionDiscovery and Integration,统一描述、发现和集成) 提供了一种服务发布、查找和定位的方法,是服务的信息注册规范,以便被需要该服务的用户发现和使用它。UDDI 规范描述了服务的概念,同时也定义了一种编程接口。通过 UDDI 提供的标准接口,企业可以发布自己的服务供其他企业查询和调用,也可以查询特定服务的描述信息,并动态绑定到该服务上。

    如何通俗地去理解这三大件呢?

    file

    还是上个图,看起来舒服一些。如上图所示:SOA中的服务1需要调用服务2的接口,那么我们就描述一下Webservices方式。

    首先虚线中,也就是开发阶段服务1要去理解服务2的WSDL描述,清楚服务2提供的服务接口是什么样子,描述语言就是XML,服务1的程序就知道需要设置什么参数,返回什么结果。

    然后在运行时服务1要从UDDI服务上,也就是注册发现中心,找到服务2在哪里,由于服务2早已经在UDDI服务中注册,那么服务1就可以获得服务2的路由地址。再对需要传递的数据进行SOAP格式编码。

    SOAP是HTTP层之上的一个传输协议,服务1对传递参数进行满足SOAP协议的xml编码和参数发送,形成对服务2的WebService接口调用,服务2接收到SOAP协议数据,进行xml解码,然后再进行内部实现层的逻辑处理,并最终将结果仍然以SOAP方式编码返回给服务1,由服务1再解码数据。这就完成了WebService的一次请求和响应。当然了服务1也可以是一个普通的客户端。

    从上述的图示例子中,我们可以看到WebService是通过XML作为中间传递格式,这就兼容了异构平台的数据格式,SOAP协议大部分是基于HTTP协议(SOAP的设计不限于HTTP),这样就兼容了异构平台数据传输。

    因此WebService的技术实现方案就非常符合SOA架构中服务的异构平台兼容性要求(SOAP),并且具备完整规范的服务接口语义描述(WSDL)和服务注册发现管理的规范定义(UDDI)。

    SOA与微服务的优劣对比

    往往没有对比就没有伤害,因此我们通过SOA架构与微服务架构的对比,来更深刻地认识SOA架构的优势与劣势,同时也能掌握到微服务优劣特征。

    单体向微服务过渡架构

    我们往往会从上图的角度去寻求微服务的发展踪迹,也就是单体向微服务的过渡。但很少有人会去从SOA的变种这个角度去思考微服务。

    因此我们需要定义一个问题,微服务到底和SOA有没有关系?其实,这其中就隐藏着两种关系:

    • (1)微服务简化了SOA架构思想,是SOA一个离经叛道的继任者,
    • (2)微服务进行了SOA基因改造,成了一个新的变种,

    微服务是SOA一个离经叛道的继任者, 其实这是一句赞美之词!

    首先我们来看看微服务和SOA比起来有多么的相似,又多么的不同。

    (1)微服务专注小的个体问题,形成服务,通过松耦合的通讯机制协作起来,解决更大的问题;反之,SOA一开始就专注大的协调问题,首先关注的是服务协议、规则、表述的统一性,然后才是设计足够大的独立服务,并通过流程建模,解决整体上的问题。

    (2)微服务倾向于拆分,也就是将单体应用尽量拆分到一个适当的粒度,形成个人或小团队去关注独立的服务个体;但SOA不同,服务要足够的粗粒度,服务接口只是作为异构系统调用的统一手段,甚至我们可以将一个大系统作为SOA的一个构建服务而独立存在,例如前面说到的应急指挥系统的SOA架构中通讯调度系统作为一个独立的SOA服务而存在。

    (3)微服务的实施模式是自底向上型:不同的小团队分配不同的微服务进行开发、构建、部署、发布。系统整体上的把控,是在发布、测试过程中所有团队共同参与的结果,这时候开发变成了运维,运维变成了顾问,这就是Devops的思想,因此微服务更适合小型团队的持续化发布;反之SOA是自顶向下的实施模式,必须进行分层式的过程管理,要有人对流程管理负责、ESB企业数据总线负责、各个构件服务也是不同组织的项目或开发团队负责。因此SOA架构在实施过程中具备清晰的责任关系,特别适合项目跨企业、大企业跨部门的复杂应用系统建设。这和微服务的实施过程可以说是天壤之别。

    (4)微服务与SOA一样,都是在分布式环境下,形成很多不同的独立服务,相对于SOA,微服务是细粒度的,SOA是粗粒度的,而且它们在技术的异构性的兼容上有着一致的风格,微服务是通过通讯机制,主要是Restful,实现不同微服务的相互协作,但微服务自身用什么技术来实现,那都不影响;同样前面的内容也说清楚了SOA的服务接口定义和Webservices实现,本身就是为了统一兼容异构平台之间的协作。

    最后我们看看SOA和微服务的对比总结

    从上面的对比,我们可以看到不能把任何问题都统一论之。微服务有其适合的场景,若在一个复杂的社会关系体系下建立一套复杂的应用系统,微服务的架构思想就是无源之水了。反倒是SOA架构思想就具备这种复杂体系下的生存条件,但是,例如放到很多互联网应用需要快速应对需求、敏捷迭代开发,灵活建立部署发布机制,那么SOA架构肯定就不适合了,这种环境正是微服务架构所适应的。

    因此我们可以总结到微服务在形式上与SOA很类似,在分布式环境中都是进行更多独立的服务、独立的部署,我们可以理解是SOA的继任者。但是骨子里微服务又将SOA那一套沉重的前期规划、设计和分层实施的思路彻底打烂,形成了一个新的思想变种,灵活、敏捷、小巧,更适合团队密切的协作。 这就是进行了SOA基因的彻底改造,形成了更简化的一种分布式架构形态,尤其满足更为互联网化应用的需求。

    前往读字节创作中心——了解”读字节“更多创作内容

    本文是公众号“读字节”原创文章,转载请务必显示文章来源

    展开全文
  • SOA,Service-Oriented Architecture,面向服务的架构。 从应用和基本原理角度看,有两种业界公认的标准定义: 应用角度:SOA是一种应用框架,它着眼于日常的业务应用,并将它们划分为单独的业务功能和流程,即...
  • 文章目录 什么是SOA: SOA主要技术 UDDI SOAP WSDL BPEL restful SOA实现方式 WebService 企业服务总线 ESB 服务注册表 什么是SOA: SOA:面向服务架构,是一种粗粒度、松耦合的服务架构,服务间通过定义良好的、...
  • positive~default-1-103328793.first_rank_v2_pc_rank_v29&utm_term=Sentinel&spm=1018.2226.3001.4449 简介: Sentinel 是面向分布式服务架构的高可用防护组件,主要以流量为切入点,从流量控制、熔断降级、系统...
  • (本文来自公众号:亨利笔记 ) 信息架构的4个组件 企业在运作过程中,首先需要管理好人和物等“资源”,然后管理好各类资源之间的联系,即各类业务交易“事件”,再对各类事件的执行效果进行“整体描述和评估”,...
  •   面向服务的架构 (Service-Oriented Architecture,SOA) 和面向资源架构 (Resource-Oriented Architecture,ROA) 是用于实现健壮、可扩展的分布式应用程序架构架构设计模式。分布式架构由通过定义良好的接口...
  • 点击上方“程序猿技术大咖”,关注并选择“设为星标”回复“加群”获取入群讨论资格!云原生架构是什么回顾过去十年,数字化转型驱动着技术创新和商业元素的不断融合和重构,可以说,现在已经不是由商业...
  • 面向空天地一体多接入的融合6G网络架构展望 刘超,陆璐,王硕,胡玉双 【摘要】 6G网络的重要需求之一是空天地一体化实现全球无缝覆盖。6G网络架构设计需要融合空天地一体化的多种接入方式。首先介绍了空天地一体...
  • 熟悉面向对象的七大设计原则,在衡量人力,资源,时间等成本的基础上尽量满足这几大原则。分别是:开闭原则、里氏替换原则、依赖倒置原则、单一职责原则、接口隔离原则、迪米特法、合成复用原则。 具体实现中主要...
  • 数据流风格架构又可以细分两种具体的架构风格:批处理序列和管道过滤器。 批处理序列 批处理风格通常会由总体协调安排批处理过程,保证其每-处理都是独立的,并且顺序执行。具体来看有以下特点: ●强时间顺序:只有...
  • 面向鲲鹏的创新架构 华为的鲲鹏920处理器以及后续的处理器系列,与传统的英特尔 x86处理器相比,存在以下3方面的不同: 具有更多计算核心,使得可以并行运行的算力大幅增加。 具有更加显著的 NUMA 特性,将导致并行...
  • 技术架构

    2021-02-03 11:06:01
    本文是阅读《极客时间-架构实战案例解析》的读书笔记 1、概述 对于开发人员来说,我们每天都在用技术。但我们写的代码,其实只是系统的一小部分,我们了解的技术,也只是系统用到的一小部分。要深入掌握技术架构,...
  • 面向部件的整车E/E架构开发咨询服务 概述 随着汽车电子电气系统复杂度的日益提高,各零部件间的交互影响带来安全性和稳定性的挑战,传统的Tier提供平台化零部件、OEM直接集成应用的开发模式,难以满足车型产品规避...
  • 软件架构设计分层模型和构图思考

    千次阅读 2021-03-20 00:17:33
    点击上方“朱小厮的博客”,选择“设为星标”后台回复"书",获取后台回复“k8s”,可领取k8s资料今天谈下架构设计中的分层思维和分层模型以及基于分层思维下的架构构图逻辑。架...
  • 在网上也看了很多关于架构方面的文章,林林总总,总感觉没有说的太清楚,可能是每个人的理解不一样,我自己也在繁杂的文章中总结一些架构方面的划分,...OA系统可以拆成人力资源管理系统、考勤系统等。 业务架构:..
  • 【软考系统架构设计师】2021年下系统架构师论文写作历年真题
  • 凤凰架构-架构演进

    2021-07-27 09:38:58
    周志明《凤凰架构:构建可靠的大型分布式系统》 https://icyfenix.cn/ 架构演进,原始分布式时代->单体系统时代->SOA时代->微服务时代->后微服务时代->无服务时代 架构并不是被“发明”出来的,而是...
  • 【软考系统架构设计师】2021年下系统架构师综合知识历年真题
  • 谈到软件系统设计的方法论,在代码层面,有我们熟悉的23种设计模式(design pattern),对应到架构层面,则有所谓的架构模式(architecture pattern)。它们分别从微观和宏观的角度指导着我们设计出良好的软件系统,...
  • 《从分层架构到微服务架构》是一系列介绍《Fundamentals of Software Architecture》中提到的8种架构模式的文章,这里不会事无巨细地介绍所有的细节,而是会挑选其中关键内容,更多详情请阅读原书。 前言 谈到软件...
  • 架构篇:整体架构设计观察 不管是从刚开始接触Workday,还是现在去回想Workday的各种使用体验,一个很深入人心的感受就是“简洁、统一”。 这让我想到了一家走标准化路线的酒店的广告词:“需要的我们都有,不需要...
  • 但随着金融支付终端硬件的增多以及设备类型的多样化,对应用软件提供基于硬件的统一架构支持成为了重要的课题.U架构是本文基于智能手持型金融终端并面向Android金融应用所设计和实现的统一软件架构.本文先根据架构所...
  • 架构技术选型到具体工程实践,书中内容理论联系实际,较为全面地剖析了容器落地、服务网格、无服务器计算、持续集成和持续部署等核心云原生技术,适合关注微服务、云原生技术的架构师、工程师及技术决策者阅读。...
  • 微服务架构服务容错设计分析

    多人点赞 热门讨论 2021-07-13 00:03:07
    在微服务体系架构中,由于拆解的服务数变多了,服务发生故障的地方也会相应的增加,因此如何保证服务架构健壮是一个值得深思的问题。微服务容错机制正是这样一种稳定性解决方案,可以理解微微服务架构的保险丝,通过...
  • 顺丰作为物流龙头,公司在 2018 年面临业务多元化、快速发展的诉求和技术架构工具、平台落后的冲突。在 2018-2021 年期间,顺丰通过联动业务研发、基础设施和工具平台“铁三角”,实现...
  • 一、软件架构评估 软件架构评估是在对架构分析、评估的基础上,对架构策略的选取进行决策。它也可以灵活地运用于对软件架构进行评审等工作中。 二、软件架构评估的方法 业界已开发出多种软件架构评估的方法,按基于...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 201,540
精华内容 80,616
关键字:

面向资源架构