RPC微服务架构:RPC个人浅析(绝对干货)

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
简介: RPC微服务架构:RPC个人浅析(绝对干货)

什么是RPC?


RPC(Remote Procedure Call Protocol)远程过程调用:

我们有生产者服务器和消费者服务器,分别部署着不同的应用a、b。当我们想通过消费者服务器来调用生产者服务器的应用上提供的函数或方法时,由于这些应用不在同一个内存空间,不能够直接调用,这就需要通过借助网络来传输数据请求。就比如我们在自己的机器上写一个程序,别人是无法直接调用的,这个时候就需要通过远程服务调用,RPC应运而生了!

微服务架构是一种将单应用程序作为一套小型服务开发的方法。(因此我们可以知道,一般的小型企业是用不到微服务的)


百科官方解答


RPC是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据。在OSI网络通信模型中,RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC采用客户机/服务器模式。请求程序就是一个客户机,而服务提供程序就是一个服务器。首先,客户机调用进程发送一个有进程参数的调用信息到服务进程,然后等待应答信息。在服务器端,进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达,服务器获得进程参数,计算结果,发送答复信息,然后等待下一个调用信息,最后,客户端调用进程接收答复信息,获得进程结果,然后调用执行继续进行。


RPC解决了什么问题?


偏技术的问题:


1.通讯问题 : 客户端和服务器端通过TCP协议进行数据的传输。

2.寻址问题 : 服务器之间的应用如何调用,如何查找到对应应用所在的IP和端口。


优点:

1.解耦:把每个系统拆分开部署在不同的服务器上。

2.避免重复开发:避免对一个系统的重复开发,当有需要的时候可以直接调用

3.方便维护


RPC具体工作流程是怎么样的?(纯个人理解,待大佬指正)


RPC需要有三方:生产者、消费者和中央管理中心。 生产者即服务提供方,消费者即服务请求方,中央管理中心(下面简称中央)是充当一个中间人的身份,可以理解为我们的房屋中介。

当生产者想要使用微服务的时候, 需要先去中央注册身份,包括IP、端口号、包括哪些类或方法等信息都需要提供给中央做记录;同时,中央会根据自己的加密规则,生成一个密钥来唯一标志该生产者。

同理,当消费者想要使用微服务的时候, 也需要先去中央注册身份,包括IP、端口号、想要访问的方法等信息都需要提供给中央做记录;同时中央根据消费者提供的信息会给消费者提供一定的权限,并根据权限来判断该消费者可以去调用哪些生产者,也会对应生成密钥。

当消费者完成注册后,通过拿到的权限,来获取对应生产者的IP、端口号和密钥等信息,并将这些信息存放在本地缓存。

当消费者发送请求时,消费者会从本地缓存读取有效数据信息,如携带着对应生产者的密钥,通过HTTP、TCP等协议进行数据传输(这里传输用到了流操作、序列化和反序列化技术,暂时不做讲解,可出门右拐进入百度),生产者接收到请求后,进行反射代理, 首先来比对密钥是否正确,正确则进行真正的请求处理工作。

到这里,一个正常简易的RPC流程算是走完了。

但是就怕意外啊,RPC还有一些保障性的工作


心跳机制: 为防止生产者服务器突发心脏病宕机,或者某天心情不好闹小情绪导致发生异常而无法使用,我们强制规定生产者需要每隔几秒(可根据具体业务自行设计)向中央发送一次心跳,来证明生产者一切健康。如果说生产者一次没有发送心跳,中央可以原谅它的小调皮,但是如果连续三次都未发送心跳,中央就会主动标记该生产者有异常,同步到消费者缓存中进行信息的更新,并对该生产者服务器进行普通生病检查,同时触发报警机制来提醒正在改bug的程序猿来为其医治。

同步机制: 当生产者服务器有新增服务器、生产者服务器减少或更换服务器的情况,中央会将生产者的信息同步到消费者缓存。

反馈与检查机制: 由于心跳机制和同步机制没有即时性,那么很多时候,生产者服务器发生问题,往往是消费者先发现,当消费者连接生产者时,一次连接不成功,尝试重连,多次连接不成功后,会从本地缓存寻找其他可用生产者服务器信息进行数据的请求,同时会把连接失败的生产者服务器信息反馈上报给中央,说明该生产者服务器偷懒不工作;中央收到反馈后,立刻去检查该生产者服务器的异常原因并尝试触发报警机制。

这样一个大体上的RPC思想算是出来了,文字不易理解,可参考下图:


20190924010534530.png


RPC中有哪些方面可以提升性能优化?


1.缓存: 缓存技术有很多种,进程缓存有jdk自带的ConcurrentHashMap缓存、功能比较丰富的Ehcache缓存等;分布式缓存有Redis和Tair等。依据我们业务需要来选择合适的缓存可以很好的提升性能。


2.数据传输流的操作: Netty作为高性能的NIO通信框架,在很多RPC框架中都有它的身影。我们也采用它当做通信服务器。

3.序列化和反序列化:

百科介绍:


序列化

(Serialization)是将对象的状态信息转换为可以存储或传输的形式的过程。在序列化期间,对象将其当前状态写入到临时或持久性存储区。以后,可以通过从存储区中读取或反序列化对象的状态,重新创建该对象。


目前互联网公司广泛使用Protobuf、Thrift、Avro等成熟的序列化解决方案来搭建RPC框架,这些都是久经考验的解决方案。当然具体使用哪种序列化还是要结合我们的业务来开展的。

4.通讯协议: 不同的通讯协议的在不同的数据结构和不同数据量时的传输性能都有所不同,也要我们看实际情况来定。我有一个想法是设计一个仿Tomcat的通讯协议,或许可以在某方面提升性能,还没实现过。

目录
相关文章
|
10天前
|
安全 应用服务中间件 API
微服务分布式系统架构之zookeeper与dubbo-2
微服务分布式系统架构之zookeeper与dubbo-2
|
10天前
|
负载均衡 Java 应用服务中间件
微服务分布式系统架构之zookeeper与dubbor-1
微服务分布式系统架构之zookeeper与dubbor-1
|
12天前
|
JSON 监控 安全
探索微服务架构中的API网关模式
【9月更文挑战第22天】在微服务架构的海洋中,API网关如同一位智慧的守门人,不仅管理着服务的进出,还维护着整个系统的秩序。本文将带你一探究竟,看看这位守门人是如何工作的,以及它为何成为现代云原生应用不可或缺的一部分。从流量控制到安全防护,再到服务聚合,我们将一起解锁API网关的秘密。
|
22天前
|
运维 Cloud Native Devops
云原生架构的崛起与实践云原生架构是一种通过容器化、微服务和DevOps等技术手段,帮助应用系统实现敏捷部署、弹性扩展和高效运维的技术理念。本文将探讨云原生的概念、核心技术以及其在企业中的应用实践,揭示云原生如何成为现代软件开发和运营的主流方式。##
云原生架构是现代IT领域的一场革命,它依托于容器化、微服务和DevOps等核心技术,旨在解决传统架构在应对复杂业务需求时的不足。通过采用云原生方法,企业可以实现敏捷部署、弹性扩展和高效运维,从而大幅提升开发效率和系统可靠性。本文详细阐述了云原生的核心概念、主要技术和实际应用案例,并探讨了企业在实施云原生过程中的挑战与解决方案。无论是正在转型的传统企业,还是寻求创新的互联网企业,云原生都提供了一条实现高效能、高灵活性和高可靠性的技术路径。 ##
29 3
|
26天前
|
监控 负载均衡 应用服务中间件
探索微服务架构下的API网关设计与实践
在数字化浪潮中,微服务架构以其灵活性和可扩展性成为企业IT架构的宠儿。本文将深入浅出地介绍微服务架构下API网关的关键作用,探讨其设计原则与实践要点,旨在帮助读者更好地理解和应用API网关,优化微服务间的通信效率和安全性,实现服务的高可用性和伸缩性。
38 3
|
9天前
|
Kubernetes Go Docker
掌握微服务架构:从Go到容器化的旅程
摘要,通常简短概述文章内容,要求精炼。在本文中,我们将打破常规,采用一种故事化叙述的摘要,旨在激发读者的好奇心和探究欲: “从宁静的海滨小城出发,我们踏上了一场技术探险之旅,探索微服务架构的奥秘。我们将学习如何用Go编写微服务,以及如何通过Docker和Kubernetes将它们打包进小巧的容器中。在这场旅程中,我们将遇到挑战、收获知识,最终实现应用的快速部署与可扩展性。”
|
10天前
|
Cloud Native Java 对象存储
揭秘微服务架构之争:Spring Cloud与Netflix OSS巅峰对决,谁将称霸弹性云原生时代?
近年来,微服务架构成为企业应用的主流设计模式。本文对比了两大热门框架Spring Cloud和Netflix OSS,探讨其在构建弹性微服务方面的表现。Spring Cloud依托Spring Boot,提供全面的微服务解决方案,包括服务注册、配置管理和负载均衡等。Netflix OSS则由一系列可独立或组合使用的组件构成,如Eureka、Hystrix等。两者相比,Spring Cloud更易集成且功能完善,而Netflix OSS则需自行整合组件,但灵活性更高。实际上,两者也可结合使用以发挥各自优势。通过对两者的对比分析,希望为企业在微服务架构选型上提供参考。
30 0
|
18天前
|
缓存 负载均衡 数据管理
深入探索微服务架构的核心要素与实践策略在当今软件开发领域,微服务架构以其独特的优势和灵活性,已成为众多企业和开发者的首选。本文将深入探讨微服务架构的核心要素,包括服务拆分、通信机制、数据管理等,并结合实际案例分析其在不同场景下的应用策略,旨在为读者提供一套全面、深入的微服务架构实践指南。**
**微服务架构作为软件开发领域的热门话题,正引领着一场技术革新。本文从微服务架构的核心要素出发,详细阐述了服务拆分的原则与方法、通信机制的选择与优化、数据管理的策略与挑战等内容。同时,结合具体案例,分析了微服务架构在不同场景下的应用策略,为读者提供了实用的指导和建议。
|
2月前
|
Kubernetes Cloud Native Docker
云原生之旅:从容器到微服务的架构演变
【8月更文挑战第29天】在数字化时代的浪潮下,云原生技术以其灵活性、可扩展性和弹性管理成为企业数字化转型的关键。本文将通过浅显易懂的语言和生动的比喻,带领读者了解云原生的基本概念,探索容器化技术的奥秘,并深入微服务架构的世界。我们将一起见证代码如何转化为现实中的服务,实现快速迭代和高效部署。无论你是初学者还是有经验的开发者,这篇文章都会为你打开一扇通往云原生世界的大门。
|
1月前
|
存储 Java Maven
从零到微服务专家:用Micronaut框架轻松构建未来架构
【9月更文挑战第5天】在现代软件开发中,微服务架构因提升应用的可伸缩性和灵活性而广受欢迎。Micronaut 是一个轻量级的 Java 框架,适合构建微服务。本文介绍如何从零开始使用 Micronaut 搭建微服务架构,包括设置开发环境、创建 Maven 项目并添加 Micronaut 依赖,编写主类启动应用,以及添加控制器处理 HTTP 请求。通过示例代码展示如何实现简单的 “Hello, World!” 功能,并介绍如何通过添加更多依赖来扩展应用功能,如数据访问、验证和安全性等。Micronaut 的强大和灵活性使你能够快速构建复杂的微服务系统。
61 5
下一篇
无影云桌面