Serverless：微服务架构的终极模式｜文末赠书，springboot面试问题2024

最新推荐文章于 2024-08-22 11:21:48 发布

碧海朝天素

最新推荐文章于 2024-08-22 11:21:48 发布

阅读量815

点赞数 9

分类专栏： 2024年程序员学习文章标签：架构 serverless 微服务

本文链接：https://blog.csdn.net/m0_58687762/article/details/136936971

版权

2024年程序员学习专栏收录该内容

317 篇文章 1 订阅

订阅专栏

1．微服务的粒度仍然比较大

当前微服务划分主要遵循单一职责的原则，比如将用户管理的功能作为一个单独的微服务。如图所示，用户管理微服务提供了API注册、登录、登出功能。通常，从提升用户体验的角度来看，浏览器会保留用户的会话，除非用户主动登出，否则不会请求登出API。所以，登出和注册的QPS差距较大，对扩展的诉求完全不同。而且，注册API和登出API的变更频率也可能不同。进一步拆分可以带来扩展性等便利，但整个微服务的数量也会提升一个量级，给基础设施的管理带来负担，那么如何做好架构权衡，既能够拥有架构上的高可扩展性，又不用增加基础设施管理成本呢？

2．微服务开发仍有较高门槛

如图所示，Java微服务开发的软件栈要求开发者掌握以下技能。

Java微服务开发技术栈

相比于单体应用开发，微服务开发效率得到提升的部分来自服务粒度减少及开发框架的改进，例如，从复杂的SpringMVC演进到SpringBoot，框架更加轻量化。但在其他方面（并发处理等）并没有什么改变，同时在微服务治理、分布式事务等方面的开发难度反而增加了。服务网格的出现，让开发人员可以不用关心服务治理的内容，但这样会带来服务性能的下降和维护的复杂性，其使用的范围也存在局限。是否存在一种新的编程模型及开发框架，让开发者在了解基本的语言特性和编程模型后，便可上手开发业务逻辑，而不用关心网络、并发、服务治理等问题？

3．微服务基础设施管理、高可用和弹性仍然很难保证

容器和Kubernetes工具的使用，提升了应用部署及基础设施运维自动化的能力，但保证基础设施高可用、可扩展对运维人员的能力要求很高。如图所示，服务上云后，基础设施团队可以不用再关心服务器、交换机等硬件的运维，但仍然需要关心虚拟机的维护，如安全补丁、基础镜像的更新升级、扩容等。

基础设施团队依然需要管理虚拟机

从On-Premise到公有云，实际上虚拟机的可用性在降低，比如云服务商提供的单虚拟机的可用性可能只有95%。运维人员需要借助云侧的工具来保证基础设施的高可用，难度仍然存在，而且很依赖运维人员的能力。

集群及其他云原生工具的维护也带来额外的挑战。以Kubernetes集群为例，维护和管理Kubernetes集群需要专业的技能。同理，维护云原生的监控、日志服务的高可用性也有不小的难度。所以，基础设施管理的难度仍然存在，只是从虚拟机转移到容器集群，从Rsyslog转移到ElasticSearch。

对于服务层面的扩展性，当前的策略也比较简单，例如，设定最少和最多使用的虚拟机数量，或者想办法改善根据CPU/内存使用率来伸缩或扩容的延迟。但是，由于总体资源量不会超过策略设定的虚拟机极限数量，因此一旦请求超过最大资源能承载的范围，可能会影响用户的使用体验甚至会服务中断。以容器为单位的扩容，从虚拟机性能的分钟级减少到30s左右，但当面对突发流量时依然会出现响应不及时、用户体验差的情况。是否存在全托管的基础设施及监控运维服务，能提供更好的弹性，从而让开发者无须关心所有底层和集群的维护工作，不再依赖高级运维人员来保证基础设施的可用性？

4．基础设施的成本依然较高

微服务会增加基础设施的成本。每个微服务都要考虑冗余，保证高可用。随着微服务数量的增加，基础设施的数量会呈现指数级增长，但云服务的基础设施收费方式没有改变，依然采用按照资源大小及以小时为单位（或包年）计费的方式。闲时和忙时的收费相同，对企业来说存在成本的浪费。是否存在一种新的基础设施服务，能按照“用多少付多少”的方式收费，从而降低基础设施成本？

微服务面临的这些新问题，是否可以通过新的基础设施服务及开发模式来解决呢？

什么是Serverless

2012年，时任Iron.io的副总裁Ken提出了Serverless的概念，他认为未来的软件和应用都应该是Serverless的：“即使云计算兴起，世界仍然围绕着服务器运转。不过，这不会持续下去。云应用程序正在进入无服务器世界，这将对软件和应用程序的创建和分发产生重大影响。”

2014年，AWS推出Lambda函数计算服务，提供简化的编程模型及函数的运行环境全托管，并且计费方式更加接近实际的使用情况（请求次数和每100ms使用的内存资源）。2015年，AWS推出API Gateway（全托管的网关服务），正式将Serverless这个概念推广开来。近年来，大部分的云提供商也提供了各种形态的Serverless服务，用于支持更多应用的开发和运行。下图为AWS Serverless全景图。

AWS Serverless全景图

Google在Serverless上的投入和发展节奏也很快。为了扩大在移动应用开发领域的优势，同时为Google云引流，Google在2011年就收购了Firebase，2016年将其作为mBaaS（移动后端即服务）的Serverless解决方案推出，以及安卓应用开发的主流云服务。除此之外，Google也推出了其他Serverless服务，以提供跨平台（Android、Web、iOS等）能力，支持移动、Web等应用开发，下图为Google Serverless全景图。

Google Serverless全景图

华为终端云服务以多年为超过百万移动应用开发者提供服务为基础，结合多年在Serverless领域的技术积累，推出了Serverless行业解决方案，包含构建类（云函数、认证、云存储、云数据库等）、增长类（推送服务、远程配置等）、质量和分析类（性能服务、崩溃服务等），提供面向移动应用开发的Serverless服务。2021年，云函数、云数据库等核心构建类服务已面向全球HMS生态的开发者开放，下图为HUAWEI AppGallery Connect Serverless全景图。

HUAWEI AppGallery Connect Serverless全景图

Serverless的定义

那么Serverless到底是什么呢？维基百科将Serverless定义为一种云计算执行模型。

云服务商按需分配计算机资源，开发者无须运维这些资源，不用关心容器、虚拟机或物理服务器的容量规划、配置、管理、维护、操作和扩展。
Serverless计算无状态，可在短时间内完成计算，其结果保存在外部存储中。
当不使用某个应用时，不向其分配计算资源。
计费基于应用消耗的实际资源来度量。

CNCF（Cloud Native Computing Foundation，云原生计算基金会）认为Serverless旨在构建和运行不需要服务器管理的应用程序，二者的不同之处在于它描述了一个更细粒度的部署模型，能够以一个或多个函数的形式将应用打包并上传到平台执行，并且按需执行、自动扩展和计费。

Serverless并不意味着不需要服务器来托管和运行代码，也不意味着不再需要运维工程师。Serverless是指开发者不再需要将时间和资源花费在服务器调配、维护、更新、扩展和容量规划上，这些任务都由Serverless平台处理，开发者只需要专注于编写应用程序的业务逻辑，运维工程师能够将精力放在业务运维上。综合维基百科和CNCF的定义，可以认为Serverless是一种云计算执行、部署和计费模型，Serverless服务按请求为应用分配资源，按照使用计费，基础设施全托管（无须关心维护、扩容等）。

目前，Serverless服务主要分为FaaS和BaaS。

函数即服务（Function as a Service，FaaS）：开发者实现的服务器端应用逻辑（微服务甚至粒度更小的服务）以事件驱动的方式运行在无状态的临时容器中，这些容器和计算资源完全由云提供商管理。如图1-7所示，从开发者角度来看，FaaS和IaaS/PaaS相比，其扩容的维度从应用级别降低到函数级别，开发者只需关心和维护业务层面的正常运行，其他部分如运行时、容器、操作系统、硬件等，都由云提供商来解决。

FaaS与IaaS、PaaS的区别

后端即服务（Backend as a Service，BaaS）：基于API的三方服务，用来取代应用程序中功能的核心子集。由于这些API是作为自动扩展和透明运行的服务提供的，因此从开发者和运维工程师的角度来看似乎是无服务器的。非计算类的全托管服务，如消息队列等中间件、NoSQL数据库服务、身份验证服务等，都可以认为是BaaS服务。

FaaS通常是承载业务逻辑代码的服务，开发者会更为关心，它也是本书重点介绍的内容。

Serverless关键技术

下图是典型的Serverless系统架构，从中可以看到一些Serverless的常用概念。

典型的Serverless架构

事件源（Event Sources）：事件的生产者，可能是HTTP请求、消息队列的事件等，通过同步或异步的方式去触发函数。
触发器（Trigger）：函数的REST呈现，通常是RESTful URL。当事件源将事件推/拉到触发器时，FaaS平台会查找触发器和函数的映射关系，从而启动该函数实例，以响应被推/拉到触发器的事件。
FaaS控制器（FaaS Controller）：FaaS平台的核心组件，管理函数的生命周期、扩容和缩容等。可以将函数实例缩容为0，同时在收到对函数的请求时迅速启动新的函数实例。
函数实例（Function Instance）：执行函数的环境，包含函数代码、函数运行环境（如JRE、Node.js）、上下文信息（如函数运行的配置，通常以环境变量注入）。一个函数实例可以同时处理1个或N个事件（取决于平台的具体实现）。函数实例通常内置可观测性，将日志和监控信息上报到对应的日志和监控服务中。
函数编程模型（Programming Model）：通常表现为函数的编码规范，如签名、入口的方法名等。函数的编程模型一般会提供同步/异步/异常处理机制，开发者只需要处理输入（事件、上下文），并返回结果即可。
BaaS平台：函数通常是无状态的，其状态一般存储在BaaS服务中，如NoSQL数据库等。函数可以基于REST API或BaaS服务提供的SDK来访问BaaS服务，而不用关心这些服务的扩容和缩容问题。

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。