电子发烧友App
本文由斯坦福大学和普林斯顿大学合作完成。这篇文章聚焦于网络中的计算，提出网络计算的核心是较快地获得正确的结果，因此要建立以计算为中心的网络。这个工作设计并实现了一个名为Fixpoint的框架，并在初步的测试中获得了较好的表现。
＞背景
云计算是当前很多大规模应用的解决方案，但是之前的设计残留着一些问题，包括1）计算关系的模糊性，即对于多个组件而言，他们的计算顺序是未知的。2）服务端算法不确定性，即针对同一种用户行为，可复现性收到怀疑。3）低可重用性，即面临代码或者数据的更改，计算的结果可能会有不同。4）以及服务端不明晰计算依赖与程序关系带来的较慢计算速度，即浪费了过多的时间在I/O上，导致整体性能出现了严重的降低。这些问题导致云设施无法较好地满足租用者的需求。
＞设计
本文实现了一个名为Fixpoint的计算框架，并在此内定义了一个轻量级的数据上计算（computation on data）的语言，以提供在各平台上可用性。本文认为这种以计算为核心的网络设计能够从细粒度的可见性，对于正确性客观的评价以及I/O的分离与对不确定性的描绘这些因素中得到提高表现的方法。
因此，本文提出，云计算较好表现需要网络系统，1）能够追踪计算的关系。2）能确保在同样的用户行为下，服务端提供的数据是相同的。3）允许在数据或者代码发生变化后，仍能允许。4）能够较为灵活地进行任务的读取与放置，加快处理的速度。
除此之外，Fixpoint的设计还遵循以下几种假设：
I/O和计算的分离是可以广泛取得的。
非确定性的内容是可以被复现的
程序的执行不会带来较大的性能开销。
效率的提高对于服务 提供商和用户双方都是有好处的。
在这些假设的基础上，本文设计了在数据上计算的语言Fix，并实现了Fixpoint的原型。
＞评估
本文在8-bit的加法程序上做了简单的实验。该工作一共选取了6个不同的加法函数，3个是简单的函数，另外三个是POSIX的程序。每一个设置均进行了4096次的实验。实验结果表明，在简单的加法操作中，Fixpoint以虚函数调用五倍的开销完成了整体的操作，而在POSIX下，他比传统的方法好上很多，比Linuxvfork快37倍，而当vfork发生在内部rr中时，它的速度约为531倍,该结果如下图。
＞观点
Fixpoint实现了一个较为完整的框架，通过获取数据流的详细信息来进行任务的处理，在网络程序中有着较好的表现。将具体的计算以及计算关系考虑在网络与通信里，是提升整体表现的一个突破点。
Rethinking Cloud-hosted Financial Exchanges for Response Time Fairness
Prateesh Goyal, Ilias Marinos (Microsoft Research); Eashan Gupta (Microsoft Research, UIUC); Chaitnya Bandi (Microsoft Research); Alan Ross (Microsoft); Ranveer Chandra (Microsoft Research)
本文由来自微软和UIUC的研究者合作完成。本文的考虑重点是相应时间的公平性，即对于客户端的响应时间，以一种新的方式进行排序，并根据这种排序依次提供服务。这种设置可以满足市场参与者的公平性需求，缓解网络延迟对于金融交易产生的影响。
＞背景
现代的金融交易服务是通过网络提供的。很多金融交易所会在他们内部的数据中心上运行中心交换服务器（CES），而CES则会产生市场数据并进行分发。市场参与者会根据这些市场数据作出反应。这种交易的利润极大来自于高速反映，因此很多交易者采用各种方法减少网络延迟。因此，对于市场来说，减少网络对于交易的公平性是极为重要的。与此同时，将CES带到云端能在给云服务提供商带来更大的机会的同时，也带来一系列挑战，突出的便是不同延迟带来的公平性，传统的高精度时钟和排序聚合的方式也都有着较大的限制。
＞设计
本文认为限制CES和市场参与者（MP）间的延迟是一个有效的方法，但是难以实现，并且并不必要。而通过获取市场数据并作出决策这种形式，我们也可以根据每个参与者做出反应所需的时间，进行相应的排序工作，从而确保公平性。 整体的架构如下图所示，对于每一个MP而言，他们都和一个RB相关联，而RB则是直接从CES中获取市场信息。每一个MP会根据市场信息作出决策，将交易信息发送给RB，RB会将一定的顺序信息和交易信息绑定，让CES据此进行排序，从而获得公平性。
构建系统需要满足以下假设：
RB和MP在地理位置上很近，因此他们之间的时延不会影响到公平性。
RB和CES间通过可靠数据连接TCP进行通信。
考虑到成熟的备份方案，我们认为CES和RB不会出现实效的问题。
考虑到实际的使用，本为提供了几类公平性分类：
强公平性
所有MP的任务都是按顺序的，且相同市场数据的交易订单会根据响应时间进行排序。
受限的公平性
不要求同一个MP的所有任务都是按顺序相应的。针对某一个相同的市场数据，如果某个MP响应时间在一定的限制内，那么只要比其他MP响应时间更短。就会被先执行。
近似公平性
对于同一个市场数据，只要某个MP响应时间比另一个MP的快一定的范围内，就会被先执行。
＞评估
本文在两种场景做了测试。分别是受限公平下的设置以及RB间有同步时钟的设置。针对RB间拥有的同步时钟的场景，在出现延迟尖峰时，则会从强公平性变为近似公平性，以提供性能保证。模拟试验结果表示，和传统的CloudEx相比，场景1获得了更好的延迟，在一定的响应时间内，获得了完美的公平性，但当响应时间增大时，公平性会降低。而场景2的延迟更大一些，场景2是通过牺牲一定的延迟来获得理想的公平性，同时，他对于延迟峰值的处理比CloudEX更好一些。
＞观点
本文将金融交易的实际场景面临的挑战和网络架构的关系结合在一起，通过逻辑设置而不是对于架构的硬性更改获得了较好的表现，并提出集中公平性的限制方法，来获得较好的表现。关于本文，可以进一步探究公平性的影响以及架构方面的设置，获取更安全的公平性。
Load Balancers Need In-Band Feedback Control
Bhavana Vannarth Shobhana, Srinivas Narayana, Badri Nath (Rutgers University)
这篇文章是由来自罗格斯大学的研究者完成的，该文章的着眼点是精细化的服务下，如何通过负载均衡来提高服务的性能与可用性。本文认为负载均衡需要调整请求路由以适应快速变化的服务器性能来主动优化应用程序响应时间，因此提出使用带内反馈控制的方法来优化端到端的延迟。
＞背景
负载均衡（LB）是将负载均匀分布在不同服务器，以获得较好的服务表现和服务可用性的技术，这种技术能避免大批量的请求集中在某几台服务器，造成服务质量的降低。但是，随着微服务、无服务与机架规模计算的出现，在较小的时间维度上也会出现严重的服务降级问题，与此同时，传统的一些方法例如请求重复、需求驱动的规模调整往往不能起到应有的作用。
＞设计 现在的网络设计中有着以下几种问题：
缺乏对于网络时延细粒度的探究
现在的微服务等应用涉及了多个服务器的响应，而最慢的微服务是整体服务响应时间的瓶颈。而相比较与执行较快但有着阻塞路径的服务器，选择较慢但路径负载较低的服务器可能会更好。
服务器性能的可变性
随着时间的推移，服务器的性能会发生变化，典型的方法耗费了太多的时间。
需要应用的修改
获取带外的信息来调整请求路由也许很有效，但对于应用程序的修改会带来极大的挑战性。
无法获取响应信息
很多响应信息会绕过LB，导致LB无法根据响应信息进行调整。 为了解决这些问题，本文设计了一个带内控制系统，以达到：
将网络和服务器处理延迟纳入请求路由决策。
对服务器性能变化做出快速反应。
使用纯本地观察，避免需要修改应用程序或外部存储。
只观察从客户端到服务器的一个方向的流量。
同时能满足标准LB要求。
优化端到端的响应延迟是整体性能提升的重点。而在LB场景下分为4部分，分别是：
用户端到LB的时延。
LB到服务端的时延。
服务端到LB的时延。
LB到客户端的时延。
很明显，评价性能指标，可以从LB和服务端的往返时延来分析。当然，3）的时延很有可能无法观测到。因此，我们需要分析相应触发的新的传输，以判断往返的时延, 如下图。
除此之外，在测量的过程中，会有这两个问题，一个是LB测量的时间和响应时延不同，另一个是LB不清楚是被触发的包是被哪一个触发的，如下图。
因此，对于时间的测量，一方面要计算出正确的时间，另一方面可以通过传输的间隔来识别被触发的传输。 在LB识别不同的负载LB后，则会执行一个简单的负载均衡算法，将最拥塞的服务器上的部分负载均分到其他的服务器上。
＞评估
本文做了简单的时延，实验结果如下图所示。从实验结果可以看到，与传统的方法相比，该方法在后续仍保持着较低的延迟。
＞个人观点
本文以带内控制的思想进行负载均衡的调度，在较长时间的维度上仍能获得较好的表现。可以考虑将应用的场景抽象成协同流等的方式，进一步提高服务的性能。
编辑：黄飞
工商网监
评论