Serverless架构实践

　　如果你曾经想过“应该有一个实现这种功能的应用”，并憧憬有谁能够为你开发一个就好了，现在我们有一个好消息，那个人找到了，就是你自己。

　　Web应用可以是非常强大、高效和易扩展的，但却不应该是复杂的。简单就是Web应用的一大优势。你可以利用这种优势来搭建自己的解决方案，实现自己的创意。一旦了解所有模块是如何搭建到一起的，你就能开发出想要的应用了。

　　本书是一本实用教程，将会演示一种无服务器的方案来搭建Web应用。使用这个方案，大部分运维方面的问题就不需要你自己操心了，而且也省去运行服务器的费用。你能集中时间和精力开发想要的应用，而让其他人去考虑业务发展带来的应用上线、配置、升级、扩展服务器等问题。使用多层Web框架、自动生成的代码或者拷贝模板，这些方法并不会带来这样的好处。等我们一起学完本书，你就会知道如何通过移除部分代码和消除中间层来交付更好的应用。

　　为了能够快速演示开发过程，我们将使用一个预设好的工作空间，里面加载了搭建完整Web应用必需的所有模块。首先，我们会完成一个单页应用，用Java、HTML和CSS代码来实现原来在服务器端实现的逻辑。我们将根据Web标准，深入挖掘单页Web应用的必要功能，从零开始搭建，从而了解它们的运行机制，保证这种设计能符合我们应用的要求。当仅凭Web标准不能完全实现需求时，我们会使用jQuery来填补差距。最后，我们会使用测试优先的方法来渐进式开发，以保证单页应用的可测试性。

　　为了降低中间层成本并确保我们的应用能供上百万的用户使用，我们使用Amazon Web Services（AWS）作为无服应用的后端。你将看到如何使用高可用、高可扩展、更便宜、更易维护的云服务来替换掉传统Web应用的服务器、数据库和负载均衡器。我们将讨论在开发此类应用时会碰到的一些安全性问题，并会介绍随着应用业务的扩展可能会用到的其他技术和工具。

　　我希望能够让你看到新的可能性。以前非常费时费钱的应用开发或许能变成一个人在一两天内就可以完成的事情。随着技术进步和个人能力的提升，更多的梦想将会实现。一旦理解了这些技术的发展，你就会发现从前因为太难而几乎无法实现的目标，现在可以借由新途径来达成。读完本书，你将学会将创意变成真实应用所需的技能。

　　无服Web应用

　　在传统Web应用中，服务器是系统不可缺少的组成部分。尽管有时候服务器的前面还有负载均衡器或者专用Web服务器，但完成大部分工作的还是应用服务器。它完成一个应用所有的必要功能，包括存储用户数据、进行安全认证、控制流程等。应用的页面大部分仅仅只是为后端提供界面而已，尽管也会涉及一些控制导航的功能。使用这种许多人称之为多层架构的传统方式，系统一般会由浏览器、应用服务器和多个后端服务构成（见下图）。

　　使用无服的方式，可以移除所有这些层次架构，达到更直接的实现。与其仅仅把网页客户端当作应用服务器的界面展示，不如构建一个单页Web应用在浏览器中实现应用逻辑。这意味着你只需要一个简单的静态网页服务器，所有的交互都只不过是应用内容的传输而已，浏览器就像是一个应用容器。这样，最终的设计就是移除传统Web应用架构中所有的中间层次，允许浏览器直接连接到它所需要的服务上。

　　使用Facebook、Google和Twitter之类的OAuth 2.0身份认证服务商提供的服务，无须保存用户密码就可以创建用户身份。如果要存储数据，你可以在浏览器端直接使用Amazon DynamoDB之类的服务。在浏览器中无法执行的函数都可以使用Amazon Lambda微服务或者其他专门的Web服务来处理。除了能够简化架构，这种切换到Web服务作为后端的方式，还能让应用获得这些服务与生俱来的可用性和可扩展性优势。

　　你可能会好奇到底发生了什么，使这种方式成为可能。为什么现在在一个Web应用中，中间层的应用服务器变得可有可无呢？答案是，自从2015年以来，类似Amazon这样的云服务提供商开始对外提供服务的API，这使得无服务器的方式成为可能，Amazon本身也为如何使用他们的工具和基础设施提供了最好的示范。

　　基于Web标准搭建一个单页Web应用，而不是使用服务器端Web框架来完成，我们可以快速应用一些新兴技术。例如，我们不再需要将应用的数据模型绑定到任何一个对象层级或者数据同步机制上，因而能更方便地集成不同服务。既然我们所有的工作都倚赖于Web，就不必拘泥于以前搭建Web应用的成见，可以用目前最新的技术来搭建应用（见下图）。

　　无服设计的好处

　　如果你在寻找一种快速搭建低成本Web应用的方法，无服Web应用很可能就是一个解决方案。不需要花费时间和精力了解传统Web应用技术栈的各个层级，采用这种方式你能更专注于实现业务功能，有人会为你操心运行维护和可扩展性的问题。接下来让我们深入探讨无服设计的好处，帮助你在考虑下一个项目中是否使用这种方式时做出更明智的决定。

　　零服务器

　　无服设计最明显的好处就是不需要维护服务器（不管是物理的还是虚拟的）。你不需要担心打安全补丁、监控CPU和内存使用情况、回滚日志、磁盘空间不足或者其他在维护自有服务器时经常碰到的运维问题。和大多数平台即服务（PaaS）方式一样，无服设计能让你专注于应用开发，而无须担心基础设施的问题。

　　易扩展

　　这种设计方式的另一大好处是，你可以依靠云服务供应商来扩展自己的应用。在做水平扩容时，不需要忙不颠地在几个负载均衡应用服务器之间保持数据的一致性，你可以直接连接Web服务，而它们已经解决了数据一致性的问题。这意味着不管你的应用有几个用户、几百个用户，还是几十万个用户，只需要修改Amazon Web Services控制台的一些设置就可以保证完美的运行。

　　高可用

　　另外，使用这种设计能轻松实现高可用性。你不必为了升级而关闭应用服务器，或者为了实现“热”部署而扩建基础设施。不再会有服务的重启或者部署包在服务器间的拷贝。最妙的是，Amazon有一群训练有素的员工7×24小时守护着你的基础设施，一旦发现问题随时能够响应。

　　低成本

　　这些服务的成本可以非常低。使用无服的方式以及利用Amazon的免费套餐（Free Tier），一个月支付几美分就可以运行你的应用。一旦超过了免费额度，其费用经常也是随着你的用户量线性增长的（考虑费用最高的情况）。我们在这本书里构建的应用就算扩展到100万的用户，一天也只需要花费一杯咖啡的钱。

　　（微）服务友好

　　这种方式可以轻松适应微服务或者其他的面向服务架构。你可以在系统中引入特定的服务以实现自定义身份认证、验证或者异步数据处理。如果有必要，你甚至可以重新引入应用服务器，渐进式地重构应用。反之，如果一开始就使用一个中间层来控制所有的安全证书，就很难切换到需要认证的Web服务上。这些应用服务器没办法像无服应用一样，在应用层管理身份信息。

　　代码更少

　　在传统Web应用里，一些操作（比如导航）在Web客户端和服务器端都需要执行，造成了代码的重复。有时候，这种重复工作并不明显，尤其当服务器代码是用不同的语言写时。而在无服应用中，应用逻辑都移到了客户端，很容易保证应用内不再有重复的代码。将应用逻辑代码放在一个位置（以及用一种语言实现）帮助我们解决了这个问题。

　　此外，无服的方式更便于构建和排错，因为系统的组成部分变得更少了。Web应用天生就是分布式的，也就是说，正如CAP理论所述 ，它们在同一个网络的节点间传递消息（一般是以请求和响应的形式），限制它们的是实现方式。

　　有些应用会比其他应用更分散（more distributed）。一个系统越分散，就越难排错。移除应用中的中间层能减少其分散的程度。在我们这个简单的应用中，如果一个客户端需要从一个数据库中获取数据，就会直接连接数据库，而不是通过中间层连接。这就意味着系统中的网络节点更少，也意味着如果出现问题，需要定位的地方更少。

　　如上所述，构建一个无服应用的理由有很多。学完本书，你就会明白为什么这种方式如此强大。了解了无服应用的这些优点，我们再来看看它有哪些限制。

　　无服设计的限制

　　尽管无服架构有许多优点，但它也不是适用于所有类型的应用。为了享受这种设计带来的益处，你必须接受一系列的限制。如果你的应用不能适应这些限制，那么它很可能不是最合适的构建方式。所以在搭建应用之前，让我们一起看看这些限制。

　　供应商锁定

　　首先最大的限制就是你使用的Web服务必须支持第三方身份认证服务商，这样在云服务提供商的选择上就受到了限制。所以如果使用无服的方式，你就会依赖于第三方服务，供应商锁定也就成了一个问题。构建一个基于其他公司服务的系统，意味着这个应用的命运和供应商公司的命运绑在了一起。如果供应商公司被收购、破产或者改变商业模式，你的应用不下大力气修改就很难在其他地方运行。所以，评估服务提供商的业务目标和长期稳定性与技术选型是同样重要的。

　　奇怪的日志

　　所有运维关注的事情，比如应用日志，在你使用无服设计之后会呈现新的形态。当你把所有请求都通过一台服务器路由时，记录下所有信息以查看用户正在做什么是非常简单的事情。没有了这种中心化设计，日志的记录必须由每个支撑应用的不同Web服务来实现。这些日志格式跟大部分应用服务器日志都不同，记录的数据也很可能是你不熟悉的。我们在后面第8章的“分析S3日志”会深入探讨Web服务日志的分析。

　　不一样的安全模型

　　对于无服应用，有些常见的安全隐患不复存在，但你将会遇到一些不熟悉的新问题。比如，为了安全而验证用户数据，结果不能在浏览器中安全地实现。你需要假设有些恶意用户可能会在浏览器中劫持证书而使用该证书授权的Web服务。使用无服的方式，意味着你不能把浏览器中的应用验证逻辑和安全验证逻辑放在一起，必须分开实现。

　　Amazon提供的许多Web服务都能验证请求。你可以参考第5章的“数据访问和验证”一节内容利用DynamoDB来实现。然而，对于有些应用来说，很难只用Web服务提供的工具来实现充分的有效性约束。比如，在浏览器中直接编写文本时，你不可能放心地将写入的数据编码后存到数据库中，保证不会有跨站脚本攻击发生。因为攻击者不使用应用就能直接将这个数据添加到数据库。

　　这种情况下，你有（至少）两个选择。第一，可以假设某些用户可编辑的表可能包含未经验证的数据，然后针对性地设计系统的其他部分。比如，用户只能写入他们自己可读取的数据，这是可行的方式。第二，可以将某些写操作委托给自定义Web服务，比如可以使用Lambda函数来进行验证，并且以一种安全的方式写入数据。我们将会在第6章的“使用Lambda构建微服务”中详细介绍。