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

目录

• 介绍
  

• 微服务生态系统

• 整体架构与微服务架构

• 微服务中的挑战

• 何时使用微服务

技术名词缩略语

• 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 网关以两种方式之一处理请求：

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

• 将请求分发（传播）到多个服务。

监控

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

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

• 监控容器及其内容。

• 服务的性能警报

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

• 监控 API 性能

• 监督组织架构

  
  

容器化

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

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

断路器

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

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

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

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

成本

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

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

代码

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

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

部署

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

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

技术栈

• 单体式：相同的代码栈

• 微服务：不同的技术堆栈（语言、运行时环境等）

微服务中的挑战

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

• 进程间通信（通过网络）

• 分布式事务

• 大量微服务

• 需要更多的自动化

何时使用微服务

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

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

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

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

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

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

小结

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

谢谢！😊 ✌

作者：场长