数人云|使微服务、容器趋向完美——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