面试题答案
一键面试基于性能指标分析和选择RPC框架
- 网络传输协议
- TCP：面向连接，可靠传输。适用于对数据准确性要求高、对实时性要求相对不那么极端的场景。它保证数据按序到达，重传机制确保数据完整性，但可能在高并发下有一定的性能开销。在实际项目中，如果业务对数据一致性要求严格，如金融交易场景，TCP协议是较为合适的选择。
- UDP：无连接，不可靠传输，但速度快，延迟低。适合对实时性要求极高，能容忍少量数据丢失的场景，如实时视频流、游戏数据传输等。在微服务项目里，若业务是类似监控数据的快速上报，UDP可能是更好的选择，因为监控数据偶尔丢失部分对整体业务影响不大，但实时性很关键。
- HTTP/2：基于HTTP协议，支持多路复用、头部压缩等特性，能有效提高传输效率。在现代微服务架构中，尤其适用于前后端交互频繁且对浏览器兼容性有要求的场景。例如，前端应用调用后端微服务获取数据展示，HTTP/2可以减少请求响应的延迟，提升用户体验。
- 序列化方式
- JSON：可读性强，通用性好，几乎所有编程语言都支持。但它的文本格式导致序列化后的数据体积较大，解析速度相对较慢。在对性能要求不是极其苛刻，更注重兼容性和开发效率的项目中，JSON是常用选择。比如一些小型的Web应用微服务，数据量不大且开发周期紧张，使用JSON序列化方便前后端开发和调试。
- Protobuf：Google开发的二进制序列化格式，数据体积小，序列化和反序列化速度快。它需要提前定义数据结构，但一旦定义好，性能优势明显。在大数据量、高并发且对性能要求严格的微服务场景中，如大型电商的订单处理微服务，Protobuf能显著提升系统性能。
- Thrift：同样是二进制序列化框架，它与Protobuf类似，提供了多种语言支持和高效的序列化机制。它在灵活性和性能之间有较好的平衡。当项目涉及多种不同编程语言的微服务交互，且对性能有较高要求时，Thrift是不错的选择，例如一个跨语言的分布式系统，后端使用Java、Python等多种语言开发不同微服务。
- 考量要点
- 业务场景：首先明确业务对响应时间、吞吐量的具体要求。如实时业务优先考虑低延迟的协议和序列化方式；大数据量传输业务注重数据体积和传输速度。
- 开发成本：在满足性能要求的前提下，尽量选择开发维护成本低的方案。例如JSON虽然性能不是最优，但开发简单，若性能满足业务，优先选择。
- 可扩展性：随着业务增长，RPC框架要能方便扩展。例如选择支持分布式部署、负载均衡的框架，以便应对高并发和业务规模扩大。
- 生态和社区支持：选择社区活跃、有丰富文档和工具支持的框架，便于解决开发中遇到的问题和系统维护。