📜  微服务架构-简介

📅  最后修改于: 2020-11-24 06:00:27             🧑  作者: Mango


微服务是一种基于服务的应用程序开发方法。在这种方法中,大型应用程序将被划分为最小的独立服务单元。微服务是通过将整个应用程序划分为互连服务的集合来实现面向服务的体系结构(SOA)的过程,其中每个服务只能满足一个业务需求。

微型化的概念

在面向服务的体系结构中,整个软件包将细分为相互连接的小型业务部门。这些小型业务部门中的每一个将使用不同的协议相互通信,以将成功的业务交付给客户。现在的问题是,微服务架构(MSA)与SOA有何不同?总之,SOA是一种设计模式,而微服务是一种实现SOA的实现方法,或者我们可以说微服务是一种SOA。

在开发面向微服务的应用程序时,需要遵循以下一些规则。

  • 独立-每个微服务应可独立部署。

  • 耦合-所有微服务都应彼此松散耦合,以使其中一项更改不会影响另一项。

  • 业务目标-整个应用程序的每个服务单元应最小,并能够交付一个特定的业务目标。

让我们考虑一个在线购物门户的示例,以深入了解微服务。现在,让我们将整个电子商务门户划分为小型业务部门,例如用户管理,订单管理,签到,付款管理,交付管理等。一个成功的订单需要在特定时间内通过所有这些模块进行帧。以下是与一个电子商务系统关联的不同业务部门的合并图像。

电子商务解决方案

这些业务模块中的每一个都应具有自己的业务逻辑和利益相关者。他们与某些特定需求的其他第三方供应商软件进行通信,并且还彼此通信。例如,订单管理可以与用户管理进行通信以获得用户信息。

现在,考虑到您正在运行包含前面提到的所有这些业务部门的在线购物门户,那么您确实需要一些由不同层(例如前端,后端,数据库等)组成的企业级应用程序。并在单个战争文件中完全开发,然后将其称为典型的整体应用程序。根据IBM的说法,典型的整体应用程序内部应具有以下模块结构,其中只有一个端点或应用程序将负责处理所有用户请求。

数据库

在上图中,您可以看到不同的模块,例如用于存储不同用户和业务数据的数据库。在前端,我们有不同的设备,我们通常在其中渲染用户或业务数据以供使用。在中间,我们有一个包,可以是可部署的EAR或WAR文件,它可以接受用户端的请求,在资源的帮助下对其进行处理,然后将其呈现给用户。一切都会好起来的,直到企业希望对以上示例进行任何更改。

考虑以下方案,在这些方案中,您必须根据业务需求更改应用程序。

业务部门需要在“搜索”模块中进行一些更改。然后,您需要更改整个搜索过程并重新部署您的应用程序。在这种情况下,您将完全重新部署其他单元。

业务部

现在,您的业务部门再次需要在“签出”模块中进行一些更改,以包括“钱包”选项。现在,您必须更改“签出”模块,然后将其重新部署到服务器中。请注意,您正在重新部署软件包的不同模块,但我们没有对其进行任何更改。这里出现了面向服务的体系结构的概念,该概念更特定于微服务体系结构。我们可以以这种方式开发整体应用程序,即软件的每个模块都将表现为一个独立的单元,能够独立处理单个业务任务。

考虑以下示例。

在以上架构中,我们不会使用紧凑的端到端服务来创建任何ear文件。相反,我们通过将软件作为服务公开来划分软件的不同部分。通过使用相应的服务,软件的任何部分都可以轻松地彼此通信。这就是微服务在现代Web应用程序中扮演重要角色的方式。

让我们比较一下微服务系列中的购物车示例。我们可以按照“搜索”,“过滤器”,“结帐”,“购物车”,“推荐”等不同的模块细分购物车。如果要构建购物车门户,则必须构建上面提到的模块可以相互连接,从而为您提供24×7的良好购物体验。

优点缺点

以下是使用微服务而不是使用整体应用程序的优势的几点。

好处

  • 体积小-微服务是SOA设计模式的一种实现。建议您尽可能多地保留服务。基本上,一项服务不应执行一项以上的业务任务,因此与任何其他整体应用程序相比,该服务的大小显然很小,并且易于维护。

  • 专注-如前所述,每个微服务仅设计为交付一项业务任务。在设计微服务时,架构师应关注服务的重点,即它的可交付性。根据定义,一种微服务本质上应该是全栈的,并且应致力于仅交付一种业务资产。

  • 自治-每个微服务都应该是整个应用程序的自治业务部门。因此,应用程序变得松散耦合,这有助于降低维护成本。

  • 技术异质性-微服务支持在一个业务部门中相互通信的不同技术,这有助于开发人员在正确的位置使用正确的技术。通过实施异构系统,可以获得最大的安全性,速度和可伸缩的系统。

  • 弹性-弹性是隔离软件单元的属性。微服务遵循高水平的构建方法弹性,因此,只要一个单元发生故障,它就不会影响整个业务。弹性是实现高可扩展性和较少耦合的系统的另一个属性。

  • 易于部署-由于将整个应用程序细分为一小部分,因此每个组件本质上都应该是完整堆栈。所有这些都可以很容易地部署在任何环境中,并且时间复杂度更低,这与同类其他单片应用程序不同。

以下是关于微服务架构的缺点的一些观点。

缺点

  • 分布式系统-由于技术的多样性,将使用不同的技术来开发微服务的不同部分。需要大量熟练的专业人员来支持这种大型的异构分布式软件。因此,分布式和异构性是使用微服务的第一个缺点。

  • 成本-微服务的成本很高,因为您必须为不同的业务任务维护不同的服务器空间。

  • 企业准备就绪-随着技术的日新月异,微服务架构可以被视为不同技术的综合体。因此,很难使微服务应用程序企业准备好与传统软件开发模型进行比较。

SOA上的微服务

下表列出了SOA和微服务的某些功能,阐明了在SOA上使用微服务的重要性。

Component SOA Microservice
Design pattern SOA is a design paradigm for computer software, where software components are exposed to the outer world for usage in the form of services. Micro Service is a part of SOA. It is a specialized implementation of SOA.
Dependency Business units are dependent on each other. All business units are independent of each other.
Size Software size is bigger than the conventional software. Software size is small.
Technology Technology stack is less than Microservice. Microservice is heterogeneous in nature as exact technologies are used to perform a specific task. Microservices can be considered as a conglomerate of many technologies.
Autonomous and Focus SOA applications are built to perform multiple business tasks. Microservice applications are built to perform a single business task.
Nature Monolithic in nature. Full stack in nature.
Deployment Deployment is time-consuming. Deployment is very easy. Hence, it will be less time-consuming.
Cost-effectiveness More cost-effective. Less cost-effective.
Scalability Less compared to Microservices. Fully scaled.
Example Let us consider one online CAB booking application. If we want to build that application using SOA, then its software units will be −
  • GetPayments And DriverInformation And MappingDataAPI
  • AuthenticateUsersAnd DriversAPI
If the same application is built using microservice architecture, then its APIs will be −
  • SubmitPaymentsService
  • GetDriverInfoService
  • GetMappingDataService
  • AuthenticateUserService
  • AuthenticateDriverService