WebRTC学习笔记三MeshSFU开源实现方案

　　一、Mesh方案
　　即多个终端之间两两进行连接，形成一个网状结构。比如A、B、C三个终端进行多对多通信，当A想要共享媒体（比如音频、视频）时，它需要分别向B和C发送数据。同样的道理，B想要共享媒体，就需要分别向A、C发送数据，依次类推。这种方案对各终端的带宽要求比较高。
　　当某个浏览器想要共享它的音视频流时，它会将共享的媒体流分别发送给其他3个浏览器，这样就实现了多人通信。1。优势：不需要服务器中转数据，STUNTUTN只是负责NAT穿越，这样利用现有WebRTC通信模型就可以实现，而不需要开发媒体服务器。充分利用了客户端的带宽资源。节省了服务器资源，由于服务器带宽往往是专线，价格昂贵，这种方案可以很好地控制成本。2。劣势：共享端共享媒体流的时候，需要给每一个参与人都转发一份媒体流，这样对上行带宽的占用很大。参与人越多，占用的带宽就越大。除此之外，对CPU、Memory等资源也是极大的考验。一般来说，客户端的机器资源、带宽资源往往是有限的，资源占用和参与人数是线性相关的。这样导致多人通信的规模非常有限，通过实践来看，这种方案在超过4个人时，就会有非常大的问题。另一方面，在多人通信时，如果有部分人不能实现NAT穿越，但还想让这些人与其他人互通，就显得很麻烦，需要做出更多的可靠性设计。二、MCU方案（MultiPointControlUnit）
　　MCU主要的处理逻辑是：接收每个共享端的音视频流，经过解码、与其他解码后的音视频进行混流、重新编码，之后再将混好的音视频流发送给房间里的所有人，也叫Mixer模式。
　　MCU技术在视频会议领域出现得非常早，目前技术也非常成熟，主要用在硬件视频会议领域。不过我们今天讨论的是软件MCU，它与硬件MCU的模型是一致的，只不过一个是通过硬件实现的，另一个是通过软件实现的罢了。MCU方案的模型是一个星形结构，如下图所示：
　　我们来假设一个条件，B1与B2同时共享音视频流，它们首先将流推送给MCU服务器，MCU服务器收到两路流后，分别将两路流进行解码，之后将解码后的两路流进行混流，然后再编码，编码后的流数据再分发给B3和B4。
　　对于B1来说，因为它是其中的一个共享者，所以MCU给它推的是没有混合它的共享流的媒体流，在这个例子中就是直接推B2的流给它。同理，对于B2来说MCU给它发的是B1的共享流。但如果有更多的人共享音视频流，那情况就更加复杂。
　　【腾讯文档】FFmpegWebRTCRTMPRTSPHLSRTP播放器音视频流媒体高级开发资料领取：FFmpegWebRTCRTMPRTSPHLSRTP鎾斁鍣闊宠棰戞祦濯掍綋楂樼骇寮鍙璧勬枡棰嗗彇
　　MCU主要的处理逻辑如下图所示：
　　接收共享端发送的音视频流。将接收到的音视频流进行解码。对于视频流，要进行重新布局，混合处理。对于音频流，要进行混音、重采样处理。将混合后的音视频进行重新编码。发送给接收客户端。1。优点技术非常成熟，在硬件视频会议中应用非常广泛作为音视频网关，通过解码、再编码可以屏蔽不同编解码设备的差异化，满足更多客户的集成需求，提升用户体验和产品竞争力。将多路视频混合成一路，所有参与人看到的是相同的画面，客户体验非常好。2。缺点重新解码、编码、混流，需要大量的运算，对CPU资源的消耗很大。重新解码、编码、混流还会带来延迟。MCU服务器的压力较大，需要较高的配置。
　　大家都知道现今直播的发展要得益于CDN分发体系，CDN主要通过RTMP协议进行传输，而WebRTC的传输协议是RTPRTCP，所以如果我们需要使用CDN网络进行分发，就需要在服务器中将RTPRTCP转成RTMP。在WebRTC中，编码格式是OPUS，而RTMP协议对应的编解码格式一般是AAC，通常这两种编码格式之间的转换也是非常现实的需求。同时，在MCU模型中，我们还可以在服务器中增加录制、混流的功能，在直播连麦的情况下，通过混流的方式可以大大减少下行的带宽。
　　除了实现以上功能外，由于如今的直播中美颜、滤镜几乎成为了标配，所以实现这种附加功能也是市场普遍的需求。虽然在WebRTC中并没有提供实现美颜、滤镜的接口，但是我们可以在服务器端实现类似的附加功能。根据实际的业务需求，通过MCU多点控制单元，可以实现这类附加功能。三、SFU（SelectiveForwardingUnit）
　　SFU像是一个媒体流路由器，接收终端的音视频流，根据需要转发给其他终端，也叫Router模式。SFU在音视频会议中应用非常广泛，尤其是WebRTC普及以后。支持WebRTC多方通信的媒体服务器基本都是SFU结构。SFU的拓扑机构和功能模型如下图：
　　在上图中，B1、B2、B3、B4分别代表4个浏览器，每一个浏览器都会共享一路流发给SFU，SFU会将每一路流转发给共享者之外的3个浏览器。
　　下面这张图是从SFU服务器的角度展示的功能示意图：
　　相比MCU，SFU在结构上显得简单很多，只是接收流然后转发给其他人。然而，这个简单结构也给音视频传输带来了很多便利。比如，SFU可以根据终端下行网络状况做一些流控，可以根据当前带宽情况、网络延时情况，选择性地丢弃一些媒体数据，保证通信的连续性。
　　目前许多SFU实现都支持SVC模式和Simulcast模式，用于适配WiFi、4G等不同网络状况，以及Phone、Pad、PC等不同终端设备。1。优点由于是数据包直接转发，不需要编码、解码，对CPU资源消耗很小直接转发也极大地降低了延迟，提高了实时性。带来了很大的灵活性，能够更好地适应不同的网络状况和终端类型。2。缺点由于是数据包直接转发，参与人观看多路视频的时候可能会出现不同步；相同的视频流，不同的参与人看到的画面也可能不一致。参与人同时观看多路视频，在多路视频窗口显示、渲染等会带来很多麻烦，尤其对多人实时通信进行录制，多路流也会带来很多回放的困难。总之，整体在通用性、一致性方面比较差。每个端需要建立一个连接用于上传自己的视频，同时还要有N1个连接用于下载其它参与方的视频信息，消耗的带宽也是最大的（带宽比较烧钱）3。Simulcast模式
　　所谓Simulcast模式就是指视频的共享者可以同时向SFU发送多路不同分辨率的视频流（一般为三路，如1080P、720P、360P）。而SFU可以将接收到的三路流根据各终端的情况而选择其中某一路发送出去。例如，由于PC端网络特别好，给PC端发送1080P分辨率的视频；而移动网络较差，就给Phone发送360P分辨率的视频。
　　Simulcast模式对移动端的终端类型非常有用，它可以灵活而又智能地适应不同的网络环境。下图就是Simulcast模式的示意图：
　　4。SVC模式
　　SVC是可伸缩的视频编码模式。与Simulcast模式的同时传多路流不同，SVC模式是在视频编码时做手脚。
　　它在视频编码时将视频分成多层核心层、中间层和扩展层。上层依赖于底层，而且越上层越清晰，越底层越模糊。在带宽不好的情况下，可以只传输底层，即核心层，在带宽充足的情况下，可以将三层全部传输过去。
　　同一路流，分成了多具层，核心层，护展层和边缘层，当带宽不足时，由上层逐渐丢弃！
　　如下图所示，PC1共享的是一路视频流，编码使用SVC分为三层发送给SFU。SFU根据接收端的情况，发现PC2网络状况不错，于是将0、1、2三层都发给PC2；发现Phone网络不好，则只将0层发给Phone。这样就可以适应不同的网络环境和终端类型了。
　　要注意的是，simulcast和SVC不能混用。这两个相比，simulcast的操作更简单一些，实用性更高一些，国内的声网便使用的这种方式。SVC更复杂一些，国外的zoom、思科的解决方案便采用的这种方式。四、现状总结1。参考WebRTC开发实践：为什么你需要SFU服务器
　　SFU服务器最核心的特点是把自己伪装成了一个WebRTC的Peer客户端，WebRTC的其他客户端其实并不知道自己通过P2P连接过去的是一台真实的客户端还是一台服务器，我们通常把这种连接称之为P2S，即：PeertoServer。除了伪装成一个WebRTC的Peer客户端外，SFU服务器还有一个最重要的能力就是具备onetomany的能力，即可以将一个Client端的数据转发到其他多个Client端。
　　这种网络拓扑结构中，无论多少人同时进行视频通话，每个WebRTC的客户端只需要连接一个SFU服务器，上行一路数据即可，极大减少了多人视频通话场景下Mesh模型给客户端带来的上行带宽压力。
　　SFU服务器跟TURN服务器最大的不同是，TURN服务器仅仅是为WebRTC客户端提供的一种辅助的数据转发通道，在P2P不通的时候进行透明的数据转发。而SFU是懂业务的，它跟WebRTC客户端是平等的关系，甚至接管了WebRTC客户端的数据转发的申请和控制。
　　从上述SFU的定义可以看到，SFU这种网络拓扑模型，通过由SFUServer来实现onetomany，减轻了多人视频通话场景下每个客户端的上行带宽压力，但是下行依然是多路流，随着通话人数的增大，下行带宽的压力依然会成比例的增大，那能否让下行也只剩一路流呢？可以，通过在服务器端合流后再下发即可解决。这种网络拓扑结构，被称之为MCU，它的特点是，由MCUServer将各路客户端上行的视频流合成为一路，再转发给其他客户端。这种模型相比于SFU降低了多人视频通话场景下客户端的下行带宽压力，但是由于合流需要转码操作，对服务器端压力比较大，而且下发给客户端的流是固定的合流画面，灵活性不是特别好。
　　综上所述，纯mesh方案无法适应多人视频通话，也无法实现服务端的各种视频处理需求，最先排除在商业应用之外。
　　SFU相比于MCU，服务器的压力更小（纯转发，无转码合流），灵活性更好（可选择性开关任意一路数据的上下行等），受到更广泛的欢迎和应用，常见的开源SFU服务器有：Licode，Janus，Jitsi，mediasoup，Medooze等等，各有特点，大家可以去项目主页了解更详细的情况。
　　当然，也可以组合使用SFUMCU的混合方案，以灵活应对不同场景的应用需要。2。SFU开源方案
　　由于各方面限制，Mesh架构在真实的应用场景中几乎没有人使用，一般刚学习WebRTC的才会考虑使用这种架构来实现多方通信。（可以简单了解下）
　　MCU架构是非常成熟的技术，在硬件视频会议中应用非常广泛。像很多做音视频会议的公司之前都会购买一套MCU设备，这样一套设备价格不菲，最低都要50万，但随着互联网的发展以及音视频技术越来越成熟，硬件MCU已经逐步被淘汰，当然现在也还有公司在使用软MCU，比较有名的开源项目是FreeSWITCH。
　　SFU是最近几年流行的新架构，目前WebRTC多方通信媒体服务器都是SFU架构。从上面的介绍中你也可以了解到SFU这种架构非常灵活，性能也非常高，再配上视频的Simulcast模式或SVC模式，则使它更加如虎添翼，因此SFU模式已经渐渐成为主流了。目前的实际应用中，使用Simulcast比使用SVC多，webRTC对两种都支持。
　　下面就来探讨下常见的SFU开源解决方案，当然，你也可以自己实现SFU流媒体服务器，但自已实现流媒体服务器困难还是蛮多的，它里面至少要涉及到DTLS协议、ICE协议、SRTPSRTCP协议等，光理解这些协议就要花不少的时间，更何况要实现它了。所以最常见的办法就是使用开源的实现。
　　部分开源系统五、Licode
　　Licode既可以用作SFU类型的流媒体服务器，也可以用作MCU类型的流媒体服务器。一般情况下，它都被用于SFU类型的流媒体服务器。
　　Licode不仅仅是一个流媒体通信服务器，而且还是一个包括了媒体通信层、业务层、用户管理等功能的完整系统，并且该系统还支持分布式部署。
　　Licode是由C和Node。js语言实现。其中，媒体通信部分由C语言实现，而信令控制、用户管理、房间管理用Node。js实现。它的源码地址为：https：github。comlynckialicode，Stars：2。6k。下面这张图是Licode的整体架构图：
　　通过这张图你可以看出，Licode从功能层面来讲分成三部分，即Nuve、ErizoController和ErizoAgent三部分，它们之间通过消息队列进行通信。Nuve是一个Web服务，用于管理用户、房间、产生token以及房间的均衡负载等相关工作。它使用MangoDB存储房间和token信息，但不存储用户信息。ErizoController，用于管理控制，信令和非音视频数据都通过它接收。它通过消息队列与Nuve进行通信，也就是说Nuve可以通过消息队列对ErizoController进行控制。ErizoAgent，用于音视频流媒体数据的传输，可以分布式布署。ErizoAgent与ErizoController的通信也是通过消息队列，信令消息通过ErizoController接收到后，再通过消息队列发给ErizoAgent，从而实现对ErizoAgent进行控制。
　　Licode不仅仅是一个SFU流媒体服务器，它还包括了与流媒体相关的业务管理系统、信令系统、流媒体服务器以及客户端SDK等等，可以说它是一个比较完善的产品。
　　如果你使用Licode作为流媒体服务器，基本上不需要做二次开发了，所以这样一套系统对于没有音视频积累的公司和个人具有非常大的诱惑力。目前IntelCS项目就是在Licode基础上研发出来的，已经为不少公司提供了服务。官网提供学习demo，和文档。
　　但Licode也有以下一些缺点：githubstar2。4kissue和pr相当活跃，社区采用的是传统提问，及时沟通相对较差在Linux下目前只支持Ubuntu14。04版本，在其他版本上很难编译通过。Licode不仅包括了SFU，而且包括了MCU，所以它的代码结构比较重，学习和掌握它要花不少的时间。Licode的性能一般，如果你把流媒体服务器的性能排在第一位的话，那么Licode就不是特别理想的SFU流媒体服务器了。官方没有看到android和ios的SDK，有其他人实现，但是早已经不更新，如果你要考虑安卓和ios的话，可能自己会下功夫。六、Janusgateway
　　Janus是一个非常有名的WebRTC流媒体服务器，它是以Linux风格编写的服务程序，采用C语言实现，支持LinuxMacOS下编译、部署，但不支持Windows环境。
　　它是一个开源项目，其源码的编译、安装非常简单，只要按GitHub上的说明操作即可。源码及编译手册的地址为：https：github。commeetechojanusgateway，stars：5。2k。
　　Janus的部署也十分简单，具体步骤详见文档，地址为：https：janus。conf。meetecho。comdocsdeploy。html。
　　从上面的架构图中，你可以看出Janus分为两层，即应用层和传输层。
　　插件层又称为应用层，每个应用都是一个插件，可以根据用户的需要动态地加载或卸载掉某个应用。插件式架构方案是非常棒的一种设计方案，灵活、易扩展、容错性强，尤其适用于业务比较复杂的业务，但缺点是实现复杂，成本比较高。
　　在Janus中默认支持的插件包括以下几个。SIP：这个插件使得Janus成了SIP用户的代理，从而允许WebRTC终端在SIP服务器（如Asterisk）上注册，并向SIP服务器发送或接收音视频流。TextRoom：该插件使用DataChannel实现了一个文本聊天室应用。Streaming：它允许WebRTC终端观看收听由其他工具生成的预先录制的文件或媒体。VideoRoom：它实现了视频会议的SFU服务，实际就是一个音视频路由器。VideoCall：这是一个简单的视频呼叫的应用，允许两个WebRTC终端相互通信，它与WebRTC官网的例子相似（https：apprtc。appspot。com），不同点是这个插件要经过服务端进行音视频流中转，而WebRTC官网的例子走的是P2P直连。RecordPlay：该插件有两个功能，一是将发送给WebRTC的数据录制下来，二是可以通过WebRTC进行回放。
　　传输层包括媒体数据传输和信令传输。媒体数据传输层主要实现了WebRTC中需要有流媒体协议及其相关协议，如DTLS协议、ICE协议、SDP协议、RTP协议、SRTP协议、SCTP协议等。
　　信令传输层用于处理Janus的各种信令，它支持的传输协议包括HTTPHTTPS、WebSocketWebSockets、NanoMsg、MQTT、PfUnix、RabbitMQ。不过需要注意的是，有些协议是可以通过编译选项来控制是否安装的，也就是说这些协议并不是默认全部安装的。另外，Janus所有信令的格式都是采用Json格式。
　　Janus整体架构采用了插件的方案，这种架构方案非常优秀，用户可以根据自己的需要非常方便地在上面编写自己的应用程序。
　　而且它目前支持的功能非常多，比如支持SIP、RTSP、音视频文件播放、录制等等，所以在与其他系统的融合性上有非常大的优势。
　　另外，它底层的代码是由C语言编写的，性能也非常强劲。Janus的开发、部署手册也非常完善，因此它是一个非常棒的开源项目。
　　githubstar4。1k，并且处理issue和pr相对较快。
　　官方提供安卓和ios的sdk。
　　缺点：架构太复杂，不适合初学者，公司采用的话人力成本和事件成本会比较高janus底层没有使用epoll这类异步IO事件处理机制，这应该说是它的一大缺陷Janus还使用glib库，由于glib库对于国内的很多开发同学来说用的比较少，所以会有一定的学习成本七、Mediasoup
　　Mediasoup是推出时间不长的WebRTC流媒体服务器开源库，其地址为：https：github。comversaticamediasoup，stars：3。3k。Mediasoup由应用层和数据处理层组成。应用层是通过Node。js实现的；数据处理层由C语言实现，包括DTLS协议实现、ICE协议实现、SRTPSRTCP协议实现、路由转发等。
　　Mediasoup把每个实例称为一个Worker，在Worker内部有多个Router，每个Router相当于一个房间。在每个房间里可以有多个用户或称为参与人，每个参与人在Mediasoup中由一个Transport代理。换句话说，对于房间（Router）来说，Transport就相当于一个用户。
　　Transport有三种类型，即WebRtcTransport、PlainRtpTransport和PipeTransport。WebRtcTransport用于与WebRTC类型的客户端进行连接，如浏览器。PlainRtpTransport用于与传统的RTP类型的客户端连接，通过该Transport可以播放多媒体文件、FFmpeg的推流等。PipeTransport用于Router之间的连接，也就是一个房间中的音视频流通过PipeTransport传到另一个房间。
　　在每个Transport中可以包括多个Producer和Consumer。Producer表示媒体流的共享者，它又分为两种类型，即音频的共享者和视频的共享者。Consumer表示媒体流的消费者，它也分为两种类型，即音频的消费者和视频的消费者。
　　Mediasoup的实现逻辑非常清晰，它不关心上层应用该如何做，只关心底层数据的传输，并将它做到极致。
　　Mediasoup底层使用C开发，使用libuv作为其异步IO事件处理库，所以保证了其性能的高效性。同时它支持了几乎所有WebRTC为了实时传输做的各种优化，所以说它是一个特别优秀的WebRTCSFU流媒体服务器。
　　它与Janus相比，它更聚焦于数据传输的实时性、高效性、简洁性，而Janus相比Mediasoup做的事儿更多，架构和逻辑也更加复杂。
　　对于开发能力比较强的公司来说，根据自己的业务需要在Mediasoup上做二次开发也是非常值得推荐的技术方案。
　　手机端的话需要自己实现安卓和ios的SDK八、Medooze
　　Medooze是一款综合流媒体服务器，它不仅支持WebRTC协议栈，还支持很多其他协议，如RTP、RTMP等。其源码地址为：https：github。commedoozemediaserver，stars：820
　　从大的方面来讲，Medooze支持RTPRTCP、SRTPSRCP等相关协议，从而可以实现与WebRTC终端进行互联。除此之外，Medooze还可以接入RTP流、RTMP流等，因此你可以使用GStreamerFFmpeg向Medooze推流，这样进入到同一个房间的其他WebRTC终端就可以看到听到由GStreamFFmpeg推送上来的音视频流了。另外，Medooze还支持录制功能，即上图中的Recorder模块的作用，可以通过它将房间内的音视频流录制下来，以便后期回放。
　　Medooze的控制逻辑层是通过Node。js实现的，Medooze通过Node。js对外提供了完整的控制逻辑操作相关的API，通过这些API你可以很容易的控制Medooze的行为了。
　　Medooze与Mediasoup相比，两者在核心层实现的功能都差不多，但Medooze的功能更强大，包括了录制、推RTMP流、播放FLV文件等相关的操作，而Mediasoup则没有这些功能。
　　Medooze也有一些缺点，尽管Medooze也是C开发的流媒体服务务器，使用了异步IO事件处理机制，但它使用的异步IO事件处理的API是poll，poll在处理异步IO事件时，与Linux下最强劲的异步IO事件APIepoll相比要逊色不少，这导致它在接收发送音视频包时性能比Mediasoup要稍差一些。九、jitsi
　　https：github。comjitsijitsi，stars：3。3khttps：github。comjitsijitsimeet，stars：15。6k使用Java构建的服务端，底层也是使用cc，使用Java语言所以性能上没有使用cc的表现好。
　　主要模块及实现语言：JitsiVideoBridge（Softwarevideobridge实现语言java）JitsiJicofo（Componentmandatoryforjitsiconference实现语言java）Prosody（XMPPServer实现语言lua）Nginx（WebServer）JitsiMeet（Webapplicationtowhichtheenduserwillinteract。实现语言js）优点：githubstar12。3k，issue和pr处理快文档齐全官方提供安卓和iosSDK，也可以自行编译SDK，使用的是ReactNative官方提供web端的SDK，并提供使用electron进行桌面端打包（端很齐全）社区采用论坛方式沟通，活跃较高社区提供分布式解决方案，但是文档偏少。每周一维护团队在jitsi上进行视频会议，回答开发者的提问，沟通使用英文，国内时间好像是晚上。社区版本更新迭代较快十、Kurento
　　使用了GStreamer对WebRTC的实现。https：opensource。comarticle191gstreamer比如这些项目：https：janus。conf。meetecho。comhttps：www。kurento。orgkurentoarchitecturekurento是比较出名的了https：github。comKurentokurentomediaserver，stars：2。3kKurento和jitsi是一样，持续维护了很多年，经过了时间的检验。不同的是他是使用c开发，有丰富的文档和示例库，对于开发者来说非常友好。
　　GStreamer在Linux下有非常普遍的使用率，但它严重依赖大量第三方项目，比如glib，libice等，都存在跨平台编译问题，也存在API使用繁琐的问题。十一、nodewebrtc
　　https：github。comnodewebrtcnodewebrtc，stars：2k将开源项目Chromium内WebRTC的cpp原生实现集成到项目中使用。原生WebRTC虽然有最好的功能实现，但复杂的编译环境，源码整合，API封装，工作量非常繁重十二、pionwebrtc
　　https：github。compionwebrtc，stars：6。8kWebRTCAPI的PureGo实现十三、总结
　　对流媒体服务器的选择，没有最好，只有最合适。每个开源实现都有其各自的特点，都可以应用到实际产品中，只不过作为开发人员都有自己独特的技术背景，你需要根据自身特点以及项目特点选一个最合适的。接下来，我就介绍一下我是如何对这些开源项目进行评判和选择的。1。团队
　　在一个团队中肯定会选择一种大家都比较熟悉的语言作为项目开发的语言，所以我们在选择开源项目时，就要选择使用这种语言开发的开源项目。比如阿里系基本都用Java语言进行开发，所以它们在选择开源项目时，基本都会选择Java开发的开源项目；而做音视频流媒体服务的开发人员，为了追求性能，所以一般都选择CC语言开发的开源项目。团队人手如果不充裕的情况下，尽量就不要选择特别复杂的，和文档比较少的开源技术。2。适合业务
　　要充分考虑到你的业务的用户量和用户群体，如果你的业务量很大，需要做分布式，那么你选择的开源技术一定要先去了解下他是否支持分布式部署，分布式部署采用那种方式。单机支持多少并发，最好自己用服务器实际测试下，官方数据会和实际测试数据多少都有出入。项目功能也需要考虑，比如业务需要录制回放，开源技术并没有这样的功能，需要自己开发，时间成本很高，但选择已经做好录制回放功能的开源技术又不一样了。3。二次开发
　　Licode是一个完整的系统，支持分布式集群部署，所以系统相对复杂，学习周期要长一些。它可以直接布署在生产环境，但是二次开发的灵活性不够。Janusgateway是一个独立的服务，支持的信令协议很丰富，而且支持插件开发，易扩展，对于LinuxC背景的开发者是很不错的选择。Medooze和Mediasoup都是流媒体服务器库，对于需要将流媒体服务器集成到自己产品中的开发者来说，应该选择它们。4。时间成本
　　公司对于项目的时间计划和成本也要考量，因为使用开源技术或多或少都会遇到坑，有可能一个坑会卡很久，所以使用文档全，社区活跃的开源技术比较好。
　　无论选择哪种开源技术，前期一定要做好调研，并实际自己搭建使用过在做决定，选择好后，为了弥补技术债，需要去深入开源技术的代码，不然还债的时候很疼苦。