无服务架构

无服务架构（Serverless Architecture）即无服务器架构，也被称为函数即服务（Function as a Service，FaaS），是一种云计算模型，用于构建和部署应用程序，无需关心底层服务器的管理。

在无服务器架构中，开发人员编写单独的函数或函数集合，这些函数以事件驱动的方式触发，并在需要时自动扩展，而无需自己管理服务器基础架构。

1、无服务的愿景

无服务器是让开发者只需要纯粹地关注业务：

与单体架构、微服务架构不同，无服务架构天生的一些特点，比如冷启动、无状态、运行时间有限制等等，决定了它不是一种具有普适性的架构模式。

自动扩展和弹性：
无服务器平台会自动处理应用程序的扩展，根据负载的增减自动分配和释放资源。这使得应用程序具有很高的弹性，能够处理不断变化的工作负载。
按需计费：
无服务器计算按照实际使用的资源进行计费，这意味着您只需支付您实际消耗的计算资源，无需支付预留的服务器容量。这可以大幅降低成本，尤其是对于不稳定或突发性的工作负载。
简化运维：
无服务器架构摆脱了服务器管理的烦恼，开发人员无需关心服务器的配置、维护和扩展。云服务提供商负责这些任务，使开发人员能够更专注于应用程序的逻辑。
快速部署：无服务器平台允许开发人员更快地部署新功能或更新，因为它们省略了服务器配置和部署的复杂性。
多语言支持：无服务器平台通常支持多种编程语言，允许开发人员选择最适合其需求的语言。
高可用性和容错性：云服务提供商通常提供高可用性和容错性，以确保应用程序的可用性。这包括跨多个数据中心的部署和自动备份。

对一些适合的应用来说，使用无服务架构确实能够降低开发和运维环节的成本，比如不需要交互的离线大规模计算，又比如多数 Web 资讯类网站、小程序、公共 API 服务、移动应用服务端等，都跟无服务架构擅长的短链接、无状态、适合事件驱动的交互形式很契合。

但是对于那些信息管理系统、网络游戏等应用来说，又或者说对所有具有业务逻辑复杂、依赖服务端状态、响应速度要求较高、需要长连接等特征的应用来说，无服务架构至少在目前来看并不是最合适的。

无服务天生“无限算力”的假设，就决定了它必须要按使用量（函数运算的时间和内存）来计费，以控制消耗算力的规模，所以函数不会一直以活动状态常驻服务器，只有请求到了才会开始运行。

这导致了函数不便于依赖服务端状态，也导致了函数会有冷启动时间，响应的性能不可能会太好（目前，无服务的云函数冷启动过程大概是在百毫秒级别，对于 Java 这类启动性能差的应用，甚至能到秒级）。

无服务和“微服务”以及“云原生”时代之间并没有继承替代关系，也不要产生”无服务比微服务更加先进”的错误想法。

软件开发的未来，不会只存在某一种“最先进的”架构风格，而是会有多种具有针对性的架构风格并存。

计算模型：最大的区别在于计算模型。无服务架构基于事件驱动的函数（Function as a
Service，FaaS），每个函数都是一个独立的、无状态的代码单元，仅在触发事件时执行。微服务架构则是基于独立的、长时间运行的服务，这些服务通常以容器形式运行。
管理复杂性：
无服务架构通常更加抽象和简化了基础设施管理，开发人员无需关心服务器的配置和维护。微服务架构需要更多的基础设施管理工作，包括容器编排和管理等。
部署：无服务架构通常具有更快的部署速度，因为它们省略了服务器配置的过程。微服务架构需要更多的时间来设置和维护容器集群。
执行时间：无服务函数通常具有短暂的执行时间限制，通常用于处理短暂的计算任务。微服务可以长时间运行，适合处理长时间运行的任务。
资源限制：无服务平台通常对函数的执行时间、内存和存储等方面设置了限制。微服务可以根据需要配置更多的资源。

无服务架构更加抽象和自动化，适用于处理事件驱动的、瞬时性的任务。微服务架构更适合长时间运行的、复杂的应用程序，但需要更多的基础设施管理。

在某些情况下，这两种架构可以结合使用，以满足不同类型的需求。选择哪种架构取决于应用程序的性质、需求和团队的技能。