内容简介：缘何Serverless架构
【编者的话】本文讨论了Serverless解决的产品研发过程中遇到的问题，从而解释了产品研发中为何选择Serverless架构，并且对如何选择Serverless架构提出了建议，文章的最后还列举了一些Serverless架构中可以使用的工具。
几个月前在Tavisca解决方案中，我们开始研发了Beats并且作为产品研发到了一定的阶段，该阶段就是当我们需要一个快速迭代产品时，该产品可以快速发展到我们平时很少需要面对的MVP（最小化可行性产品）阶段。我们每次研发新产品，都有机会选择当时最前沿并且最适合的技术。
本文将讨论我们面对的问题，以及最终我们是怎样为我们的产品选择Serverless架构（耶，这并不是个神秘的博客）。读者阅读本文之前，最好能对微服务有一些了解，如果在该领域不太涉及的话，建议先阅读笔者的另一个文章（ https://cloudncode.blog/2016/0 ... rted/ ）。
Serverless到底是什么？
以我的经验，人们第一次听到”serverless”一般都有两个反应：
1. 嗯。。。代码在哪儿运行呢？
2. 我很想揍捏造serverless概念的人，根本就没有这种东西，它只会让其他人感到困惑；
3. 我喜欢我的服务器，它让我能控制服务；
4. 所以。。。代码在哪儿运行呢？
请允许用我自己的语言定义serverless，当然是好的声明：
“Serverless架构是完全基于第三方服务设计的，代码运行在临时的容器中，使用FaaS同时调用BaaS达到数据存储的目的”
一个同事说以上的声明和Martin Fowlers 的定义极其类似，但是我向你们保证我同事给我看相关资料之前我从未读过。
函数即服务（FaaS）
FaaS是公有云模型中的创新产品，从经济方面的衡量，使得供应商提供一个简单明了的平台变得可行，用户的代码运行在容器中（例如docker），这些容器则按照响应的事件构建，例如到API网关的http调用，或者数据流中的一个数据包，诸如此类云供应商可以支持的任何内容。
Azure提供了Azure Function，Google提供了Cloud Functions，而我最青睐的FaaS是AWS Lambda。前面两者都遵循了相同的定律，不创建或者维护服务器。
后端即服务（BaaS）
不像FaaS，BaaS早些时候在app开发者中变得非常流行，他们在因特网上寻找一种后台服务可以提供类似数据存储（duh）、事件驱动通知以及一些随着app增长可以横向扩展的东西，这方面BaaS提供的比FaaS更成熟，并且有越来越多的人认识到了这些。这个环节AWS主要是通过Dynamo DB提供服务，对应Azure的Cosmos DB以及Google的Cloud Datastore。
接下来把我们之前讨论的内容图形化吧：
浏览器调用API网关，该网关用容器执行你的代码，然后和DB（BaaS）交互获取到数据，是不是看上去很熟悉？上层的工作流还是一样，在函数方面有着不同的键值，容器的创建和销毁基于FaaS提供商所使用的算法，用户无法控制。笔者写过一篇关于AWS Lambda如何在后台工作以及最佳实践的文章，建议读者阅读。
那么还有服务器吗？
是的，无论何时听到Serverless，就像你的常识告诉你的，实际上还是有服务器存在的。Serverless在我看来，是创造出来实现你不需要创造、维护甚至拥有服务器的存在，在Serverless的世界里，服务器根据你的需求、使用率创建，它可以在后台变化，而用户对此毫无察觉。
以上说明听起来很可怕，我同意，但是如果你以前使用过高质量的第三方服务
，特别是像类似Amazon（AWS）、Mircosoft（Azure）或者Google，，你就会知道你可以相信他们至少比使用你自己服务器承诺的运行时间要长得多。
产品-技术设备
那Serverless是我们遇到所有问题的答案吗？当然不是，为了选择最好的技术，我们首先必须理解我们将要使用该项技术的产品，否则我们将会陷入永远选择下一个酷技术的陷阱，而不管这个技术对实际的生意是否公正，该技术是否适用。
要理解为何采用Serverless，我们就必须在可预见的未来了解产品的需求，还有什么是Serverless以及理解它的本质。
Beats产品的原则是什么？
Beats作为一个SaaS，意味着被DMC（目的地管理公司）代理或者更多简单化的旅行代理使用，这些代理对于旅行行业的术语并是不非常的熟悉。这儿有Beats需要的蓝图：
- 根据Marty Cagan书里提到的“inspired”产品开发方式开发软件，该方法浅显地谈到了产品研发周期，软件基于产品自身的发展周期高度迭代（包括市场/客户在内的反馈）
- 市场调查目前把每个用户license的价格定在999/-INR（~15.6美元），意味着运营每个用户产品的花费会很低。
- 产品研发周期需要表现出引人注意地、可持续地增长，增长的速度比常规的速度更快，直到最后找到市场立足点。
- 该软件的本质就是发掘出用户近期的多重经验，例如为代理在网络异常时完成节假日目的地工作的离线app。
- 我们背后并没有10亿美元的投资人。
产品经理的工作和工程师团队的并不一样？
延缓产品研发进程的因素，主要有以下几点：
1. 人工维护服务器或者编写Chef/Puppet脚本；
2. 编写云自动化脚本或者手工操作（想到就哆嗦）；
3. 可量化目的的重构（处理更多的用户）；
4. 非功能性的bug修复；
SaaS服务中技术分支需要的成本
1. 员工薪水，高级技术职员例如研发、devops、QA自动化工程师以及leader；
2. 框架成本 – 该成本用于环境中运行服务器/服务、数据库以及它们所需要的license（Dev-QA-Stage-Prod等等）;
3. 第三方license，举个例子，GitHub私有repo的license，My Get.org（包管理）的license，开发IDE工具例如Visual Studio的license；
4. 研发工作机器；
Serverless架构的性质是什么？
1. 我们不拥有或者控制安全限制之外的成本，例如服务器、虚机或者容器等等；
2. 大部分运行我们代码的FaaS服务都驻留运行在短生命周期的容器中，每个请求对应一个容器，这样可以在服务中规避并发的问题；
3. 基于以上两点，编码需要按照可在大量容器中水平伸缩的原则进行，而不是像运行在大型机器上一样垂直堆砌；
4. 不像在AWS EC2提供的永久或者自动调整虚机中大部分时间可以做的那样，你不能依赖状态保存在内存中的应用；
5. 基于架构分配按照收入需要的原则，FaaS和BaaS一般都按照每个使用的原则付费，如果没有调用，FaaS免费的运行着，BaaS则需要一直付费，因为数据一直都被维护着并且为服务分配着流量；
6. 如果你使用Serverless框架，当然这是笔者强烈推荐的，开发者可以通过在微服务中编码实现对架构的控制；
7. 一般情况下你不需要去选择CPU，在AWS Lambda里是已经分配好的，关于RAM则需要你自己选择。Serverless功能对于繁重的计算需求并不意味着快速，从而关闭一台独立服务器，你可以实现更复杂的设计从而把这类功能伸展成几千个并发运行从而获取更好的结果；
8. 并不是说对于FaaS服务来说分配应答你的请求框架的时间是微不足道的，特别是针对突发流量的场景。以我的经验，AWS Lambda大概需要5~80ms的时间完成动作，时间长短取决于代码量的大小；
9. 你无须考虑并发或者多线程的场景，因为你的框架在任一指定时间点都运行在每请求一容器的模式；
结论
现在我们从产品技术了解了产品的需求以及Serverless架构所涉及的技术，我们可以就Beats产品得出以下结论：
1. 我们借助微服务模式以跟上快速迭代的脚步，提供多用户接口的REST API接口；
2. Beats不是个毫秒级敏感的应用，它只要求可依靠性以及不算慢的响应；
3. 缺乏成本，更重要的是创建维护我们自己服务器的时间在很大程度上投入到了Serverless；
4. 基于FaaS和BaaS的每用户付费原则，我可以拥有24*7在线的环境，而并不需要为它们花很多的钱；
5. Beats不需要任何CPU的大幅提升；
6. 由于bug少的属性、不存在并发场景，还有执行可扩展模型等等，我们花费在非功能性修复的时间会很少；
7. Serverless框架开发人员创建他们自己的架构概念，这就意味着较少的多样化知识的需求，更重要的是开发人员精确的知道他们所创建的以及这些架构运行的环境即可；
好了，希望我回答了为何使用Serverless的问题，在留言区欢迎给我反馈，并看看下面推荐给Serverless架构使用的工具。
工具推荐
框架创建及更新
如果你要使用Serverless，我强烈推荐使用Serverless框架，我写了一篇从零开始的文章可以一步步指导创建你们的第一个Serverless应用
Serverless CI
AWS CodeBuild和CodePipeline提供了Jenkins的一个很好的替代品，不要拥有服务器和
Faas
没什么秘密，AWS Lambda就是我的选择，开始使用吧
API网关
调用你的FaaS所必须的，如果使用AWS Lambda，AWS API网关是你唯一的选择，我不确定哪些和Google以及微软的同等产品兼容
BaaS
AWS Dynamo DB是个很棒的服务，并且还有个很好的缓存层服务AWS DAX马上要上线了
原文链接： https://cloudncode.blog/2017/0 ... ture/
以上所述就是小编给大家介绍的《缘何Serverless架构》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
- 『互联网架构』软件架构-分布式架构（14）
- 『互联网架构』软件架构-电商系统架构（上）（69）
- 『互联网架构』软件架构-电商系统架构（中）（70）
- 『互联网架构』软件架构-电商系统架构（下）（71）
- 『互联网架构』软件架构-电商系统架构发展历程（68）
- 阿里P8架构师谈：淘宝技术架构从1.0到4.0的架构变迁！附架构资料
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
