17611538698
webmaster@21cto.com

微服务架构技术指南

架构 0 984 2022-11-29 11:56:07

图片

导读:通过参考和阅读本文,开发者将能够更好地了解微服务架构以及何时使用它。本文由以下主要内容构成。

目录

  • 介绍

  • 微服务生态系统

  • 整体架构与微服务架构

  • 微服务中的挑战

  • 何时使用微服务


技术名词缩略语

  • API:应用程序编程接口

  • Microservice:微服务

  • NoSQL:不仅仅是SQL

  • RTE:运行时环境


介绍


微服务架构是一种应用程序开发方法,也就是将大型应用程序构建为一组模块化服务(这表示它(微服务)是一种应用程序架构,其中应用程序作为服务集合开发)。每个模块都支持一个特定的业务目标,并使用一个定义好的简单接口与其它服务集合进行通信。此外,集中管理服务是最低限度的,这些服务可以用不同的编程语言来写,如Java、Python等,在微服务架构中也可以使用不同的数据存储技术,如关系型数据库和NoSQL。


图片

微服务架构

服务有一些关键特性/特性如下:


  • 高度可维护和可测试

  • 松散耦合(通过接口通信)

  • 可独立部署

  • 围绕业务能力组织

  • 由一个小团队(跨职能团队)拥有


微服务生态系统


通常,微服务系统包含以下列出的实体。其中一些实体是标准软件开发中的阶段,其中一些是微服务特定的流程,它们为高效微服务系统提供支撑。


负载均衡设备

负载均衡的主要职责是在许多微服务实例之间分配传入负载。它主要有两种类型的负载均衡器,分别为客户端发现(client-side load balancer)和服务器发现(server-side load balancer)。在客户端发现中,客户端与服务注册中心对话并进行负载均衡。因为客户端需要知道服务注册表。在服务器发现中,客户端与负载均衡器对话,而负载均衡器与服务注册中心对话。因此,客户端服务不需要知道服务注册表。通过查看下图,你可以更深入地了解这两种类型的负载均衡器。

图片

客户端负载均衡设备


服务发现服务器

服务发现功能允许微服务在启动时自行注册,而不是手动跟踪当前部署的微服务以及需要的主机和端口。比如,如果 MS1 要与 MS2 通话,首先,MS1 从属于它环境的注册服务中获取详细信息,然后与 MS2 通话。此外,当有另一个名为 MS3 的 MS 在同一环境中启动或关闭时,注册表服务将自动更新。

图片

服务发现服务器

API网关

API 网关是一个服务器。它是系统的单一入口点。API Gateway 封装了内部系统架构。它提供了为每个客户端量身定制的 API。它还具有其他职责,例如身份验证、监控、负载平衡、缓存、请求整形和管理以及静态响应处理。API 网关还负责请求路由、组合和协议转换。客户端发出的所有请求都经过 API 网关。之后,API 网关将请求路由到适当的微服务。

API 网关以两种方式之一处理请求:

  • 将请求路由或代理到适当的服务。

  • 将请求分发(传播)到多个服务。

图片

API网关


监控

我们知道在同一个生态系统中的不同节点上,运行着很多微服务。因此需要在单个系统中一起监控它们是必不可少的。Hystrix 仪表板和 Spring boot 管理仪表板是监控工具的一些实例。

监控微服务有以下五个重要原则:

  • 监控容器及其内容。

  • 服务的性能警报

  • 监控弹性和多位置的服务

  • 监控 API 性能

  • 监督组织架构


图片

监控

容器化

当人们实施微服务时,它们可能运行在不同的运行环境上,例如 Java 和 Node.js,微服务的实施可以使用不同的技术栈来完成。

此外,这些微服务是以多语言方式部署的,因此节点并不知道已部署微服务的运行环境,我们需要在每个节点中手动安装。但是当谈到容器化时,我们需要将 RTE 与微服务打包在一起。因此我们可以在不考虑运行环境的情况下,在任何地点运行微服务,并且可以轻松地管理和更新这些服务。

图片

容器化

断路器

图片

断路器


断路器
是微服务生态系统中非常重要的实体。大多数时候,它被定义为一种模式。出于理解的更直观,它与您家中的电源断路器也有点相似。它可以保护你免受过热等灾难,并阻止已出现问题的传播。

当微服务发生了相同的问题和情况,假设客户端向微服务发送请求,并且在响应到来时出现了连接问题。由于客户端等待响应时间很长,因此极可能影响其它服务。由于断路器架构,有问题的通信通道将被丢弃,从而解决等待的问题。

此外,断路器有三种不同的状态,分别为已关闭,打开和半打开。

单体架构与微服务架构的比较


图片


整体架构与微服务架构之比较


成本

  • 单体式:一旦项目规模扩大,就会变高

  • 微服务:在第一个开发阶段,成本较高


代码

  • 单体式:整个产品统一代码库与数据库

  • 微服务:多个代码文件;每个微服务处理一个基础和一个数据存储


部署

  • 单体式:需要部署整个代码库

  • 微服务:每个微服务单独部署


技术栈

  • 单体式:相同的代码栈

  • 微服务:不同的技术堆栈(语言、运行时环境等)


微服务中的挑战


程序员在处理微服务时会遇到如下一些挑战:

  • 进程间通信(通过网络)

  • 分布式事务

  • 大量微服务

  • 需要更多的自动化


何时使用微服务


现在我们对微服务有了一些理解,看看哪些场景适合微服务:

  • 公司希望立即构建清洁、可读的代码并避免技术债务

  • 公司拥有微服务开发人力储备

  • 公司将长期利益置于短期利益之上

  • 团队开发人员使用不同的技术栈和工具

  • 平台必须具有高度可扩展性


小结

在这篇文章中,我们讨论了微服务架构、它的结构以及微服务与单体架构的区别等。希望这对任何正在进入微服务世界的人有所帮助。

谢谢!😊 ✌

作者:场长

评论