一张图看懂微服务架构路线

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 一张图看懂微服务架构路线

目录

一张图看懂微服务架构路线

我为什么选择微服务架构?

微服务架构路线

基本思路

Docker

容器编排

Docker 容器管理

API网关

负载均衡

服务发现

事件总线

日志记录

监控和警报

分布式追踪

数据持久化

缓存

云供应商

结论



一张图看懂微服务架构路线

我为什么选择微服务架构

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

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


微服务架构路线

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


基本思路

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

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

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

  1. 它是什么?
  2. 我为什么要使用它?
  3. 哪些工具比较好?

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

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

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

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

  • Docker
  • 容器编排
  • Docker容器管理
  • API网关
  • 负载均衡
  • 服务发现
  • 事件总线
  • 日志记录
  • 监控和警报
  • 分布式追踪
  • 数据持久化
  • 缓存
  • 云供应商


Docker

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

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

哪些工具比较好:Docker


容器编排

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

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

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

哪些工具比较好:Kubernetes or K8sDocker Swarm


Docker 容器管理

它是什么: 管理 Docker 环境、配置管理、安全管理等。

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

哪些工具比较好:Portainer , DockStation, Kitematic,Rancher


API网关

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

  • Routing :网关接收所有 API 请求并将它们转发到目标服务。
  • Logging :你将能够在一处记录所有请求。
  • Authorization: 检查你作为用户是否有资格访问该服务,如果没有,可以拒绝该请求
  • Performance profiling:你可以估计每个请求的执行时间并检查你的应用程序瓶颈。
  • Caching:通过在网关级别处理缓存,你将消除服务上的大量流量。

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

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

哪些工具比较好:KongOcelot


负载均衡

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

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

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

哪些工具比较好:Traefik , NGINX,Seesaw


服务发现

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

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

哪些工具比较好:ConsulZookeeperEurekaetcdKeepalived


事件总线

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

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

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

哪些工具比较好:RabbitMQKafka


日志记录

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

我为什么要使用它: 系统调试时,如果没有提前集中在一个地方收集服务日志,你可能会遇到困难。你还可以将与特定请求相关的日志与唯一的相关 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


缓存

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

我为什么要使用它:

在微服务架构中,有许多策略可以通过这些方式实现缓存。考虑以下:

1:嵌入式缓存(分布式和非分布式) 2:客户端-服务器缓存(分布式) 3:反向代理缓存(Sidecar)

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

哪些工具比较好Redis (Remote Dictionary Server), Apache Ignite,Hazelcast IMDG


云供应商

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

云提供商最重要的类别:

  • 软件即服务 (SaaS)。
  • 平台即服务 (PaaS)。
  • 基础设施即服务 (IaaS)。

我为什么要使用它 使用云计算服务的一个好处是,公司可以避免搭建和维护自己的 IT 基础设施的前期成本和复杂性,而只需在使用时为所用的东西付费。今天,公司可以租用从应用程序到存储的任何东西,而不是拥有自己的计算基础设施或数据中心。 哪些工具比较好Amazon Web Services (AWS), Microsoft Azure, Google Cloud,Alibaba Cloud


结论

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

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


译文链接: Making a Microservice Architecture Roadmap - DZone Microservices


目录
相关文章
|
20天前
|
运维 Kubernetes Cloud Native
云原生技术浪潮下的微服务架构演进
在数字化转型的风潮中,云原生技术以其灵活性、可扩展性和弹性成为企业IT战略的核心。本文深入探讨了微服务架构如何借助云原生环境进行优化,并分析了容器化、服务网格等技术如何助力微服务更好地适应云原生生态。通过案例分析,我们揭示了微服务在现代云平台上的实践挑战与解决策略,同时对未来的技术趋势进行了预测。
44 0
|
3天前
|
监控 负载均衡 API
从单体到微服务:架构转型之道
【8月更文挑战第17天】从单体架构到微服务架构的转型是一项复杂而系统的工程,需要综合考虑技术、团队、文化等多个方面的因素。通过合理的规划和实施策略,可以克服转型过程中的挑战,实现系统架构的升级和优化。微服务架构以其高度的模块化、可扩展性和灵活性,为业务的持续发展和创新提供了坚实的技术保障。
|
12天前
|
Cloud Native 云计算 微服务
云原生时代:企业分布式应用架构的惊人蜕变,从SOA到微服务的大逃亡!
【8月更文挑战第8天】在云计算与容器技术推动下,企业分布式应用架构正经历从SOA到微服务再到云原生的深刻变革。SOA强调服务重用与组合,通过标准化接口实现服务解耦;微服务以细粒度划分服务,增强系统灵活性;云原生架构借助容器化与自动化技术简化部署与管理。每一步演进都为企业带来新的技术挑战与机遇。
50 6
|
10天前
|
设计模式 监控 API
探索微服务架构中的API网关模式
在微服务的宇宙里,API网关是连接星辰的桥梁。它不仅管理着服务间的通信流量,还肩负着保护、增强和监控微服务集群的重任。本文将带你走进API网关的世界,了解其如何成为微服务架构中不可或缺的一环,以及它在实际应用中扮演的角色和面临的挑战。
|
13天前
|
缓存 监控 API
【微服务战场上的神秘守门人】:揭秘API网关的超能力 —— 探索微服务架构中的终极守护者与它的神奇魔法!
【8月更文挑战第7天】随着微服务架构的流行,企业应用被拆分为围绕特定业务功能构建的小型服务。API网关作为微服务间的通信管理核心,对请求进行路由、认证、限流等处理,简化客户端集成并提升用户体验。以电商应用为例,通过Kong部署API网关,配置产品目录等服务的API及JWT认证插件,确保安全高效的数据交互。这种方式不仅增强了系统的可维护性和扩展性,还提供了额外的安全保障。
31 2
|
18天前
|
运维 监控 负载均衡
探索微服务架构中的API网关
在现代软件开发中,微服务架构已成为设计灵活、可扩展系统的首选方法。本文将深入探讨API网关的核心作用,包括它如何简化客户端与微服务之间的交互,提供请求路由、负载均衡、认证、限流及监控等关键功能。我们将通过实际案例分析,揭示API网关在提升系统性能、增强安全性和提高开发效率方面的重要性。
|
16天前
|
负载均衡 监控 API
探索微服务架构中的API网关模式
在微服务架构的海洋中,API网关扮演着枢纽的角色。它不仅是客户端请求的接收者,也是各个微服务间通信的协调者。本文将深入探讨API网关的设计原则、实现策略以及它在微服务生态中的重要性。我们将通过实际案例分析,了解API网关如何优化系统性能、提高安全性和简化客户端与服务的交互。
37 4
|
16天前
|
运维 监控 负载均衡
探索微服务架构中的API网关设计
在微服务架构的复杂性中,API网关作为客户端和后端服务间的桥梁,扮演着至关重要的角色。本文将深入探讨如何设计一个高效、可扩展且安全的API网关,包括处理请求转发、负载均衡、身份验证、监控与日志记录等核心功能,并讨论如何在保障性能的同时确保系统的高可用性和安全性。通过具体案例,我们将了解API网关在实际生产环境中的实现方式及其对整个微服务生态系统的影响。
39 3
|
16天前
|
Kubernetes 监控 开发者
探索后端开发的新境界:微服务架构与容器化技术
在数字化时代的浪潮中,后端开发不断演进,涌现出创新的架构与技术。本文深入探讨了微服务架构和容器化技术如何重塑后端开发,提升系统的可维护性、可扩展性和部署效率。通过实际案例分析,我们揭示了这些技术背后的原理,并提供了实施的最佳实践和面临的挑战,为后端开发者提供一条清晰的技术升级路径。
41 3
|
21天前
|
负载均衡 监控 API
探索微服务架构中的API网关模式
【7月更文挑战第30天】在微服务架构的复杂网络中,API网关扮演着交通枢纽的角色,不仅简化了客户端与各微服务的交互,还提升了系统的安全性和可维护性。本文将深入探讨API网关的设计原则、核心功能以及在实际应用中的部署策略,旨在为后端开发者提供一套完整的API网关解决方案。