微服务下：Serverless实践

背景

随着微服务的兴起，我们强调业务(服务)进程的隔离性，且为了保证服务的高可用和高性能，避免单点事故，我们常常都会通过冗余的方式，会启多个进程来提供相同的服务。那么在基础设施层面来说，我们通常有以下几种方式：

• 传统的方式，一台物理机上面部署多个应用进程。
  • 点评：自建基础设施，前期投入大, 需要维护的东西很多，一般借助虚拟化技术，比如vSphere, vCloud等技术来实现计算资源的分配管理；一般由专门的团队负责，不提供自助服务，资源的申请流程很长。
• 云时代，比如亚马逊提供的IAAS服务，已经把服务器抽象成了一种可灵活使用的资源，屏蔽了基础设施层的管理（计算，存储，网络），AWS的成功, 引导开发者将应用转移到云上, 解决了硬件管理的问题，而软件配置和管理相关的问题利用自动化配置工具Ansible、Chef等解决；一般会将一个服务部署到一个EC2实例上面。
  • 点评：通过EC2做到了业务进程的隔离，屏蔽了业务进程之间的相互影响
• 容器时代，Docker把服务器抽象成了镜像，保证一个包含环境和部署软件的镜像在任何地方运行都能保证行为一致。Platform As A Service平台，比如redhat的Openshift，它基于K8S做容器的编排，通过docker做资源和进程的隔离，可以做到在一个虚拟机上面运行多个docker容器，优化了资源利用率。
  • 点评： 容器与虚拟机相比有如下的优点
    • 启动速度，容器通常在一秒内可以启动，而虚拟机通常要1分钟或更久
    • 资源利用率， 一台普通物理PC可以跑几百上千个容器，VM上面一般最多几十个
    • 性能开销， VM通常需要额外的CPU和内存来完成硬件模拟，Docker接近原生
    • 隔离性， VM单独内核， 完全隔离； Docker共享内核，通过namespace安全隔离
    • 轻量级， VM一般为GB级，Docker容器一般为MB
• Serverless， 为了进一步的让开发团队只关注业务，无服务器架构，进一步按需启动容器，按需扩展，根据代码运行时间付费，对外提供服务，最大程度的提高了资源利用率, 减少资源碎片的情况。

整体平台演进路线图，概括如下：

image.png

应用场景

• 与微服务的契合

Serverless is lightweight event-based microservices.

• 无状态
• 负载起伏明显
• 对延时不敏感（事件驱动，最终一致性）

AWS Lambda

AWS Lambda is a compute service that lets you run code without provisioning or managing servers

image.png

• 每个月前一百万的请求免费
• 0.20美元/百万请求，每个请求接近$0.0000002美元，对于很多流量小的服务，费用可以忽略

事件源

image.png

支持多种事件源触发机制，事件获取既有“推”又有“拉”的方式。

同步调用方式：

• API gateway
• AWS SDK

异步调用方式：

• S3
• SNS
  ......

部署方式

• 可使用传统的Jenkins结合Serverless插件实现持续集成
• 集成包括编译，静态扫描，单元测试，mock集成测试等
• 打包为ZIP文件，上传到AWS S3上以供使用，如下图：

image.png

• 一些部署限制：

image.png

• 也可以基于Cloudformation的部署方式，如下图（这里有多年前用typescript + serverless framework写的演示代码： https://github.com/qinnnyul/serverless-aws-lambda-typescript； 除此之外，还可以参考的框架有SAM和Claudia.js，他们都是基于CF做Infrastructure as code）：

image

异常处理

运行时异常的捕获

• 超时 - Timeout
• 内存不足 - Out of memory
• 错误配置 - Miss configuration

提供了Dead Letter Queues机制，以防止数据的丢失，方便做事后补偿（可以是自动或者人工的方式）。

image.png

案例

• 用于数据流的处理， 这个案例中使用了发布订阅（SNS）的方式，当数据被存在S3上面的时候，触发了S3事件，然后所有订阅SNS topic的订阅者（这里是多个Lambda），会被触发，实现相应的数据转存，不同的服务对数据进行了侧重点不同的消费（比如数据分析和数据查询）

image

局限性

• 首次启动响应时间
  • 项目中启动Spring boot的项目的时候，有些服务启动延时多达10秒以上
  • AWS lambda在一段闲置状态后（4小时内，这个数据是与AWS咨询师确认后得知，官网没有），一般会收回计算资源。
  • 基于动态语言的服务，比如nodejs或者python，没有这个问题，一般延时在几百毫秒。
• 强第三方依赖
  • Serverless框架本身是平台托管的，比如AWS Lambda与AWS绑定，事件源也和平台相关。
  • 转化平台的代价大。
• 不适合所有场景
  • 有状态的服务
  • 长时间运行的服务（lambda的最长运行时间为5分钟）
• 环境资源的限制

image.png