以云计算目前的创新速度，业内流行语和噱头可能会从字面上给用户造成误导或混淆。可能你已经听说过使用无服务器计算平台构建应用程序，或设计运行在微服务架构上的软件等类似例子。即使这些想法听起来像噱头，但现实是，他们正在改变企业构建、部署和运行应用程序的方式。
无服务器计算是开发人员构建应用程序而不必考虑服务器的一种方式。它只是个抽象层，使开发人员能够专注于编写代码，同时忽略服务器和传统基础设施概念。
2014年，亚马逊发布AWS Lambda，这项服务使开发人员能够创建在现有托管实例上运行基于云的函数。 AWS稍后发布了其API网关服务，可用于配置公共节点以通过HTTP调用Lambda函数。综合来看，AWS Lambda和API网关能够帮助组织建立Web、移动和互联网后端，这些后端完全可扩展，而且不需要服务器。
AWS技术被认为是无服务器计算架构类的领导者，但该公司不是唯一提供商。 Microsoft、Google、IBM等也发布了类似产品，被视为函数服务(FaaS)。开发人员可以与任何提供者创建和运行函数，以实现无服务器应用程序体系结构。
更高的可扩展性效率
无论FaaS平台如何，无服务器计算架构受到很多关注。以下是FaaS平台的一些主要功能，使其成为一种极具颠覆性的技术。
- 降低复杂性。 在公有云平台如AWS和Azure的支持下，构建高可用性的应用程序架构变得更为容易。在负载平衡器后启动自动缩放的虚拟机非常简单。你甚至可以跨多个地区扩展应用程序架构，以实现地理冗余。
通过无服务器计算，基础架构将消失。开发人员可以完全专注于编写支持应用程序功能的代码。云平台负责管理调用这些功能的服务器，因此其可用性非常之高。
- 内置可扩展性。 在云中构建Web应用程序的最棘手的部分之一是调整虚拟服务器规模的自动缩放。必须找到正确的平衡点，以确保可以根据流量峰值进行扩展，并在高峰消失时收缩。听起来很简单，但每个应用程序都有自己的行为，并且必须调整设置以优化成本并提供最佳性能。使用无服务器计算，就是将这项任务转移到供应商，客户可以更自由地关注应用程序。例如，AWS Lambda服务运行在完全管理下的Elastic Compute Cloud实例上。该服务将根据正在执行的代码对应用程序进行扩展，开发人员或运维工程师不再需要管理虚拟机或自动缩放组。
- 消除空闲资源。 无服务器计算的另一大优点是，只需要在实例运行代码时才付费。对于传统服务器，即使使用自动缩放应用程序，也会占用一些资源。但是无服务器，只有有人实际使用应用程序时，才需要付费。不必支付小时费用来运行可能执行或未进行任何工作的虚拟机。AWS通过其Lambda服务提供次秒计量，因此只需按每100毫秒执行代码的次数来计费。其他FaaS提供商提供类似的定价。
深入无服务器架构
要了解无服务器应用程序的构建方式，让我们看看使用AWS无服务器架构的常见Web应用程序。
- 前端层。
为Web应用程序前端提供支持的静态资源托管在Amazon Simple Storage Service(S3)(即AWS对象存储服务)中。你可以使用S3将某个bucket，理解为某个文件夹，转换成静态网站。可以在此位置存储HTML、Javascript、CSS文件和图像静态内容。
Amazon CloudFront(内容传送网络(CDN))分发这些资源。CDN是可选的，但可以减少最终用户访问静态内容的延迟。总的来说，这个想法是，通过客户端Javascript框架与静态无服务器网站驱动应用前端。该框架可以调用Lambda为应用程序执行后端工作。
- API层。
在这种情况下，AWS Lambda和API网关为网络应用程序的后端支持。开发人员可以编写离散的无状态Lambda函数来处理支持应用程序的各种资源的创建、读取、更新和删除操作。前端代码通过API网关调用Lambda函数来为应用程序做大量工作。
- 数据库层。
持久性数据可以存储在其他托管服务中，例如Amazon DynamoDB，即NoSQL数据库服务，或Amazon Relational Database Service。 AWS Lambda功能可以直接与这些服务进行通信，以保留数据。
请记住，这只是无服务器架构的一个例子。移动和互联网的后端，以及实时流处理，是无服务器计算的其他用例。
亚马逊和Netflix多年来一直使用微服务架构风格。微服务的想法是将一个大型应用程序分解成面向任务的服务集合。
商业应用程序通常构建为单个唯一单元。这些通常包括为最终用户提供HTML的应用程序前端，用于处理繁重的业务的后端服务器端代码以及用于存储和保留数据的数据库层。单片应用架构多年来运作良好。但随着应用程序的发展，为支持大量的用户，更新变得更加困难。因为单片应用程序的组件是紧密耦合的，即使对代码库的轻微更改也可能需要一个全新版本的应用程序。
作为替代，许多较小的微服务器可以集中地为整个应用程序提供支撑。因为微服务通常没有连带责任，他们专注于实现单一工作或执行支持整个应用程序的某个任务。
微服务的好处
那么为什么企业需要分解单一应用程序来组建微服务架构呢?有一些坚实的理由。
微服务组成部分：轻量级应用程序;耦合低，甚至没有;更改代码库可能需要完整的APP新版本。
- 故障隔离。 当应用程序的每个组件作为单独的服务运行时，可能会失败，而不会破坏整个系统。负责微服务的不同小团队可以快速迭代，并对代码库进行更改，而不会在整个应用程序中造成错误。这样可以减少应用程序的总体停机时间，并提高小型团队构建和支持特定微服务器的生产率。
- 松耦合。每个微服务都是完全独立的，可以运行自己的技术栈。只要应用程序内的其他服务可以使用非专用HTTP API与微服务器进行通信，则微服务器的基础实现可随时更改。这使得团队能够实现最有意义的技术，并且它防止了使用单个技术堆栈来满足整个单应用程序的要求。
- 减少进入障碍。较小的微服务不太复杂，因此更容易理解。这使得新加入的开发人员更容易与现有团队进行合作。
与目前利用公共云的FaaS不同，微服务架构可以在内部机房或云端运行。
虽然使用容器构建微服务是常见的，但新兴的实践是构建微服务器架构与无服务器功能。你可以在Amazon S3中部署静态网站，并使用前端代码在整个体系结构中调用一个或多个微服务API。
在尝试之前的考虑
毫无疑问，这里讨论的模式和做法有很大的优势。然而，在深入无服务器的微服务之前，有一些重要的事情要考虑。
- 供应商锁定。 每个无服务器的计算平台都具有自己的功能和特性。一般来说，通用语言，包括Javascript、Python和C#将可从AWS，Microsoft和其他主要提供商获得。
即使如此，决定拿起并移动到另一个平台也许需要大量的工作。
- 开发工具。 在这个阶段最大的困难之一是开发者工具。致力于大规模无服务器应用程序开发的IT团队需要通过一些工具管理依赖关系。预计未来几年该领域将会大幅进步。
- 服务限制 每个提供商将有自己的函数可以执行多长时间，以及可用于应用程序代码和依赖关系的容量限制。
这是在检查无服务器应用程序时应该注意的事项。
- 业务成熟度。部署和支持微服务架构并不是为了微弱的心脏。当然，亚马逊、微软和Netflix都已经非常成功地采用了这些模式。但并不是每个团队都有类似的技术技能。如果您正在考虑使用无服务器的微服务方法，请准备聘请有才华的员工，并提供培训，以便现有员工能够获得成效。
