RPC实战与核心原理
何小锋
京东技术架构部首席架构师
立即订阅
4741 人已学习
课程目录
已完结 29 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 别老想着怎么用好RPC框架,你得多花时间琢磨原理
免费
基础篇 (6讲)
01 | 核心原理:能否画张图解释下RPC的通信流程?
02 | 协议:怎么设计可扩展且向后兼容的协议?
03 | 序列化:对象怎么在网络中传输?
04 | 网络通信:RPC框架在网络通信上更倾向于哪种网络IO模型?
05 | 动态代理:面向接口编程,屏蔽RPC处理流程
06 | RPC实战:剖析gRPC源码,动手实现一个完整的RPC
进阶篇 (11讲)
07 | 架构设计:设计一个灵活的RPC框架
08 | 服务发现:到底是要CP还是AP?
09 | 健康检测:这个节点都挂了,为啥还要疯狂发请求?
10 | 路由策略:怎么让请求按照设定的规则发到不同的节点上?
11 | 负载均衡:节点负载差距这么大,为什么收到的流量还一样?
12 | 异常重试:在约定时间内安全可靠地重试
13 | 优雅关闭:如何避免服务停机带来的业务损失?
14 | 优雅启动:如何避免流量打到没有启动完成的节点?
15 | 熔断限流:业务如何实现自我保护?
16 | 业务分组:如何隔离流量?
答疑课堂 | 基础篇与进阶篇思考题答案合集
高级篇 (8讲)
17 | 异步RPC:压榨单机吞吐量
18 | 安全体系:如何建立可靠的安全体系?
19 | 分布式环境下如何快速定位问题?
20 | 详解时钟轮在RPC中的应用
21 | 流量回放:保障业务技术升级的神器
22 | 动态分组:超高效实现秒级扩缩容
23 | 如何在没有接口的情况下进行RPC调用?
24 | 如何在线上环境里兼容多种RPC协议?
结束语 (1讲)
结束语 | 学会从优秀项目的源代码中挖掘知识
加餐 (2讲)
加餐 | 谈谈我所经历过的RPC
加餐 | RPC框架代码实例详解
RPC实战与核心原理
15
15
1.0x
00:00/00:00
登录|注册

18 | 安全体系:如何建立可靠的安全体系?

何小锋 2020-04-01
你好,我是何小锋。上一讲我们学习了在 RPC 里面该如何提升单机资源的利用率,你要记住的关键点就一个,那就是“异步化”。调用方利用异步化机制实现并行调用多个服务,以缩短整个调用时间;而服务提供方则可以利用异步化把业务逻辑放到自定义线程池里面去执行,以提升单机的 OPS。
回顾完上一讲的重点,我们就切入今天的主题,一起来看看 RPC 里面的安全问题。

为什么需要考虑安全问题?

说起安全问题,你可能会想到像 SQL 注入、XSS 攻击等恶意攻击行为,还有就是相对更广义的安全,像网络安全、信息安全等,那在 RPC 里面我们说的安全一般指什么呢?
我们知道 RPC 是解决应用间互相通信的框架,而应用之间的远程调用过程一般不会暴露在公网,换句话讲就是说 RPC 一般用于解决内部应用之间的通信,而这个“内部”是指应用都部署在同一个大局域网内。相对于公网环境,局域网的隔离性更好,也就相对更安全,所以在 RPC 里面我们很少考虑像数据包篡改、请求伪造等恶意行为。
那在 RPC 里面我们应该关心什么样的安全问题呢?要搞清楚这个问题,我们可以先看一个完整的 RPC 应用流程。
我们一般是先由服务提供方定义好一个接口,并把这个接口的 Jar 包发布到私服上去,然后在项目中去实现这个接口,最后通过 RPC 提供的 API 把这个接口和其对应的实现类完成对外暴露,如果是 Spring 应用的话直接定义成一个 Bean 就好了。到这儿,服务提供方就完成了一个接口的对外发布了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《RPC实战与核心原理》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(12)

  • 前面讲的调用方之间的安全问题,我们更多只是解决认证问题,并没有解决权限问题。在现实开发过程中,一个 RPC 接口定义里面一般会包含多个方法,但我们目前只是解决了你能不能调用接口的问题,并没有解决你能调用我接口里面的哪些方法。像这种问题,你有什么好方案吗?

    这节讲的容易消化,老师提的问题,我之前在JD的时候也恰好实现过一个解决方案,我们组做过一个POP的订单中间件功能,提供的服务为了防止未知系统任意调用,在我们的那套系统里做了一个服务调用管理功能,就是到方法级。
    1:我们提供服务调用的申请模板,描述那个系统,那个应用,调用我们那个服务的那个方法,调用量多少,调用应用负责人是谁,对接研发谁,还有别的配置信息
    2:我们会把调用配置信息落库,然后放入缓存,使用调用者信息及我们提供服务的信息组成key,放入redis
    3:在调用方调用我们的时候,去做拦截和鉴权
    4:j-one统一部署平台中有系统和应用的唯一标识信息,这些信息在调用接口时作为入参的一部分,就能实现细粒度到方法基本的控制了

    另外,就是使用token的方式,这种方式应用的就更多了,也是申请时分发,其实本质是一样的就看对应的配置信息存储在哪里啦!
    2020-05-16
    2
  • 北漂鱼
    简单总结一下。服务端提供的安全校验方式。
    1.md5摘要校验(安全级别较低,服务端直接提供或者网关代劳)
    2.非对称加密算法就行签名(RSA和老师提到的HMAC等算法,服务端直接提供或者网关代劳)
    3.Oauth2授权(有单独的授权服务,四种模式任君选择)

    作者回复: 👍

    2020-04-28
    2
  • 陈国林
    老师,你在上文提到的HMAC来做认证,服务提供方是使用 “公钥” 验证服务调用方的签名串吗?那如果是这样的话,是要事先生成公私钥对吧

    作者回复: 是的

    2020-04-05
    2
  • Darren
    我们之前是用的配置中心来存储对应的关系,B服务可以被那些服务调用或者不可以被那些服务调用,同时,也有B服务的接口权限,然后内部网关同步相关信息,保存到内存缓存中,当调用方请求经过网管时,获取调用方,服务方,服务方具体的接口,然后去校验相关的信息,判断是否可以放行,我们的鉴权没有放在服务方本身去实现,是在网关实现的,请老师指点

    作者回复: 前提就是怎么识别调用方的身份,比如应用id

    2020-04-01
    1
    2
  • JDY
    我突然觉得,rpc这东西好像跟k8s有点像,k8s是类似把一个大服务拆分成很多模块,完了之后来把这些微服务管理起来,而rpc是提供了一系列接口,通过网络的方式,让各个调用方去调用。不知道能不能这样比较,求老师指点。

    作者回复: k8s可以看做rpc升级版本,后面我会讲到的

    2020-04-15
    1
  • 陈国林
    可以从鉴权和授权2个方面来看(参考k8s)
    1. 鉴权可以用 token 的方式,token鉴权应该是目前用的最多的一种认证方式
    2. 授权可以用 RBAC 方式,类似k8s里面的 serviceAccount 和 role 和 roleBinding 等等

    作者回复: 是的,认证和授权一般都是同时使用

    2020-04-05
    1
  • Raymond
    老师,请问服务提供方对服务调用方的授权认证后,已认证的状态应该存在服务提供端本地吧,那服务端集群中各个节点之间怎么共享同一个服务调用方应用的认证状态呢?还是说每次调用到不同的的服务提供方节点都需要从新进行鉴权?或者说是服务调用方在获取到服务提供方的IP列表后统一进行一次遍历的授权认证?请老师帮助解惑。

    作者回复: 每个节点都得鉴权一次

    2020-05-08
  • 波波
    老师,RPC可以用于公网通信吗?鉴权放在服务端对服务端的压力是不是也挺大的?

    作者回复: 公网一般比较少,鉴权只要一次开销,压力还是可控的

    2020-04-20
  • 忆澜
    这种授权方式,对于调用方而言,加密后的签名怎么维护呢,感觉有代码侵入呀

    作者回复: 统一授权平台上获取

    2020-04-03
  • 雨霖铃声声慢
    首先肯定是在服务端做,其次是应该在每一个服务提供端对其接口做权限审核,假如一个服务端提供10个接口出来,5个可以被A调用,另外5个不能被A服务调用,那么就应该有个配置文件配置这调用端和服务端各个接口的权限配置信息,这个权限配置应该放在配置中心,然后每个服务端会动态获取配置信息根据配置信息来决定是否拒绝服务。对于新增的调用服务,它需要先申请权限,然后服务端提供方修改配置文件对其提供服务。

    作者回复: 这也是一种思路

    2020-04-02
  • 2102
    权限控制应放在服务提供方,权限控制规则可以放到单独管理节点,服务启动的时候从管理节点获取规则,权限规则变更后下发到服务节点。

    作者回复: 这有一个前提就是统一调用方身份的问题,规则里面是按照什么对象来识别身份

    2020-04-01
  • 一步
    在进行接口授权的同时也进行接口方法的授权

    作者回复: 授权和认证都需要考虑

    2020-04-01
收起评论
12
返回
顶部