什么是Serverless架构

Posted 2023-05-03

Serverless（无服务器架构）是指服务端逻辑由开发者实现，应用运行在无状态的计算容器中，由事件触发，完全被第三方管理，其业务层面的状态则存储在数据库或其他介质中。

Serverless可以使开发者更聚焦在业务逻辑，而减少对基础设施的关注。

Serverless通常包含了两个领域 BaaS（Backend as a Service）和 FaaS（Function as a Service）

BaaS是一种广泛依赖于第三方应用和服务的无服务器计算方法。BaaS供应商可以提供加密、用户认证、云数据库的使用。这些服务可以通过调用云供应商提供的API进行访问；相比自己重新开发，这些功能可以更方便地整合到各个类型的系统中。

FaaS 是一种事件驱动的由消息触发的服务，FaaS 供应商一般会集成各种同步和异步的事件（如AWS的SNS），通过订阅这些事件，可以触发指定的函数运行，例如当前使用很广泛的 AWS 的 Lambda函数。

Serverless架构的优点

降低运营成本：

Serverless是非常简单的外包解决方案。它可以让您委托服务提供商管理服务器、数据库和应用程序甚至逻辑。由于这个服务使用者的数量会非常庞大，于是就会产生规模经济效应。在降低成本上包含了两个方面，即基础设施的成本和人员（运营/开发/维护）的成本。

降低开发成本：

Serverless作为一种云服务，使得整个应用程序组件被商品化。

扩展能力：

横向扩展是完全自动的、有弹性的、且由服务提供者所管理。从基本的基础设施方面受益最大的好处是，您只需支付您所需要的计算能力。

更简单的管理：

Serverless架构明显比其他架构更简单。更少的组件，就意味着您的管理开销会更少。

有效利用计算资源：

据《福布斯》的统计，在商业和企业数据中心的典型服务器仅提供5%～15%的平均最大处理能力的输出。这无疑是一种资源的巨大浪费。Serverless让服务提供商提供我们的计算能力最大限度满足实时需求，更有效地利用计算资源。




Serverless架构的缺点

状态管理：

要想实现自由的缩放，无状态是必须的，而对于有状态的服务，使用serverless这就丧失了灵活性。

延迟：

Serverless应用程序是高度分布式、低耦合的，这就意味着延迟将始终是一个问题，单纯使用serverless的应用程序是不太现实的。

本地测试：

Serverless应用的本地测试困难是一个很棘手的问题。虽然可以在测试环境下使用各种数据库和消息队列来模拟生产环境，但是对于无服务应用的集成或者端到端测试很困难。

参考技术A Serverless不代表再也不需要服务器了，而是说：开发者再也不用过多考虑服务器的问题，计算资源作为服务而不是服务器的概念出现。
Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来管理你的应用部署，你甚至可以管理某个具体
功能或端口的部署，这就能让开发者快速迭代，更快速地开发软件。

以亚马逊的AWS
Lambda为案例，Lambda能让不用思考任何服务器，也就是说，不用你处理服务器上的部署、服务器容量和服务器的扩展和失败容错，还有服务器上选择
什么OS操作系统，语言的更新，日志等等问题。你的应用程序只需要和多个第三方的API或服务打交道，也可以自我创建一个无服务器的API。

Serverless有以下几个特点：

Serverless意味无维护，Serverless不代表完全去除服务器，而是代表去除有关对服务器运行状态的关心和担心，它们是否
在工作，应用是否跑起来正常运行等等。Serverless代表的是你不要关心运营维护问题。有了Serverless，可以几乎无需Devops了。

Serverless不代表某个具体技术，有些人会给他们的语言框架取名为Serverless，Serverless其实去除维护的担心，如果你了解某个具体服务器技术当然有帮助，但不是必须的。
Serverless中的服务或功能代表的只是微功能或微服务，Serverless是思维方式的转变，从过去：“构建一个框架运行在一
台服务器上，对多个事件进行响应。”变为：“构建或使用一个微服务或微功能来响应一个事件。”，你可以使用 django or node.js
和express等实现，但是serverless本身超越这些框架概念。框架变得也不那么重要了。

Serverless规模扩展性方面由于充分利用云计算的特点，因此其扩展是平滑的，同时由于Serverless是基于微服务的，而一些微功能微服务的云计算是零收费，这样有助于降低整体运营费用。

将来下述具体应用将可能使用Serverless架构：

静态网站的管理
替代WordPress( Serverless Blog Project
)
个人媒体服务器(less!)
物联网Iot或家庭自动框架或项目 (使用 AWS IoT
)

架构演进两大方向，一个是Serverless，另一个是什么？ | 技术前沿

在 一文中，我们就什么是无服务器技术，它是如何发展的，它的优点、缺点是什么，对企业的价值在哪里进行了梳理。本文讲讲 Service Mesh 。在架构领域，Service Mesh和Serverless一样，是非常重要的一个方向。

这么说吧，掌握了Service Mesh，你就选择了一条未来技术框架的道路。至于这条道路会怎么发展，还要再观察。这篇文章将 解释什么是Service Mesh，为什么需要Service Mesh，以及Service Mesh的现状如何。

 

初识Service Mesh

Service Mesh很新，最早在2016年9月29日由开发Linkerd的Buoyant公司提出。

 

时间回到2016年10月，Alex Leong开始在Buoyant公司的官方博客中连载一系列关于“A Service Mesh for Kubernetes”的文章。

 

随着2017年Linkerd加入CNCF，Service Mesh开始大规模出现在各个技术论坛上，Service Mesh在国内被翻译为“服务网格” 。

 

那么到底什么是Service Mesh呢？目前比较公认的定义是Buoyant的CEO William Morgan在博客中给出的具体描述，如下：

英文原文，滑动查看

现在，Service Mesh逐步发展为一个独立的基础设施层。

在Cloud Native架构下，单个应用程序可能由数百个服务组成；每个服务可能有数千个实例；并且这些实例中的每一个实例都可能处于不断变化的状态，因为它们是由诸如Kubernetes之类的资源调度系统动态调度的。这个世界中的服务通信不仅非常复杂，而且是运行时的普遍行为之一，管理它对于确保端到端的性能和可靠性至关重要。

 

Sidecar的比喻从何而来？

业内也有类似“Sidecar”的说法。这个概念很形象，就是我们以前在战争影片中看到的那种挎斗车。

在模式库中，Sidecar被这样描述：

将应用程序的组件部署到单独的进程或容器中以提供隔离和封装。这种模式还可以使应用程序由异构组件和技术组成。

这种模式被命名为Sidecar，因为它类似于连接到摩托车的辅助车。在该模式中，辅助车被附加到父应用程序并为应用程序提供支持功能。辅助车也与父应用程序共享相同的生命周期，与父进程一起被创建和推出。

 

解释了这么多，一句话来说的话，那就是： Service Mesh帮助应用程序在海量服务、复杂的架构和网络中建立稳定的通信机制，业务所有的流量都转发到Service Mesh的代理服务中。

 

不仅如此，Service Mesh还承担了微服务框架所有的功能，包括服务注册发现、负载均衡、熔断限流、认证鉴权、缓存加速等。不同的是，Service Mesh强调的是通过独立的进程代理的方式，除此之外，还承担了上报日志、监控的责任。Service Mesh架构如下。

轻量、自治促进不断发展

Service Mesh的出现是由微服务架构推动的，随着一个应用被拆分为几百个甚至几万个应用，服务治理面临巨大的挑战。这个时候，微服务框架出现，例如，Finagle、Dubbo、SpringCloud、Netflix OSS等。这些框架都是基于客户端负载均衡直连的方式，此方案的优势是性能高、应用性好，如Spring Cloud。

归根结底，在微服务架构中，我们要解决的问题是，让开发人员感觉不到微服务之间的通信。当服务数量越来越多，升级微服务框架变得越来越复杂的时候，你不可能要求微服务框架一直不变，而且是没有bug的。在技术更新如此之快的年代，就更不可能了。

 

因此，微服务框架的部分功能开始逐步向服务端移动，希望客户端可以尽量“薄”，但是客户端不可能无限制的“薄”，剩余部分仍然比较“厚”。

 

因为使用客户端更像一种交付的模式，不容易变更，控制力较差，而Service Mesh则从业务进程集成客户端的方式演进为独立进程的方式，也就是说，原本的客户端变成了一个独立进程。对这个独立进程升级、运维要比绑在一起强得多。

 

微服务架构更强调去中心化、独立自治、跨语言，但是通常微服务框架限制了这一点，不可能为每种语言都实现一种框架，要么都用一种语言，要么实现多种语言的框架。 而Service Mesh通过独立进程的方式进行了隔离，可以低成本实现跨语言。

 

随着Docker及Kubernetes的崛起，微服务的部署模式开始发生转变，越来越趋向于轻量级，越来越强调隔离自治。每个服务独立占用一个容器，将服务、依赖包、操作系统、监控运维所需的代理打包成一个镜像。这种模式促成了Service Mesh的发展，让Service Mesh实现起来更容易。否则开发人员需要额外维护Service Mesh进程，就非常麻烦了。

 

主流框架的弊病和优势

目前Service Mesh的框架如雨后春笋般快速涌现，以下几个框架是目前为止被提到次数最多的。

 

先驱者如Linkerd，被誉为业界第一个Service Mesh项目，但由于很多功能被后续框架所取代，发展有限。现在最流行的是Envoy，它在性能和资源消耗上表现得非常出色，被Istio收编之后， 专注于数据平面。最值得注意的是Istio，因为它的背后是Google和IBM。从0.3版本开始支持非Kubernetes平台，并可以独立运行。

 

当然业内还有其他一些框架，由于暂时没有投入到生产环境，进展有限，可以关注一下，比如Conduit 、nginMesh等。

 

就拿Istio来说，虽然它的架构思想被很多人认同，功能也很多，但是Istio的问题仍然较多，可用性较差，几乎没有生产级的案例。有点像当初Kubernetes刚刚研发出来的感觉，也许随着技术的不断发展会成为Service Mesh的未来，毕竟当前很多公司都在跟随这个框架。

 

先谨慎观察  未来可期

实际上，如果在一个小公司，Service Mesh的优势并不是十分明显。例如小公司很少会考虑采用多语言，因为多一种语言就意味着要花费额外的精力进行维护，所以到目前为止，大多数公司在后端只使用一两种语言。

 

另外，微服务框架相对来说比较稳定，就如同Spring Framework一样，不会轻易进行不兼容的升级，只要保持好节奏，问题不会太多。因此，像Netflix这样的公司，基本上还是沿用类似Spring Cloud模式的。

 

Service Mesh对业务开发人员友好，但是基础设施层的研发会更复杂，需要依赖更多的服务、组件，否则将带来极大的架构、运维复杂度。 对于很多公司来说，门槛稍高，且需要投入成本。

 

百度内部业务也很早就开始了基于Service Mesh思想的微服务实践，并自研了BMesh框架，大大降低了Service Mesh的实施和维护成本，并解决其自身的性能问题。 基于这些内部实践，百度智能云CNAP产品目前已经邀测推出了非侵入式微服务解决方案，为客户提供可商用的基于Service Mesh的微服务监控、追踪和治理平台。

目前来看，在没有成熟起来以前，Service Mesh并不具备压倒性的优势。 但未来随着微服务的进一步快速普及，Service Mesh作为重要的架构演进方向值得关注。

本文参考资料

百度智能云官网：

https://cloud.baidu.com/product/cnap.html

CNCF官网：

https://www.cncf.io/

《云原生基础架构》，机械工业出版社，2018年9月第一版

《持续演进的Cloud Native 云原生架构下微服务最佳实践》，电子工业出版社，2018年10月第一版