后端开发：前端Web程序员的启蒙之路

发表时间: 2018-12-03 17:47

如果你是一名想要更熟悉后端的前端开发者和程序员，那么要学习的不同概念的种类和数量，可能会非常庞大。为了感受端到端生产应用程序的强大功能，而无需依赖其他人的帮助；或者你可能只是希望能够与后端团队沟通时更加顺畅。无论你的初衷是什么，更熟悉后端，都会对你大有裨益！

本文，将介绍Web应用中使用的主要组件。如：每个组件的核心目的和好处；它与之交互的其他组件；实现它的常用技术的例子。

Web应用服务器

Web应用程序服务器是运行自定义代码的地方，用于处理客户端的请求（对HTML页面或API调用的请求）。你的自定义代码将调用其他组件来发送或获取数据（例如下面列出的那些），然后将响应发送回客户端。

你可以使用服务器端语言编写此自定义代码，例如Node.js，Python，PHP，Java，C＃或Ruby。每种语言都有自己的Web框架（例如Ruby on Rails，ASP.NET MVC for C＃或Express for Node.js）。这些框架使开发人员能够编写更少的样板代码来处理请求。

除了托管自定义应用程序代码之外，一些Web应用体系结构还使用“Web服务器进程”，例如Apache HTTP Server或nginx。这些服务器进程在到达你的自定义代码之前拦截客户端请求。使用它们有以下几个原因：

快速重定向某些请求，而不是必须通过自定义代码执行。
提供存储在Web服务器文件系统上的静态内容（例如图像，CSS，JS）比通过自定义代码更快。
某些服务器端语言（例如PHP）没有内置生产级Web服务器，因此需要通过专用Web服务器进程启动。

安装这些工具和自定义代码的Web服务器计算机本身可以采用以下几种形式：

一台物理机器
虚拟专用服务器
托管的虚拟机实例（例如AWS EC2，谷歌GCE）
平台即服务（PaaS）主机（例如Heroku）

负载均衡

如果你预计流量高峰或高正常运行时间很重要，你可以决定在2个或更多应用服务器上安装自定义代码。在这种情况下，将需要使用负载平衡。

负载均衡是从客户端接收请求然后将其转发到Web应用服务器的服务器。

你需要告诉它将转发客户端请求的Web应用服务器的位置（IP地址或域名）。然后，它将向每个应用服务器发送称为“运行状况检查”的常规ping消息（例如，每5秒），以确保服务器响应。当负载均衡收到客户端请求时，它使用算法（例如循环法）将请求转发给下一个健康的应用服务器。

在Web应用程序中使用负载均衡有两个主要好处：

它通过确保单个Web服务器不会被所有请求淹没，来帮助维持一致的响应时间，因此处理每个请求的速度会更慢。
它保持高可用性。如果服务器崩溃，所有后续客户端请求仍将继续，因为它们将路由到正常的服务器，并且你的最终用户不会发现任何问题。

负载均衡实现的一些示例如：

HAProxy：可以在自己的虚拟机上安装的开源软件

域名系统（DNS）

当用户在其地址栏中输入URL时，浏览器将获取URL的域部分（例如www.google.com）并调用DNS名称服务器。名称服务器发回该网站服务器的IP地址位置（例如172.217.23.4）。一旦它具有IP地址，它就可以发送对网页的实际请求。

如果你的Web应用程序使用负载均衡，则应将域名配置为指向负载均衡的域名或IP地址。如果你没有使用负载均衡，那么可以将域名直接指向应用服务器的域名/IP地址。

大多数互联网域名注册服务都提供DNS管理控制台。这些允许你配置域名（和子域）以指向你的应用程序的位置。

HTTPS/SSL证书

如果你正在构建Web应用（或静态网站），则需要通过HTTPS提供服务，以确保用户与服务器之间的安全通信。现在使用HTTPS也有SEO的好处，所以没有理由不使用它。

这意味着你需要在后端安装SSL证书。具体来说，需要在任何服务器上安装它们，这是客户端请求的第一个联系点。这通常意味着负载均衡和CDN服务器，但如果你没有使用负载均衡，也可能是应用服务器。

你可以使用LetsEncrypt免费生成证书。或者，如果使用的是云基础架构，则可以使用托管服务。这允许你创建并自动续订SSL证书并将其分发到应用服务器，负载平衡和CDN服务器。

数据库

几乎所有Web应用都需要在某处保留数据。在大多数情况下，某处是某种形式的数据库。数据库的主要工作是将数据可靠地保存到永久存储中，并允许通过查询检索数据。它还可以围绕它存储的数据结构强制执行一些规则。

有许多不同的数据库实现。但是，最多有2个高级类别：关系数据库（基于SQL）和“NoSQL”数据库。关系数据库（例如MySql，Postgres，SQL Server，Oracle，SQLite）已经存在了40多年，并且一直是大多数Web应用的支柱。在过去十年左右的时间里，NoSQL数据库（例如MongoDB，Cassandra，CouchDB，DynamoDB）在Web应用中变得越来越普遍，主要是因为它们具有可扩展性优势和数据结构灵活性。

你可以在一台服务器上托管数据库，但在生产方案中更常见的是将其托管在某种形式的集群中的2台或更多服务器上。这可确保数据库具有高可用性并降低数据丢失的风险，例如，如果一台服务器的存储损坏。

近年来，少数云托管的“无服务器数据库”已经可用。这些是你可以通过API调用的数据库，但你无需担心设置服务器来托管它们。除了处理诸如自动备份之类的事情之外，云供应商还为你无形地执行此操作。如亚马逊DynamoDB（NoSQL），Firebase实时数据库（NoSQL）和Aurora无服务器（关系型数据库）等等。

Blob/文件存储

虽然数据库通常用于存储动态数据（例如，由最终用户或API客户端生成），但是存在某些类别的数据，这些数据不能由用户改变或者基于文件而不适合数据库存储。这方面的例子是：

前端网站资产，如图像，Javascript，CSS，字体，音频，视频文件
用户通过表单上传的文件

云供应商不是将这些存储在数据库中，而是提供专用服务来存储这些服务，例如AWS Simple Storage Service（S3），Google Cloud Storage和Azure Storage等等。

这样做的好处是云供应商可以安全地存储文件，并可以为其制作冗余副本，以最大限度地降低数据丢失的风险。

“Blob”是用于表示Web应用程序用于存储其静态内容的顶级存储文件夹的术语。

内容分发网络（CDN）

Blob/文件存储服务允许客户端通过HTTP端点访问文件。例如，你的Web应用程序的HTML标记可以简单地链接到云中存储的图像和CSS文件的URL。但是，假设你的用户位于欧欧洲，而购买的云存储位于美国，数据传输距离很远，因此用户会有延迟。

CDN是云供应商提供的服务，它们在全球范围内分布有“边缘服务器”。这些边缘服务器从“原点”（例如，blob /文件存储位置）获取文件的副本。你的前端Web应用程序将指向其CDN URL，而不是指向静态资产的Blob存储URL。现在，客户端和“边缘”之间的距离更近，因此文件的获取速度更快。

常用CDN的，比如CloudFlare。

缓存服务

虽然CDN是静态文件的一种缓存形式，但Web应用可能需要临时缓存动态数据。

例如，假设存在一个数据库查询，该查询对昨天的数据进行计算，其结果每天经常被成千上万的用户访问。那么，每次用户请求此数据时都联系数据库则没有太大意义。

对此的解决方案是使用高速缓存服务在第一个用户请求之后将结果存储一段时间。通过缓存可以更快地提供对该数据的后续请求。

缓存服务本质上是一种特殊类型的数据库。上面数据库部分中基于服务器的集群注释都适用于此处。缓存采用键值存储的形式，其中键是应用程序代码用于查询数据的字符串（例如DailySiteStats_2018-12-3），值是缓存的实际数据。缓存的数据通常完全保存在内存中，这使得从缓存中检索数据的速度非常快。

常见的缓存服务如Redis和Memcached。

消息队列

有时，你需要执行的任务与响应用户请求没有直接关系。

例如，假设用户上传了你现在需要编码和水印的视频。但这是一个长期运行的任务，因此让用户在完成时等待是没有意义的。更好的方法是异步执行此操作。你网络应用程序代码会在队列中创建一条作业消息，并通知你的用户，当水印视频准备就绪时，他们将收到一封电子邮件。

然后，你将拥有一个可以执行以下操作的工作任务：

从队列中读取消息
开始处理视频
完成后，保存视频的编码副本
向用户发送通知电子邮件
从队列中删除消息

这里有2个架构组件：

应用程序将作业写入的消息队列本身
从队列中读取并执行处理的工作任务常用消息队列服务的示例是ActiveMQ，RabbitMQ。

可以通过以下几种方式实现任务：

调度计划任务以触发应用程序服务器上安装的某些自定义代码，以便按特定计划从队列中读取
每当将消息添加到队列时，使用功能即服务平台（FaaS）来调用你的工作程序代码。

功能即服务（FaaS）

功能即服务是一种可以在云基础架构上运行自定义代码的方式，无需担心配置和维护运行该代码的服务器。你可能还会听到这种称为“无服务器”计算（尽管严格来说FaaS是无服务器的一个子集）。

FaaS有很多用例：

数据处理工作
后端服务集成
自动化服务器维护和编排任务
构建Web API
服务器端HTML呈现

FaaS提供程序的示例包括AWS Lambda，Google Cloud Functions和Azure Functions等。

全栈开发的未来将更加轻松

随着无服务器技术的成熟及其局限性的降低，我相信FaaS和其他完全托管的云服务将在未来几年内在Web应用程序架构中变得更加普遍。

有抱负的全栈开发人员的好消息是，这意味着许多上述架构概念（例如应用服务器，负载平衡）将变得多余。它们的复杂性正被吸收到将使用的云服务中。成为一名成熟的全栈工程师的障碍正在降低。

这使你可以更专注于真正的商业价值所在：为用户设计和编写应用程序代码。