大公司偏爱RPC的核心原因深度解析一、先搞懂RPC到底是什么RPC全称为远程过程调用Call, 就单个而言, 其意思是, 对于不同服务器之中的调用情况, 对于其不同服务之间的情况, 能够让这样的调用, 如同针对本地方法进行调用那般轻易简单, 并且, 这样的情况是无需手动去完成网络通信相关处理的, 是无需手动去干完数据序列化相关事宜的, 是无须手动做连接管理等底层繁琐细节工作的。Dubbo、gRPC、Cloud 、、HSF等等, 这些是常见的企业级RPC框架, 大公司的微服务架构当中会用到它, 分布式系统里也会用到它、跨语言跨平台服务交互同样会用到它并且几乎都是离不开RPC的, 这可不是技术跟风行为, 而是贴合大公司业务涵盖范围、技术搭建框架以及运维管理等方面之后的必然选择。二、大公司必用RPC的核心底层原因1. 极致性能优化适配高并发海量请求大公司所面对的是千万级以及亿级别的并发流量, 像电商秒杀这种场景, 还有金融交易场景, 社交推送场景, 物流实时调度场景等, 对于接口响应速度有着极高要求, 对于吞吐量同样有着极高要求, 这属于RPC最为核心的优势, 并且这还是HTTP接口没有办法去替代的关键所在:相比HTTP的JSON/XML文本序列化, RPC采用、、等二进制序列化协议, 序列化更高效, 其数据体积更小, 序列化反序列化速度更快, 能大幅减少网络传输耗时以及CPU开销, 标点的使用也需要符合要求, 标点的使用也需要符合要求。说到长连接复用, RPC默认是支持TCP长连接的。这样一来可以避免出现那种, HTTP短连接每次发起请求时, 都得重新去建立TCP三次握手, 然后再断开四次挥手进而造成损耗的情况。能够在高并发场景下达成连接复用, 显著减少延迟现象, 还能有效提升吞吐量。传输协议定制为私有RPC协议, 以此达成协议轻量化, 把HTTP协议里诸多冗余的请求头、响应头数据去除, 让传输在业务内容方面更专注, 其网络传输效率比HTTP要高很多。2. 适配分布式微服务架构解耦业务系统规模较大的公司, 其业务具备繁杂的特性, 单一一个应用已然没办法起到支撑的作用了, 一定得拆分成数量达到数百, 甚至是上千个微服务才行就像是用户服务、订单服务、支付服务、商品服务之类的, 各个服务相互之间需要有着高效且稳定的通信, RPC从一开始就是为了分布式的场景而进行设计的:有着一种能力, 它被称作服务化治理能力, 主流的RPC框架自身带着服务注册功能, 带着服务发现功能, 带着负载均衡功能, 带着服务熔断功能, 带着服务降级功能, 还有限流管控等一系列的核心治理功能, 并不需要去做额外的开发这样子, 便能够达成微服务集群的自动化管理, 进而解决服务数量众多, 部署分散, 以及难以维护的这类问题。跨平台且跨语言做到兼容, 大型公司技术栈呈现多元状态, 或许会同时存有以Java、Go、C等不同语言来开发打造的服务 , gRPC等RPC框架对跨语言调用予以支持, 破除语言障碍, 达成不同技术栈服务之间的无缝般对接。- 透明化地实施调用, 开发人员并不需要在意服务的部署位置究竟是在哪一个服务器, 又是在哪一个机房, 仅仅只是像调用本地所拥有的方法那样去调用远程服务, 底层涉及到的网络通信、负载进行分发、故障实现转移, 这全部都是由RPC框架来予以处理的, 如此显著地降低了分布式开发所存在的难度。3. 企业级运维管控适配大规模集群管理大公司所拥有的服务集群, 其规模甚是庞大, 随随便便就可高达上百台服务器。并且是在多个机房展开部署, 如此一来, 运维难度变得极其之高。而RPC框架自身所携带的企业级管控能力, 非常好地解决了运维方面存在的痛点:负载均衡策略多样, 支持轮询算法, 支持加权轮询算法, 支持随机算法, 支持一致性哈希算法, 支持最小连接数算法等众多负载均衡算法, 能够依据业务场景灵活进行配置, 预防单台服务器压力过于巨大, 达成集群流量均匀分配。故障时能自愈且具备容错能力, 内置超时重试机制, 还有熔断降级机制, 以及故障隔离机制, 更有失败切换机制, 当某一台服务节点出现故障的时候, RPC框架能够自动除掉故障节点, 把流量转向健康节点, 确保核心业务不中断, 以此提升系统可用性。- 具备很强的可观测性: 自身带有接口耗时这一监控指标, 还有调用次数方面监控指标, 存在错误率监控指标, 以及流量分布监控指标并且支持对接ELK等监控系统, 能够方便运维工作人员快速去定位分布式系统里的性能瓶颈以及故障点。4. 强契约规范保障团队协作与接口稳定大公司的研发团队数目众多, 人员规模庞大, 各个不同的团队负责开展不同的微服务在此情况下接口规范以及兼容性显得极为关键, 极为重要, 至关重要:接口契约化, RPC框架依据IDL接口定义语言来定义服务接口以及数据结构, 接口参数有着严格规范, 返回值有着严格规范, 异常信息也有着严格规范, 如此可避免不同团队所开发的接口发生参数不匹配的问题, 如此可避免不同团队所开发的接口出现格式混乱的问题。- 版本兼容方面: 其一支持接口版本管理, 其二在升级服务之际, 可确保新旧版本接口兼容, 其三不会因单个服务升级致使整个系统调用失败, 其四适配大公司延续递增与灰度发布的研发流程。根据IDL文件, 能够进行代码自动生成, 生成的是客户端和服务端代码, 这样做减少了重复开发工作的量, 在避免源自手动编码的语法错误这一点上也颇有成效, 并且提升了开发效率以及代码规范性。5. 安全与合规满足企业级业务要求大数据安全、权限管控方面, 金融、电商、政企等大型公司所持需求甚高, RPC框架能够以轻松之态达成企业级别的安全管控:它能够进行细粒度权限控制, 这种控制支持服务级以及接口级权限校验, 利用此校验可以精准地控制不同客户端的调用权限, 从而防止出现非法进行的调用以及越权操作。数据加密进行传输: 对TLS/SSL加密予以支持, 对对称加密给予支持, 对非对称加密加以支持, 让处于服务之间进行传输的敏感性的数据像是用户信息、交易数据不会被窃取掉, 也不会被篡改, 从而能够满足行业合规的要求。流量审计, 能够记录服务调用的每一次日志, 其中涵盖调用方、参数、耗时以及结果等各类信息, 这有利于事后开展审计工作, 进行问题追溯, 它是符合金融、政企等行业的审计规范要求的。6. 成本与资源优化降低大规模部署开销规模较大的公司, 其服务器以及带宽资源所需付出的成本是极其高昂的, 而RPC能够在多个不同的方面, 使得资源消耗得以降低:- 二进制序列化减少数据传输体积降低带宽成本长连接进行复用, 使得TCP连接数得以减少, 进而降低了服务器内存的花销, 以及CPU的开销。精密化限流熔断, 杜绝严重延迟与报错, 防止服务器资源过度消耗, 降低运维人力成本, 避免服务雪崩引发重大故障与潜在负面影响影响损失。---三、RPC与HTTP相比, 为何大型企业不采用HTTP去替换RPC, 为什么, 是有什么特别的原因吗?对比维度RPCHTTP传输性能二进制协议轻量化低延迟高吞吐文本协议冗余头多延迟高吞吐低服务治理自带注册发现、负载均衡、熔断限流需额外集成网关、注册中心无原生治理适用场景内部微服务通信、高并发分布式系统前后端交互、对外开放API、跨网简单调用跨语言支持需IDL定义天然支持无契约约束开发复杂度稍高需定义接口契约低简单易用最为关键的结论是, HTTP十分契合前后端之间的交互, 并且能够对外给出开放的接口, 然而RPC是大型公司内部的微服务集群里通信的最佳解决方案, 这两者并非是替代的关系, 相反是进行分工协作。---四、大公司使用RPC的典型业务场景电商平台, 订单服务会对库存服务进行调用, 支付服务会对用户服务进行调用, 在秒杀场景当中能够支撑万级并发调用。在金融行业当中, 存在着银行核心系统, 还有支付清算系统, 它们有着低延迟、高可用以及数据安全这样的要求。面向互联网大厂, 存在微服务集群, 有跨机房部署情况, 设有大数据平台, 还涉及AI服务调用。政企系统, 其内部业务系统需实现互通, 要达成权限管控, 要保证审计合规, 要做到稳定可靠。---五、总结RPC是大公司分布式架构的刚需大公司挑选RPC, 并非仅仅是为了追逐技术潮流这般简单, 而是依据业务规模、性能需求、架构复杂程度、运维管控状况、安全合规情形等多方面进行综合权衡考量的结果:场景是海量并发、分布式集群以及多团队协作、多技术栈融为一起的情况, RPC依靠极致性能、完善的服务治理、强契约规范、还有企业级安全这四大核心方面的优势, 成为大公司内部服务通信的符合标准配备的技术。中小型公司业务的规模小, HTTP就能够满足需求, 这正是只有大公司会大规模去落实RPC的最根本的缘由。
