Node

停更了

数据库还是那么的无聊，有时候就忘了，我觉得数据库更在于设计和优化吧。应该实践多一点好。 我更了很多篇文章，我现在感觉没一点意义，可能只是对关系型数据==熟悉一下吧。

传统的多线程 Web 服务器

当前大多数主流 Web 服务器都是多线程的，包括 Apache 和 IIS。这意味着每个新的访问者（或会话）会拥有单独的线程和对应的 RAM，通常在 8mb 左右。

比如两个人一起进入一家银行并做互相独立的事。在多线程模式下，他们将分别去对应的银行柜员处理自己的需求。双方都不知道对方，也不会受到对方的影响。如果有足够多的银行柜员服务客户，这种方式会运行得非常完美。当银行变得忙碌，客户人数超过银行柜员人数时，服务会开始变慢，客户必须等待，银行永远不会担心这种情况，并乐于让客户排队，但网站和银行和不一样。如果网站响应非常慢，用户会可能会选择离开，并且永远不再回来。

**这就是 Web 服务器通常准备如此多RAM的原因之一，尽管它们在 90%的时间里不会被用到。

单线程 Web服务器

Node.js 服务器是单线程的，并且工作方式不同于多线程服务器。Node.js 服务器会将所有访问者加入同一个线程中，而不是为每位访问者分配独立线程和单独的资源空间。 访问者和线程之间只在必要时才发生交互，比如访问者请求某些内容，或者线程响应某个请求。

假设只有一名银行柜员服务所有顾客。但是与u端到端的处理和管理所有请求不同的是，银行会将所有耗时的任务委托给后台员工，然后直接处理下一个请求。

比如两个人向同一个银行柜员发出请求。 银行柜员不是在下一个请求之前只处理它们中的某一个，而是在接受下个请求前，先接受第一个请求并将它委托给最适合的人去处理。 当银行柜员被告知请求任务已经完成时，就将处理结果传递给最初发送请求的访问者。

对于采用单线程方式完成的工作，必须确认代码里没有触发阻塞的内容。实现方法是将任何会导致阻塞的操作，都处理成异步，以防止它们阻塞主要流程。

REST API

REST 是一种架构风格，而不是严格的协议。REST 是无状态的，它不知道当时用户的状态和历史记录。

API使得应用程序之间能够相互通信。REST API 是应用程序的无状态接口。 当你拿到接口的时候，有个好的文档才是最好的=-=

单页面应用（缺点）

不管是 ng，vue,react 或者是其他的总之使用这些库，或者框架构建单页面应用就像驾驶一辆跑车。但有时单页面应用不是解决问题的最佳方案。

单页面应用的用户体验一般都很好，能减少i服务器上的负载，从而降低服务器托管费用。

对搜索引擎不友好

对于搜索引擎来说，JS 应用程序的内容很难被抓取和收录到。大多数引擎会查看页面的 HTML 内容，但不会执行或下载大量的 JS。正因为如此，JS 创建的内容被抓取到实际效果，远不如服务器直接输出 HTML 好。

如果所有内容都是通过 JS 应用程序提供的，将无法确定其中有多少内容能被搜索引擎收录到

是否重要取决于构建的是什么。对于正在构建的应用程序，如果流量的主要增长计划是通过搜索引擎或社交共享，那么需要考虑这些问题。 另外一方面，当正在构建不需要太多 SEO 的应用程序时（甚至希望网站更难被搜索引擎抓取到）就不必再担心这个问题，这甚至可以算作优势。

谷歌分析和浏览器历史记录

向 Goole Analytics 这些的分析工具，在很大程度上依赖于浏览器 URL 变化导致的新页面的整体加载。单页面应用不是这样，这也是它们被称为单页面应用的原因。

当页面第一次加载完时，应用程序将在内部处理所有后续的页面和内容更改。浏览器永远不会加载新的页面：浏览器历史记录中也不会添加任何内容；分析工具不知道网站上的用户是谁，又做了什么。

问题的严重程度取决与是否需要精确的数据分析服务。如果希望能够监控访问者流量和用户行为的数据趋势，你会发现分析服务很容易整合这些数据。 需要的数据越详细，越精确，要做的开发和测试工作就越多。可以确认在服务器生成网站的每个页面，都比较容易加入分析代码。但数据分析集成不太可能是选择非单页页面应用的唯一原因。

初始化速度

单页面应用相比基于服务器的应用程序，首次加载速度会更慢，浏览器在渲染必要的 HTML 视图之前，必须先加载框架和应用程序代码。而基于服务器的应用程序只需要将必要的 HTML 输出到浏览器就足够了，从而减少了延迟和下载时间。

提高页面加载速度

有些方法可以提高单页面应用的加载速度，例如配置重度代码缓存和懒加载，懒加载是指在模块需要的时候再做加载。但是你永远无法摆脱这样的事实：单页面应用需要下载框架（至少是应用程序的部分代码），并且在浏览器呈现页面几乎都需要通过 API 来获取数据。

选择单页面应用还是非单页面应用

我并不是来分析谁好谁坏，而是花点时间来思考一些经常被忽略的事情，等意识到的时候往往太迟了，我之前做过一个 分享网盘的网站从现在看它的特点应该是交互性强，公开和可分享的，内容丰富的。我当时是用的 MongoDB，Express，Node.JS 构建的 REST API，前端是由 react 构建的单页面应用。现在来看，可以确认非常不合适。

确切地说，希望从服务器直接输出 HTML 内容。Express 特别擅长这些，甚至可以从一开始就支持选择模板引擎。HTML 内容需要数据库提供的数据。 当然还有一种方式更灵活。 此时两个独立的应用程序，每个应用程序使用一个 REST API。通过一些规划可以让应用程序的两端使用一个公共的 REST API。单个 REST API 与两个前端应用程序交互。

如果在 NODE.JS 和 EXPRESS 中构建应用程序，直接从服务器输出 HTML，从 NODE.js 应用程序直接与数据库进行通信将非常容易。从短期看，这是一种简单的方式；但从长远看，这将成为一种困难方式，因为数据与应用程序代码紧密地耦合在一起，其他任何应用程序将无法使用这些数据。

另外一种选择是构建自己的 API，可以直接与数据库通信并输出所需的数据。然后 NODE.js 应用程序可以与此 API 通信，而不是直接与数据库通信，在这个阶段，的确产生了更多的工作量，但是你需要看得更长远。 回想一下，可以设想出三种可能得应用程序架构。

• NODE.js 和 Express 构成的应用程序
• 由 NODE.js 和 Express 构成并使用 框架or库 增加交互的应用程序
• 单页应用

没有任何特殊的业务需求会促使你从上述三种架构中找出最喜欢的那种架构

硬件架构

最初的硬件规格，可以在同一台服务器上负载和运行应用程序的所有部分 数据库，RESTAPI 应用程序。 对于流量较低的应用程序，这种架构是可以接受的，但考虑到应用程序的用户量不断增长。不建议这样做，因为你肯定不希望应用程序和数据库因为同一资源发生冲突。

独立的数据库服务器

我手里刚好有两台过年打折的服务器，通常最先被分离成单独服务器的都是数据库。现在有两台服务器：一台用于部署应用程序代码，另一台用于部署数据库。 这是常见的硬件架构方式，一台服务器运行应用程序代码和 API，另一台服务器运行独立的数据库。

扩展规模

使用三台服务器的分离架构；一台用于数据库，另一台用于 API，第三台用于应用程序代码。