一、我为什么选择微服务架构？

众所周知，单体应用程序，由于其种种不足，几乎不支持敏捷方法。如果你想为一个大型或复杂的业务创建一个软件项目，最好从微服务架构开始。

微服务架构是一种灵活的架构，可以显著性地提高应用程序灵活性、可扩展性等。

二、微服务架构路线

据我了解很多开发者，想知道他们应该如何开始微服务架构旅程，虽然有成千上万的资源可以使用，但是资源到处分散。我决定通过为微服务架构学习定义路线图，使这段旅程更加清晰。

1、基本思路

基于微服务的架构通常有几个独立的单元，它们协同工作以接收和处理各种请求。

例如，如果你决定实现一个微服务架构，你应该熟悉应用程序生命周期中的各种关注点，如持久化、日志记录、监控、负载均衡、缓存等，此外你还应该知道哪些哪些工具比较好或哪些堆栈更适合你的应用程序。

2、Docker

Docker 是一个开源平台，用于容器化你的应用程序，其中包含你的应用程序在各种环境中运行所需的类库和依赖项。在 Docker 的帮助下，开发团队能够将应用程序打包到容器中。

我为什么要使用它：

实际上，Docker 是容器化应用程序的哪些工具比较好之一，你也可以在不使用 Docker 的情况下创建容器，Docker 的真正好处是使这个过程更容易、更安全、更简单。

3、容器编排

在容器化应用程序后，你将需要一些哪些工具比较好来管理容器化应用程序，以执行一些手动和自动操作，例如水平扩展。

我为什么要使用它：

这些哪些工具比较好为你的应用程序管理提供一些服务，例如自动负载均衡，保证服务的高可用性。

这种服务是通过定义多个管理器节点来完成的，如果一个节点管理器出现任何故障，其他管理器可以保持应用程序服务可用。

哪些工具比较好：

Kubernetes or K8s

4、API网关

API 网关可以被视为一种充当你的应用程序服务和不同客户端之间的中间件。API 网关可以管理许多事情，例如：

Routing ：网关接收所有 API 请求并将它们转发到目标服务。

Logging ：你将能够在一处记录所有请求。

Authorization: 检查你作为用户是否有资格访问该服务，如果没有，可以拒绝该请求

Performance profiling：你可以估计每个请求的执行时间并检查你的应用程序瓶颈。

Caching：通过在网关级别处理缓存，你将消除服务上的大量流量。

事实上，它是作为一个反向代理工作的，客户端只需要知道你的网关，应用服务就可以隐藏起来，不直接向其他系统暴露。

我为什么要使用它：

如果没有 API 网关，你可能需要在每个服务中做一些横切关注点，例如，如果你想记录服务的请求和响应。此外，如果你的应用程序由多个服务组成，你的客户端需要知道每个服务地址，并且在更改服务地址的情况下，应该更新多个地方。

哪些工具比较好：

Kong，Ocelot

5、负载均衡

我们选择微服务架构最重要的原因是可扩展性，这意味着我们将能够通过运行更多服务实例来处理更多请求，但问题是，哪个实例应该接收请求，或客户端如何知道哪个服务实例应该处理请求？

这些问题的答案是负载均衡。负载均衡是高可用网络基础架构的关键组件,通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。

我为什么要使用它：

为了扩展你的独立服务，你需要运行多个服务实例。使用负载均衡器，客户端不需要知道服务的正确实例。

哪些工具比较好：

Traefik , NGINX，Seesaw

6、服务发现

随着你的应用服务的数量越来越多，服务需要知道彼此的服务实例地址，但是在有很多服务的大型应用中，这是无法处理的。因此我们需要服务发现，它负责提供应用程序中所有组件的地址，它们可以轻松地向服务发现系统发送请求并获取可用的服务实例地址。

我为什么要使用它：

当你的应用程序中可以有多个服务时，服务发现对于你的应用程序来说是必不可少的。你的应用服务不需要知道每个服务实例地址，这意味着服务发现为你铺平了道路。

哪些工具比较好：

Consul，Zookeeper，Eureka，Nacos，etcd和Keepalived

7、事件总线

在微服务架构模式中，你将使用两种不同类型的通信，同步通信以及异步通信。同步通信是指服务之间通过 HTTP 或 GRPC 相互调用。异步通信意味着服务通过消息总线或事件总线相互交互，这意味着服务之间没有直接连接。

你的架构可以同时使用两种通信方式，例如：在在线商店示例中，你可以在订单注册时发送消息，并且订阅了特定频道的服务将收到该消息。但有时你可能需要一些实时的查询，例如：你需要知道一个物品的数量，你可能会在服务之间使用 GRPC 或 HTTP 调用来获取响应。

我为什么要使用它：

如果你想要一个包含多个服务的可扩展应用程序，你将遵循的原则之一是创建松散耦合的服务，这些服务通过事件总线相互交互。此外，如果你需要创建一个能够插入新服务以接收一系列特定消息的应用程序，则需要使用事件总线。

哪些工具比较好：

RabbitMQ，Kafka

8、日志记录

使用微服务架构模式时，最好将服务日志集中起来。这些日志将用于调试问题或根据其类型聚合日志以供分析使用。

我为什么要使用它：

系统调试时，如果没有提前集中在一个地方收集服务日志，你可能会遇到困难。你还可以将与特定请求相关的日志与唯一的相关 ID 关联。这意味着与请求相关的不同服务中的所有日志都可以通过此关联 ID 访问。

哪些工具比较好：

Elastic Logstash

9、监控和警报

在微服务架构中，如果你想要一个可靠的应用程序或服务，你必须监控应用程序的功能、性能、通信和任何其他方面，以实现一个负责任的应用程序。

我为什么要使用它：

你需要监控整体功能和服务健康状况，还需要监控性能瓶颈，并准备解决故障的计划。通过在关键点定义服务的早期警报来减少服务的停机时间，从而优化用户体验。当负载较重时等，可以监控服务的整体资源消耗。

哪些工具比较好：

Prometheus , Kibana,Graphana

10、分布式追踪

调试始终是开发人员最关心的问题之一，因为你都有跟踪或调试单体引用程序的经验。那是非常直接和容易，但是在微服务架构上，因为一个请求可能会通过不同的服务，这使得调试和跟踪变得困难，因为服务不在一个地方，所以分布式追踪工具将会有所帮助。

我为什么要使用它：

如果没有分布式跟踪哪些工具比较好，通过不同的服务跟踪你的请求会令人沮丧或不可能。你可以借助用于演示请求流的丰富 UI 轻松跟踪请求和事件。

哪些工具比较好：

OpenTelemetry , Jeager，Zipkin

11、数据持久化

在大多数系统中，我们需要持久化数据，将应用程序的数据写入具有不同结构的物理文件中，以便数据用于进一步的处理或报告。

我为什么要使用它：

在单体应用程序中，我们曾经有一种或两种不同的持久性类型，大多数单体应用程序使用关系数据库，如 SQL Server、Oracle、MySQL。但是在微服务架构中，我们应该遵循“DataBase Per Service”模式，这意味着保持每个微服务的持久数据对该服务是私有的，并且只能通过其 API 访问。

对于不同的用途和场景，你将拥有不同的数据库。例如，数据展示服务可能会使用像 ElasticSearch 或 MongoDB 这样的 NoSQL 数据库，因为它们使用文档基础结构，这意味着这些数据库中持久化数据的结构与关系数据库不同，更适用于具有读多写少的服务。

另一方面，在某些微服务中，你可能需要 Oracle 或 SQL SERVER 等关系数据库，或者你可能还需要一些支持图结构或键值结构的数据库。

所以，在微服务架构中，根据服务的使命，你会需要不同类型的数据库。

哪些工具比较好：

关系数据库或 RDBMS : PostgreSQL, MySQL, SQL SERVRE, Oracle

NoSQL 数据库 : MongoDB, Cassandra，Elasticsearch