【.com快译】Serverless架构风格挑战软件设计现状，实现开发、运维和管理开销最优的部署基础。由于继承了微服务架构（MicroservicesArchitecture，MSA）的基本概念，因此被赋予了相当前卫的模式来实现最底层的硬件空置架构。 虽然它带来了重大进步，但它的采用需要一个深思熟虑的过程，将企业解决方案需求映射到无服务器计算上。 软件系统最初的实现是部署在一台物理服务器上，因为在给定时间内只能运行一个操作系统实例，所以底层硬件的计算能力无法得到最佳利用。随着技术的发展，建立分时计算资源后，通过同时切换CPU和I/O操作，多个虚拟机可以运行在同一个硬件上。 这种技术发展带动了很多行业的革新，对于云技术的起步也非常重要。此时，虚拟机与软件部署的计算环境隔离开来，是最可控、可扩展、可编程的单元之一。2006年前后，当谷歌结合Linux内核的特点实现控制组时，Linux容器技术随即出现。 从那以后，Linux容器实际上就停滞不前了，因为只有像谷歌这样规模大、技术优秀的企业才能大规模使用。到2012年，微服务架构的概念被一群软件架构师引入欧洲。2013年底，Docker眨眼间填补了容器生态系统中的可访问性、可用性和支持服务缺口。因此，容器变得流行起来。 Linux容器通过将大型单片系统分解为独立的、独立的服务来开辟新的视野，这些服务可以通过细粒度的资源利用来执行。随着这些进步，Kubernetes（谷歌开源的Docker容器集群管理系统）和Mesosphere等容器集群管理系统开始提供端到端的容器即服务（ContainerasaService，CaaS）功能，同时进入上升周期。 2015年晚些时候，AWS又向前迈出了一大步，推出了AWSLambda。它通过按需运行微服务并在没有负载时停止它们来进一步节省软件部署成本。这个概念类似于省油汽车上的启停功能，通过自动关闭内燃机来降低油耗。 它是如何工作的？ 尽管“无服务器”一词乍一看似乎很荒谬，但它实际上意味着：无需任何基础设施干预即可部署软件的能力。无服务器平台可自动执行按需构建、部署和启动服务的整个过程。用户只需要注册各种需要的业务功能和自己的资源需求。 显然，此类功能可以分为两种主要类型：由客户端请求触发的功能和由事件或需要在后台执行的事件触发的功能。一般来说，这样的无服务器系统可以使用容器集群管理器（CCM）和一个可以按需扩展容器的动态路由器来实现。但是，这还需要考虑路由器延迟、容器创建时间、语言支持、协议支持、功能接口、功能初始化时间、配置参数传递以及提供证明文件。 虽然这种部署方式要求容器能够在没有负载时停止，但在现实世界中，在处理请求后如此迅速地终止容器的代价是昂贵的。因为在更短的时间间隔内可能会产生更多的请求，所以更常见的是将无服务器计算容器保留一段预先配置的时间，以便被更多的请求服务重用到。这类似于PaaS平台的自动缩放行为。扩展服务后，它的某些实例将保留一段时间以处理更多请求，而不是立即终止它们。 选择无服务器平台 无服务器平台一般分为以下三类： 1。公共云上的功能即服务(FaaS)解决方案： A。AWSLambda、B.MicrosoftAzureFunctions、C.GoogleCloudFunctions、D.Webtask、E.Syncano 2。在公共和私有数据中心运行的无服务器框架： A。Fission-在Kubernetes上运行，B.Funktion-在Kubernetes上运行，C.Kubeless-在Kubernetes上运行，D.GalacticFogGestalt-在DC/OS上运行，E.IBMOpenWhisk-在Docker上运行，F.IronFunctions-在Docker上运行,DockerSwarm,Kubernetes上 3.为现有Serverless框架的增值服务提供不可知的应用程序接口或/和包装框架： A。Serverless.com–支持AWSLambda、IBMOpenWhisk、B.Apex–支持AWSLambda 如果要决定选择哪个serverless平台，首先要看数据中心运行什么样的解决方案。二是它的特殊性、成熟度、对供应商的依赖性，可能也需要评估。除了公共FaaS可以提供的，AWSLambda和Azure还可以提供完全成熟的无服务器产品。谷歌的云服务功能仍处于测试阶段，仅限受邀者使用。Fission和Funktion是Kubernetes无服务器框架的两个流行应用程序。IronFunctions由Iron.io开发，是一个相对较新的独立于无服务器框架的平台。IBM的OpenWhisk平台已捐赠给Apache软件基金会，目前正处于孵化阶段。另外，上面的第三种还提供了serverless部署选项，实现多云，这也是对现有公有FaaS的增值提供。 Serverless函数设计最佳实践 在设计Serverless函数时，我们应该考虑以下设计原则： ·在定义函数范围时应遵循单一职责原则。 ·通过函数优化实现毫秒级执行效率。 ·遵守无状态协议，以便能够无缝扩展功能。 ·使用外部服务进行服务发现、状态和缓存管理。 ·使用环境变量读取配置，而不是依赖文件。 ·鉴于容器被设计为短暂的，我们应该避免使用文件系统来实现数据持久化。 结论 Serverless架构技术和设计模式还处于起步阶段。目前，各种新的应用程序和现有系统的扩展都可以毫不费力地迁移到这个架构上，只要对实现这个功能的支持的编程模型没有限制。同时，由于WebSocket、ProtocolBuffer、AMQP、MQTT、ApacheThrift等各种RPC协议都需要一个永远活跃的监听器，所以信息接收通道选择无状态协议也很重要。此外，可能需要第三方服务和工具来实现协调逻辑的业务需求，实现业务流程的功能分组，以及管理分布式事务和状态。使用容器池的Serverless平台也可能因为容器复用方式的不同而带来一些安全漏洞。他们也可能不允许按功能分配资源。因此，在考虑为生产系统采用无服务器架构时，了解所有这些方面非常重要。然而，鉴于许多框架已经建立和完善，这可能仍然是构建POC（云平台）并评估其对即将开展的项目的优势的好时机。 【原标题】AdaptingServerlessArchitecture（作者：ImeshGunaratne） 原文链接：https://dzone.com/articles/adapting-Serverless-architecture【译文，合作站点转载请注明出处和来源是.com]
