别再死记硬背！用问题驱动，深入浅出理解微服务核心概念
微服务框架中，一直会接触ProtoBuf的概念，微服务在搭建的过程中，使用上，需要编写.proto 后缀命名的文件，我们定义了数据的结构和接口，然后我们就使用这个文件生成对应的代码，当客户端调用远程方法的时候，会依赖于这个文件调用服务端提供的方法，服务端实现的方法会依赖于这个文件进行注册，所以这到底是什么？为什么他能够这么做，接下来我们通过问题的驱动下，一起来揭秘它神秘的面纱~
ProtoBuf(协议缓冲区)，wiki上解释，是一种免费的开源跨平台数据格式，用于序列化结构化数据。该方法涉及一种描述某些数据结构的接口描述语言，以及一个根据该描述生成源代码的程序，用于生成或解析表示结构化数据的字节流。它在开发通过网络相互通信或存储数据的程序时非常有用。
本质上他也是一种语言，可以理解为不同编译语言的中间语言，它类似于json，每个语言都认识，我们可以通过 ProtoBuf 定义数据结构，并生成多种语言（如 Java, Go, Python, C++ 等）相应的代码，这样不同语言的微服务之间就能通过统一的数据格式来交换数据。
1.ProtoBuf 是谁提出和实现的？它的实现最开始是为了解决什么问题？
由 Google 提出，最初是为了处理 Google 内部大量数据通信和存储时的性能问题。 它的目标是提供一个高效、跨平台的序列化工具，能减少带宽消耗并提高通信效率。
关键点：
解决性能瓶颈：为大规模数据存储和高效网络传输提供支持。
跨平台兼容：可以支持多种语言和平台。
2. ProtoBuf 的作用与意义，它在微服务中扮演什么角色？
作用是定义数据结构并对其进行序列化。 在 微服务 中，ProtoBuf 通过提供一种标准化的格式（接口定义），使得不同语言实现的服务可以进行跨语言通信。不同语言的服务通过ProtoBuf 提供的统一的接口和消息格式进行通信，避免了传统的 JSON 或 XML 传输中的效率瓶颈。
关键点：
统一接口：定义接口、请求体参数和返回值。
跨语言通信：不同语言可以互相通信。
数据格式统一：避免了 JSON 或 XML 的性能损耗。
3. 同样是跨平台数据格式，为什么不用 JSON 而是ProtoBuf？
ProtoBuf 比 JSON 更高效：它使用二进制格式进行数据序列化，传输速度更快、占用带宽更小。 性能对比：JSON 是文本格式，解析和序列化更慢，而 ProtoBuf 的二进制格式更紧凑、解析速度更快。 跨语言支持：ProtoBuf 更容易通过生成对应语言的代码来实现跨语言通信，而 JSON 没有那么强的类型和协议支持。
关键点：
性能更好：二进制格式比 JSON 更高效。
跨语言支持：ProtoBuf 通过生成代码支持多种语言。
4. RPC 协议与 HTTP 协议的区别，它们都是应用层协议吗？
RPC 通常用于微服务间的高效通信，而 HTTP 更多用于 Web 服务中的请求-响应通信。
关键点：
RPC 更适合服务间通信，支持远程调用。
HTTP 适合客户端和服务器之间的请求响应。
5.gRPC中，服务端的服务注册在哪，客户端调用的方法是直接在 gRPC 上吗，还是注册中心？直接和服务器交互吗？
1 | 服务端启动 → 注册地址到注册中心 → 注册中心维护服务列表 |
服务注册：gRPC 本身不自带服务注册功能，在微服务场景中，需结合 Consul、Etcd 等第三方注册中心实现。gRPC 服务器启动时，会通过自定义代码或第三方 SDK 将自身地址、服务名称等信息注册到注册中心，由注册中心维护服务实例的动态列表（包括新增、下线、健康状态等）。
客户端调用：客户端调用分为两个阶段。首先是服务发现，客户端启动时或定期向注册中心请求目标服务的可用实例地址；然后，客户端根据 gRPC 协议文件生成本地存根（Stub），通过存根调用远程方法，存根会按照 gRPC 协议（基于 HTTP/2）将请求参数序列化后，直接与获取到地址的 gRPC 服务器建立连接并发送请求，服务端处理后将结果返回给客户端。
关键点：
服务注册：依赖第三方注册中心管理服务实例，非 gRPC 内置功能。
客户端与服务器交互：客户端先从注册中心获取服务地址，再通过存根与服务器直接交互，注册中心不参与通信过程。
6.gRPC 存根是什么，和gRPC 服务器端的关系，存根是框架自动生成的吗？
gRPC 存根与服务器端通过 .proto 文件关联，存根由框架根据 .proto 自动生成，分客户端和服务端。客户端存根封装通信细节，服务端存根负责解析请求、调度业务实现。服务器端基于服务端存根实现具体业务逻辑，处理客户端通过存根发起的调用。
关键点：
存根：自动生成，是通信桥梁，隐藏网络细节。
服务器端：实现业务逻辑，通过存根接收和处理请求。