Practitioner

估算在系统设计中非常重要，这决定了你的设计是否可以满足要求，要实现比较靠谱的估算，就需要对如下几个概念熟练掌握第一个概念：二的幂尽管在处理分布式系统时，数据量可能是巨大的，但计算都可以归结为基础知识。为了获得正确的计算结果，关键是要知道使用2的幂的数据量单位。一个字节是一个8位的序列。一个ASCII字符使用一个字节的内存（8位）。可参考如下表格第二个概念：关于延时指标的常见场景注：以下指标说明来自，虽然是基于2010年的状况，但是目前这些指标还是有一定的参考价值。

数据库的扩展有两种方法：垂直扩展和水平扩展。垂直扩展是通过提高现有机器的硬件配置（CPU、硬盘、内存等）来进行扩展。比如，如果使用的是亚马逊的 RDS ，可以得到一个超大内存的数据库服务器，所以在一台数据库服务器，就可以实现存储和处理大量的数据。但是垂直扩展也有一些严重的缺点。虽然可以在数据库服务器上增加更多的 CPU、内存等，但是有硬件的限制，如果用户数量巨大，一台服务器是不够的。单点故障的风险更大。垂直扩展的总体成本很高。如果要配置一个强大的服务器，费用是很高的。垂直扩展的示例图如下。

针对小型网站，日志、监控和自动化支持是很好的做法，但不是必须的。然而，如果网站已经发展到为大型企业服务，日志、监控和自动化工具是必不可少的。日志有助于识别系统中的错误和问题。关于日志，有两种处理方式方式一，在每个单独服务器层面上记录日志；方式二，使用工具将它们汇总到一个集中的服务中，以便于搜索和查看。监控并收集不同类型的指标有助于了解系统的健康状况，一些监控的指标如下主机级指标，例如：CPU、内存、磁盘I/O，等等。汇总级指标：例如，整个数据库层、缓存层等的性能。

消息队列是一个支持持久化的组件，数据存储在内存中，支持异步通信。它作为一个缓冲器，分配异步请求。消息队列的基本架构很简单，包含两个部分第一部分：输入服务，称为生产者/发布者，创建消息，并将其发布到消息队列中。第二部分：其他服务或服务器，称为消费者/订阅者，连接到队列，并执行消息所定义的动作。消息队列可以实现服务之间的解耦，成为构建可扩展和可靠的应用程序的首选架构。有了消息队列，生产者可以在消费者无法处理消息时将其发布到队列中。即使生产者不可用，消费者也可以从队列中读取消息。

无状态的服务在横向扩展服务的过程中，将状态（例如用户会话数据）从服务中移出并将会话数据存储在持久性存储介质中，如关系型数据库或 NoSQL。集群中的每个服务都可以从数据库中访问状态数据。这就是所谓的无状态服务。架构如下有状态的服务和无状态服务不一样，有状态的服务从一个请求到下一个请求都会记住客户数据（状态）。而无状态服务器不保留任何状态信息，架构如下上图中，如果使用有状态服务，用户1的状态数据（比如：会话数据和资料图片）都存储在Server 1中。

CDN 全称 Content delivery network ，即：内容分发网络。CDN 是一个地理上分散的服务器网络，主要用于提供静态内容。如：图片、视频、CSS、JavaScript 文件等。还有一种是动态内容缓存，它可以实现基于请求路径、查询字符串、cookies和请求头的HTML页面的缓存。参考。本文主要介绍 CDN 技术当用户访问一个网站时，离用户最近的 CDN 服务器将提供静态内容。也就是说，用户离 CDN 服务器越远，网站的加载速度就越慢。架构如下整个工作流程如下。

缓存是一个临时存储区域，如果请求的数据获取代价比较高或者数据的访问频率比较高，则会把响应结果存储在内存中，以便更快速地提供后续请求。每次加载一个新的网页，都要执行一次或多次数据库调用来获取数据。反复调用数据库会大大影响应用程序的性能。缓存可以缓解这个问题，架构如下在收到一个请求后，网络服务器首先检查缓存是否有可用的响应。如果有它有，它就把数据发回给客户。如果没有，它就查询数据库，将响应存储在缓存，并将其发回给客户端。这种缓存策略被称为"读过式缓存"。根据数据的类型、大小和访问模式，还有其他的缓存策略。

在中提到了数据库类型的选择，针对大数据量，高可用的场景，数据库复制是一种比较好的方式，其中多个数据库实例之间可以是主/从关系。主数据库通常只支持写操作。从数据库从主数据库获得数据的副本，只支持读操作。所有修改数据的命令，如插入、删除或更新，必须发送到主数据库。大多数应用要求的读和写的比例要高得多；因此，系统中的从属数据库的数量通常比主数据库的数量多。以下是主/从数据库架构的示例图。以上架构的优势是更好的性能。在主从模式中，所有的写和更新都发生在主节点；而读操作则分布在从节点上。

单服务器模型是最简单的一种架构，参考如下图用户访问一个 URL，URL 会先到 DNS 服务器进行域名解析，然后返回给客户端一个 IP 地址，客户端会通过这个 IP 地址访问到真正的服务，服务接收到客户端请求以后，返回对应的 HTML 页面，就完成了整个过程。当然，以上是静态页面，相对复杂的应用会配置数据库，架构如下在选择数据库的时候，会涉及数据库选型问题，有两类比较主流的数据库可以选择，即和。关系型数据库也被称为关系型数据库管理系统（RDBMS），关系型数据库以表和行来表示和存储数据。

关系，Node01 是主，Node02 是备，Node01 挂了，Node02 可以自动顶上。Node01 和 Node02 是接收请求的入口，接下来，会将请求以负载均衡的方式请求后端的 Node04 和 Node05 服务。要实现 IP 的对内可见，对外隐藏，还需要在 Node03 和 Node04 上配置环路接口, 在 Node04 和 Node03 上分别执行。是对应你的 Node03 的信息，然后就可以把 Node03 的 index.html 复制到 Node04 的对应位置了。

API Gateway将访问令牌（例如JWT，即JSON web令牌）传递给服务，这些服务可以验证令牌并获取有关用户的信息。后续模式是指用来解决当前模式引入的新问题的模式，例如，如果你采纳了微服务架构模式，你需要一系列的后续模式来解决诸如服务发现、断路器等微服务带来的新问题。当前模式的替代模式，提供了另外的解决方案，例如，单体架构和微服务架构就是互为替代的模式，它们都是应用的架构风格。前导模式是催生这个模式的需求的模式，例如，微服务架构模式是除单体架构模式以外整个模式语言中所有模式的前导模式。