多个跨云服务器之间满带宽测速的完结计划

　　方针需求

　　因为咱们现在开发的云渠道项目是一个跨云调度的重型核算渠道，所以会用到不同的云服务厂商的核算实例服务器，比方阿里云的ECS、亚马逊的EC2或许谷歌云的compute engine等，一起也会在这些核算实例之间进行数据传输。

　　这些服务器之间的传输速度通常是不同的，即便是同一个云服务厂商内的不同区域服务器之间传输数据，带宽也会有所不同。

　　所以需求对这些服务器之间的带宽速度进行丈量，以供调度进程分配任务和传输数据。

　　总结起来这个功用完结起来有3个要求：

　　对不同区域内的云服务器的TCP/UDP传输速度进行检测。

　　有必要是满带宽的测速，也便是说两台服务器在测速的时分不能有其它网络程序运转。

　　多台服务器之间需求高效地树立两两衔接。

　　针对这3个问题，我实行了以下处理计划。

　　根本结构

　　一种简略的想象便是发动测速所需的客户端和服务端，让这些程序之间相互争抢进行测速。

　　可是这种方法在进程的办理上很简略呈现问题，因为每个进程既要操作自己的状况还需求操作其它进程的状况，一起一会儿起4个进程也比较糟蹋，因为事实上每次测速只会有一个进程作业。

　　所以更好的方法是用主从结构，由一个主进程来启停担任测速的客户/服务端子进程。

　　这样不光能有效地防止资源的糟蹋和争抢，一起主进程中也能够集成许多逻辑功用，比方对外供给 REST API，记载日志、备份测验成果等。

　　当然为了便利布置和程序操控，一切的进程都是布置在 Docker 容器中。

　　因为主进程需求拜访宿主机的 Docker 服务，所以需求敞开 Docker 的 remote API 服务，对容器供给REST API进行操作。

　　功用完结

　　根本测速

　　TCP与UDP

　　网络协议是一层一层封装起来的，而TCP和UDP归于同一层的两种协议。

　　其间TCP协议在前后端开发中十分常用，因为REST API恳求依靠的HTTP(S)协议便是TCP的上层协议，而UDP协议在视频、游戏、下载等事务中运用也十分多。

　　它们有一些共同点：恳求的建议方称为客户端，恳求的接纳方称为服务端，服务端和客户端能够双向通讯。

　　而它们的侧重点有所区别。TCP更重视安稳，客户端和服务端之间需求树立衔接之后才干相互发送数据。

　　UDP则更重视速度，客户端不需求和服务端树立衔接即可直接发送数据，可是假如发送速度太快或许网络不安稳或许会形成丢包，导致对方接纳的数据部分丢掉。

　　测速东西

　　常用的命令行测速东西有iperf和speedtest，相较之下挑选了功用更强壮的iperf。

　　iperf是一个比较抱负的测速东西，支撑TCP、UDP协议，还能够经过参数来拟定传输数据巨细、传输次数或许传输时刻，以及输出成果的格局。

　　可是因为前面UDP协议的特性，测速会稍微费事一些，需求找到适宜的带宽。

　　比方依照1Gbps的速度发送数据，丢包率是70%和依照10Mbps的速度发送数据，丢包率是0，那么对数据完整性有要求的话必定更倾向于后者。

　　当然实践状况并不是关于丢包率为0便是最好的，而是在可容忍的范围内选用最大速度传输（数据丢了还能够重传不是~）。

　　这就意味着需求依据实践网络状况不断调整和测验。

　　而iperf并没有这么智能，所以UDP这一块选用团队内部开发的一款UDP传输东西，来找到抱负的传输速度。

　　满带宽

　　要确保满带宽只需求确保测速时没有其它程序占用带宽即可。

　　因为咱们能够发动一台独立的抢占式服务器来运转测速程序，所以其它非测速程序的进程不太或许占用带宽，而简略争抢带宽的是用来测速的子程序。

　　所以需求让子程序之间是互斥运转，乃至是互斥存在的。

　　选用状况办理根本上就能够完结，主程序在每次有进程发动的时分将状况置为”connecting”，测速完结后置为”waiting”，只要在”waiting”状况下才干够发动新的子程序进行测速。

　　可是这仅仅从代码逻辑层面操控，关于安稳强健的程序而言，最好还有其它的硬性操控方法。

　　这时分运用容器的话就能够轻松办到。

　　但凡需求进行测速的进程都在容器中发动，一起容器的称号都统一，那么一旦程序呈现bug，一起发动多个子程序时，Docke r服务则会报错，奉告容器称号抵触，然后创立失利。

　　当然这种方法也有必定的危险，比方上一个进程测速过程中呈现问题没有准时退出，那么则无法进行新的测速，所以需求需求设定一个超时时刻，超越一段时刻后自动中止当时测速子程序。

　　一起假如主程序意外退出，导致中止失利的话，也要进行处理：在每次发动主程序的时分进行检查，及时毁掉未中止的子程序。

　　多节点

　　多节点算是十分扎手的问题。试想假如在一段时刻内一起在多个云服务器上发动多个测速程序，怎样确保他们有序的进行测速呢？

　　要处理这个问题，先考虑一个简略些的问题：

　　在一段时刻内，怎样决议哪些云服务器发动服务端子程序哪些云服务器发动客户端子程序呢？

　　假如依照“主-从”方式的话需求树立一个中心节点来进行操控，可是这样的缺陷许多，最重要的一个缺陷是假如某个节点与中心节点无法通讯那么就无法取得与其它节点通讯的时机，及时它和其它节点之间网络疏通。

　　一起中心节点和其它节点之间也存在多节点通讯的问题。

　　总而言之这种方法下通讯的本钱太高，服务端与客户端传输数据需求的中心环节太多，很简略呈现问题。

　　所以简略的方法是让云服务器之间相互建议测速恳求并呼应。

　　这样的话，主程序的逻辑要分为两个模块，一个模块用来呼应恳求、、分配端口、发动服务端容器。

　　另一个用来轮询带测速行列并建议恳求、发动客户端容器树立衔接。

　　作业流程大致如下：

　　这种处理方法还有一种极点状况，便是两个云服务器之间相互恳求进行测验，假如两边恳求抵达时刻共同，那么就会一起给对方分配端口，然后一起遭到对方分配的端口之后发现服务端已发动所以抛弃衔接。

　　所以呈现了相似进程“死锁”的状况。

　　关于这种状况的处理方法是运用时刻戳来记载恳求建议的时刻，两边经过时刻戳的先后来决议是否发动客户端或服务端。

　　即便更极点的状况呈现——两边时刻戳相同。那么经过超时收回或许发消息开释端口来树立下一次衔接。

　　弱网络下的处理

　　弱网络指的是网络不安稳或许带宽较小的状况。

　　这种状况的处理方法原则上便是重测，可是关于重测有几个需求留意的当地：

　　关于带宽较小的状况需求考虑减小传输数据的体积以确保在拟定的超时时刻内完结测速。

　　关于测速失利的状况进行判别偏重测，一起限制重测次数，防止无限重测。

　　重测时能够让客户端与服务端进行交换测验，经过限制一方建议重测可完结。

　　总结

　　整体结构图如下：

　　许多时分完结一个功用并不困难，可是要把功用完结好却是一件不简略的事。

　　尽管理论上完结起来仅仅简略的调用测速东西就能够得到成果，但在实践场景下可用性会变得很低。

　　比方没有对弱网络的重测机制，那么偶尔的网络颤动就会影响到测速成果。

　　假如没有考虑到多节点争抢衔接的问题，那么实践运转在多个云服务器上或许会形成程序过错或测速成果不精确的问题。

　　要怎样样把功用完结好呢？

　　至少有两个考虑方向：

　　倍数思想。比方当时结构支撑10个页面没问题，那么假如100个、1000个会不会有功用问题？

　　极限思想。便是一些极点状况下的处理机制，比方在本文中对超时的处理，对容器互斥的处理等。