行业资讯
在服务中不断加深对用户需求的理解，并促进产品与服务的不断完善
在服务中不断加深对用户需求的理解，并促进产品与服务的不断完善
去年国庆，Facebook的故障让好多人都学会了BGP这个单词，而到了年底，AWS的网络故障更是加了一把火，直接把AWS烧的开始重构一套操控平面了。然而国内呢？好像要么魔改BGP、要么不务正业去搞
SDWAN
操控协议变革
云网的操控平面设计，Facebook有了OpenR，google有自己的Orion，Azure贡献了Sonic。反诘国内几个云在做什么？而现在AWS已经开始找人重构操控面了。
昨天跟一位领导谈到这个话题的时候，整个Ruta的思路非常简略清晰，但是为什么没有诞生在十年前或者二十年前，渣也反思过这个问题，总结的答案如下：
20年前MPLS刚起步有了一些Overlay的概念，但是带宽仍是很紧张，因而源路由的概念并不被认可。而基于目的路由的SDN操控例如OpenFlow在10年前出来了，又遇到了一个问题，全网一致性是一个非常难以处理的问题。而针对新的协议的定制开发芯片也非常困难，因而五六年前有了P4这样的ASIC。再加上分布式数据库技术的成熟和云原生架构的实践，那么在这样的背景下必然会诞生Ruta这样的项目。于渣而言，只是刚好在各个边际反复试探，并且充分了解了园区网、
SDWAN
和数据中心及云网和容器网络的痛点，而产生的方案。
一个好的架构师只是在恰当的时间用恰当的食材做了一锅恰当的料理罢了。
传输协议变革
当然在有些地方有些争议就不多点评了，有些东西存在并能带来一些价值，同时又不产生过高的成本就是一个恰当的技术。而任何技术都有被新技术淘汰的那一天，还不如放置争议，先用起来再说。
从学术上来看，咱们来议论另一个需要用到window的地方，那就Streaming DataProcessing中的概念，Processing Time、Injection Time、Event Time到底选哪个？以及用Time测量并操控Window的缺陷，渣不想多点评什么，即便是Google Swift也搞得很烦人。消除抖动是关键，而关键是你在空间仍是时间维度去看抖动。
Flink或者google DataFlow 最终提高性能的不是把数据放入某个Window，而是把Window Assign给数据，并容忍乱序,引入Watermark，并引入Actor同时实现ExactlyOnce的语义，这个思维惯式的问题很难讲清楚，必须要自己切身的痛过才会感受。
图灵的无限长纸带好像成了TCP协议一开始想模拟的东西，而接下来整个工业界在拥塞操控上都采用滑动窗口的方式，把偏序集定义在了通信上，而不是把偏序集定义在数据上。用Window没错，但是滑动的不该该是Window，而是数据。
渣再一次强调：通信的语义满意半格的代数结构对大家都有益处，这又是一个很多人都没看懂的地方。
首先咱们来看内存的分布，其实它就是以内存地址为序列的一个偏序集(Partially ordered set),对内存上进行的操作如果满意可交换(Commutative)、幂等(idempotent)并且满意半群(Semi-Group)中定义的封闭性和结合律。那么这个对内存的操作就是一个半格(Semi-lattice).而简略的内存读写操作是满意幂等的，至于结合律取决于这个操作里的幺元是什么，也就是说是以消息为原子，仍是以Byte为原子进行操作，因为内存例如 Write 和 Read之间操作的地址空间有冲突则不满意结合律了，而消息的语义则很好的隔离开了这两者，所以你也就会看到分布式并行程序设计里常见的Actor模型和CSP模型。
所以只要咱们关于消息的语义的内存使用作为幺元，然后把内存操作的地址和指令和消息绑定在一起，那么就能够实现Semi-lattice的代数结构了，进而就解决了大规模通信的难题。交换律(Commutative)决定了Out-of-order能够随便用多路径解决拥塞，幂等(idempotent)决定了丢包能够随便重传，结合律(associative)使得多个操作能够代数上merge好了再传远端，并且能够实现Transactional Memory的访问，保证Transaction的原子性。
通信方式上引入Semi-Lattice，辩证的看待通信和计算的本源，这一点本质上不亚于当年大数据时代引入的map-reduce，而reduce对算子的要求也是要满意交换律，这是分布式系统提升容量的最关键的地方。
今天渣还做了一个NetDAM BRAM的延迟测试，通过交换机打时间戳，结果如下， 基本上NetDAM裸卡延迟在430ns，抖动几乎为零，这就是Fetch-And-Add能做到592M QPS的原因。
QQ客服