「全栈之路」Web前端开发的后端指南

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

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

目前SSL证书根据验证级别分为三种类型

一般情况下，企业类网站使用的OV SSL证书比较多，而且价格也适中，在大众用户可接受范围内。

5、数据库，Database

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

5.1 数据库的种类

早期比较流行的数据库模型有三种，分别为层次式数据库、网络式数据库和关系型数据库。

而在当今的互联网中，最常用的数据库模型主要是两种，即关系型（SQL）数据库和非关系型（NoSQL）数据库。

5.2 数据库部署

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

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

5.3 数据库基础方案

来源：架构设计之「数据库从主备到主主的高可用方案」

无论底层是关系型数据库，还是NoSQL数据库，无论是 Mysql 还是 Redis、MongoDB，在架构设计上都是相通的。

数据库服务器的基础方案分为三种：

1、一主一备的架构(主备式)

主备式架构是双机部署中最简单的一种架构，几乎市面上所有的数据库系统都会自带这个主备功能。

其思路也特别的简单：

这个架构的优缺点都很明显，优点就是几乎不需要做什么开发改造，各类数据库就支持这种模式，部署维护起来也简单，并没有引入额外的系统复杂度和瓶颈。

但是缺点呢，就是当「主机」出现故障的时候，需要人工去干预啊，运维同学很辛苦的，而且处理还不一定及时。再还有一个缺点就是，主备架构会造成严重浪费资源，毕竟需要一台与「主机」同等配置的「备机」长期备着，但又不作为线上服务来使用，你说浪费不浪费。

为了解决这个资源浪费问题，我们就得想一个把「备机」也用起来的方案：主从式架构。

2、一主一从的架构(主从式)

主从式架构大体上与上述的主备式架构差不多。区别就是主备式的「备机」平时是不干活的的，主要起到备份的作用。而主从式的「备机」改为了「从机」，平时也要提供服务，跟「主机」一样随时随刻的在干活的。

主从式架构中的「从机」虽然也在随时随刻提供服务，但是它只提供「读」服务，并不提供「写」服务。「主机」会实时的将线上数据同步到「从机」，以保证「从机」能够正常的提供读操作。这种架构相比较主备式，对资源是一种节约，毕竟「从机」也在提供服务，没有白白的浪费。并且在「主机」出现故障时，在人工介入之前，好歹「从机」也是能够提供数据的「读」操作的，毕竟大多数业务都是「读」多「写」少，因此对稳定性又提高了一个层次。缺点就是架构稍微复杂了一点，毕竟「主机」和「从机」都有「读」服务，那么前端业务系统就需要用一定策略去判断该路由到哪一台去读取数据。还有就是，延迟问题，「主机」的数据同步到「从机」难免会有一定程度的延迟，这个延迟可能会对数据实时性要求较高的业务有一定影响。

3、互为主从的架构(主主式)

互为主从的架构是指两台机器自己都是主机，并且也都是作为对方的从机。两台机器都提供完整的读写服务，因此无需切换，客户机在调用的时候随机挑选一台即可，当其中一台宕机了，另外一台还可以继续服务。

至于数据库集群方案，我暂时没看懂，就不写了。。。

6、Blob / 文件存储

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

云服务供应商不是将这些存储在数据库中，而是提供专用服务来存储这些服务，例如 AWSSimpleStorageService（S3）， Azure， GoogleCloudStorage和阿里云 OSS等。

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

6.1 关于 Blob 存储:

Blob 存储用于：

7、内容分发网络（CDN）

Blob /文件存储服务允许客户端通过 HTTP端点访问文件。例如，您的Web应用程序的HTML标记可以简单地链接到AWS S3中存储的图像和CSS文件的URL。传统网络访问：

但是，假设我的用户位于中国，我的S3存储位于美国西部 - 数据传输距离数千英里，因此我的用户会看到延迟。

CDN是什么？使用CDN有什么优势？

使用了CDN的网站访问：

7.1 CDN工作流

通过权威DNS服务器来实现最优节点的选择，通过缓存来减少源站的压力。

8、缓存服务：CachingService

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

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

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

缓存服务本质上是一种特殊类型的数据库。 缓存采用键值存储的形式，其中键是应用程序代码用于查询数据的字符串（例如DailySiteStats_2018-10-17），值是缓存的实际数据。缓存的数据通常完全保存在内存中，这使得从缓存中检索数据的速度非常快。

常见的缓存服务是 Redis和 Memcached。AWS通过其 Elasticache服务提供这两者的托管版本。

8.1 Redis和 Memcached对比

Redis和 Memcached是都是主流的开源内存数据存储。虽然它们既易于使用又提供高性能，但在选择引擎时需要考虑重要的差异。Memcached是为简单而设计的，而 Redis提供了丰富的功能，使其能够广泛用于各种用例。

MemcachedRedis亚毫秒级延迟是是开发人员易用性是是数据分区是是多语言支持是是高级数据结构-是多线程架构是-快照-是复制-是发布/订阅-是Lua脚本-是地理空间支持-是

亚毫秒级延迟:

Redis和 Memcached都支持亚毫秒的响应时间。通过将数据存储在内存中，它们可以比基于磁盘的数据库更快地读取数据。

开发人员易用性:

Redis和 Memcached在语法上都很容易使用，并且需要最少量的代码才能集成到您的应用程序中。

数据分区:

Redis和Memcached`都允许您在多个节点之间分发数据。这允许您在需求增长时向外扩展以更好地处理更多数据。

支持广泛的编程语言:

Redis和 Memcached都有许多面向开发人员的开源客户端。支持的语言包括 Java，Python，PHP，C，C++，C＃，JavaScript，Node.js，Ruby，Go等等。

高级数据结构:

除了字符串， Redis还支持列表，集合，有序集，哈希，位数组等。应用程序可以使用这些更高级的数据结构来支持各种用例。例如，你可以使用Redis排序集轻松实现游戏排行榜，该排行榜保持按其排名排序的玩家列表。

多线程架构：

由于 Memcached是多线程的，因此它可以使用多个处理核心。这意味着您可以通过扩展计算容量来处理更多操作。

快照:

使用 Redis，您可以使用即时快照将数据保存在磁盘上，该快照可用于存档或恢复。

复制:

Redis允许您创建 Redis主数据库的多个副本。这允许您扩展数据库读取并具有高可用性集群。