penghuima

NativeLB

### 分布式应用的需求 在文章中 Bilgin Ibryam 首先总结了现代分布式应用的四大需求: 生命周期（Lifecycle）、网络（Networking）、状态（State）、捆绑（Binding）  ### 传统中间件限制 然后列举了传统解决方案如企业服务总线（ESB）及其变体在现代分布式应用四大需求方面的限制 > ESB虽然可以提供良好的功能集，但ESB的主要挑战是单体架构以及业务逻辑和平台之间紧密的技术耦合 #### 生命周期（Lifecycle） 在传统的中间件中，通常只有一个受支持的语言运行时（例如 Java），它规定了软件的打包方式、可用的库、需要维护的频率等。业务服务必须使用这些库，使其与平台（平台编写语言与业务服务是一样的）紧密结合。在生产实践中，这导致服务和平台的升级必须要协调，常规服务与平台的发布不能够独立进行 #### 网络（Networking） 尽管传统中间件具有与内部和外部服务交互的高级功能，但它有一些主要缺点，网络功能集中于一种主要语言及其相关技术，更重要的是，网络问题和语义也深深地刻在业务服务中。有一些抽象能力的库来解决网络问题，但是该库的抽象“泄漏”到了服务的编程模型、交换模式、错误处理语义以及库本身中。意味着该库与业务逻辑耦合在一个实现中。 #### 状态（State） 为了进行可靠的服务编排、业务流程管理等，需要对数据库进行集群化和弹性，但主要约束在于与状态交互的库和接口没有完全抽象出来，也没有与服务运行时分离。通常，这些库必须配置有数据库详细信息，并且它们存在于服务中，从而将语义和依赖关系泄漏到应用程序域中。 #### 捆绑（Binding） 使用集成中间件的一个主要原因是能够使用不同的协议、数据格式和消息交换模式连接到其它各种系统。但是，这些连接器必须与应用程序一起使用，这意味着必须将这些依赖与业务逻辑一起进行更新和维护 **企业服务总线（ESB）无法满足现代应用快速扩展和维护更改的能力，这也是微服务架构出现及解决的问题** ### 未来架构的趋势...

在介绍完 Mecha/Multiple Runtime 的理念之后，我们来看看目前微软新推出来的 [Dapr](https://github.com/dapr/dapr) 项目 —— 这应该是业界第一个 Multiple Runtime 的开源实践项目。

这篇文章的主要贡献有： - 将 Serverless 中的 Keep-alive 策略类比于缓存，并证明了两者之间的等价性，且基于缓存领域中的算法 Greedy-Dual-Size-Frequency 提出了Greedy-Dual Keep-Alive Policy 策略，来减少冷启动的开销。 - 缓存中诸如 reuse distances 、hit-ratio curves 等概念也被应用于 Serverless 服务资源配置，动态调整服务器资源（因为工作负载是动态变化的）。

#### Keep-alive Tradeoffs 为了理解函数冷启动开销，我们先分析一个用 TensorFlow 框架做机器学习推理的函数被调用的时间线。  图中显示了从函数被调用到实际函数执行整个期间冷启动开销的主要来源： - OpenWhisk 先检查函数是否可以由其维护的 warm 容器池提供容器运行环境。 - 如果没有找到对应容器，则需要启动新容器，并初始化函数的运行时（如OpenWhisk和Python运行时初始化）。 - 应用程序运行需要的特定的显式初始化（一些库函数以及数据依赖的下载）。如在机器学习函数中，可能需要下载神经网络模型和一些python包。 函数初始化（initialization）阶段会产生不可忽略的函数整体执行延迟时间。因此减少函数启动开销是无服务器计算中的关键挑战。为了减少冷启动开销（图中红色和黄色部分），最常见的技术就是函数执行完毕后，将**运行该函数的容器**保持一段时间的 warm 状态，这样将来该函数再次调用，就可以避免冷启动开销。虽然 keep-alive策略可以减少整体函数冷启动开销，但 keep-alive 会消耗物理服务器上的资源，也会降低整个系统的效率。因此需要开发一类新的资源管理技术来优化 keep-alive策略。实现容器保持 warm 状态所带来的资源消耗和系统整体效率之间的权衡，从而有效地执行不同的FaaS工作负载。 Keep-Alive的主要目标是根据函数的特性，为每个函数设置不同的keep alive 时间，减少初始化和冷启动开销。在本论文中，作者使用以下指标去指定 keep...

#### Caching-based Keep-alive Policies 本论文的新颖之处在于它证明了Keep-alive 策略等价于缓存 ”The central insight of this paper is that keeping functions alive is equivalent to keeping objects in a cache“： - 保持函数处于活动状态可以减少函数响应延迟 == 将一个对象缓存后可以减少访问延迟； -...

#### SERVER PROVISIONING POLICIES 资源配置即确定能够用于处理FaaS工作负载的服务器资源大小和容量。对于一定的函数工作负载，给服务器分配过多的资源，显然 keep-alive 缓存可以减少冷启动开销，提高性能，但过度的资源提供也意味着服务器资源利用不足，不足的服务器资源分配又会造成 FaaS 性能下降。资源配置的根本挑战在于性能和资源利用率之间的权衡。 > 注意：本论文的服务器资源配置就等同于缓存大小设置 此外，函数的工作负载可以是动态的，因此资源配置必须是弹性的，能够根据负载动态的增加或减少。因此，本文提出了一个静态配置策略，用来确定一个给定函数工作负载的服务器资源配置；一个动态配置策略，用来弹性伸缩服务器资源配置以处理随时间动态变化的函数工作负载。 下面具体介绍一下静态服务器资源配置策略 ##### Static Provisioning 在前文章节中，作者已经做了 keep-alive policy 和 cache eviction 的类比，在本章节中作者将进一步扩展缓存概念的类比，并提出了一种静态配置策略来优化资源配置，实现成本和性能之间的权衡与折衷。 在缓存领域，经常使用命中率曲线（hit ratio curve）来设置能达到一定访问命中率预期的缓存大小，并由复用距离（reuse distance）来求解构造命中率曲线。将缓存这些概念类比到Serverless领域，**serverless 函数的性能和资源可用性之间权衡可以通过命中率曲线来理解和建模**。一般会选择命中率曲线图中的**拐点**（inflection point）所对应的横坐标缓存的值作为服务器资源的配置方案。 在缓存领域，复用距离（reuse...

2012 年，云基础设施服务提供商 [Iron](https://www.iron.io/) 的副总裁 Ken Formm 在文章 Why The Future of Software and Apps is Serverless 中首次提出了 Serverless 的概念，为云中运行的应用程序描述了一种全新的系统体系架构。2014年Amazon发布的 AWS Lambda 让 Serverless 这一范式落地并商业化。截至2017年各大云厂商基本上都已经在Serverless进行了基础的布局，尤其是国内的几大云厂商，也都先后在这一年迈入“Serverless时代”。 当前，Serverless 的热度可谓如日中天，和之前的 Kubernetes 相比有过之而无不及。Serverless 受到了各大云计算厂商的推崇和追捧，生怕错失了新一波云计算和服务变革的潮流。 >...

前言描述 在 FAAS 工作流中，一组函数通过交互及数据交换实现应用程序的逻辑。但由于 FAAS 本身的无状态特性，需要为函数之间的状态通信付出昂贵的时间延迟（一般做法是一个函数的状态存入第三方云存储产品，然后另一个函数再访问云存储产品获取上一个函数的状态），且当前各FAAS平台的处理方式是将一个工作流实例中每一个函数分别部署在独立的容器中。这种部署方式带来的后果就是需要忍受函数间跨容器复制瞬时函数状态的交互延迟。而且有的平台会限制函数间直接管道通信的状态大小（比如几十K),像机器学习这类数据密集型应用（处理的图像集大小上几十M级别），就不得不通过云存储服务（如 Amzzon S3）实现函数间的状态传递。

论文主要贡献 在这篇论文中，Faastlane 努力做到在一个容器内的单个进程内以线程的形式执行工作流。通过共享进程内存地址空间来最大限度地减少了函数间地状态传输延迟。即通过最简单的 load/store 指令来实现数据共享。 _但这种做法会带来新的挑战 ：_ - ​如何实现线程级别的隔离，来保护敏感数据 - 函数的并行执行又如何实现 _应对挑战的解决办法：_ - 众所周知，进程级别的隔离已经有前人做了大量研究，在本文中作者通过应用 Intel Memory Protection Keys(MPK) 硬件技术实现了线程级隔离。 - 在工作流中，有一种结构是允许并行执行实例中的多个函数，然而一些FAAS应用程序是由一些解释型语言如 Nodejs 、Python等编写的，这类语言存在全局解释器锁（global interpreter lock (GIL)），从而阻碍函数的并发执行。因此 Faastlane 当检测工作流存在并发执行的机会，就会在同一容器内 fork process...