什么鬼,微服务还没搞懂,又来个流服务

简介: 本文节选自《实时流计算系统设计与实现》一书。当一个服务模块的输入和输出都是流的时候,我们称其为流服务。流服务的好处在于其可以直观地描述业务执行流程。流服务使用 DAG 来描述执行流程,DAG 的每个节点代表一个业务单元,每个业务单元负责一定的业务逻辑。

本文节选自《实时流计算系统设计与实现》一书。

当一个服务模块的输入和输出都是流的时候,我们称其为流服务。流服务的好处在于其可以直观地描述业务执行流程。

流服务使用 DAG 来描述执行流程,DAG 的每个节点代表一个业务单元,每个业务单元负责一定的业务逻辑。

在业务单元中,经常会用到一些具有特定功能的辅助性服务,如 IP 分析、GPS 解析、第三方征信服务等。将实现这些辅助性功能的代码直接放入流计算应用的业务代码里,或许是一个好方法,特别是在我们非常在乎性能的时候。

毕竟将这些辅助性功能的逻辑集成到流应用里,会减少相当多的 I/O 操作,确保了流应用的性能。但是这样做并不优雅。

考虑下,如果流计算任务需要用到很多辅助性功能(这种情况其实相当常见),而且这些辅助性功能中的某些内部逻辑甚至相当复杂,那么将这些功能的实现代码全都放到业务流程的实现中,势必会造成业务逻辑和技术细节纵横交错、程序执行流程杂乱无章。

一种折中的方案是将辅助性功能抽取为独立的源码项目,将它们编译为库后再链接进流计算应用。

这样一方面能够保证流计算应用的性能,另一方面避免了流计算应用的代码过于杂乱。这样做不失为一个比较好的办法,并且在性能优先的情况下可能是最优选择。

但这样做也存在问题,即每次对辅助性功能服务做更改或升级时,流计算应用必须重新构建、测试和发布。

从服务治理的角度而言,我们还是应该将辅助性功能剥离出去,让它们成为单独的服务,对外提供 REST 或 RPC 的访问接口。

下图描述了这种将辅助性功能剥离为单独微服务,由流服务调用接口访问的架构。

这样,流计算应用负责整体的业务逻辑,而辅助性功能被封装在一个个独立的微服务内并对外提供友好的使用界面,整个流计算系统架构清晰,在将来需要调整时也更加灵活。

在流服务中调用外部的微服务也存在一个问题,即性能问题。

在状态存储时,我们建议使用本地数据存储方案替代远程数据存储方案,原因在于远程数据存储方案可能会极大地降低流服务的性能。与此类似,在流服务中调用外部微服务时也涉及网络 I/O,这同样会比较显著地降低流服务的性能。所以,我们要针对微服务的调用过程做优化。

一方面,要小心谨慎地设计微服务,确保微服务能够快速地返回,不管是成功还是失败,都必须在给定的时间内快速返回。另一方面,流服务在调用微服务时,可以采取异步 I/O 的方式,这样能够保证流服务在处理事件时不会让 CPU 阻塞在等待微服务请求返回,从而提升流服务的吞吐能力。

另外,必须强调的是,在流计算中使用微服务最好采用只读方式,或者至少应该是幂等的。因为,如果流服务访问微服务时造成了外部状态的改变,就有可能破坏流计算应用整体的可靠性保证机制。

关于出现这个问题的原因,我们在前文讨论各种开源流计算框架的消息传达可靠性保证机制时已有所分析,这里不再赘述。

相比流服务,微服务是一种更加为大众所知的服务组织架构。

从形式上,微服务和流服务最大的区别在于,微服务是请求并响应的模式,而流服务则是事件驱动的模式。微服务系统架构将复杂软件系统按业务功能划分为一个个独立的服务模块,每个服务模块独立开发、独立部署、独立提供服务,各独立服务模块之间天然是一种松耦合的状态。

微服务确实有助于我们分解复杂的系统,但与之而来的问题是,它会让业务系统变得复杂。

相比流服务有一个提纲挈领的 DAG 代表了完整的业务流程,微服务系统如果没有额外的设计文档进行解释,那么我们是很难一下就弄清楚业务系统的完整执行流程的。

相比微服务而言,流服务的服务治理方案是“与生俱来”的,原因有以下几点。

第一,大部分流计算框架是构建在诸如YARN这样的分布式操作系统上的,所以它们所运行的环境已经云化。这意味着基于这些流计算框架构建的应用是可以自由横向伸缩的。

第二,大部分流计算框架或多或少地提供了管理界面,这让我们能够非常方便地监测和追踪运行在系统中的应用的状况。

第三,大部分流计算框架具备一定的容错机制,并且可在服务失败时自动完成服务恢复,不需要我们外部干预。但是微服务就不一样了。

微服务系统架构和服务治理还是有较大距离的,甚至可以说,服务治理的概念最初正是为了更好地管理微服务系统而提出的。

针对微服务系统的服务治理方案多种多样,从 Apache Dubbo 和 Spring Cloud,到 Docker Swarm 和Kubernetes,再到如今的 Service Mesh 等,各种微服务治理方案可谓方兴未艾,它们正在快速地发展和演进过程中。

虽然像诸如 Kubernetes 和 Service Mesh 等前沿、新颖的微服务治理方案确实非常有趣,但限于本书的主题,我们不展开讨论它们,强烈建议感兴趣的读者自行查阅相关资料。

笔者只在这里斗胆做一个预言,在诸如 Kubernetes 和 Service Mesh 等基于资源云化技术和服务编排技术的服务治理平台更加成熟和普及时,未来微服务和流服务之间的边界将越来越模糊,直接基于这些服务治理平台开发流计算框架也未尝不是一件有趣的事。

本文节选自《实时流计算系统设计与实现》一书。作者:周爽

本书高度抽象出实时流计算系统的技术支撑、架构模式、编程模式、系统实现与协同系统,并从零编写一个分布式实时流计算系统。

本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。

相关文章
|
运维 监控 负载均衡
动态服务管理平台:驱动微服务架构的高效引擎
动态服务管理平台:驱动微服务架构的高效引擎
257 17
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
运维 监控 负载均衡
探索微服务架构下的服务治理:动态服务管理平台深度解析
探索微服务架构下的服务治理:动态服务管理平台深度解析
|
运维 监控 安全
探索微服务架构下的服务治理:动态服务管理平台的力量
探索微服务架构下的服务治理:动态服务管理平台的力量
|
Cloud Native Java API
聊聊从单体到微服务架构服务演化过程
本文介绍了从单体应用到微服务再到云原生架构的演进过程。单体应用虽易于搭建和部署,但难以局部更新;面向服务架构(SOA)通过模块化和服务总线提升了组件复用性和分布式部署能力;微服务则进一步实现了服务的独立开发与部署,提高了灵活性;云原生架构则利用容器化、微服务和自动化工具,实现了应用在动态环境中的弹性扩展与高效管理。这一演进体现了软件架构向着更灵活、更高效的方向发展。
|
弹性计算 Kubernetes API
构建高效后端服务:微服务架构的深度剖析与实践####
本文深入探讨了微服务架构的核心理念、设计原则及实现策略,旨在为开发者提供一套系统化的方法论,助力其构建灵活、可扩展且易于维护的后端服务体系。通过案例分析与实战经验分享,揭示了微服务在提升开发效率、优化资源利用及增强系统稳定性方面的关键作用。文章首先概述了微服务架构的基本概念,随后详细阐述了其在后端开发中的应用优势与面临的挑战,最后结合具体实例,展示了如何从零开始规划并实施一个基于微服务的后端项目。 ####
|
NoSQL 前端开发 测试技术
👀探秘微服务:从零开启网关 SSO 服务搭建之旅
单点登录(Single Sign-On,简称SSO)是一种认证机制,它允许用户只需一次登录就可以访问多个应用程序或系统。本文结合网关和SaToken快速搭建可用的Session管理服务。
923 8
|
弹性计算 持续交付 API
构建高效后端服务:微服务架构的深度解析与实践
在当今快速发展的软件行业中,构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用,通过具体案例分析,展示如何利用微服务架构解决传统单体应用面临的挑战,提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署(CI/CD)等方面进行全面剖析,旨在为读者提供一套实用的微服务实施指南。
|
机器学习/深度学习 运维 监控
动态服务管理平台:构建高效、灵活的微服务架构基石
动态服务管理平台:构建高效、灵活的微服务架构基石
234 17
|
Kubernetes 负载均衡 Docker
构建高效后端服务:微服务架构的探索与实践
【10月更文挑战第20天】 在数字化时代,后端服务的构建对于任何在线业务的成功至关重要。本文将深入探讨微服务架构的概念、优势以及如何在实际项目中有效实施。我们将从微服务的基本理念出发,逐步解析其在提高系统可维护性、扩展性和敏捷性方面的作用。通过实际案例分析,揭示微服务架构在不同场景下的应用策略和最佳实践。无论你是后端开发新手还是经验丰富的工程师,本文都将为你提供宝贵的见解和实用的指导。
160 27