姓名：李浩然
学号：16030410020
转自：http://blog.csdn.net/dev_csdn/article/details/78655483（有删改）
【嵌牛导读】：无服务器是这几年新提出的一种概念，作者在本文介绍了一下无服务器架构是如何在CDN Edge中进行应用的，如果你对无服务器架构有兴趣，那就赶紧阅读本文吧！以下为译文
【嵌牛鼻子】：无服务器架构、去中心化、云区域、无状态计算、脏数据、SRDT
【嵌牛提问】：无服务器架构的应用有哪些？去中心化有什么好处？基于SRDT的解决方案有什么？
【嵌牛正文】：无服务器架构（Serverless）是一种新兴的基础设施即服务（IaaS）解决方案，以后的互联网可能会随处可见。2014年AmazonLambda掀起了无服务器架构的浪潮，几年之后，无服务器架构已经扩展到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系统，他们有缺点(探索之后)，但总的来说比基于共识的解决方案要更好。