1. 软市首页
  2. 行业观察

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

• 行业观察

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

作为一个非技术人员，我一直在努力理解应用程序的底层。随着时间的推移，它变得更好了：感谢各种书籍、文章、聚会、我的技术朋友，当然还有一位 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 服务：

  • 添加克隆
  • 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》一书后，我松了口气，因为我听到了很多关于软件架构和工作中的各种技术的信息，但我总觉得“我不完全明白”。我想深入潜水。我很高兴它发生了！

    但是还有很多东西要学

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

    下次见！

    声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

    上一篇 2022年5月2日
    下一篇 2022年5月2日

    相关推荐

    首页
    软件超市
    企服市场