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

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

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

基于微服务的架构通常有几个独立的单元，它们协同工作以接收和处理各种请求。这个复杂的某些部分可以是插件，这意味着在需要的情况下，你可以在不干扰应用程序的整体工作情况下， 新增一个新插件或删除一个插件。

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

本文，我将从以下几个方面来介绍各种关注点：

请注意，我在哪些工具比较好部分提到了两三个哪些工具比较好，当然，我们还有很多其他哪些工具比较好，选择这些哪些工具比较好的标准是业务需求，受欢迎程度、性能、开源以及更新频率。

再次注意，我们还有基于云的服务，这不在本文讨论的范围内。

本文，我用上图作为架构图示例。这个图涉及到大部分微服务架构组件，虽然不是也很全面，但是微服务架构的标准模型。

本文将会介绍微服务架构的关注点有：

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

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

Docker

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

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

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

Kubernetes or K8s，Docker Swarm

管理 Docker 环境、配置、安全等。

为用户提供了一个基于 GUI 的Docker 容器管理，可以使他们不必处理不舒服的 CLI。这些工具也为开发人员提供了丰富的 UI 来构建和发布他们的镜像，还可以通过提供简化的用户界面来更轻松地执行一些操作任务，例如服务水平扩展。

Portainer，DockStation，Kitematic，Rancher

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

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

Kong，Ocelot

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

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

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

Traefik，NGINX，Seesaw

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

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

Consul，Zookeeper，Eureka，etcd和Keepalived

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

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

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

RabbitMQ，Kafka

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

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

Elastic Logstash

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

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

Prometheus，Kibana，Graphana

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

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

OpenTelemetry，Jeager，Zipkin

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

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

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

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

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

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

NoSQL 数据库 : MongoDB，Cassandra，Elasticsearch

缓存减少了微服务架构的服务到服务通信的延迟。缓存是高速数据存储层。当从缓存中请求数据时，它的速度比访问硬盘中的数据要快。

我为什么要使用它：

在微服务架构中，有许多策略可以通过这些方式实现缓存，可以考虑以下几种：

为了减少延迟，可以在不同的层中实现缓存。此外，你还可以实现分布式缓存，它可以被多个微服务访问。它们还有不同的用途，比如限流，限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务。

Redis (Remote Dictionary Server)，Apache Ignite，Hazelcast IMDG

云服务提供商是一个第三方公司，提供基于云的平台，基础设施，应用程序或存储服务。就像房主为电力或天然气等公用事业付费一样，公司通常只需根据业务需求为他们使用的云服务数量付费。

云提供商最重要的类别：

使用云计算服务的一个好处是，公司可以避免搭建和维护自己的 IT 基础设施的前期成本和复杂性，而只需在使用时为所用的东西付费。今天，公司可以租用从应用程序到存储的任何东西，而不是拥有自己的计算基础设施或数据中心。

Amazon Web Services (AWS)，Microsoft Azure，Google Cloud，Alibaba Cloud

在本文中，我试图展示一个与微服务架构模式相关的路线图。如果你想从头开始实现微服务架构或将单体架构迁移到微服务架构，你将需要了解这些概念。

除了这些概念之外，我们还有其他概念，如服务网格、缓存、持久性，它们可能是本路线图的一部分，但为了简单起见，我故意没有提及它们。

• https://dzone.com/articles/microservice-roadmap