一张图看懂微服务架构路线 Posted 2022-02-21 中生代技术
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一张图看懂微服务架构路线相关的知识,希望对你有一定的参考价值。
众所周知,单体应用程序,由于其种种不足,几乎不支持敏捷方法。如果你想为一个大型或复杂的业务创建一个软件项目,最好从微服务架构开始。 微服务架构是一种灵活的架构,可以显著性地提高应用程序灵活性、可扩展性等。
- 微服务架构路线 -
据我了解很多开发者,想知道他们应该如何开始微服务架构旅程,虽然有成千上万的资源可以使用,但是资源到处分散。我决定通过为微服务架构学习定义路线图,使这段旅程更加清晰。
- 基本思路 -
基于微服务的架构通常有几个独立的单元,它们协同工作以接收和处理各种请求。这个复杂的某些部分可以是插件,这意味着在需要的情况下,你可以在不干扰应用程序的整体工作情况下, 新增一个新插件或删除一个插件。 例如,如果你决定实现一个微服务架构,你应该熟悉应用程序生命周期中的各种关注点,如持久化、日志记录、监控、负载均衡、缓存等,此外你还应该知道哪些哪些工具比较好或哪些堆栈更适合你的应用程序。 请注意,我在哪些工具比较好部分提到了两三个哪些工具比较好,当然,我们还有很多其他哪些工具比较好,选择这些哪些工具比较好的标准是业务需求,受欢迎程度、性能、开源以及更新频率。 再次注意,我们还有基于云的服务,这不在本文讨论的范围内。
本文,我用上图作为架构图示例。这个图涉及到大部分微服务架构组件,虽然不是也很全面,但是微服务架构的标准模型。
- Docker -
Docker 是一个开源平台,用于容器化你的应用程序,其中包含你的应用程序在各种环境中运行所需的类库和依赖项。在 Docker 的帮助下,开发团队能够将应用程序打包到容器中。 实际上,Docker 是容器化应用程序的哪些工具比较好之一,你也可以在不使用 Docker 的情况下创建容器,Docker 的真正好处是使这个过程更容易、更安全、更简单。
- 容器编排 -
在容器化应用程序后,你将需要一些哪些工具比较好来管理容器化应用程序,以执行一些手动和自动操作,例如水平扩展。 这些哪些工具比较好为你的应用程序管理提供一些服务,例如自动负载均衡,保证服务的高可用性。 这种服务是通过定义多个管理器节点来完成的,如果一个节点管理器出现任何故障,其他管理器可以保持应用程序服务可用。 Kubernetes or K8s,Docker Swarm
- Docker 容器管理 -
为用户提供了一个基于 GUI 的Docker 容器管理,可以使他们不必处理不舒服的 CLI。这些工具也为开发人员提供了丰富的 UI 来构建和发布他们的镜像,还可以通过提供简化的用户界面来更轻松地执行一些操作任务,例如服务水平扩展。 Portainer, DockStation, Kitematic,Rancher
- API网关 -
API 网关可以被视为一种充当你的应用程序服务和不同客户端之间的中间件。API 网关可以管理许多事情,例如: Routing :网关接收所有 API 请求并将它们转发到目标服务。 Authorization: 检查你作为用户是否有资格访问该服务,如果没有,可以拒绝该请求 Performance profiling:你可以估计每个请求的执行时间并检查你的应用程序瓶颈。 Caching:通过在网关级别处理缓存,你将消除服务上的大量流量。 事实上,它是作为一个反向代理工作的,客户端只需要知道你的网关,应用服务就可以隐藏起来,不直接向其他系统暴露。 如果没有 API 网关,你可能需要在每个服务中做一些横切关注点,例如,如果你想记录服务的请求和响应。此外,如果你的应用程序由多个服务组成,你的客户端需要知道每个服务地址,并且在更改服务地址的情况下,应该更新多个地方。
- 负载均衡 -
我们选择微服务架构最重要的原因是可扩展性,这意味着我们将能够通过运行更多服务实例来处理更多请求,但问题是,哪个实例应该接收请求,或客户端如何知道哪个服务实例应该处理请求? 这些问题的答案是负载均衡。负载均衡是高可用网络基础架构的关键组件,通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。 为了扩展你的独立服务,你需要运行多个服务实例。使用负载均衡器,客户端不需要知道服务的正确实例。
- 服务发现 -
随着你的应用服务的数量越来越多,服务需要知道彼此的服务实例地址,但是在有很多服务的大型应用中,这是无法处理的。因此我们需要服务发现,它负责提供应用程序中所有组件的地址,它们可以轻松地向服务发现系统发送请求并获取可用的服务实例地址。 当你的应用程序中可以有多个服务时,服务发现对于你的应用程序来说是必不可少的。你的应用服务不需要知道每个服务实例地址,这意味着服务发现为你铺平了道路。 Consul,Zookeeper,Eureka,etcd和Keepalived
- 事件总线 -
在微服务架构模式中,你将使用两种不同类型的通信,同步通信以及异步通信。同步通信是指服务之间通过 HTTP 或 GRPC 相互调用。异步通信意味着服务通过消息总线或事件总线相互交互,这意味着服务之间没有直接连接。 你的架构可以同时使用两种通信方式,例如在在线商店示例中,你可以在订单注册时发送消息,并且订阅了特定频道的服务将收到该消息。但有时你可能需要一些实时的查询,例如,你需要知道一个物品的数量,你可能会在服务之间使用 GRPC 或 HTTP 调用来获取响应。 如果你想要一个包含多个服务的可扩展应用程序,你将遵循的原则之一是创建松散耦合的服务,这些服务通过事件总线相互交互。此外,如果你需要创建一个能够插入新服务以接收一系列特定消息的应用程序,则需要使用事件总线。
- 日志记录 -
使用微服务架构模式时,最好将服务日志集中起来。这些日志将用于调试问题或根据其类型聚合日志以供分析使用。 系统调试时,如果没有提前集中在一个地方收集服务日志,你可能会遇到困难。你还可以将与特定请求相关的日志与唯一的相关 ID 关联。这意味着与请求相关的不同服务中的所有日志都可以通过此关联 ID 访问。
- 监控和警报 -
在微服务架构中,如果你想要一个可靠的应用程序或服务,你必须监控应用程序的功能、性能、通信和任何其他方面,以实现一个负责任的应用程序。 你需要监控整体功能和服务健康状况,还需要监控性能瓶颈,并准备解决故障的计划。通过在关键点定义服务的早期警报来减少服务的停机时间,从而优化用户体验。当负载较重时等,可以监控服务的整体资源消耗。 Prometheus , Kibana,Grafana
- 分布式追踪 -
调试始终是开发人员最关心的问题之一,因为你都有跟踪或调试单体引用程序的经验。那是非常直接和容易,但是在微服务架构上,因为一个请求可能会通过不同的服务,这使得调试和跟踪变得困难,因为服务不在一个地方,所以分布式追踪工具将会有所帮助。 如果没有分布式跟踪哪些工具比较好,通过不同的服务跟踪你的请求会令人沮丧或不可能。你可以借助用于演示请求流的丰富 UI 轻松跟踪请求和事件。 OpenTelemetry , Jeager,Zipkin
- 数据持久化 -
在大多数系统中,我们需要持久化数据,将应用程序的数据写入具有不同结构的物理文件中,以便数据用于进一步的处理或报告。 在单体应用程序中,我们曾经有一种或两种不同的持久性类型,大多数单体应用程序使用关系数据库,如 SQL Server、Oracle、mysql 。但是在微服务架构中,我们应该遵循“DataBase Per Service”模式,这意味着保持每个微服务的持久数据对该服务是私有的,并且只能通过其 API 访问。 对于不同的用途和场景,你将拥有不同的数据库。例如,数据展示服务可能会使用像 ElasticSearch 或 MongoDB 这样的 NoSQL 数据库,因为它们使用文档基础结构,这意味着这些数据库中持久化数据的结构与关系数据库不同,更适用于具有读多写少的服务。 另一方面,在某些微服务中,你可能需要 Oracle 或 SQL SERVER 等关系数据库,或者你可能还需要一些支持图结构或键值结构的数据库。 所以,在微服务架构中,根据服务的使命,你会需要不同类型的数据库。 关系数据库或 RDBMS : PostgreSQL, MySQL, SQL Server, Oracle NoSQL 数据库 : MongoDB, Cassandra,ElasticSearch
- 缓存 -
缓存减少了微服务架构的服务到服务通信的延迟。缓存是高速数据存储层。当从缓存中请求数据时,它的速度比访问硬盘中的数据要快。 在微服务架构中,有许多策略可以通过这些方式实现缓存。考虑以下: 为了减少延迟,可以在不同的层中实现缓存。此外,你还可以实现分布式缓存,它可以被多个微服务访问。它们还有不同的用途,比如限流,限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统,一旦达到限制速率则可以拒绝服务。 Redis (Remote Dictionary Server), Apache Ignite,Hazelcast IMDG
- 云供应商 -
云服务提供商是一个第三方公司,提供基于云的平台,基础设施,应用程序或存储服务。就像房主为电力或天然气等公用事业付费一样,公司通常只需根据业务需求为他们使用的云服务数量付费。
- 我为什么要使用它 -
使用云计算服务的一个好处是,公司可以避免搭建和维护自己的 IT 基础设施的前期成本和复杂性,而只需在使用时为所用的东西付费。今天,公司可以租用从应用程序到存储的任何东西,而不是拥有自己的计算基础设施或数据中心。 Amazon Web Services (AWS), Microsoft Azure, Google Cloud,Alibaba Cloud
- 总结 -
在本文中,我试图展示一个与微服务架构模式相关的路线图。如果你想从头开始实现微服务架构或将单体架构迁移到微服务架构,你将需要了解这些概念。 除了这些概念之外,我们还有其他概念,如服务网格、缓存、持久性,它们可能是本路线图的一部分,但为了简单起见,我故意没有提及它们。
作者:王延飞
来源 : www.kubernetes.org.cn/9711.html
版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢!
RedisJson 是什么?比ES快 500 倍?
一张图看懂MapReduce 架构是如何工作的?
MapReduce架构是Hadoop框架中最核心的设计之一。
MapReduce 的思想简单的一句话解释就是“任务的分解与结果的汇总”。MapReduce 从名字上来看,两个动词Map 和Reduce,
“Map(地图)”就是将一个图分解成为多个子图,
“Reduce(缩小)”就是将分解后多任务处理的结果汇总起来,得出最后的分析结果。
通俗说MapReduce 是一套从海量源数据提取分析元素最后返回结果集的编程模型,将文件分布式存储到硬盘是第一步,而从海量数据中提取分析我们需要的内容就是MapReduce 做的事了。
健康监测
由于Hadoop 处于一个极其脆弱的环境,各计算单元发生故障的可能性是存在的,恰当的健康监测是判断计算单元是否正常工作的基础架构,它有两种基本形式:
第一种:命令/响应(ping/echo):
探测器定时发出一个命令,并希望预定时间内收到一个审查计算单元的响应,这种响应应该力求对于各个计算单元是统一的。
这种健康监测的特点是简单,但是待审查计算单元时间常数不一致时,将很难确定同步周期。
第二种:心跳(dead man):
“心跳”是一种主动检测方案,由被测计算单元主动发出一个自检结果信息(心跳),由探测器收听这个信息,如果心跳失败,则可以判断这个计算单元失灵,并通知按照可靠性策略纠正错误计算单元。心跳也可以同时传递数据,比如传递上一次处理的日志。
心跳方式比较灵活,可以适应待审查计算单元时间常数不一致的情况,缺点是监测器要复杂一些。由于分布式计算各计算点情况比较复杂,所以Hadoop 采用了心跳方案,以保证即使系统非常脆弱,也能正常完成分布式计算任务。
MapReduce 基本架构
在分布式系统中,机器集群就可以看作硬件资源池,将并行的任务拆分,然后交由每一个空闲机器资源去处理,能够极大地提高计算效率,同时这种具体资源无关性,对于计算集群的扩展无疑提供了最好的设计保证。
本文出自 “中科院计算所培训 ” 博客,谢绝转载!
以上是关于一张图看懂微服务架构路线的主要内容,如果未能解决你的问题,请参考以下文章
一张图看懂微服务架构路线
一张图看懂MapReduce 架构是如何工作的?
F3简介一张图看懂FPGA-F3实例
一张图看懂腾讯云智能语音给企业带来怎样的黑科技?
一张图看懂数据库实例
一张图看懂kibana 原型链rce漏洞过程