关于云计算:Kurento实战之四应用开发指南

欢送拜访我的 GitHub

https://github.com/zq2599/blog_demos

内容：所有原创文章分类汇总及配套源码，波及 Java、Docker、Kubernetes、DevOPS 等；

本篇概览

• 本文是《Kurento 实战》的第四篇，后面的文章中，咱们先部署 KMS 再启动官网 demo，还把 Kurento 的重要概念都分类学习过，接下来要开始利用开发了；
• 本文的次要内容是剖析官网的 <font color=”blue”>kurento-hello-world</font> 我的项目，理解 Kurento 利用开发的根本流程和知识点，本文应用的代码是官网公布的 6.15.0 版本，地址：https://github.com/Kurento/ku…
• 浏览代码时，如果能从整体上将划分分明功能模块，再有针对性的一一攻破细节，将会更高效的学习和了解源码，接下来咱们就依照 Kurento 官网的规范套路去拆分并一一攻破；

如何划分功能模块

依照不同的职责划分，整个代码被拆分为三局部：

1. WebSocket 相干：WebSocket 相干的通用解决，例如连贯建设、敞开、异样的回调，业务逻辑的散发等；
2. WebRTC 信令相干：ICE、SDP 相干的解决；
3. 业务逻辑：如果说 1 和 2 代表的是 WebRTC 的通用解决，那么剩下的就是如何应用 Kurento 来实现业务需要了，这部分的次要内容是业务利用应用 Kurento 官网 client 和 KMS 交互，管制 KMS 为端侧提供服务，交互方式如下图：
   

• 依照上述形式将代码做好拆分，划定边界，不论是浏览官网 demo 还是本人开发利用，都能条理清晰的应答，接下来一起学习官网的 hello-world 源码，看看一个残缺的 Kurento 利用是如何开发进去的

WebSocket 相干

最简略的逻辑应该是通用的 WebSocket 解决了，咱们先看这部分，简单的稍后再说，Handler 类中和 WebSockert 相干的逻辑如下：

1. 继承自 TextWebSocketHandler(只解决 text 类型的数据，对于二进制数据间接敞开会话)；
2. 重写 afterConnectionEstablished：WebSocket 连贯建设的回调，只打了一行日志；
3. 重写 handleTransportError：WebSocket 产生异样时候的回调，仅敞开 WebSocketSession；
4. 重写 afterConnectionClosed：不管 WebSocket 是失常敞开还是产生异样，此办法都会执行，逻辑也很简略，就是调用 stop 办法，这个办法是用来开释 KMS 资源的，有好几处都会调用，咱们留到稍后和其余解决 KMS 的中央一起讲；
5. WebSockert 局部最重要的代码是 handleTextMessage 办法，外面是收到前端数据时的解决逻辑：先把数据转为 JsonObject 对象，此对象的 messageId 字段有四种值，每一种 id 及其对应的解决办法如下表格所示：

6. 并不是所有的利用都须要重写上诉全副代码，还是以理论需要登程决定是否要重写，以 <font color=”blue”>kurento-one2one-call</font> 我的项目为例，只重写了 handleTextMessage 和 afterConnectionClosed，其余的应用父类的即可，如下图：

7. 还有一个发送音讯到浏览器侧的 sendMessage 办法，以及发送错误信息的 sendError 办法；

信令相干

• <font color=”blue”>kurento-hello-world</font> 利用的性能是和 KMS 实现实时音视频通信，因而 WebRTC 规范的信令解决是必不可少的，惋惜 Kurento 官网并没有对信令解决做太多封装（也可能是信令和不同的业务解决逻辑都不一样，导致不好形象），后果就是一堆信令解决的代码散落在业务代码中；
• 就算业务和信令的解决代码同时呈现在 Handler 类中，只有相熟 WebRTC 的信令解决流程，也很容易读懂代码，下图联合了 WebRTC 规范的信令解决流程，对前端和服务端的代码串联在一起就行剖析，右边是浏览器上执行的 js 代码，左边是服务端，这些代码都用红色箭头标识了处于 WebRTC 信令解决流程的具体位置，至此，整个流程都清晰的展示进去：

• 如果您在电脑或手机上看上图感觉含糊，请下载原始文件，用 <font color=”blue”>draw.io</font> 关上，文件所在目录是：https://github.com/zq2599/blo…，文件名为 <font color=”red”>helloworld-flow.drawio</font>

• 上图列出了信令相干的所有代码，等到看完这些，剩下的就是业务代码了，也就是图中紫色局部的 <font color=”blue”>handleProcessSdpOffer</font> 办法；

  业务相干

• <font color=”blue”>kurento-hello-world</font> 利用是把本地摄像头和麦克风数据传到 KMS，再从 KMS 获得这些数据在页面展现，先看看官网是如何形容 KMS pipeline 的：

• 从上图可见 pipeline 逻辑非常简单：只有一个 WebRtcEndpoint，把本人的 Src 和 Sink 接上就实现了，咱们来看看对应的代码，在办法 handleProcessSdpOffer 中：

    // 创立 pipeline
    final MediaPipeline pipeline = kurento.createMediaPipeline();
    user.setMediaPipeline(pipeline);

    // 创立 webRtcEndpoint
    final WebRtcEndpoint webRtcEp =
        new WebRtcEndpoint.Builder(pipeline).build();
    user.setWebRtcEndpoint(webRtcEp);

    // 本人的 sink 连贯上本人的 src
    webRtcEp.connect(webRtcEp);

    // ---- Endpoint configuration

    String sdpOffer = jsonMessage.get("sdpOffer").getAsString();
    
    // 注册各类监听，例如媒体资源状态变动、ICE 变动等
    // 通过 websocket 回复 SDP Offer
    initWebRtcEndpoint(session, webRtcEp, sdpOffer);

    log.info("[Handler::handleStart] New WebRtcEndpoint: {}",
        webRtcEp.getName());
    
    // ---- Endpoint startup
    // 获得 ICE 信息
    startWebRtcEndpoint(webRtcEp);

• 再来看看进行 WebRtc 的 stop 办法，其实就是向 KMS 发送了 release 指令：

  private void stop(final WebSocketSession session) {
    // Remove the user session and release all resources
    final UserSession user = users.remove(session.getId());
    if (user != null) {MediaPipeline mediaPipeline = user.getMediaPipeline();
      if (mediaPipeline != null) {log.info("[Handler::stop] Release the Media Pipeline");
        mediaPipeline.release();}
    }
  }

小结

以上就是整个 <font color=”blue”>kurento-hello-world</font> 的源码剖析，整个工程的代码在拆分后再剖析时，变得异样清晰和简略：

1. WebSocket 和惯例的 java 开发无异，向规范聚拢即可；
2. WebRTC 相干代码占了较大比重，然而严格遵循了规范的信令流程，只有相熟 WebRTC 就很容易浏览和了解；
3. 业务逻辑其实是和业务需要相关联的，这里须要相熟 KMS 提供的能力，能力充分发挥 KMS 的实例，而 pipeline 编排和各个 element 的应用，也会是咱们前面文章的重点，用好这些 element，打磨出更弱小灵便的服务；

你不孤独，欣宸原创一路相伴

1. Java 系列
2. Spring 系列
3. Docker 系列
4. kubernetes 系列
5. 数据库 + 中间件系列
6. DevOps 系列

欢送关注公众号：程序员欣宸

微信搜寻「程序员欣宸」，我是欣宸，期待与您一起畅游 Java 世界 …
https://github.com/zq2599/blog_demos