微服务技术架构深入解析Word文档下载推荐.docx
- 文档编号:15187966
- 上传时间:2022-10-28
- 格式:DOCX
- 页数:11
- 大小:392.88KB
微服务技术架构深入解析Word文档下载推荐.docx
《微服务技术架构深入解析Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《微服务技术架构深入解析Word文档下载推荐.docx(11页珍藏版)》请在冰豆网上搜索。
至少有两个专门讨论该主题的会议:
O’Reilly的软件架构会议和SATURN会议。
许多开发人员的目标是成为一名架构师。
但什么是架构,为什么它如此重要?
为了回答这个问题,我首先定义术语软件架构的含义。
之后,我将讨论应用程序的架构是多维的,并使用一组视图或蓝图进行描述。
然后我将强调软件架构的重要性,因为它对应用程序的质量属性有显著的影响。
软件架构的定义
软件架构有很多定义。
例如,维基百科上列举了大量的定义。
我最喜欢的定义来自卡耐基梅隆大学软件工程研究所的LenBass及其同事,他们在使软件架构成为一门学科方面发挥了关键作用。
他们定义的软件架构如下:
计算机系统的软件架构是构建这个系统所需要的一组结构,包括软件元素、它们之间的关系以及两者的属性。
这显然是一个非常抽象的定义。
但其实质是应用程序的架构是将软件分解为元素(element)和这些元素之间的关系(relation)。
由于以下两个原因,分解很重要:
它促进了劳动和知识的分工。
它使具有特定专业知识的人们(或多个团队)能够就应用程序高效地协同工作。
它定义了软件元素的交互方式。
将软件分解成元素以及定义这些元素之间的关系,决定了软件的能力。
软件架构的4+1视图模型
从更具体的角度而言,应用程序的架构可以从多个视角来看,就像建筑架构,一般有结构、管线、电气等多个架构视角。
PhillipKrutchen在他经典的论文《ArchitecturalBlueprints—The4+1ViewModelofSoftwareArchitecture》中提出了软件架构的4+1视图。
图1展示的这套视图定义了四个不同的软件架构视图,每一个视图都只描述架构的一个特定方面。
每个视图包括一些特定的软件元素和它们相互之间的关系。
图1 4+1视图模型使用四个视图描述应用程序的架构,并显示每个视图中的元素如何协作处理请求的场景
每个视图的目的如下:
·
逻辑视图:
开发人员创建的软件元素。
在面向对象的语言中,这些元素是类和包。
它们之间的关系是类和包之间的关系,包括继承、关联和依赖。
实现视图:
构建编译系统的输出。
此视图由表示打包代码的模块和组件组成,组件是由一个或多个模块组成的可执行或可部署单元。
在Java中,模块是JAR文件,组件通常是WAR文件或可执行JAR文件。
它们之间的关系包括模块之间的依赖关系以及组件和模块之间的组合关系。
进程视图:
运行时的组件。
每个元素都是一个进程,进程之间的关系代表进程间通信。
部署视图:
进程如何映射到机器。
此视图中的元素由(物理或虚拟)计算机和进程组成。
机器之间的关系代表网络。
该视图还描述了进程和机器之间的关系。
除了这四个视图以外,4+1中的+1是指场景,它负责把视图串联在一起。
每个场景负责描述在一个视图中的多个架构元素如何协作,以完成一个请求。
例如,在逻辑视图中的场景,展现了类是如何协作的。
同样,在进程视图中的场景,展现了进程是如何协作的。
4+1视图是描述应用程序架构的绝佳方式。
每一个视图都描述了架构的一个重要侧面。
场景把视图中的元素如何协作串联在一起。
现在我们来看看为什么架构是如此重要。
为什么架构如此重要
应用程序有两个层面的需求。
第一类是功能性需求,这些需求决定一个应用程序做什么。
这些通常都包含在用例(usecase)或者用户故事(userstory)中。
应用的架构其实跟这些功能性需求没什么关系。
功能性需求可以通过任意的架构来实现,甚至是非常糟糕的大泥球架构。
架构的重要性在于,它帮助应用程序满足了第二类需求:
非功能性需求。
我们把这类需求也称之为质量属性需求,或者简称为“能力”。
这些非功能性需求决定一个应用程序在运行时的质量,比如可扩展性和可靠性。
它们也决定了开发阶段的质量,包括可维护性、可测试性、可扩展性和可部署性。
为应用程序所选择的架构将决定这些质量属性。
2 什么是架构的风格
在物理世界中,建筑物的建筑通常遵循特定的风格,例如维多利亚式、美国工匠式或装饰艺术式。
每种风格都是一系列设计决策,限制了建筑的特征和建筑材料。
建筑风格的概念也适用于软件。
DavidGarlan和MaryShaw这两位软件架构学科的先驱定义了如下架构风格:
因此,架构风格根据结构组织模式定义了一系列此类系统。
更具体地说,架构风格确定可以在该风格的实例中使用的组件和连接器的词汇表,以及关于如何组合它们的一组约束。
特定的架构风格提供了有限的元素(组件)和关系(连接器),你可以从中定义应用程序架构的视图。
应用程序通常使用多种架构风格的组合。
例如,在本节的后面,我将描述单体架构是如何将实现视图构造为单个(可执行与可部署)组件的架构样式。
微服务架构将应用程序构造为一组松散耦合的服务。
分层式架构风格
架构的典型例子是分层架构。
分层架构将软件元素按“层”的方式组织。
每个层都有明确定义的职责。
分层架构还限制了层之间的依赖关系。
每一层只能依赖于紧邻其下方的层(如果严格分层)或其下面的任何层。
可以将分层架构应用于前面讨论的四个视图中的任何一个。
流行的三层架构是应用于逻辑视图的分层架构。
它将应用程序的类组织到以下层中:
表现层:
包含实现用户界面或外部API的代码。
业务逻辑层:
包含业务逻辑。
数据持久化层:
实现与数据库交互的逻辑。
分层架构是架构风格的一个很好的例子,但它确实有一些明显的弊端:
单个表现层:
它无法展现应用程序可能不仅仅由单个系统调用的事实。
单一数据持久化层:
它无法展现应用程序可能与多个数据库进行交互的事实。
将业务逻辑层定义为依赖于数据持久化层:
理论上,这样的依赖性会妨碍你在没有数据库的情况下测试业务逻辑。
此外,分层架构错误地表示了精心设计的应用程序中的依赖关系。
业务逻辑通常定义数据访问方法的接口或接口库。
数据持久化层则定义了实现存储库接口的DAO类。
换句话说,依赖关系与分层架构所描述的相反。
让我们看一下克服这些弊端的替代架构:
六边形架构。
关于架构风格的六边形
六边形架构是分层架构风格的替代品。
如图2-2所示,六边形架构风格选择以业务逻辑为中心的方式组织逻辑视图。
应用程序具有一个或多个入站适配器,而不是表示层,它通过调用业务逻辑来处理来自外部的请求。
同样,应用程序具有一个或多个出站适配器,而不是数据持久化层,这些出站适配器由业务逻辑调用并调用外部应用程序。
此架构的一个关键特性和优点是业务逻辑不依赖于适配器。
相反,各种适配器都依赖业务逻辑。
图2 六边形架构的一个示例,它由业务逻辑和一个或多个与外部系统通信的适配器组成。
业务逻辑具有一个或多个端口。
处理来自外部系统请求的入站适配器调用入站端口。
出站适配器实现出站端口,并调用外部系统
业务逻辑具有一个或多个端口(port)。
端口定义了一组操作,关于业务逻辑如何与外部交互。
例如,在Java中,端口通常是Java接口。
有两种端口:
入站和出站端口。
入站端口是业务逻辑公开的API,它使外部应用程序可以调用它。
入站端口的一个实例是服务接口,它定义服务的公共方法。
出站端口是业务逻辑调用外部系统的方式。
出站端口的一个实例是存储库接口,它定义数据访问操作的集合。
业务逻辑的周围是适配器。
与端口一样,有两种类型的适配器:
入站和出站。
入站适配器通过调用入站端口来处理来自外部世界的请求。
入站适配器的一个实例是SpringMVCController,它实现一组REST接口(endpoint)或一组Web页面。
另一个实例是订阅消息的消息代理客户端。
多个入站适配器可以调用相同的入站端口。
出站适配器实现出站端口,并通过调用外部应用程序或服务处理来自业务逻辑的请求。
出站适配器的一个实例是实现访问数据库的操作的数据访问对象(DAO)类。
另一个实例是调用远程服务的代理类。
出站适配器也可以发布事件。
六边形架构风格的一个重要好处是它将业务逻辑与适配器中包含的表示层和数据访问层的逻辑分离开来。
业务逻辑不依赖于表示层逻辑或数据访问层逻辑。
由于这种分离,单独测试业务逻辑要容易得多。
另一个好处是它更准确地反映了现代应用程序的架构。
可以通过多个适配器调用业务逻辑,每个适配器实现特定的API或用户界面。
业务逻辑还可以调用多个适配器,每个适配器调用不同的外部系统。
六边形架构是描述微服务架构中每个服务的架构的好方法。
分层架构和六边形架构都是架构风格的实例。
每个都定义了架构的构建块(元素),并对它们之间的关系施加了约束。
六边形架构和分层架构(三层架构)构成了软件的逻辑视图。
现在让我们将微服务架构定义为构成软件的实现视图的架构风格。
2.1.3 微服务架构是一种架构风格
前面已经讨论过4+1视图模型和架构风格,所以现在可以开始定义单体架构和微服务架构。
它们都是架构风格。
单体架构是一种架构风格,它的实现视图是单个组件:
单个可执行文件或WAR文件。
这个定义并没有说明其他的视图。
例如,单体应用程序可以具有六边形架构风格的逻辑视图。
模式:
单体架构
将应用程序构建为单个可执行和可部署组件。
请参阅:
http:
//microservices.io/patterns/monolithic.html。
微服务架构也是一种架构风格。
它的实现视图由多个组件构成:
一组可执行文件或WAR文件。
它的组件是服务,连接器是使这些服务能够协作的通信协议。
每个服务都有自己的逻辑视图架构,通常也是六边形架构。
图2-3显示了FTGO应用程序可能的微服务架构。
此架构中的服务对应于业务功能,例如订单管理和餐馆管理。
微服务架构
将应用程序构建为松耦合、可独立部署的一组服务。
//microservices.io/patterns/microservices.html。
图3 FTGO应用程序可能的微服务架构。
它由众多服务组成
微服务架构强加的一个关键约束是服务松耦合。
因此,服务之间的协作方式存在一定限制。
为了解释这些限制,我将尝试定义什么是服务,解释松耦合意味着什么,并告诉你为什么这很重要。
什么是服务
服务是一个单一的、可独立部署的软件组件,它实现了一些有用的功能。
图2-4显示了服务的外部视图,在此示例中是OrderService。
服务具有API,为其客户端提供对功能的访问。
有两种类型的操作:
命令和查询。
API由命令、查询和事件组成。
命令如createOrder()执行操作并更新数据。
查询,如findOrderById()检索数据。
服务还发布由其客户端使用的事件,例如OrderCreated。
服务的API封装了其内部实现。
与单体架构不同,开发人员无法绕过服务的API直接访问服务内部的方法或数据。
因此,微服务架构强制实现了应用程序的模块化。
微服务架构中的每项服务都有自己的架构,可能还有独特的技术栈。
但是典型的服务往往都具有六边形架构。
其API由与服务的业务
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 微服 技术 架构 深入 解析
![提示](https://static.bdocx.com/images/bang_tan.gif)