您当前的位置:首页 > 电脑百科 > 程序开发 > 架构

JD架构师分享:微服务架构到底是什么东西

时间:2019-08-07 09:17:21  来源:  作者:

软件的架构是一种抽象的结构,它由软件的各个组成部分和这些部分之间的依赖关系构成。正如你将在本文中看到的,软件的架构是多维的,因此有多种方法可以对其进行描述。架构很重要的原因是它决定了应用程序的质量属性或能力。传统上,架构的目标是可扩展性、可靠性和安全性。但是今天,该架构能够快速安全地交付软件,这一点非常重要。你将了解微服务架构是一种架构风格,可为应用程序提供更高的可维护性、可测试性和可部署性。

JD架构师分享:微服务架构到底是什么东西

 

我将通过描述软件架构的概念及其重要性来开始本文。接下来,我将讨论架构风格的概念。然后我将微服务架构定义为特定的架构风格。让我们从理解软件架构的概念开始。

1软件架构是什么,为什么它如此重要

架构显然很重要。至少有两个专门讨论该主题的会议:O’Reilly的软件架构会议和SATURN会议。许多开发人员的目标是成为一名架构师。但什么是架构,为什么它如此重要?

为了回答这个问题,我首先定义术语软件架构的含义。之后,我将讨论应用程序的架构是多维的,并使用一组视图或蓝图进行描述。然后我将强调软件架构的重要性,因为它对应用程序的质量属性有显著的影响。

JD架构师分享:微服务架构到底是什么东西

 

软件架构的定义

软件架构有很多定义。例如,维基百科上列举了大量的定义。我最喜欢的定义来自卡耐基梅隆大学软件工程研究所的Len Bass及其同事,他们在使软件架构成为一门学科方面发挥了关键作用。他们定义的软件架构如下:

计算机系统的软件架构是构建这个系统所需要的一组结构,包括软件元素、它们之间的关系以及两者的属性。

这显然是一个非常抽象的定义。但其实质是应用程序的架构是将软件分解为元素(element)和这些元素之间的关系(relation)。由于以下两个原因,分解很重要:

它促进了劳动和知识的分工。它使具有特定专业知识的人们(或多个团队)能够就应用程序高效地协同工作。

它定义了软件元素的交互方式。

将软件分解成元素以及定义这些元素之间的关系,决定了软件的能力。

软件架构的4+1视图模型

从更具体的角度而言,应用程序的架构可以从多个视角来看,就像建筑架构,一般有结构、管线、电气等多个架构视角。 Phillip Krutchen 在他经典的论文《 Architectural Blueprints — The 4+1 View Model of Software Architecture 》中提出了软件架构的4+1视图。图1展示的这套视图定义了四个不同的软件架构视图,每一个视图都只描述架构的一个特定方面。每个视图包括一些特定的软件元素和它们相互之间的关系。

 

JD架构师分享:微服务架构到底是什么东西

 

 

图14+1视图模型使用四个视图描述应用程序的架构,并显示每个视图中的元素如何协作处理请求的场景

每个视图的目的如下:

  • 逻辑视图:开发人员创建的软件元素。在面向对象的语言中,这些元素是类和包。它们之间的关系是类和包之间的关系,包括继承、关联和依赖。
  • 实现视图:构建编译系统的输出。此视图由表示打包代码的模块和组件组成,组件是由一个或多个模块组成的可执行或可部署单元。在JAVA中,模块是JAR文件,组件通常是WAR文件或可执行JAR文件。它们之间的关系包括模块之间的依赖关系以及组件和模块之间的组合关系。
  • 进程视图:运行时的组件。每个元素都是一个进程,进程之间的关系代表进程间通信。
  • 部署视图:进程如何映射到机器。此视图中的元素由(物理或虚拟)计算机和进程组成。机器之间的关系代表网络。该视图还描述了进程和机器之间的关系。

除了这四个视图以外,4+1中的+1是指场景,它负责把视图串联在一起。每个场景负责描述在一个视图中的多个架构元素如何协作,以完成一个请求。例如,在逻辑视图中的场景,展现了类是如何协作的。同样,在进程视图中的场景,展现了进程是如何协作的。

4+1视图是描述应用程序架构的绝佳方式。每一个视图都描述了架构的一个重要侧面。场景把视图中的元素如何协作串联在一起。现在我们来看看为什么架构是如此重要。

为什么架构如此重要

应用程序有两个层面的需求。第一类是功能性需求,这些需求决定一个应用程序做什么。这些通常都包含在用例(use case)或者用户故事(user story)中。应用的架构其实跟这些功能性需求没什么关系。功能性需求可以通过任意的架构来实现,甚至是非常糟糕的大泥球架构。

JD架构师分享:微服务架构到底是什么东西

 

架构的重要性在于,它帮助应用程序满足了第二类需求:非功能性需求。我们把这类需求也称之为质量属性需求,或者简称为“能力”。这些非功能性需求决定一个应用程序在运行时的质量,比如可扩展性和可靠性。它们也决定了开发阶段的质量,包括可维护性、可测试性、可扩展性和可部署性。为应用程序所选择的架构将决定这些质量属性。

2什么是架构的风格

在物理世界中,建筑物的建筑通常遵循特定的风格,例如维多利亚式、美国工匠式或装饰艺术式。每种风格都是一系列设计决策,限制了建筑的特征和建筑材料。建筑风格的概念也适用于软件。David Garlan和Mary Shaw这两位软件架构学科的先驱定义了如下架构风格:

因此,架构风格根据结构组织模式定义了一系列此类系统。更具体地说,架构风格确定可以在该风格的实例中使用的组件和连接器的词汇表,以及关于如何组合它们的一组约束。

特定的架构风格提供了有限的元素(组件)和关系(连接器),你可以从中定义应用程序架构的视图。应用程序通常使用多种架构风格的组合。例如,在本节的后面,我将描述单体架构是如何将实现视图构造为单个(可执行与可部署)组件的架构样式。微服务架构将应用程序构造为一组松散耦合的服务。

分层式架构风格

架构的典型例子是分层架构。分层架构将软件元素按“层”的方式组织。每个层都有明确定义的职责。分层架构还限制了层之间的依赖关系。每一层只能依赖于紧邻其下方的层(如果严格分层)或其下面的任何层。

可以将分层架构应用于前面讨论的四个视图中的任何一个。流行的三层架构是应用于逻辑视图的分层架构。它将应用程序的类组织到以下层中:

  • 表现层:包含实现用户界面或外部API的代码。
  • 业务逻辑层:包含业务逻辑。
  • 数据持久化层:实现与数据库交互的逻辑。

分层架构是架构风格的一个很好的例子,但它确实有一些明显的弊端:

  • 单个表现层:它无法展现应用程序可能不仅仅由单个系统调用的事实。
  • 单一数据持久化层:它无法展现应用程序可能与多个数据库进行交互的事实。
  • 将业务逻辑层定义为依赖于数据持久化层:理论上,这样的依赖性会妨碍你在没有数据库的情况下测试业务逻辑。

此外,分层架构错误地表示了精心设计的应用程序中的依赖关系。业务逻辑通常定义数据访问方法的接口或接口库。数据持久化层则定义了实现存储库接口的DAO类。换句话说,依赖关系与分层架构所描述的相反。

让我们看一下克服这些弊端的替代架构:六边形架构。

关于架构风格的六边形

六边形架构是分层架构风格的替代品。如图2-2所示,六边形架构风格选择以业务逻辑为中心的方式组织逻辑视图。应用程序具有一个或多个入站适配器,而不是表示层,它通过调用业务逻辑来处理来自外部的请求。同样,应用程序具有一个或多个出站适配器,而不是数据持久化层,这些出站适配器由业务逻辑调用并调用外部应用程序。此架构的一个关键特性和优点是业务逻辑不依赖于适配器。相反,各种适配器都依赖业务逻辑。

 

JD架构师分享:微服务架构到底是什么东西

 

 

图2六边形架构的一个示例,它由业务逻辑和一个或多个与外部系统通信的适配器组成。业务逻辑具有一个或多个端口。处理来自外部系统请求的入站适配器调用入站端口。出站适配器实现出站端口,并调用外部系统

业务逻辑具有一个或多个端口( port )。端口定义了一组操作,关于业务逻辑如何与外部交互。例如,在 Java 中,端口通常是 Java 接口。有两种端口:入站和出站端口。入站端口是业务逻辑公开的API,它使外部应用程序可以调用它。入站端口的一个实例是服务接口,它定义服务的公共方法。出站端口是业务逻辑调用外部系统的方式。出站端口的一个实例是存储库接口,它定义数据访问操作的集合。

业务逻辑的周围是适配器。与端口一样,有两种类型的适配器:入站和出站。入站适配器通过调用入站端口来处理来自外部世界的请求。入站适配器的一个实例是 Spring MVC Controller ,它实现一组 REST 接口( endpoint )或一组 Web 页面。另一个实例是订阅消息的消息代理客户端。多个入站适配器可以调用相同的入站端口。

出站适配器实现出站端口,并通过调用外部应用程序或服务处理来自业务逻辑的请求。出站适配器的一个实例是实现访问数据库的操作的数据访问对象( DAO )类。另一个实例是调用远程服务的代理类。出站适配器也可以发布事件。

六边形架构风格的一个重要好处是它将业务逻辑与适配器中包含的表示层和数据访问层的逻辑分离开来。业务逻辑不依赖于表示层逻辑或数据访问层逻辑。

由于这种分离,单独测试业务逻辑要容易得多。另一个好处是它更准确地反映了现代应用程序的架构。可以通过多个适配器调用业务逻辑,每个适配器实现特定的API或用户界面。业务逻辑还可以调用多个适配器,每个适配器调用不同的外部系统。六边形架构是描述微服务架构中每个服务的架构的好方法。

分层架构和六边形架构都是架构风格的实例。每个都定义了架构的构建块(元素),并对它们之间的关系施加了约束。六边形架构和分层架构(三层架构)构成了软件的逻辑视图。现在让我们将微服务架构定义为构成软件的实现视图的架构风格。

2.1.3微服务架构是一种架构风格

前面已经讨论过4+1视图模型和架构风格,所以现在可以开始定义单体架构和微服务架构。它们都是架构风格。单体架构是一种架构风格,它的实现视图是单个组件:单个可执行文件或WAR文件。这个定义并没有说明其他的视图。例如,单体应用程序可以具有六边形架构风格的逻辑视图。

模式:单体架构

将应用程序构建为单个可执行和可部署组件。请参阅: http://microservices.io/patterns/monolithic.html

微服务架构也是一种架构风格。它的实现视图由多个组件构成:一组可执行文件或WAR文件。它的组件是服务,连接器是使这些服务能够协作的通信协议。每个服务都有自己的逻辑视图架构,通常也是六边形架构。图2-3显示了FTGO应用程序可能的微服务架构。此架构中的服务对应于业务功能,例如订单管理和餐馆管理。

模式:微服务架构

将应用程序构建为松耦合、可独立部署的一组服务。请参阅: http://microservices.io/patterns/microservices.html。

 

JD架构师分享:微服务架构到底是什么东西

 

 

图3FTGO应用程序可能的微服务架构。它由众多服务组成

微服务架构强加的一个关键约束是服务松耦合。因此,服务之间的协作方式存在一定限制。为了解释这些限制,我将尝试定义什么是服务,解释松耦合意味着什么,并告诉你为什么这很重要。

什么是服务

服务是一个单一的、可独立部署的软件组件,它实现了一些有用的功能。图2-4显示了服务的外部视图,在此示例中是Order Service。服务具有API,为其客户端提供对功能的访问。有两种类型的操作:命令和查询。API由命令、查询和事件组成。命令如createOrder()执行操作并更新数据。查询,如findOrderById()检索数据。服务还发布由其客户端使用的事件,例如OrderCreated。

服务的API封装了其内部实现。与单体架构不同,开发人员无法绕过服务的API直接访问服务内部的方法或数据。因此,微服务架构强制实现了应用程序的模块化。

微服务架构中的每项服务都有自己的架构,可能还有独特的技术栈。但是典型的服务往往都具有六边形架构。其API由与服务的业务逻辑交互的适配器实现。操作适配器调用业务逻辑,事件适配器对外发布业务逻辑产生的事件。

 

JD架构师分享:微服务架构到底是什么东西

 

 

图4服务具有封装实现的API。API定义了由客户端调用的操作。有两种类型的操作:命令用来更新数据,查询用来检索数据。当服务的数据发生更改时,服务会发布可供客户端订阅的事件

在本书第12章讨论部署技术时,你将看到服务的实现视图可以采用多种形式。该组件可以是独立进程,在容器中运行的Web应用程序或OSGI包、云主机或Serverless技术,等等。但是,一个基本要求是服务具有API并且可以独立部署。

什么是松耦合

微服务架构的最核心特性是服务之间的松耦合性。服务之间的交互采用API完成,这样做就封装了服务的实现细节。这允许服务在不影响客户端的情况下,对实现方式做出修改。松耦合服务是改善开发效率、提升可维护性和可测试性的关键。小的、松耦合的服务更容易被理解、修改和测试。

我们通过API来实现松耦合服务之间的协调调用,这样就避免了外界对服务的数据库的直接访问和调用。服务自身的持久化数据就如同类的私有属性一样,是不对外的。保证数据的私有属性是实现松耦合的前提之一。这样做,就允许开发者修改服务的数据结构,而不用提前与其他服务的开发者互相协商。这样做在运行时也实现了更好的隔离。例如,一个服务的数据库加锁不会影响另外的服务。但是你稍后就会看到在服务间不共享数据库的弊端,特别是处理数据一致性和跨服务查询都变得更为复杂。

共享类库的角色

开发人员经常把一些通用的功能打包到库或模块中,以便多个应用程序可以重用它而无须复制代码。毕竟,如果没有Maven或npm库,我们今天的开发工作都会变得更困难。你可能也想在微服务架构中使用共享库。从表面上看,它似乎是减少服务中代码重复的好方法。但是你需要确保不会意外地在服务之间引入耦合。

例如,想象一下多个服务需要更新Order业务对象的场景。一种选择是将该功能打包为可供多个服务使用的库。一方面,使用库可以消除代码重复。另一方面,如果业务需求的变更影响了Order业务对象,开发者需要同时重建和重新部署所有使用了共享库的服务。更好的选择是把这些可能会更改的通用功能(例如Order管理)作为服务来实现,而不是共享库。

你应该努力使用共享库来实现不太可能改变的功能。例如,在典型的应用程序中,在每个服务中都实现一个通用的Money类(例如用来实现币种转换等固定功能)没有任何意义。相反,你应该创建一个供所有服务使用的共享库。

服务的大小并不重要

微服务这个术语的一个问题是会将你的关注点错误地聚焦在微上。它暗示服务应该非常小。其他基于大小的术语 (如miniservice或nanoservice) 也是如此。实际上,大小不是一个重要的考虑因素。

更好的目标是将精心设计的服务定义为能够由小团队开发的服务,并且交付时间最短,与其他团队协作最少。理论上,团队可能只负责单一服务,因此服务绝不是微小的。相反,如果服务需要大型团队或需要很长时间进行测试,那么拆分团队或服务可能是有意义的。另外,如果你因为其他服务的变更而不断需要同步更新自己负责的服务,或者你所负责的服务正在触发其他服务的同步更新,那么这表明服务没有实现松耦合。你构建的甚至可能是一个分布式的单体。

微服务架构把应用程序通过一些小的、松耦合的服务组织在一起。结果,这样的架构提升了开发阶段的效率,特别是可维护性、可测试性和可部署性,这也就让组织的软件开发速度更快。微服务架构也同时提升了应用程序的可扩展性,尽管这不是微服务的主要目标。为了使用微服务架构开发软件,你首先需要识别服务,并确定它们之间如何协作。现在我们来看看如何定义一个应用程序的微服务架构。

4 总结

  • 架构决定了软件的各种非功能性因素,比如可维护性、可测试性、可部署性和可扩展性,它们会直接影响开发速度。
  • 微服务架构是一种架构风格,它给应用程序带来了更高的可维护性、可测试性、可部署性和可扩展性。


Tags:微服务架构   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
前言要理解微服务,首先要先理解不是微服务的那些。通常跟微服务相对的是单体应用,即将所有功能都打包成在一个独立单元的应用程序。从单体应用到微服务并不是一蹴而就的,这是一...【详细内容】
2021-07-09  Tags: 微服务架构  点击:(112)  评论:(0)  加入收藏
一、Zuul简介Zuul相当于是第三方调用和服务提供方之间的防护门,其中最大的亮点就是可动态发布过滤器二、Zuul可以为我们提供什么1、权限控制2、预警和监控3、红绿部署、(粘...【详细内容】
2021-04-21  Tags: 微服务架构  点击:(230)  评论:(0)  加入收藏
前不久作为架构师完成了某知名快消企业的一个业务中台建设。系统上线后,经历了双十一活动的流量高峰,整体运行稳定。最近有空,便将此次架构的思路,心得稍作整理在这篇博客中分享...【详细内容】
2021-02-07  Tags: 微服务架构  点击:(182)  评论:(0)  加入收藏
文章简介:作者结合自身微服务架构研发经验进行回顾、总结,本文将介绍微服务架构中,在技术选型时需要注意哪些选型原则,会遇到哪些开源框架,又该如何选择, 进行了全面的归纳、对比,希望能够为大家提供一些思路、方向,少走一些...【详细内容】
2021-02-05  Tags: 微服务架构  点击:(160)  评论:(0)  加入收藏
思维导图 文章已收录Github精选,欢迎Star:https://github.com/yehongzhi/learningSummary一、前言伴随着Eurka2.0版本已停止维护,开始要考虑使用微服务新一代的开源的注册中心...【详细内容】
2020-11-13  Tags: 微服务架构  点击:(159)  评论:(0)  加入收藏
消息总线的定义前面在1.4.2节中强调过,在微服务架构中,经常会使用REST 服务或基于消息的通信机制。在3.6节中也详细介绍了消息通信的实现方式。消息总线就是一种基于消息的通...【详细内容】
2020-09-29  Tags: 微服务架构  点击:(141)  评论:(0)  加入收藏
微服务的高级主题一自动扩展Spring Cloud 提供了大规模部署微服务所必需的支持。为了获得像云服务环境一样的能力, 微服务实例也应该能够根据流量的规模来自动扩展,也称自动缩...【详细内容】
2020-09-23  Tags: 微服务架构  点击:(96)  评论:(0)  加入收藏
Spring Cloud 微服务总体架构图Spring cloud作为当下主流的微服务框架,让我们实现微服务架构简单快捷,Spring cloud中各个组件在微服务架构中扮演的角色如图所示。spring-cl...【详细内容】
2020-09-20  Tags: 微服务架构  点击:(133)  评论:(0)  加入收藏
常见微服务的消费者本节就常见的微服务的消费者进行介绍。在Java领域比较常用的消费者框架主要有HttpClient、Ribbon、Feign 等。 Apache HttpClientApache HttpClient是Apa...【详细内容】
2020-09-11  Tags: 微服务架构  点击:(129)  评论:(0)  加入收藏
什么是微服务模式随着网络基础设施的高速发展,以及越来越多的个体接入互联网,在考虑构建支持海量请求以及多变业务的软件平台时,微服务架构成为多数人的首选。微服务架构的出现...【详细内容】
2020-09-09  Tags: 微服务架构  点击:(95)  评论:(0)  加入收藏
▌简易百科推荐
为了构建高并发、高可用的系统架构,压测、容量预估必不可少,在发现系统瓶颈后,需要有针对性地扩容、优化。结合楼主的经验和知识,本文做一个简单的总结,欢迎探讨。1、QPS保障目标...【详细内容】
2021-12-27  大数据架构师    Tags:架构   点击:(5)  评论:(0)  加入收藏
前言 单片机开发中,我们往往首先接触裸机系统,然后到RTOS,那么它们的软件架构是什么?这是我们开发人员必须认真考虑的问题。在实际项目中,首先选择软件架构是非常重要的,接下来我...【详细内容】
2021-12-23  正点原子原子哥    Tags:架构   点击:(7)  评论:(0)  加入收藏
现有数据架构难以支撑现代化应用的实现。 随着云计算产业的快速崛起,带动着各行各业开始自己的基于云的业务创新和信息架构现代化,云计算的可靠性、灵活性、按需计费的高性价...【详细内容】
2021-12-22    CSDN  Tags:数据架构   点击:(10)  评论:(0)  加入收藏
▶ 企业级项目结构封装释义 如果你刚毕业,作为Java新手程序员进入一家企业,拿到代码之后,你有什么感觉呢?如果你没有听过多模块、分布式这类的概念,那么多半会傻眼。为什么一个项...【详细内容】
2021-12-20  蜗牛学苑    Tags:微服务   点击:(9)  评论:(0)  加入收藏
我是一名程序员关注我们吧,我们会多多分享技术和资源。进来的朋友,可以多了解下青锋的产品,已开源多个产品的架构版本。Thymeleaf版(开源)1、采用技术: springboot、layui、Thymel...【详细内容】
2021-12-14  青锋爱编程    Tags:后台架构   点击:(21)  评论:(0)  加入收藏
在了解连接池之前,我们需要对长、短链接建立初步认识。我们都知道,网络通信大部分都是基于TCP/IP协议,数据传输之前,双方通过“三次握手”建立连接,当数据传输完成之后,又通过“四次挥手”释放连接,以下是“三次握手”与“四...【详细内容】
2021-12-14  架构即人生    Tags:连接池   点击:(17)  评论:(0)  加入收藏
随着移动互联网技术的快速发展,在新业务、新领域、新场景的驱动下,基于传统大型机的服务部署方式,不仅难以适应快速增长的业务需求,而且持续耗费高昂的成本,从而使得各大生产厂商...【详细内容】
2021-12-08  架构驿站    Tags:分布式系统   点击:(23)  评论:(0)  加入收藏
本系列为 Netty 学习笔记,本篇介绍总结Java NIO 网络编程。Netty 作为一个异步的、事件驱动的网络应用程序框架,也是基于NIO的客户、服务器端的编程框架。其对 Java NIO 底层...【详细内容】
2021-12-07  大数据架构师    Tags:Netty   点击:(17)  评论:(0)  加入收藏
前面谈过很多关于数字化转型,云原生,微服务方面的文章。虽然自己一直做大集团的SOA集成平台咨询规划和建设项目,但是当前传统企业数字化转型,国产化和自主可控,云原生,微服务是不...【详细内容】
2021-12-06  人月聊IT    Tags:架构   点击:(23)  评论:(0)  加入收藏
微服务看似是完美的解决方案。从理论上来说,微服务提高了开发速度,而且还可以单独扩展应用的某个部分。但实际上,微服务带有一定的隐形成本。我认为,没有亲自动手构建微服务的经历,就无法真正了解其复杂性。...【详细内容】
2021-11-26  GreekDataGuy  CSDN  Tags:单体应用   点击:(35)  评论:(0)  加入收藏
最新更新
栏目热门
栏目头条