Serverless 下的微服务实践-阿里云开发者社区

开发者社区> 阿里巴巴云原生小助手> 正文

Serverless 下的微服务实践

简介: 开发者根本不需要去关心 Server ,只需要去专注业务逻辑即可,本文将详解微服务体系与平台化的 Serverless 架构融合的过程。
+关注继续查看

微服务架构介绍


微服务架构诞生背景


在互联网早期即 Web 1.0 的时代,当时流行的是单体应用,研发团队比较小,主要是外部网页,然后新闻门户等;到了新世纪的互联网时期 Web 2.0 时代,网民数量大幅激增,相继出现电商、社交这样巨无霸级别的互联网产品,出现了几百人甚至上千的研发团队在一个场景下,流量及业务复杂度相较于上一个时代有了质的变化,因此单体服务的弊端:例如研发效率等问题便显现出来。


此时出现了一个叫 SOA 的架构,其架构思路与微服务很像,它有类似于 ESB 这种中心化组件,阿里的 HSF,包括后来开源的 Double,都是在此阶段诞生的。


移动互联网时代出现之后,各种各样的 APP 诞生,生活也开始全面互联网化。大流量高并发以及规模化的研发团队变得越来越寻常,相应对高技术、生产力的要求也在逐步提升,此时微服务的概念应运而生。


微服务其实一直贯穿在整个架构的发展过程中。在 Java 的技术栈,类似于 Spring Cloud 、Double 这些框架都已经非常流行。不难发现整个社会已经步入数字化高速发展阶段,此时更大的问题蕴含其中,如流量升高、应用复杂度提升,研发团队扩大、对于效率的要求增高等等。


单体时期 1.0 版本

1.png

大部分的公司或早期业务都会经历过这样的过程(如图所示):先是客户端,此时需要通过一个入口访问,上图中 SLB 是阿里云一个负载均衡服务,它相当于一个网络入口,可以对应到 ECS(ECS 为阿里云的虚拟机)打到对应的单体的服务中,而此时他们会共用一个数据库,这是第一个时期。


单体时期 2.0 版本


2.png


到第二个时期 SOA 架构:此时出现了分治的思想,它会将一些业务进行拆分。但它并未做到服务与底层的拆分,如存储数据库的拆分,其本质上还是共用一套数据库,因此它还是单体的架构。


微服务时期


3.png


而到微服务时期,如若客户端通过 SLB 访问网关(如图所示),随后会转发对应的服务,且服务与服务之间会产生一些调用;每个服务会对应一个单独的数据库或缓存,且每个服务会通过类似于 Nacos 这种的服务进行注册、发现以及配置管理。


微服务引入之后,虽然解决了架构业务的分离,能够让研发团队在某一个领域、业务能够做到精专,不过从整体架构来看便会发现,相较于之前它其实是更为复杂的,所以也带来一些运维上的问题。


4.png


在单体架构中于单体应用而言,会发生边界不清晰、模块耦合、共享代码库容易冲突的问题,同时如果团队规模较大,此时的协作效率也会相对较低。但是微服务架构的核心就是解耦,如果做到拆分之后的解耦,就可以释放开发团队效率。


云原生时代微服务架构发展


微服务技术在云原生时代的技术引进


云原生是一个很宏观的概念,如果我们以微服务为起点来看云原生给微服务带来的变化与演进,可以更好地帮助我们理解什么是云原生。


5.png

微服务和单体应用的本质是什么呢?(如图所示)它其实是把单体应用从一个巨型的应用拆分成数个微小的服务,协作来完成原先单体应用等效的业务服务。此时微服务与微服务之间会形成一个依赖关系,它需要部署至一个或多个资源上,这时的资源便是计算资源。


过去单体应用与资源之间的关系十分简单,单体应用的协同也都是一些内部协同,不存在外部动态的依赖。但架构转换到微服务之后,由于外部依赖和节点数量的爆炸,整个体系会变成网状,管理起来十分复杂。超过 50% 的企业会觉得采用微服务架构,最大挑战是复杂的运维,即整个服务生命周期的管理。


如今,比较公认的一点是云原生的根基在于容器与容器的管理编排(K8S)。而容器与 K8S 的技术能够帮助我们解决微服务体系中所存在繁杂运维的问题。

6.png

首先不同的微服务之间会存在异构,即一个团队,在微服务体系下为了发挥最大效能,可能会允许不同小团队采用不同的编程语言、运行环境去运行微服务。因此最初我们在运维和管理微服务时,是没有统一的标准去处理这些异构环境的。这便促发了云原生容器技术的流行,因为这项技术的作用就是通过一层标准化的运行时和封装来限制微服务部署。这样从生命周期与管理角度来看,每一个微服务之间的差异变少,十分有利于资源的调度。


随后。基于容器调度衍生出了容器平台。容器平台就是管理容器的,就 K8S 来说,它可以标准便捷地将微服务运行到底层的资源上,随后存储计算网络可以通过 K8S 这层来进行统一封装,一层抽象与封装,它类似于云原生时代的操作系统。


它具体会提供哪些帮助呢?在 K8S 中有个概念叫 POD ,POD 是一组容器的结合,与微服务实体生命周期的耦合,在一个 POD 里面,它可以运行一个或者是多个容器。


7.png

采用微服务架构时,一般会把微服务运行的主体放在主容器中,也就是把微服务执行的主逻辑放在主容器里面。此时主容器的生命周期与 POD 的生命周期是完全耦合的,POD 什么时候消亡,微服的运行主体便何时消亡。除此之外我们还会运行一些边车容器— Sidecar,它主要是为主容器提供辅助功能,如日志采集、网络代理、身份鉴权等 。此时的微服务便除了提供自身核心业务以外,它还可以动态的提供额外辅助能力,这让微服务的管理变得更加稳定与便捷。


POD 这个模型还提供了许多非常有用的功能,比如状态信息。(状态信息是指:POD 会提供一个标准的接口来显示运行时的状态)通过这个信息状态可以出判断微服务或是容器的运行状态,如它是否处于运行中、业务是否已经准备好可以迎接流量接入,POD 为整体的稳定性提供了保障。另一个是地址服务功能,每个 POD 会有一个标准化的 DNS 地址服务,它对于需要统一暴露出来的 API ,日志监控追踪能力都十分有帮助。通过 DNS 的日志地址来访问以及暴露的可观测性信息,可以快速发现运行时的问题。由此便可总结:容器及容器平台能够在微观上帮微服务具备更多的能力。

8.png

图中为 4 种发布模型:

  1. 滚动更新
  2. 固定更新
  3. 蓝绿部署
  4. 金丝雀发布(灰度发布)


流量治理


微服务将过去单体时期静态的通信关系,通过拆分编成动态运行时。通常服务间的通信与协同是需要单独管理的,微服务框架帮助我们进行了每个服务通用功能的抽象与实现。


9.png

抽象层面包含两方面:业务逻辑与通信、流量、服务治理能力。我们可以将底层通用能力抽象成一个具体的框架,但是不同微服务之间的框架是没办法实现相互调用的。而到了云原生时代,它能够使用不同的开发语言以及模型进行编程,实现微服务的研发。


10.png

Service Mesh 服务网格就是为了解决流量治理在多语言,多环境下的问题而出现的。


在数据层面,Sidecar 负责流量劫持转发以及管理,该功能典型 Sidecar 实现就是 Envoy。


如图它会先将上面部分从框架层面抽象出来后与业务直接进行解耦,将通用能力放在 Sidecar 中,通过 Sidecar 之间的通信、转发去管理;这样会使问题变得简单很多。开发者只需要在流量管理和 Sidecar 之间通信,不同技术栈的微服务实例便可实现互相通信。


除了数据层面,我们还需要管控层面的支持。需要一个组件来实现原微服务体系中的策略规则的管理,经典实现就是 Istio。比如在原来在微服务体系中的服务注册、服务发现、流量观测等能力是需要管控层面的主线去完成的。有这些能力之后它就组成了 Service Mesh。我们可以通过管理 POD 中的流量以及数据层面的单点,让他们形成网状结构,变成集群实现流量的分配、安全、观测。


11.png图中的编程模型与函数计算相关


请求驱动是基于请求的动态弹性伸缩,并简化请求处理的逻辑。微服务的调用,从流量进来后,会经过 4 层或者 7 层的负载均衡分发到不同的微服务实例;但是在同一个微服务实例进程的内部,一般会有两个逻辑:第一个是请求管理,它可能是一个 HTTP 服务器,或者是一些 Handler,也可能是一些队列管理,请求分发能力的组成;这些组成最终会将请求提交到第二部分,即请求处理中,而请求处理也是开发者真正需要实现的一些逻辑。


比如说 Java Go 、Python,它们都有自己的一套请求管理逻辑,请求管理和请求处理之间会形成强烈的耦合,这个实例既包含请求的管理,又包含请求处理的逻辑。在这个架构下不存在一个全局独立,且可以感知到请求去进行流量管理的控制层,只有到整个实例自身的处理层才如此解释请求。即便此时微服务实例已然过载,也很难再次将这个请求转发到其它微服务实例上进行负载均衡。因此请求驱动系统就是查数据、并解决这两个要素,开发者实际在做的就是请求驱动的解耦。


12.png

如图所示,首先外部系统传输过来的请求会先进行标准化,有一个适配器;标准化之后就会将其放在请求负载均衡器中,这个负载均衡器可以理解该请求本身的语义;然后它可以驱动并进行处理。当处理单元不够时,它可以通过管理器来进行扩容;逻辑单元比较多时,它还可以进行缩容,这样便形成了一个动态管理,可以为开发者节约非常多的成本。


请求驱动模型:


  1. 请求标准化
  2. 请求路由
  3. 处理管理


将请求标准化、请求路由、处理管理等组合起来,便与 Serverless 的概念吻合。开发者根本不需要去关心 Server ,只需要去专注业务逻辑即可。这其实也是微服务体系与平台化的 Serverless 架构融合的过程。阿里云的 FC (函数计算)和 SAE(应用引擎) 都是以解决这些问题为核心的。


微服务+Serverless 的最佳实践


13.png

Serverless 其实经过了很多年的发展,其理念最早可以追溯到 2012 年;2014 年 AWS 正式推出 Lambda,才掀起了 Serverless 浪潮;但随后而来的是一段沉静的发展期。这种情况出现的原因是为什么呢?分析来看是因为函数计算的开发模式与原本模式有非常大的出入,它更适合前端而不是 long running 形式的一些应用,它更偏向基于请求的一些处理。因此那些需要长时间运行的服务或应用架构便不太能够享受到 Serverless 所带来的弹性和降本提效等红利。


微服务架构的痛点


14.png

微服务的痛点在于稳定性。微服务带来了许多其他组件。例如服务发现、或是其他的一些工具类的产品,这些在单体情况下会变得更加复杂,因为整个架构变成网状结构。容器与容器平台在某些程度上是帮助我们承载微服务这部分的运维的,但是其本身如容器 K8S 都是存在一定复杂性的。

15.png

K8S 的架构图


K8S 不仅复杂也存在一些痛点:


  1. 容器镜像部署方式差异
  2. K8S 组件运维的复杂
  3. 学习成本

16.png

对于开发者来说是最有吸引力的是不需要改变原本的开发方式的基础上可以将精力专注于业务逻辑。而微服务比较理想的状态也是开发者只需关注架构中的业务系统,其它部分如:网关 CICD 发布系统、验货流程,注册中心、告警监控、分析日志,这些通通都不再需开发者再去关心。其优势可以总结为:


  1. 让开发者专注业务逻辑
  2. 不改变原有开发方式
  3. 无需关心与运维底层资源
  4. 具备弹性能力可以降低闲时成本
  5. 优秀的工具链


总结

17.png


微服务体系在整个云计算发展的时代有不同的事件。如最开始部署就是传统的 IT 设施,像 IDC 这种机房,微服务提供的是静态的物理计算资源。


然后到了第二步就是云托管时代,就是我们大家所熟知的 VM,阿里的话就是 ECS ,它可以提供弹性的计算资源,但它并没有实质的改变,只是资源上变成弹性,它对于服务、微服务的部署,包括管理运维等本质上都没有太大变化。


到了第三阶段云原生时代,云平台、云服务都可以承担这些复杂的运维操作、配置、管理。微服务提供的就是一个运行环境与平台,此时用户只需要去关心业务系统、以及如何实现业务系统即可。将复杂的技术变得越来越简单,让用户不再感知那些烦杂的操作,由平台代替用户去做重复的、难以维护的工作,这也十分符合计算机技术整体的发展方向。


本文整理自《ServerlessLive 直播课》,关注 Serverless 公众号,回复“927”,即可获取本堂课程 PPT!

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
9497 0
如何 0 改造,让单体/微服务应用成为 Serverless Application
随着 2013 年以 Docker 为代表的容器技术、CNCF 基金会以及 K8s 的发展等,云原生开始被广大开发者所熟知。云原生时代之前还有两个阶段:一是自建 IDC 机房,二是简单地把原有的应用搬迁到云上。自建 IDC 机房很难获得高可用、高可扩展以及运维提效等能力;而第二个阶段就是云计算时代,相比 IDC 有了一定的进步,但大部分还是在相对原始地用云,很难用好云,这个阶段的资源已经接近无限,但是基于虚拟机及各种自建服务的方式还有待改善。
2938 0
微服务+异步工作流+ Serverless,Netflix 决定弃用稳定运行 7 年的旧平台
2021 年,Netflix 会将大部分的工作负载从 Reloaded 转移到 Cosmos 平台。Cosmos 是一个计算平台,它将微服务的最佳特性与异步工作流以及 Serverless 结合在一起。
1251 0
(四)spring cloud微服务架构b2b2c电子商务 - common-service 项目构建过程
我们将对common-service整个项目进行剖析,将整个构建的流程给记录下来,让更多的关注者来参考学习。 首先在构建spring cloud的common-service之前,我们需要准备的技术: Maven(项目构建)、Spring Boot、Spring Cloud、微服务概念、去中心化思想、分布式等,针对于common-service的顶级项目,这里我们主要使用Maven来构建,闲话少说,我们直接上代码是最直观的。
1414 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
13186 0
阿里云ECS云服务器初始化设置教程方法
阿里云ECS云服务器初始化是指将云服务器系统恢复到最初状态的过程,阿里云的服务器初始化是通过更换系统盘来实现的,是免费的,阿里云百科网分享服务器初始化教程: 服务器初始化教程方法 本文的服务器初始化是指将ECS云服务器系统恢复到最初状态,服务器中的数据也会被清空,所以初始化之前一定要先备份好。
11509 0
如何通过 Serverless 技术降低微服务应用资源成本?
世上没有免费的午餐,微服务技术让 IT 系统变得更敏捷、更健壮、更高性能的同时,也带来了架构复杂度的提升。对于开发者而言,要想更好的驾驭微服务架构,需要解决持续集成、服务发现、应用通信、配置管理、流量防护等一系列难题。
9145 0
Serverless 微服务实践-移动应用包分发服务(Fun 3.0 升级版)
Serverless 微服务实践-移动应用包分发服务 背景 阿里云函数计算是事件驱动的全托管计算服务。通过函数计算,您无需管理服务器等基础设施,只需编写代码并上传。函数计算会为您准备好计算资源,以弹性、可靠的方式运行您的代码,并提供日志查询、性能监控、报警等功能。
2257 0
阿里云ECS云服务器初始化设置教程方法
阿里云ECS云服务器初始化是指将云服务器系统恢复到最初状态的过程,阿里云的服务器初始化是通过更换系统盘来实现的,是免费的,阿里云百科网分享服务器初始化教程: 服务器初始化教程方法 本文的服务器初始化是指将ECS云服务器系统恢复到最初状态,服务器中的数据也会被清空,所以初始化之前一定要先备份好。
6895 0
1314
文章
0
问答
来源圈子
更多
专注Serverless、微服务、函数计算等
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载