论 Serverless 架构体系的革新与发展

社区导读:本文将为大家介绍软件体系结构演变,称为“Serverless(无服务器)”的新概念与模式的基础知识。 



初看一下 Serverless 这个术语,它听起来像是在没有服务器的情况下却能实现有服务器的功能。 没错,这意味着你没有一台服务器。但实际上,有人已经这样干了。几个大公司已经提供了这样的技术。 例如,Amazon AWS Lambda,Google Cloud Functions和Windows Azure Functions,现在这几家可以被确定为互为竞争对手。


Serverles 架构之演进


架构演进:On premise monoliths > 面向服务的架构 > 云 > 微服务架构 > Serverless架构


硬件演进:物理服务器 > 虚拟机 > 容器


Serverless 可以被认为是云与微服务架构(MSA)结合的结果。 让我们看看如何到达到那里。


企业软件架构在过去若干年中经历了很多次迭代。软件曾经被人们认为是一个庞然大物,它不断开发和增加功能。大多数情况下,这些软件都部署或安装在物理硬件较高的大型服务器上。接着,开发者们开始发明新模式以实现更高的灵活性,敏捷性与生产力,体系结构经历了不同阶段发展后,面向服务架构(SOA)诞生了。


云技术提升了SOA。 REST 引入了一种简单的方法来实现SOA,规范比使用SOAP要严谨得多,并且提供了使用不同消息类型(如JSON)的自由,这些提升了SOA在行业中的受欢迎程度。 虚拟机也可以实现SOA的能力,SOA 满足了适合该体系结构的动态需求。


微服务架构继续演进且,更多的人认为SOA也不错,但是Serverless打破了这些格局,它能提供更好地服务,可以更灵活更干净地完成任务。


为什么行业等待这么长时间才用此模式?在微服务架构的普及前,运行服务器并不是一项低成本的任务,它并不允许系统更快更灵活创建和删除服务器。 虚拟机技术也没有达到这种先进要求的标准,后来容器技术的普及和采用让Serverless架构涌现了出来。



Serverless 的优点


本节我们讨论Serverless体系结构与早期的体系结构链相比的优点。以下的一些优点将与微服务的很多优点重叠,因为它们之间是近亲。来看如下:


1)技术选型 - 可以为套件选择不同的功能与不同的开发语言。


2)体系结构的选择 - 可创决定使用Serverless,但不用唯一。我们可以决定实施一套服务使用Serverless,另一套服务在微服务上,也可以使用之前的遗留系统。


3)更快的部署时间,配合市场营销 - 考虑改变现有服务增加功能,通过独立创建全新服务来增加功能。 后者将为开发者节省大量时间。 它避免了对整个服务的影响,并且可以让开发者更快地完成功能。 我们可以在在几天内甚至几小时推出新功能,且不必担心可用性的问题,


4)永远不浪费钱 - 如果没有流量产生,我们无需支付任何费用,也无需维护无流量服务器。 如果流量启动时,服务器成本可以按毫秒级的时间计算。


5)性能更快、更低成本扩展 - 简单/小功能和类似微服务架构(MSA)有助于快速横向扩展服务。快速的启动时间有助于在毫秒级内提供容量并提高平台的数量。这样我们可以顺利地处理陡峭的尖峰流量,如秒杀,抢票等场景,无需再担心系统可用性的问题。


6)简化团队职责 - 在为复杂应用程序的不同部分工作时,不同的开发团队将带来更多复杂性,且产生耗时的讨论和交互。 在明确定义边界的API的场合下,开发团队便会轻松一点。


7)卸载基础架构的担心 - 在 Serverless 架构出现 之前,软件开发工程师容易忽略了在线运行服务的状态。 这意味着人们必须提前根据容量规划,设置,分析,处理系统缩放等来优化节点资源。 Serverless 运营商则通常将所有产品捆绑在了一起,包括生态系统的所有备件。


4)为世界节约 - 当你努力让平台保持9s可用时,可能必须在世界上的不同地区部署服务器,并且需要冗余资源,如线路,带宽、机房以及硬件设备等,以应对突然出现的流量高峰。 在这个过程中,我们不得不为不均衡的资源分配和闲置的消耗浪费能源。


Serverless 体系可以最好地利用资源,节省能源,不浪费闲置的服务器。


Serverless 的缺点


在无服务器Serverless 架构中,我们可以看到很多优点。但是与传统架构相比,也可以找出它几个缺点。


1)缺少管控 - 由于服务是在云中管理,隶属于第三方云提供商,因此开发者可能不得不依赖他们。 后期想转向新的平台将付出高昂的代价,您可能不得不固定此供应商,尽管可能对方提价或API变化较高等。 


我们可以使用变通的方法,例如可以在容器中获取代码,并应用AWS Lambda。


2)体系结构复杂 - 人们可能混合搭配体系架构。因此会在软件包中设置增加其复杂性。 处理不同的体系结构和不同的参与方,不会是一个顺利的过程。


3)不适用于长时间运行的应用 - 由于Serverless提供的函数被配置为短期和动态函数,因此如果需要长时间运行,它可能不适合我们的应用。


4)多租户与隐私问题 - 这些函数通常可以在同一个应用程序服务器上为几个不同的客户提供服务。 可能有攻击者利用系统中的安全漏洞实施攻击。


适合 Serverless 的用例


几乎任何想要快速启动和运行的功能都可以视为Serverless的用例。 以下是用例的一些典型特征:


1)新的体系结构 - 可能你想要把单个应用程序分解为多个功能,或者想要一些彼此独立的实用程序和无状态函数。那么,Serverless 可以是我们的选项。


2)添加安全功能给不安全的组件 - 如果有一个功能需要更安全地运行,哪些功能不能在客户端应用程序中运行,可以简单地创建一个Serverless应用并将其应用于启用安全性的API。


3)当前体系结构的新特别功能 - 如果已经使用SOA或微服务体系结构实现并运行了软件体系结构,如果希望引入一个小且全新的功能。您可以快速完成Serverless功能并立即部署。



作者:高明

来源:21世纪技术官


如有事情需要联系我们,请发送邮件到:lianxi@wmqn.net