Serverless加CRDT掀起的新浪潮_基于crdt的-CSDN博客

原文：Birth Of The NearCloud： Serverless + CRDTs @ Edge Is The New Next Thing
翻译：Vincent

译者注：无服务器是这几年新提出的一种概念，作者在本文介绍了一下无服务器架构是如何在CDN Edge中进行应用的，如果你对无服务器架构有兴趣，那就赶紧阅读本文吧！以下为译文。

与Amazon Lambda相比，Kuhiro的速度快了10倍

本文是Kuhirō创始人兼首席技术官Russell Sullivan的一篇客座文章。

无服务器架构（Serverless）是一种新兴的基础设施即服务（IaaS）解决方案，以后的互联网可能会随处可见。2014年Amazon Lambda掀起了无服务器架构的浪潮，几年之后，无服务器架构已经扩展到CDN-Edge，现在也跨越了最后一道鸿沟，渗入到了移动，物联网和存储几大领域。

创业并出售了一个 NoSQL 公司的这段经历让我意识到目前的计算还仅限于数据中心或设备：这两者之间存在着一片很大的空白区。因此，我与几位小伙伴们开始了合作，创立了Kuhirō公司：一家致力于逐渐将云端推向互联网边缘，逐步创建靠近终端用户的分散式云（也就是NearCloud）的公司。

NearCloud 的基础是计算和数据，于是便从构建一个有状态的SAE系统开始，该系统将成为后续产品（例如ML推理，实时分析等）的基础模型。在 CDN Edge将客户业务逻辑作为读取和写入实时客户数据的函数进行运行。我们致力于建立一个基于CRDT的数据层。Kuhirō使客户能够将其应用程序的动态延迟敏感部分从云端移动到边缘，从而变成全局性的实时应用。

无服务器架构在Edge框架中的应用

就物理方面而言，SAE系统和内容传输网络(CDNs)非常相似：将那些称之为“入网点”（PoPs）的小型数据中心放置于全国（或全球）战略位置，从而尽可能减少延迟带给用户的干扰。SAE客户将url中的域名转换为SAE供应商的域名，这样用户的web请求就会发送到附近的SAE PoP。

仅在美国，SAE系统就可以扩展到30 万个基站，99% 的人口距离他们附近的基站只有几公里。

去中心化的好处

一般来说，去中心化会给带宽、延迟和健壮性带来很多优势。为了说明这些优势，让我们先看一个去中心化系统的示例：Amazon的仓储中心。正是由于这些巨大的建筑，所以Amazo基本上可以在两天之内将货物交付到用户手中：因为只需要将货物从分散的物理地点直接运过来就可以了。

去中心化的好处：

延迟：Amazon Prime旨在实现货物必须在两天内送达：延迟确定了成败。
带宽：仓储中心越多，每个仓储中心需要处理的货品就越少，Prime 会员规模就可以更好地伸缩。
健壮性：如果硅谷的仓储中心被地震摧毁了，订单可以让其他中心（斯托克顿，特蕾西，Patterson)接管。

SAE系统功能就和Amazon的这种方式非常相似：

延迟：Edge PoP放置区域尽可能地接近用户，实现了低延迟。
带宽：每个 PoP 只负责处理一部分用户，不需要将请求路由到中心系统：负载是分布式的，可以更好地伸缩。
健壮性：如果被地震摧毁，请求可以立即转移到附近的PoP 。

所有的互联网应用都受益于去中心化

去中心化的三个主要优势：延迟、带宽和健壮性在很多互联网垂直领域(如网络、手机、游戏、广告、AR / VR、地图等)是非常有价值的。

延迟才能决定成败，这是以前的网络说法，同样也适用于现代网络应用。通过在许多不同的web/移动应用(1，2，3)改善用户体验，减少延迟，这样就可以增加收入。延迟越低，这样才更有竞争力，尤其是在那些非常关注延迟的垂直领域(例如游戏、广告、地图)。在不远的将来，某些垂直应用(AR/VR，无人驾驶)只有使用低延迟的NearClouds才能真正实现。

某些公司不想在负载达到高峰或者DDoS攻击发生时，或者由于自然灾害以及人为错误发生问题时，还需要去考虑如何对系统的动态部进行操作和扩展，这种时候，带宽和健壮性的优势就显示出来了。

利用NearCloud进行重要的增量改进/升级，这样做几乎可以让所有的互联网应用都能受益。

Serverless 为 Edge 带来多租户和伸缩性

NearCloud可以带来的优势已经讨论过了，接下来让我们看看为什么Serverless才是正确的基础设施的选择。先从比较Edge和Cloud之间存在哪些物理差异开始。

单个云区域的服务器规模可能超过100000台，而Edge PoP规模则是非常小的（假设10到100台服务器）。PoP硬件资源远不如云资源。

假设现在需要在10台机器上为 1 万个客户提供IaaS 服务。你能给每位客户一个虚拟机吗？不可能的……甚至连私有的容器都没办法提供。所以你会想到选择一个较小的单位计算：FaaS（也就是 Serverless）。那么这样可以把 1 万个用户函数部署在 10 台服务器上吗？这个是可以做到的，甚至可以部署更多的函数。

这样的话Serverless 与 Edge PoP 的配合的真是天衣无缝了。

SAE的状态: 无状态持续运行

那么SAE现在到底发展到了哪个阶段?当前又处于什么状态?作为一个新兴领域(2016年才上市)，目前能提供SAE的公司数量非常少，但是却是在逐渐增长。目前市面上能提供这种服务的，最有趣的当属Cloudflare的Workers 和Amazon的Lambda@Edge.

这两者都非常安全，并且都以无服务器的形式提供了最少的IaaS@Edge，但它们在灵活性和性能方面有所不同。

无状态计算寸步难行

不幸的是无论是Cloudflare Workers还是Lambda@Edge提供的动态数据选项，都只是提供计算功能。缺乏动态数据能力（AKA无状态）使得SAE以基于客户端状态或原始状态重写请求/响应的功能受到了限制。

与普通编程相比，无状态计算更类似于网络路由：对智能负载平衡和请求/响应重写有用，但不多。

想象一下，假设Amazon将其所有产品只存储在一个中心位置，仓储中心只负责重写收到的订单或重新包装即将交付的产品：如果这样，Amazon Prime根本就无法实现，我们又会回到以前的时代，只能在几周时间内拿到网上订单，而不是现在的几天时间。

数据冲突导致边缘数据出现脏数据

SAE产品目前还是无状态的，其原因是为许多（〜100）地理位置较远的PoP添加数据层，复杂性非常高。

理想的情况下，我们只需要在每个边缘节点中添加一个数据库，那么边缘函数就会在这个本地数据库上面进行读/写操作，并将其复制到其他节点的数据库中。这种方法会带来一个问题，这个问题也是分布式系统里面很经典的问题：一旦对集中式的数据存储进行分割，复制到其它多个分散式进行数据存储，毫无因为就会引起数据冲突，分散式节点之间的地理距离越远，数据冲突发生的频率就越高。

分散数据主要有两种方法：基于共识的和基于CRDT的。两者各有优缺点，在分布式数据世界里面也都有各自的优势。下面的内容会对这两种方法进行分析比对。

Edge 复制

现在我们将开始深入研究通过检查SAE系统中复制数据的唯一性，从而为SAE添加一个数据层。

当在SAE中单个PoP中的数据被修改时，这个数据会被复制到哪里呢？是复制到所有的PoP，还是仅仅只是PoP的子集，或压根就不会复制到其它POP*？答案取决于问题中的那些数据…所以总的来说答案是需要支持这三种数据流的。

*需要注意的是出于由于需要备份，因此所有的修改也会复制到某个(集中)目的地。

可以将SAE的复制类比为频谱，开始的时候是只复制某个PoP中的单个用户，结束的时候是复制所有PoP之间的用户。

单用户复制流程很简单：数据在PoP上创建并备份。全用户复制流程是一个持续的多向点对点数据广播（加上备份）。在频谱中间的复制的例子是组数据，例如在线的用户数据组（例如足球队）。组数据是在少量PoP上创作的，并在它们之间进行复制。

在错误条件类比分解一些：单用户比上面的描述流动变得更加复杂。单用户可以移动到另一个流行在永久和颞流行失败以及流量控制的目的。出于这个原因，单用户流在错误条件可能需要同时从多个弹出复制到多个持久性有机污染物。(即组流)。

更糟的是，所有用户流在修改率高可以成为自己造成的DDoS攻击。应对这种风险，高容量的所有用户流可以交易延迟的性能和采用coalesce-and-batch方法，美丽的鳞片。

Edge 的数据复制问题非常独特，与已有的数据存储复制流程不太一样，所以需要新的技术来支持它。

基于 CRDT 的解决方案

幸运的是Edge 的状态复杂性和特殊性可以通过数据结构和CRDTs进行解决。CRDTs允许参与者自主修改数据，并以零共识的方式自动解决数据冲突。CRDT 的这些特点（自主性、零共识、自动解决冲突）是 SAE 平台实现低延迟的基础要素。

自主性意味着 PoP 可以在本地处理请求并快速做出响应，不需要与千里之外的其他 PoP 达成共识。PoP 的自主性和并行修改数据会导致数据冲突，而 CRDT 可以通过多种数据结构自动解决数据冲突，并提供最终强一致性.

CRDTs更适合低延迟SAE系统，他们有缺点(探索之后)，但总的来说比基于共识的解决方案要更好。

基于共识的解决方案太慢了

Spanner 是目前最为先进的基于共识的数据层解决方案，Spanner 的论文中提到：

客户端和区域需要处于网络延迟低于 1 毫秒的数据中心里。

Spanner 并不适合用于长距离节点，也无法实现低延迟的并行提交。Spanner 使用的是两阶段提交，每个事务需要穿行网络两次。美国东海岸到美国西海岸一个来回需要 100 毫秒，那么两阶段提交需要 200 毫秒，这对于大部分应用程序来说都太慢了。

购物 Demo 演示

已经介绍了足够多的理论知识，接下来看一个具体的例子，了解一下应用程序是如何在NearCloud上面运行的。写一个简单的购物演示：

这是一个正在运行的购物演示的链接，点击这个链接，可以发现它正在运行。

功能很简单：添加产品，客户注册/登录，浏览产品/品牌，添加产品到购物车，购买产品。源代码就在这里，这个代码不值得研究，就是简单的Node.js代码直接调用DocumentDB。

这是添加产品到用户购物车的代码片段：

function add_product_to_user_cart(username， product_id， callback) {
   // left-push product_id into user’s cart.items[]

   var update = {operation ： "INSERT"， values ： ["items"， 0， product_id]};
   var params = {TableName ： "cart"，
                 Key       ： {username ： username}，
                 Updates   ： [update]};
   Data.update(params， callback);

}

可以看出代码很标准，没有CRDT调用的原语，CRDT的功能被抽象出来，在数据层中进行实现。整个演示的数据建模只使用JSON数据类型：{number，string，object，array}。

进入Kuhirō API时会遵从其他云产品，这方面我们投入了大量精力。我们坚持认为无服务器架构作为技术应该尽可能不与供应商做绑定，所以我们的产品在云提供商和Kuhirō之间可以很轻松的切换。

Kuhirō兼容的代码、配置和数据与Amazonλ和DynamoDB水平。相同的演示购物代码运行在λ。这是一个链接演示，这是生活，点击的东西。它的字面意思相同的代码包括调用数据层。来回切换从λ+ DynamoDB Kuhirō可能通过一个命令行工具(一旦注册完成)。

这里有一个EC2 demo的屏幕截图：

注意两个截图之间的持续时间差异。可以发现，Kuhirō版本比EC2要快得多。

Kuhirō的延迟性降低了5-10倍

demo展示了最终运行客户业务逻辑的好处，对于西海岸的用户来说，Kuhirō的运行速度比Lambda快5-10倍，东海岸的用户更像2-4倍（Lambda正在使用我们的east-1 in VA ），而国际用户则高达50倍以上。除了运行在全球各地的多个PoP之外，我们还致力于将整个堆栈中的延迟尽可能的降低。

减少延迟已被证明对增加收入有直接影响(1，2，3，4，5)，对于应用程序来说，Kuhirō则代表了一种新的工具，这种工具可以加快应用的速度，提高用户体验,并将潜在收入进行最大化。

Kuhirō的健壮性让人大为称赞

另一个大约一年前做的demo(视频)展示了Kuhirō数据层的健壮性。视频大约12分钟的时候，我们对数据层做了“一些糟糕的坏事情”：我们开始随机杀死不同数据中心的不同节点，然后再杀死整个数据中心，然后恢复原状，这是真的非常混乱。视频直观地显示了基于CRDT系统的鲁棒性是多么可笑。

不管是日常的机器故障，不太常发生的数据中心级停机，还是发生了DDoS攻击，这种健壮性都会带来很多好处。

Kuhirō处于（隐形）测试阶段，可以使用NearCloud系统的测试版客户端。如果你有兴趣成为Kuhiro的测试用户或只是想成为NearCloud的极客，那么请给我发邮件吧，我的邮箱是russ@kuhiro.com.

12月16日，来自腾讯、华为、思科、蘑菇街、58同城、当当等6位顶级互联网公司的一线开发者，将为我们带来Container技术的最新实践成果分享，议题囊括过往经验总结、当前容器云架构实现、微服务框架演进、也有对新技术ServiceMesh的第一手实践分享，欢迎参加：http://edu.csdn.net/huiyiCourse/series_detail/73
这里写图片描述