转载

谈微服务和Serverless(10.23)

首先我们来看下对Serverless基础说明的一篇文章

https://blog.csdn.net/cc18868876837/article/details/90672971

Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来管理你的应用部署。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态（Stateless）、暂存（可能只存在于一次调用的过程中）计算容器内。

构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作云端或本地的服务器或运行时。Serverless真正做到了部署应用无需涉及基础设施的建设，自动构建、部署和启动服务。

注：这里必须搞清和容器化paas的区别点，要知道容器PaaS本身也是不用关系服务器的，但是可以看到在Serverless是一种更小更灵活的动态容器这是其一，其次是真正到了服务级别，而不是部署包级别。因为在原来的部署包级别就一定还是会存在编译打包部署，要将部署包部署到类似tomact，jboss中间件的过程。而到了Serverless阶段功能都是FaaS粒度更新，没有打包构建动作，你也不用关系应用中间件。

Serverless由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发，完全被第三方管理，其业务层面的状态则被开发者使用的数据库和存储资源所记录。

Serverless提供的关键两类服务-FaaS和BaaS。

FaaS（Function as a Service，函数即服务）

FaaS意在无须自行管理服务器系统或自己的服务器应用程序，即可直接运行后端代码。其中所指的服务器应用程序，是该技术与容器和PaaS（平台即服务）等其他现代化架构最大的差异。FaaS可以取代一些服务处理服务器（可能是物理计算机，但绝对需要运行某种应用程序），这样不仅不需要自行供应服务器，也不需要全时运行应用程序。

FaaS产品不要求必须使用特定框架或库进行开发。在语言和环境方面，FaaS函数就是常规的应用程序。（这点很重要，实际上没有很重的开发框架概念了，类似在微服务架构开发的时候，我们还会使用SpringCloud开发框架和库，这个在FaaS里面不再存在。）例如AWS Lambda的函数可以通过Javascript、Python以及任何JVM语言（Java、Clojure、Scala）等实现。然而Lambda函数也可以执行任何捆绑有所需部署构件的进程，因此可以使用任何语言，只要能编译为Unix进程即可。FaaS函数在架构方面确实存在一定的局限，尤其是在状态和执行时间方面。

相比传统系统，部署方法会有较大变化 – 将代码上传至FaaS供应商，其他事情均可由供应商完成（不再存在编译构建，并要打包为部署包这个动作） 。目前这种方式通常意味着需要上传代码的全新定义（例如上传zip或JAR文件），随后调用一个专有API发起更新过程。

FaaS中的函数可以通过供应商定义的事件类型触发。对于亚马逊AWS，此类触发事件可以包括S3（文件）更新、时间（计划任务），以及加入消息总线的消息（例如Kinesis）。通常你的函数需要通过参数指定自己需要绑定到的事件源。大部分供应商还允许函数作为对传入Http请求的响应来触发，通常这类请求来自某种该类型的API网关（例如AWS API网关、Webtask）。

BaaS（Backend as a Service，后端即服务）

BaaS（Backend as a Service，后端即服务）是指我们不再编写或管理所有服务端组件，可以使用领域通用的远程组件（而不是进程内的库）来提供服务。

理解BaaS，需要搞清楚它与PaaS的区别。

首先BaaS并非PaaS，它们的区别在于： PaaS需要参与应用的生命周期管理，BaaS则仅仅提供应用依赖的第三方服务。典型的PaaS平台需要提供手段让开发者部署和配置应用，例如自动将应用部署到Tomcat容器中，并管理应用的生命周期。BaaS不包含这些内容，BaaS只以API的方式提供应用依赖的后端服务，例如数据库和对象存储(对中间件资源池的关注转变对API能力接口的关注，真正从资源到服务)。 BaaS可以是公共云服务商提供的，也可以是第三方厂商提供的。其次从功能上讲，BaaS可以看作PaaS的一个子集，即提供第三方依赖组件的部分。

BaaS服务还允许我们依赖其他人已经实现的应用逻辑。对于这点，认证就是一个很好的例子。很多应用都要自己编写实现注册、登录、密码管理等逻辑的代码，而对于不同的应用这些代码往往大同小异。完全可以把这些重复性的工作提取出来，再做成外部服务，而这正是Auth0和Amazon Cognito等产品的目标。它们能实现全面的认证和用户管理，开发团队再也不用自己编写或者管理实现这些功能的代码。

Serverless架构适合的场景

在现阶段，Serverless主要应用在以下几个场景。首先在Web及移动端服务中，可以整合API网关和Serverles服务构建Web及移动后端，帮助开发者构建可弹性扩展、高可用的移动或 Web后端应用服务。

在IoT场景下可高效的处理实时流数据，由设备产生海量的实时信息流数据，通过Serverles服务分类处理并写入后端处理。另外在实时媒体资讯内容处理场景里，用户上传的音视频到对象存储OBS，通过上传事件触发多个函数，分别完成高清转码、音频转码等功能，满足用户对实时性和并发能力的高要求。

无服务器计算还适合于任何事件驱动的各种不同的用例，这包括物联网，移动应用，基于网络的应用程序和聊天机器人等。这里简单说两个场景，方便大家思考。

场景一：应用负载有显著的波峰波谷

Serverless 应用成功与否的评判标准并不是公司规模的大小，而是其业务背后的具体技术问题，比如业务波峰波谷明显，如何实现削峰填谷。一个公司的业务负载具有波峰波谷时，机器资源要按照峰值需求预估；而在波谷时期机器利用率则明显下降，因为不能进行资源复用而导致浪费。

业界普遍共识是，当自有机器的利用率小于 30%，使用 Serverless 后会有显著的效率提升。对于云服务厂商，在具备了足够多的用户之后，各种波峰波谷叠加后平稳化，聚合之后资源复用性更高。比如，外卖企业负载高峰是在用餐时期，安防行业的负载高峰则是夜间，这是受各个企业业务定位所限的；而对于一个成熟的云服务厂商，如果其平台足够大，用户足够多，是不应该有明显的波峰波谷现象的。

场景二：典型用例 - 基于事件的数据处理

视频处理的后端系统，常见功能需求如下：视频转码、抽取数据、人脸识别等，这些均为通用计算任务，可由函数计算执行。开发者需要自己写出实现逻辑，再将任务按照控制流连接起来，每个任务的具体执行由云厂商来负责。如此，开发变得更便捷，并且构建的系统天然高可用、实时弹性伸缩，用户不需要关心机器层面问题。

以下参考： https://cloud.tencent.com/developer/article/1479938

Serverless架构的优势和好处

以目前使用较多的AWS的Serverless服务Lambda为例，它提供了如下功能：

Java/Nodejs/Python的运行时环境。 这意味着可以部署Ruby（JRuby）/Scala/Clojure/Java等运行在JVM上的代码，只是部署时需要编译成class文件打包上传。Nodejs和Python的代码可以直接部署，随时上线。
零宕机时间部署。 通过Lambda可以很容易地实现函数的蓝绿部署。
限量限时的运行资源。 Lambda的运行单位是容器，它能使用的资源比较有限，最大分配的内存不超过1.5GB，临时磁盘大小不超过512MB，进程和线程总数不超过1024个等，代码需要的资源超过限制会出错。每个容器的生命周期只有5分钟，超过5分钟会自动销毁，所以一定要保证任务在5分钟内完成。
事件驱动。 Lambda支持S3、API Gateway、CloudWatch等多种AWS上的服务绑定事件句柄，在事件发生时触发对应的Lambda函数。
自动伸缩。 每个账户在每个Region上最多能同时运行1000个Lambda函数，算上每个容器的生存周期和并发量，几乎可以认为是无限伸缩了。
按请求次数和资源使用量收费。 在撰写本文时，Lambda每个月前100万次请求以及400,000 GB秒的运算资源都是免费的。后续的每百万请求约为1.5元人民币，每GB秒的使用费用约为0.00012元人民币。据估算，使用Lambda 部署代码的成本比在EC2上部署服务的成本低30%。

我们很容易看出，相比部署在虚拟机或者容器的微服务，Serverless的好处在于：

几乎是“零”维护成本。 开发人员可以专注于实现业务逻辑，不用担心基础设施创建、自动化部署的问题，也不用担心服务器维护、升级等问题。
降低安全风险。 不用管理基础设施，减少了因为维护造成的安全问题。
更低的资源开销。 Lambda通过请求次数和资源使用量收费，而部署在EC2实例上的服务则是按秒收费。
更灵活的伸缩。 相比部署在虚拟机或者容器上的微服务，需要根据经验或者监控去设置、调整伸缩策略，使用Serverless则几乎不需要考虑这点，它会按需自动伸缩。
更快上线。 对于开发人员来说，他们只需要直接部署代码到Serverless的服务中，而通常这样的部署很快，几乎是零宕机时间。

微服务和Serverless

当我们比较微服务和Serverless时，实际上比较的是微服务和FaaS。直观上来看， 微服务和FaaS的差别在于粒度，而要实现FaaS，首先必须将单体应用演进到微服务，然后才能进一步地分解到函数级别，实现FaaS 。我们可以进一步从如下几个方面比较微服务和FaaS。

微服务和Serverless不完全是同一层面的事物，但是BaaS可以帮助解决微服务带来的基础设施、维护、资源成本等问题，FaaS进一步改造微服务，降低其实现的粒度，实现更快的上线。Redpoint总结的Serverless LandScape。

谈微服务和Serverless(10.23)

使用AWS服务来创建Serverless应用

参考： https://blog.csdn.net/u012724947/article/details/52896720

https://blog.csdn.net/wucong60/article/details/96880585

谈微服务和Serverless(10.23)

在用Serverless创建一个应用一般会涉及到如下内容

1.API Gateway 网关服务，实现我们需要的网络RESTful接口

2.Lambda 函数计算，实现我们需要的平行扩展业务运算

3.Dynamodb数据库，实现我们需要的“单机”无限性能数据库

4.S3服务，实现前端静态页面的存储

通过 Amazon API Gateway，您可以根据在 AWS Lambda 中运行的代码快速、轻松地创建自定义 API，然后通过 API 调用 Lambda 代码。Amazon API Gateway 可以用您的账户执行 AWS Lambda 代码，也可以在 AWS 外部通过可公共访问的 HTTP 端点来调用 AWS Elastic Beanstalk、Amazon EC2 或 Web 服务。利用 Amazon API Gateway 控制台，您可以定义 REST API 及其关联的资源和方法、管理 API 生命周期、生成客户端 SDK，并能查看 API 指标。

对Serverless的进一步思考

前面讲到脱离应用中间件依赖性，下一步就是脱离数据库依赖性，比较好的就是NoSql数据库，而最佳的就是完全使用存储服务能力。但是对于业务复杂，数据事务和关联要求高的业务不合适。但是对于简单应用完全可以做到去数据库，并且实现数据库无关性。

Serverless比微服务粒度打的更细，完全到了功能点级，实际上可以看到后续管控运维的复杂度是增加了的，对于类似单一功能APP，微信小程序，定向数据采集等适合，但是对于复制应用系统暂时不适合。包括我们看到企业内部复杂业务系统，当前转微服务架构本身就已经很吃力。一拆分一定会带来集成的问题，监控运维的问题，事务一致性的问题。

注意对于Serverless不仅仅是无服务器，是整体架构设计的概念都弱化了，同时应用开发框架的概念也随着弱化，没有重的开发框架和底层平台，也没有编译和部署概念。

在已有的API服务能力都用传统方式提供出来后，可以看到对于Serverless更加适合用来做前端应用的组合和轻量即编排，通过FaaS来实现对各类第三方API服务能力的整合完成要给特定功能。比如你要做一个简单的图像处理程序，那么图像采集，图像识别和匹配，图像存储都可以调用独立的第三方API接口服务来完成。

在Serverless后，可以看到对开发人员技能要求进一步降低，更不需要大家都去做全栈工程师，开发人员也可以花更多的精力来关注业务场景和业务需求的理解和实现。同时在Serverless后也可以看到，小功能的开发和交付周期会更快更加敏捷。

原文 http://blog.sina.com.cn/s/blog_493a84550102z4c3.html

正文到此结束