更快的网络+成本更低的消息=>微服务=>函数=>边缘计算

在德国柏林举办的microXchg 2017大会上，亚马逊公司技术专家Adrian Cockroft发表了一个前瞻性的演讲。Adrian Cockroft是Cloud Native和微服务架构的技术布道者。他的演讲报告名为：“microXchg 2017：浓缩微服务功能”，在这个报告中阐述了微服务的未来。这个低调的报告来自Adrian多年的经验之谈。

Adrian给出了一个令人信服的例子，即在同样的技术驱动力情况下，更快的网络和成本更低的消息传递，将会推动微服务的发展。

毫无疑问，人们听到有关Serverless的一些情况。但Adrian以一种有趣的方式进行开发，他在追踪架构如何随时间的推移而演变。以下了解一下这个报告的细节。

未来的函数是什么?Adrian谈到将Lambda函数推向了边缘计算。这个话题让人颇感兴趣。

(1)数据中心消失。Lambda函数将不再运行在AWS上面，其代码放置在使用CDN端点的客户的附近。现在，企业在边缘网络有一个完整的分布式，可以低延迟在客户端运行代码。企业可以构建架构，部分位于数据中心，部分位于客户端。因为在AWS区域，所以当然是围绕着Lambda函数进行构建。AWS公司也在采用Greengrass和Snowball Edge窥探未来会变成什么样子。

(2)这里有一个隐藏的局势。一旦将代码放在边缘计算，就会违反Lambda的两个关键假设：函数是使用可扩展的后端服务组合和消息传递低延迟。边缘计算将有一个高延迟路径返回到服务中的数据中心，那么如何在边缘网路创建基于分布式应用程序的函数?边缘计算是否支持一个以更少的信息的传统架构返回到一体化架构的核心?

还是边缘计算需要完全不同的东西?这里有一个想法可能完全不一样，看起来可能是这样的：Datane是一个新的CRDT数据库，让用户将做坏的事情分布数据。

现在让我们展望一下未来，首先回顾一下过去：

从单片机到微型设备再发展到功能

以往

•10年前。

•大部分为1gbps网络带宽。

•当时采用的最先进的技术是连接到大型关系数据库的单片Java应用程序。

•使用交换XML消息的Web服务分解系统。

•通过慢速网络发送XML的开销很高。解析XML很慢。

•由于Web服务速度较慢，因此最终结构的特征是大型服务器之间交换的消息数量相对较少。

•系统的缓慢意味着请求在回复前不能超过两到三个服务，因此很难将整体分解成较小的服务。

现在

•网络带宽为25 gbps。

•消息是Avro，gRPC等，其效率比XML高出100倍。

•将更快的网络与更好的消息格式相结合，意味着在服务器之间发送消息的效率提高了100倍至1000倍。

•现在有可能将架构分解成许多较小的服务，因为可以进行100个微服务调用，并在延迟范围内返回回复。

•由于技术变革，微型服务成为可能。一个系统可以分解成更小的服务，每个服务都有一个单一的责任。

•现在可以通过将微服务进一步分解成组成这些服务的单独功能。

•有能力将所有这些功能连接在一起，因为信息成本已经变得更低。

交付代码的时代

你想放多少代码?构建和提供代码需要多长时间?

(1)以往：

•转到供应商，购买机器，将其放入数据中心，然后将代码交付给它。

•提供代码是一个手动复杂的项目，它们都是独立的。

•有一些自动化，但通常是高度人工发布的程序。

•每6个月或一年发布一次，这是一个复杂的过程，需要进行大量测试才能确保一切正常。

(2)DevOps的第一波-敏捷时代

•代码交付加快，每两周发布一次。

•需要自动化，以便能够快速发布代码。

•第一波DevOps。自动化已经到位，以便更快地完成工作。Chef和Puppet被用来使用新的代码来升级一系列机器。

(3)DevOps的第二波 - 云计算，API，开发者驱动

•还有一个问题：如果用户需要更多的机器怎么办?

•这就是采用云计算的原因所在：建立弹性系统，提供按需配置的能力。不使用机器时可能缩小，按需支付。

•云计算在开发和操作之间放置API。

•开发人员使用平台API来完成任务。

•开发人员能够通过自动化尽可能地推动操作。

•使用API +弹性+开发者驱动，可以创建Blue-Green部署：

o新的软件版本在新的一组机器上推出。

o新软件并列运行。

o当验证新的构建工作时，旧机器被终止。

o不需要使用Chef或Puppet。 Netflix架构从来不需要它们。只需部署新的东西，并从头开始创建东西，而不是升级。

o这是Immutable 基础设施的理念。

•这让很多事情加快速度。因为交付费用的时间不是6个月，而是一天或几个小时。

•需要聚集的人数减少。创建个人微服务的个人开发人员可以根据需要使用自动化来推出。

容器周围的组件标准化

•这个阶段是在几年前开始的。

•当部署一个新的自动缩放组的实例时，需要几分钟才能完全启动，并按小时付款。部署可能需要几分钟到几个小时。

•适用于日间流通模式，白天忙碌，夜晚安静，预测这些模式和自动调整比较容易。

•网站受到电视广告驱动的大量负载影响时会发生什么?用户需要快速响应，但不知道负载会有多大。

•处理尖峰负载的第一步是转移到容器。容器大约在一秒钟内启动，所以部署时间已经从几分钟减少到几秒钟。

•使用容器可以构建更精细的微服务器。

•容器开始标准化。每个人都运行相同的Redis或Nginx容器，取决于DockerHub上最新的容器。

•采用标准化调试良好的服务在容器中取代自定义组件。因此不需要数百人调试的组件从头开始编辑软件?

Serverless的第一阶段

•这个阶段是两年前开始的。

•编写代码，但在被调用之前不会部署。它只是在那里准备部署，但不能在任何地方运行。当代码中的请求出现时，必须进行部署和启动。

•Javascript或Python的启动时间相当快，达到了100毫秒。

•一旦预热，将在十几毫秒内启动。

•停止使用时，用户可以停止支付费用。

•在几秒钟内部署能力，但需要部署的机器，即可在10秒或100毫秒内部署，并以100毫秒的单位付费。

•如果用户每秒运行一百万个请求，则使用容器，因为计算机始终需要启动并运行。有很多工作负载往来的流量很大。

•减少内存使用。在微服务器或整体中有很多不同的功能。这些功能中的一些调用并不频繁，即使没有使用，它们仍然使用内存。通过将系统分解为功能，只有在使用时才占用内存，所以平均的内存占用量将会下降。

•CPU的成本下降，因为用户只需支付使用的费用(以100毫秒为单位)。

•将代码投入生产中需要多长时间?答案是100毫秒。

•构建块并不是容器，它们是服务，如DynamoDB。这些服务很少使用。

•现在可以在很短的时间内开发应用程序。在亚马逊re：Invent，Hackathon的团队的四个人能够在十二个小时内构建一个完整的复杂系统。它们不仅仅是原型，可以被部署在规模生产中，因为它们是建立在Lambda之上的，所有的组都使用Lambda。

•快速构建时间是一个有趣的新功能。从数据中心移动应用程序时，用户可以考虑使用Lambda从头开始重写，而不必将原有的应用程序解锁。

Serverless的第二阶段：事件驱动的基础设施

云基础设施本身开始发布可被Lambda函数消耗的事件。例如，创建一个新的实例可以触发一个Lambda函数。

•这使得自动化水平达到了新的水平。这是用户基础设施的新的bash脚本，只有作为事件驱动的Lambda函数的脚本。

•这是一个新的事件驱动的基础设施，事件可以链接在一起。例如：当有新机器使用Lambda函数来附加卷时;或者在实例死机之后进行清理。

Serverless的第三阶段：边缘的Lambda函数

•人们还不了解Radical departure。

•数据中心消失。函数不在AWS区域运行，代码位于CDN端点处的CDN附近。

•现在，使用与其他地方相同的Lambda编程模型，可以从客户运行代码的方式全面分布，低延迟，毫秒级(注意目前在AWS边缘网络所做的很有限)。

•边缘计算与物联网相衔接。如果用户想编程这个东西，那么Greengrass项目让其可以在该项目中放置一个功能。

•现在，可以构建部分位于数据中心的架构，部分位于客户端。

•Snowball边缘设备是一个重达50磅的设备，里面有Lambda以及100TB的存储空间。可以在用户的控制台上在云端编程，并且在现场交付盒子。微服务可以在飞机，船舶，通信发射塔或商店中分发。

•功能可以使用相同的编程模型推送。

组织的影响

•高层管理人员的问题几乎都是人员管理的问题。他们可以改变的是雇用人员，如何组织，以及他们的预算。企业可以告诉他们使用某种技术，但他们应该自己来选择。

•组织团体的新方法。如果想要一个特定的架构，你需要做一个反向操作：设置组大概是用户想要的分区，并假定这些组将建立彼此通话的服务。

•新的工作方式。在新的世界里，需要建立一个开发人员和产品经理构成的团队。这是亚马逊能够扩大其工程组织的原因之一。这些小群体需要被赋予自由和独立来建立某种东西。

•大多数有微服务问题的人会发现，有些团队没有完成的责任，在一个地方做了一些工作，就会转交给另一个小组。

•如果用户有团队分散在世界各地，每个团队都应该完全拥有一个微服务器并自行更改。用户应该能够完全拥有和修改微服务器，而不会超出时区。希望都在一个房间办公，或至少在同一个聊天室中会话。

•用户正在建立的是一个可以高度信任的团队，这是关键。很多大型组织本来就是低信任的组织。而当每个人都彼此相识时，就相互信任，组织可以非常有效地操作。

•组之间的低信任接口是API和SLA。这是为了使用像Google地图这样的服务或在同一个房间中实施另一个微服务的团队。这需要团队具有高度的信任。

担心AWS锁定?

•不要担心。用户表示在Lambda上构建速度非常快，用户应该只需要构建它，而不用担心它是一个仅限于AWS的功能。

•如果需要迁移，也只需一个星期的时间。

•Lambda函数封装了业务逻辑的核心和业务逻辑，并且相当容易进行迁移。

•不要担心再次使用，因为代码更容易更换。