数人云|使微服务、容器趋向完美——Serverless架构你应当知道的二三事

无服务架构（Serverless）和DevOps、SRE、微服务、容器等一样，是最近两年比较新兴的概念，数人云之前给大家分享过《Serverless用这5大优势，挽救了后来7亿用户的Instagram》，今天再来探讨下Serverless和容器与微服务之间的互补与碰撞。

近年来很多人在讨论云计算时都会提到容器，因为其几乎完美得解决了DevOps所面临的挑战。

本文将阐述Serverless的解决方案，它与传统和容器化的应用的不同之处。

一个典型的N层Web应用是由前端、公开的Web服务器组成；后端：高度隔离的数据层以及中间件层。

微服务

先来说说微服务，在微服务的模式下，可以无需使用服务器去呈现所有的用户界面，例如，处理所有的业务对象和逻辑，只需一个应用即可创建多个应用编程接口或API。

这是以酒店为应用场景的一种基于微服务的现代WEB和移动应用的方法。

假设经营了一家连锁酒店，需要面向公众的服务，允许用户登录到网站预定房间，通过第三方邮件列表进行邮件促销，以及提供WEB和移动应用页面的一般方式。

可以创建处理用户数据请求的API，这里用白色显示，与其拥有传统的服务器呈现的用户界面，还可以创建单个页面WEB应用和使用该API的移动应用，以获取所需的信息去适应该平台的方式提供信息。

这使得作者的工作量去除了整个开发链：设计人员和前端开发人员可以让界面看起来更漂亮，并且能够高效得执行，而后端团队只需要专注于创建一个单一的方法去为他们提供相同的信息。

只需要将代码和其依赖项打包到一个容器中，然后即可在任何地方运行——因为它们通常很小，可以将大量的容器装到一台机器上——TechCrunch。

容器

从业务的角度讲，能有什么原因不喜欢容器呢？答案是，没有。

容器之所以伟大，是因为它们可以让我们打包所有的东西——操作系统、代码、服务、以及应用需要工作的所有东西并且运行它们。这不仅显著得简化了DevOps模式，节约了大量的人工和时间的成本，而且它还为我们提供了如何部署解决方案的选项，其中许多现在都是免费的特定供应商。

另外，正如TechCrunch所指出的，可以在一台主机上运行几个容器，这意味着浪费的资源要少的多，反过来又浪费了成本。

所以可以用容器来提供这些微服务，也就是说，用户接口API可以在容器A中运行，而在容器B中预定API，以及在容器C中的电子邮件通讯API，容器D中的身份验证API。

容器使得上面所提到的具有高度可移植性，如果构建的得当，高度可伸缩，甚至可以很好得适应Bug。

DevOps和容器

从DevOps的角度去看，仍旧是没有理由不喜欢容器技术。其具有的优势有：

1. 可快速地进行部署。
2. 在一些基本配置中，可以安装所需的应用和服务，配置环境以及支持应用，并未整个流程编写脚本。
3. 技术团队无需花费一整天的时间去创建新的环境：脚本一次就完成了。
4. 运维的成本降低。

如果应用被适当得设计成可伸缩的需求，那么使用容器的扩展就像启动应用镜像的另一个实例一样简单，甚至可以自动化这个过程，应用可以响应时需求和规模来满足需求。

更为重要的是，可以自动化构建和部署过程，容器在自动化的构建过程和应用生命周期管理中非常有用。

可以轻松得使用容器简化版本和构建过程，所有的这些都很容易通过开源或低成本工具以及过程进行编排。

容器的不足之处

容器也有一些不足之处，因为容器化仍然是一项新技术，所以会有很多变化。不用担心Docker或Mesosphere会很快消失，但它们可能会发生重大的变化，对于在部署管道中管理容器镜像的最佳实践，还没有达成共识。

根据其特性，容器需要在客户机器上具有更高的权限，若成功利用这一点，就会让它们更加危险，例如：一台虚拟机在客户服务器上被破坏。

也很容易得到比需要的容器更多的容器以及曾经执行一些工作负载的孤立容器：它们已经失效，但没有被清理掉。

有一些研究表明，在所有基于云计算的虚拟机中，有四分之一到三分之一都是僵尸的，而容器也遇到了同样的问题，因为容器可以快速且轻而易举的创建，并且在很大程度上是为了处理一次性的工作负载而设计，所以这方面是存在着很大的隐患。

大多数容器都需要外部程序集——即“助手”应用，使用它们的主要应用能够运行，当容器从镜像中创建时，很难确保这些程序集所在的存储库是联机的，并且可以遇到容器对这些程序集的依赖可能会被破坏的情况。

最后，使用某些容器技术（如Docker）进行安全高效得网络连接，需要熟练的人手。

Serverless

Serverless在此基础上应用而生，可以消除几乎所有的问题和以及传统基础设施和容器上存在的大部分问题。

需要明确的一点是，无服务架构（Serverless）并不意味着没有任何服务器去运行代码。

Serverless是无需管理服务器，只需要关注代码，而提供者将处理其余的部分。

像所有的流行技术一样，Serverless有一些变化的定义，这取决于说的是谁，但在供应商的角度，核心概念是相同的：

• Serverless计算提供了以通用的匿名操作系统，代码将会在其中运行，下文将进行详解。
• 这些实例由云提供应用完全管理，会做所有的补丁、调优、服务安装等等。只需要编写运行在此服务上的代码，而云提供应用将确保代码在该环境中运行。
• 每个匿名且通用的环境只在需要时提供，当不再需要代码时，该环境就会被减少。
• 最后，只需要为代码实际使用付费：代码被执行的次数以及所需的计算资源的数量。

微服务和Serverless

但如果所有这些相对简单的任务或微服务将它们组成一个解决方案继续进行交付，就如果它们是整个服务器应用一样，又有什么意义呢？

当然，容器在怎么创建和管理基于服务器的解决方案上面给予了很大的灵活性，不过它仍然像管理整个工作流一样管理架构。

这就是Serverless技术的切入点。

Serverless是一种新的工作流方法，用拟人的描述方式是它说：会有一些事件调用我的代码，当事件发生时，我可能会从某个东西中获取输入并可能创建一些输出，这就是我需要关心的。

正因如此，Serverless的应用可以快速扩展到需求，而因为它的设计高度可用，下面以一个例子去深入探讨这个问题：

在HTTP端点上侦听服务器函数的典型工作流

这里有一个典型的例子，说明了Serverless的函数是如何工作的，在Serverless的技术中，按需进行的代码被称为服务的功能，它们被称为“服务”，因为每个按需执行的执行都服务于特定的目的或功能。

在本例中，创建了一个处理Web请求的函数，首先，当介入到入站请求时，云提供程序将查看是否有可用的函数实例正在运行，若不是，它就创建一个，但如果是这样，它就将这个请求交给可用的函数。

然后，函数代码解析WEB请求，以某种方式处理它，并返回对请求客户机的响应。

通常，云提供程序将会让该实例运行几分钟，以加速处理下一个请求，从而消除生成另一个实例的需要，但在大约5分钟后，弱没有第二个请求，云提供商就会取消这个实例。

人人为我，我为人人

之前提到，在匿名且通用的操作实例上承载了服务器的功能。

这是它们工作的关键，云提供程序对基本操作系统（如Linux或Windows）进行定制，其环境和服务设置与特定的编程语言（如node JS、Java、Python或Dot net core）协同工作。

云提供程序可以非常快得创建实例，因为它们完全相同，没有什么特别之处，每个工作与其他实例完全相同。

当部署代码时，会被保存到云提供商的存储服务中。

当代码需要运行时，提供者检索代码、启动其中的一个实例，将代码放到它上面，然后执行该代码，正如前面所指出的，一旦代码执行完毕，提供者通常会让实例运行一点，以处理后续的请求，但一旦需求下降，就会取消该实例。

服务器成本低于大多数定价模型，包括容器，照片通过Joshua_Willson在Pixabay公共领域。

定价模型

这种方法导致了一个不同于虚拟机或容器的定价模型。

在VMs的情况下，通常根据VM的CPU内核和内存的容量来支付每小时的费用，也会经常把应用许可费捆绑在一起，需要支付存储数据和数据系统磁盘的费用。

同样的情况也适用于容器定价：需要为承载容器的VM付费。不同之处在于，在VM上的传统代码可能会留下许多未使用的资源，可以将多个容器打包到一个VM上，以相同的价格处理多个工作负载。

在Serverless功能的情况下，需要为代码运行的次数和每个执行使用的计算资源数量付费。这就为我们带来了很大的回报。

简而言之，降低实际的基础设施成本，大大简化了部署管道以及总体成本，这只是当前成本的一小部分。

来看看函数与虚拟机的直接托管成本。

每月执行50万次的费用，4GB/S

在这里，将承担一个包括每月50万次执行的工作量，每秒钟大约有两个请求，要完成这项工作，每秒钟大约需要4GB的内存。

因此，对于虚拟机，需要至少提供8GB的内存，在Azure中，最便宜的选择是D3V2 VM，如果运行Linux，每月的运行成本约为100美元和4美元，对于AWS来说，最便宜的EC2实际是T2，大的，每月约70美元。

但如果使用的是服务器功能，那么可以大幅降低成本，在Azure功能的情况下，可以将实际的基础设施成本削减到大约四分之一，使用Lambda，可以将成本与EC2的比例减半。

每月执行200万次执行，每次执行4 GB/ s。

如果将执行的次数增加到200万，就能得到更好的存储，VM成本显著增加，以满足32GB的内存需要。

服务器成本也在增加，减少了在VM上实现的百分比节省，但实际的节省会更好。

在Azure的情况下，通过使用函数，每月可以节省近100美元，在AWS的情况下，每个月可以节省150美元。

每个月处理2万次执行的费用，每次执行的费用为512 MB/ s。

如果工作负载更小的话，那么节省下来也会很明显，让我们将假设改为每个月2万次请求，或者每两分钟一次请求，每秒钟可以处理1G的RAM。

在这种情况下，可以使用一个Azure标准的A1 V2 VM，每月大约32美元，或一个T2小的EC2实例，每月大约17美元。

长尾定价

你可能会问自己：“AWS和Azure怎么能让这个服务免费？”

同样，它又回到了一个事实，即Serverless的实例都是一样的，由于底层图像是完全相同的，云提供程序可以轻松得提供它们，而且每个实例实际上变得比以前一个更便宜，所以在游戏中有巨大的规模。

就像Facebook一样，每个新用户几乎不用花费任何东西来创造，事实上，仅仅通过创建账户来实现盈利，同样的，最终也就是Serverless的实例。

每个工作负载几乎不需要部署，因此给您大量的免费计算时间和实例是有理可图的，因为即使是少数用户超过了免费的服务阈值，也只有周期性得获得了丰厚的回报。

而Serverless技术的用户几乎总是需要额外的服务：数据库作为服务，消息队列，内存缓存，API网关等等，这相当于赠送剃须刀手柄，并加价出售刀片。

这是一个长尾的效应，但利润抛物线非常陡峭，得到了很多只有执行和计算时间，因为它只需要稍微超过这些限制，云提供商就能实现利润。

因此当使用Serverles时，会得到显著的成本节省。

无论大小，在服务器上运行相同数量的工作比虚拟机上花费更少。

更好的是，没有服务器，也没有僵尸。

因为服务提供者会自动处理供应和自动设备，而且只需要支付代码运行的次数以及它在运行时所使用的计算资源的数量，就不会为正在使用电力的服务器实例付费。

Serverless并不意味着NoOps，但它确实意味着是更精简的DevOps团队。

Serverless的Ops

这里有Serverless的实际好处：如果没有服务器可以管理，那么构建和部署解决方案的工作就更少了吗？

答案是，是的，作为技术经理所需要领导的时间将会大大减少，每个员工的工作时间也会被压缩到生产当中。

什么叫NoOps？这是一个时髦的词，所以每个人的定义各有不同，但大部分的人都会同意以下观点：NoOps的核心是可以使用自动化、服务抽象和供应商提供的服务来减少或消除传统上需要在DevOps中执行的任务。

例如，今天可能有一个敏捷过程，在此之中，工作被分配给Sprint，每个星期、两周或任何时候，团队实现其变更，然后构建和测试，如果测试完毕即可部署。

这涉及到测试工程师的工作，构建工程师，系统工程师、开发团队等等，都会产生一些焦虑，尤其是在构建失败的时候。

在NoOps中，发展的速度要快得多，使用持续集成和持续部署，自动化构建和测试用于确保每个特性或修复不被破坏解决方案，如果有，将快速调整更改，重复这个自动构建和测试过程，直到特性或修复工作，然后就可以立即被推到登台和生产。

这种快速的节奏之所以有效，是因为构建（通过微服务）是有意分发的。

通过处理应用和几个小任务的组合，可以安全得处理每一个小任务，而不需要对给定的微服务任何变化都有很大的担心，降低了宕机时间。

另外由于函数是自动配置和分配以满足需求的，因此基于它们的应用往往会快速扩展并具有很高的可用性。

也就是说，无需监控微服务看它的在线或满足需求高峰，如果云提供商的底层服务器服务正常运行，即会处理需求峰值和出问题的实例。

因此，根据定义，除非云提供商正在历经服务中断，否则在一个不需要任何服务的应用中，就不能有宕机时间，即使这样也可以通过将完全相同的代码库部署到不同的区域，并使用基于DNS的路由来确保故障转移保护。

Serverless的好处

因此回顾一下Serverless功能的好处：

• 实际基础设施成本较低。
• 通过微服务架构进行工作，这是有意将业务逻辑关注点彼此分离的，这使您的应用开过过程更加简单，因为i额可以将解决方案的功能作为独立单元进行管理。
• 因为无需管理服务器，所以只需要关注代码，减少每个代码更改的人员和时间。
• 而事实上，这允许我们采用一个非常快速的开发过程，专注于自动化、抽象和持续交付以及持续集成。
• 而且由于云提供程序在实例被供应和分配时处理，有效的将高可用性和灾难恢复构建在基于服务器的解决方案中。
• 诚然，底层服务可能会遇到问题，但可以使用传统的基于云的业务连续性技术来管理这种情况。

若每个人都能专注于编程

事实上，Serverless是一个跳板，它本身就是一个让每个人都能成为程序员的通道，因为一旦完成了配置和部署服务器这种神秘的工作，就可以专注于代码本身的自动化。

微服务体系结构本身就是将几个小任务链接到一个工作流中的过程，可以将这些任务以新的方式结合起来，以新的投入为基础，为问题创造全新的解决方案。

我们已经达到了一个目标：使用人工智能和智能设备，比如Sire以及Google搜索、Alexa去理解相对非结构化的请求并生成有意义的响应，为什么这些相同类型的服务不能用于创建代码？或者至少是智能工作流呢？

为什么那些有创造力的人不能创造出新的和重要的解决方案，他们能够自己创造这些工作流程，利用现代计算的力量呢？

这些是值得去思考的问题。

微软的三种现代解决方案特点：“智能边缘”设备的遥测技术在“智能中心”中得到巩固和解释，使用人工智能，在中心和边缘进行Serverless的技术处理计算。

上面所说很大程度上借用了Satya Nadella在微软（Microsoft Build）的主题演讲。

Satya Nadella对计算机的未来提出了一个设想，包括两个领域：“智能边缘”和“智能云”。

智能EDGE是我们所有链接到互联网网的设备，而且通常也自身也足够强大，拥有独立思考的属性，不仅是我们的电脑，智能手机，平板电脑等，还包括电视、电器、汽车、医疗监视器、玩具，甚至是使用的工具。

从所有这些设备的输入中，有一个统一的平台去进行管理——智能云。

当每个设备都在我们的生活中实践时，云利用人工智能和大数据推导出真知灼见以及行动，然后反馈到每个设备上，指导它们如何行动，并且告诉它们这是为什么，以便于它们进行学习。

在微软的愿景当中，这种云处理是在Serverless的平台上进行的，这种平台是无限可伸缩的。

Serverless的欠缺处

和上面提到的容器的欠缺之处一样，Serverless本身也是拥有不足的，接下来就来谈谈它不能做什么，以及为什么虚拟机容器不会很快消失。

显然将大规模的应用集群改为微服务架构并非小事。

前期的成本很高，可能会有伙伴关系或其他业务和要求，比如数据隐私和主权，这限制或阻止简单得放弃一直在构建应用的方式。

即使有很好的基本的N层架构，从使用容器中得到得益处可能远远超过将应用重新构建为可移植单元的好处。

而且并不是每个工作负载都适用于微服务，如果你的任务不需要扩展——如果它有一个可预测的工作负载——那么就有一个强有力的理由反对使用微服务。

如果解决方案严重依赖于其他服务，或者需要对运行时环境进行高度专门化的控制，那么这一点尤其正确，不要试图绕过服务器运行时环境的限制，或补偿大量外部请求和响应；只需将解决方案构建为一个包，并将其部署到容器中。

或者，如果应用需要大量的计算资源来完成它的工作，当然，可能会在托管方面节省一些钱，但是不断供应的VM或容器的可靠性可能会超过服务器功能所固有的代码限制。

这是一个讨论Serverless解决方案局限性的好办法。

一个明显的问题是，因为实例只在需要时才提供，所以在很少使用Serverless代码的情况下，可能会有一些延迟处理，可以通过运行探测来修复这个代码，使得代码保持温暖，但这是一种黑客才使用的行为，也许最好只是简单得将不经常访问的代码放到一个总是热的容器当中去，特别是在调用代码时，性能是非常重要的。

此外，还需要准备好解决延迟和删除微服务之间的链接的解决方案，例如，如果有一个作为所有解决方案的微服务运行身份验证API，那么在它的通信中，即使是400微秒的延迟也会被放大成一个严重的、系统性的错误。

虽然容器还是一个比较新兴的技术，但是Serverless比它更要新，Azure的功能在一般情况下还不到一年，Google的Serverless解决方案仍处于测试阶段，IBM创建Serverless标准的努力也扔处于初级阶段。

这就引出了另外一个问题：无论采取什么Serverless的方法，它在这个时候会有点拘泥于一个供应商，几乎可以在任何地方运行一个容器，但如何获得服务器代码的运行将多少取决于云提供商所支持的语言，以及它们用于创建Serverless实例和支持服务的方法。

代码可以运行到云提供商所支持的运行时和版本上，这是很有限的，因此很难引入某些库或程序集，这会让编程更加复杂。

最后，Serverless的编程模型——一个触发接收输入并创建一些输出的事件——可能不是某个需求的正确解决方案。

总结

Serverless是云计算的下一个浪潮，它节约了巨大的时间和成本，而且总投入甚至少于容器，只需要按需付费，没有更多的僵尸服务占用整体利润。

云供应商也通过供给本质上相同的服务器给每个需要它们的人获取显著的利益，同时也保证了低成本和高性能。

由于是自动化的，Serverless的通用方面，高可用和灾难恢复是内置的，在区域性服务中断的情况下，您可以使用传统的基于云的业务连续性技术来保持运行。

整个微服务概念建立在快速部署、持续集成、持续交付和分离关注的基础上，使Serverless成为改进服务交付和快速适应的理想方法。

但Serverless并不是每个工作负载都适用的，最好在容器中建立一个解决方案。

原文地址：http://www.tuicool.com/articl...
原文作者：Doug Vanderweide