大家好，欢迎来到IT知识分享网。

软件架构：我希望我早点知道这一点……

作为一个非技术人员，我一直在努力理解应用程序的底层。随着时间的推移，它变得更好了：感谢各种书籍、文章、聚会、我的技术朋友，当然还有一位 Java 开发人员，他也是我的丈夫 :)

嗯……

在这个故事中，我想推荐和回顾一本书，我认为对于没有技术背景或教育（或拥有但在工作环境中不确定）的每个人来说都是必须的。这是Artur Ejsmont 的“面向初创工程师的 Web 可扩展性”一书。虽然这本书是关于 Web 应用程序可扩展性的，但它实际上解释了软件架构的核心概念和组件。我不能告诉你这本书是如何清晰和明确的！

重要笔记

这个故事完全基于Artur Ejsmont 的专业知识和知识。我不会假装自己不是技术专家（至少现在）。

我在这个故事中分享的内容非常有限。在阅读这本书时，我为自己准备了包含 20 页 Google Docs 的摘要。如果您想提高对软件架构的理解，我建议您阅读本书，准备摘要，并与技术朋友或同事讨论您所学到的知识。

要记住的一张图片

Web 应用程序架构概述（面向初创工程师的 Web 可扩展性，2015 年，Artur Ejsmont，第 23 页）

0. 客户：您的 Web 应用程序的最终用户。
1.域名系统（DNS）：基于域名（例如olgamitroshyna.com ）定义IP地址（将处理用户请求的服务器的地址）。
2.负载均衡器：在多台服务器之间分配流量以分担负载。
3,5。缓存：存储数据以更快地满足用户请求。
4.前端应用（Front-end）：这是用户界面，一个应用皮肤，一个表现层。
6. 消息队列：存储用户请求以供 Web 服务进一步处理。
7. Web 服务（后端）：业务逻辑（应用程序功能）所在的位置。
8. 数据存储：Web 服务从哪里写入数据和读取数据。
9. 搜索引擎：负责数据存储无法有效处理的复杂搜索查询。
10. 内容交付网络 (CDN)：存储静态文件，如图像、CSS 和 JavaScript 文件，以更快地满足用户请求。
11. Queue Workers：处理来自消息队列的请求（即消息）的附加服务器。

前端层

前端层组件有：

• 域名系统；
• 内容分发网络；
• 负载均衡器/反向代理。可以是以下三种类型之一：
  a) 托管服务（例如 Amazon 的 Elastic Load Balancer）；
  b) 一个自我管理的基于软件的负载均衡器（例如 Nginx）；
  c) 硬件负载平衡器。
• 前端 Web 服务器（表示和后端结果聚合层；技术：PHP、Python、Groovy、Ruby 或 JavaScript (Node.js)）。

同样重要的是要知道前端层通过以下方式存储有关HTTP 会话的信息（有关用户的数据）： a) cookie；或 b) 外部数据存储；或 c) 负载均衡器（如果这是粘性会话的情况）：负载均衡器需要确保具有相同会话 cookie 的请求始终发送到最初发出 cookie 的服务器。

后端层/网络服务

实现应用程序的选项：

1. 构建单体应用，然后根据业务需求添加 Web 服务；
2. 遵循 API 优先的方法：所有客户端（移动应用程序、桌面网站、移动网站等）在与 Web 应用程序通信时使用相同的 API 接口；
3. 以上两者结合。

网络服务的类型：

• 以函数为中心
  > 能够在远程机器上调用函数的方法，而无需知道这些函数是如何实现的；
  > 示例：SOAP（使用 XML 和 HTTP 协议）；SOAP 比 REST 更复杂和安全，REST 在文档方面比 SOAP 更轻量。
• 以资源为中心（REST + JSON）
  > 资源被视为对象，可以对对象进行 4 种操作：读取、创建、更新和删除（GET、POST、PUT、DELETE）；
  > REST 需要身份验证才能访问资源（OAuth 2）；
  > 取决于传输层安全性 (HTTP S )。

扩展 REST Web 服务：

• 进入功能块/功能分区
  > 一种将服务拆分为更小的、独立的 Web 服务的方法，其中每个 Web 服务都专注于特定的功能；
  > Web 服务之间可能存在一些依赖关系——这没关系（例如，当用户从目录中保存一些产品时，在用户 (UserProfileService) 和产品目录 (ProductCatalogService) 之间）；
  > 每个 Web 服务都可以独立扩展；
  > 服务集成可能具有挑战性；
  > 作者建议仅在技术团队超过 10-20 名工程师时才使用面向服务的架构和 Web 服务。
• 添加克隆
• HTTP 协议缓存
  > 缓存 GET 响应时（从缓存返回响应，而不是向 Web 服务请求响应）。

可扩展性解决方案

1. 添加更多克隆/服务器（最简单、最便宜的选择）；
2. 按功能划分（服务器专业化，代表面向服务的架构（SOA）；需要更多努力；功能有限）；
3. 按数据划分（请参阅下面的“数据层”段落）。

数据层

传统扩展——垂直（购买更强大的服务器、添加 RAM、更多硬盘等）。

扩展关系数据存储（例如 MySQL）：

1. 复制
   > 将相同数据的多个副本存储在不同的机器上；
   > 需要同步两台服务器的状态：源&副本；
   > 数据修改——只能通过源服务器，但读取查询可以分布在副本之间；
   > 复制的挑战：a) 仅扩展读取（非常适合读取繁重的应用程序）；b) 不是解决数据集活跃增​长问题的方法；c) 副本可以返回过时的数据。
2. 数据分区/分片
   > 将数据集划分为更小的部分（无需处理整个数据集）；
   >分片键 是划分的标准（例如我们在一个网店有用户，一个用户id可以代表一个分片，所以任何用户信息如订单都存储在那个分片中）；
   > 缺点： a) 增加了大量的工作量和复杂性；b) 你不能跨多个分片执行查询；c) 根据您从分片键映射到服务器编号的方式，可能难以将更多服务器添加到您的基础架构；
   > Azure SQL 数据库 Elastic Sc​​ale 是一个现成的分片解决方案。

使用 NoSQL 进行扩展（例如 Cassandra、Redis、MongoDB、Riak、CouchDB）：

Eric Brewer 的 CAP 定理：不可能构建一个同时保证一致性、可用性和分区容错性的分布式系统。

• 一致性：相同的数据同时对所有节点可见。
• 可用性：所有可用节点都需要处理所有传入请求并返回有效响应。
• 分区：集群必须继续工作，尽管系统中的节点之间发生了任何数量的通信故障。

这意味着一次只能满足 3 个属性中的 2 个。例如，MongoDB 以高可用性换取一致性，它是一个 CP 数据存储。Cassandra 是一种 AP 数据存储——它提供可用性和分区容错性，但不能始终提供一致性。

当前趋势：根据业务需求使用Web服务层的功能分区和不同的数据存储。

缓存

• 用于提高性能和可扩展性，因为它返回即用型结果；
• 尝试达到更高的缓存命中率（多少次可以重复使用相同的缓存响应）；
• 缓存适用于读取次数多的应用程序，而对于写入次数多的应用程序可能无用；
• 如果需要，可以在稍后阶段添加任何缓存。

基于 HTTP 的缓存— 通读缓存（这意味着客户端与缓存对话，并且只有当缓存无法响应客户端时，才会请求 Web 服务）。

基于 HTTP 的缓存类型：

1. 浏览器缓存
   > 我们将数据存储在浏览器中。
2. 缓存代理
   > 服务器通常安装在本地公司网络中或由 Internet 服务提供商 (ISP) 安装。
3. 反向代理（例如 Nginx）
   > 放置在您自己的数据中心，以减少您自己的 Web 服务器上的负载；
   > 一种很好的扩展方式。
4. CDN
   > 用于缓存静态文件，如图像、CSS、JavaScript、视频、PDF（但如果需要也可以提供动态内容）。

自定义对象缓存：

1. 客户端的对象缓存
   > 存储在客户端的设备上。
2. 缓存与代码
   位于同一位置> 位于 Web 服务器（FE 或 BE）上；
   > 对象可以直接缓存在： a) 应用程序的内存/RAM；b) 共享内存（在同一台机器上运行的多个进程可以访问它们）；c) 缓存服务器可以作为单独的应用程序部署在每个 Web 服务器上（对于小型 Web 应用程序）。
3. 分布式对象缓存
   > Redis、Memcached

异步处理

同步处理 ——调用者在继续自己的工作之前发送一个请求并等待响应。您无法使用同步处理构建现代响应式应用程序。

异步处理——客户端可以在不知道请求是否被处理的情况下完成自己的工作，这是一种“即发即弃”原则。

消息队列 是一种异步处理技​​术：

• 消息生产者 ——客户端代码的一部分，创建消息并将其发送到消息队列。
• 消息队列——为消费者发送和缓冲消息的地方；
• 消息消费者——接收和处理来自消息队列的消息。消息消费者的类型： a) 类似 cron 的（从队列中拉消息）；2) 类似守护进程（推模型）。

消息平台：

• Amazon Simple Queue Service (SQS)（简单、实用；适合早期初创公司的良好解决方案）；
• RabbitMQ（提供许多特性（包括复杂的路由），相当简单、灵活）；
• ActiveMQ（基于 Java，延迟低得多，路由不太灵活，可能对发布的大量消息很敏感）。

事件驱动架构

• 不是请求/响应模型，组件宣布已经发生的事件（而不是请求完成的工作）；
• 事件 是表示某事发生的对象或消息；
• 我们的发布者和消费者对彼此一无所知——他们只知道事件消息的格式和含义。

搜索数据

• 全表扫描是一种普通的搜索（需要扫描整个数据集才能找到要查找的行）；
• 索引用于加速搜索：

索引示例

• 至于数据模型，关系数据模型是具有关系的表的表示。在非关系数据模型中，您专注于用例并设计相应的查询，例如返回产品集合（通常是带有产品列表的 JSON）。
• 建议使用搜索引擎进行复杂的搜索查询。他们通常使用允许搜索短语或单个单词的倒排索引。现成的搜索引擎有：Amazon CloudSearch、Azure Search、Elasticsearch、Solr、Sphinx。

和更多…

可扩展性不仅与架构有关，还与：

• 各种流程的自动化（无论是测试、构建和部署流程、监控和警报，还是日志聚合）；
• 扩展自己：
  > 更聪明地工作，而不是更努力地工作；
  > 避免加班，因为这会导致精神问题和倦怠；
  > 按优先级管理您的任务，了解其真正价值；
  > 构建简单、简约的功能；
  > 代表；
  > 分享知识、协作；
  > 使用第三方服务，不要重新发明轮子；
  > 协商截止日期；
  > 小块发布，收集反馈，不要在真空中开发；
  > 为特定产品领域创建 4-9 人的小型跨职能自治团队（例如，围绕结账功能的团队）；
  > 保持所有项目程序和标准的灵活性，因为它们限制了创造力和创新；
  > 调整团队，设定共同目标，建立良好的工程文化；
  > 还有更多有用的建议！

结论

说实话，读了 Artur Ejsmont 的《Web Scalability for Startup Engineers》一书后，我松了口气，因为我听到了很多关于软件架构和工作中的各种技术的信息，但我总觉得“我不完全明白”。我想深入潜水。我很高兴它发生了！

但是还有很多东西要学

感谢您阅读我的简短摘要（它真的很短，因为本书包含更多有价值的信息），希望您喜欢我的故事并喜欢这本书！

下次见！