【注】本文讲述的流程，在最后会附上一个完整的流程示意图。可以先看一下，有一个印象，但是具体的解释，还是要好好看文字描述。

        前面6篇文章，讲述了TCP服务器端的实现流程。这个流程实现了服务器与设备的通信，搭建起来了云平台的设备通信桥梁。此时服务器后台程序作为业务核心，在时刻不断的运行，是设备主动和服务器发起的通信，服务器被动的处理业务而已。

    如果仅仅是上面的TCP服务器端的通信和业务处理，是够不上云平台的，就仅仅是一个TCP服务器程序而已。这个程序的开发，相信有socket编程经验的程序员都是可以写出来的。只是写的复杂程度不同而已。你可以使用同步的方式实现通信，也可以使用异步，也可以使用事件机制。也就是，你所学到的socket的几种通信模式，随你用，都可以达到这个效果。
    而我这个实现，也不是讲述socket原始的实现细节，而是直接将TCP服务器的实现建立在libuv库之上，免去写底层的socket代码。我们要实现的是一个大的云平台服务器程序。当然，如果你有兴趣自己在Linux上实现epoll的模式的通信，或者Windows上的IOCP，也可以尝试一下。
    现在有了TCP客户端和服务器端的通信通路，却只有客户端向服务器端发起通信，并没有服务器主动向客户端发起通信。服务器为什么要想客户端发起通信呢？当然，我们这里说的发起通信属于业务上的说法，也就是服务器主动向客户端发命令来控制客户端的行为。那么再演进一下，服务器本身是不会去做这个动作的，必然是有一个地方先给服务器端发起了一个命令，让服务器向客户端发命令。因为最初发这个控制命令的方式，和客户端没有直接的联系，只有通过服务器。而服务器是事先就和客户端建立好了连接的，所以就可以和客户端发命令。
    这么命令只是业务上的规定，通常是客户端和服务器端同时支持的一个协议约定。当客户端收到服务器发过来的这样的命令，客户端就执行一定的动作。这也就是远程控制的原理。
    远程控制发起端，一般就是我们常常提到的APP端、web端、微信公众号或者微信小程序等。这些发起端无法直接与客户端（设备端）通信，所以必须借助服务器来中转命令。那么这个链路又是如何完成的呢？
    那么APP、web等的业务功能的实现，我们使用restful api提供。这样我们就可以支持很多方式的终端控制方式，因为所有控制端只需要调用我们的这些api就可以实现对应的功能，扩展性非常强。所以，我们就需要web服务器来支持restful api。这就是我们前面搭建的Nginx+uWSGI+webpy的原因。我们实现一组api，也就是写好一组python脚本。当一个api被远程调用的时候，即url被访问时，web服务器就会执行对应的python脚本来实现对应的功能。
    所以后台控制，也就是通过这样的api供各个控制端发起调用，web服务器再执行api对应的功能，完成调用。那么一般来说，对于web开发，到这一步也就差不多了。比如网页开发。这是一条完整的web执行流程。
    如果我们想通过控制端发起api调用后，实现设备的控制，我们就需要打通web服务器与TCP服务器。也就是说，当我们在web端调用api后，web服务器要将对应的命令发给TCP服务器，然后TCP服务器再将命令发给客户端。当客户端执行了命令后，再将结果返回给TCP服务器，TCP服务器再返回给web服务器，最终通过原来的路线一步步返回给最初的发起端。
    我们已经单独实现了TCP服务器与客户端（设备端）的通信和控制端（APP、微信等）与Web服务器的通信链路，现在只需要将两个链路串接起来，我们整个链路就形成了回路，也就实现了我们所要的云平台。这样也就是打通控制端和设备端的通信，借助了服务器的两个程序（tcp服务器程序和web服务器程序）。
    web服务器链路就是我们配置的Nginx+uWSGI+webpy服务器。而最终执行的web程序，也就是我们写的api的程序，即python脚本。所以，我们在python脚本中要实现与TCP服务器程序的通信。为了提高效率，我是用C++开发了一个动态库供python调用。在这个动态库里实现了与TCP服务器通信的。所以你不用担心python写系统相关的代码以及效率问题。选择你最熟悉的实现方式就行了。
    因为两个程序都是在一个服务器中运行的，所以我们可以将这两个服务器的通信做成进程间通信。进程间通信方式有很多，你可以选择适合自己的方式。我选择了消息队列的方式，通过在Linux系统创建一个全局的消息队列，然后两个服务器进程共享这个消息队列，从而实现进程间的通信。
    最后，云平台整个控制流程示意图如下：