作为一个非技能职员，我一贯在努力理解运用程序的底层。随着韶光的推移，它变得更好了：感谢各种书本、文章、聚会、我的技能朋友，当然还有一位 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 的做事器。
后端层/网络做事实现运用程序的选项：
构建单体运用，然后根据业务需求添加 Web 做事；遵照 API 优先的方法：所有客户端（移动运用程序、桌面网站、移动网站等）在与 Web 运用程序通信时利用相同的 API 接口；以上两者结合。网络做事的类型：
以函数为中央> 能够在远程机器上调用函数的方法，而无需知道这些函数是如何实现的；> 示例：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 做事要求相应）。可扩展性办理方案添加更多克隆/做事器（最大略、最便宜的选择）；按功能划分（做事器专业化，代表面向做事的架构（SOA）；须要更多努力；功能有限）；按数据划分（请参阅下面的“数据层”段落）。数据层传统扩展——垂直（购买更强大的做事器、添加 RAM、更多硬盘等）。
扩展关系数据存储（例如 MySQL）：
复制> 将相同数据的多个副本存储在不同的机器上；> 须要同步两台做事器的状态：源&副本；> 数据修正——只能通过源做事器，但读取查询可以分布在副本之间；> 复制的寻衅：a) 仅扩展读取（非常适宜读取繁重的运用程序）；b) 不是办理数据集生动增长问题的方法；c) 副本可以返回过期的数据。数据分区/分片> 将数据集划分为更小的部分（无需处理全体数据集）；>分片键 是划分的标准（例如我们在一个网店有用户，一个用户id可以代表一个分片，以是任何用户信息如订单都存储在那个分片中）；> 缺陷： a) 增加了大量的事情量和繁芜性；b) 你不能跨多个分片实行查询；c) 根据您从分片键映射到做事器编号的办法，可能难以将更多做事器添加到您的根本架构；> Azure SQL 数据库 Elastic Scale 是一个现成的分片办理方案。利用 NoSQL 进行扩展（例如 Cassandra、Redis、MongoDB、Riak、CouchDB）：
Eric Brewer 的 CAP 定理：不可能构建一个同时担保同等性、可用性和分区容错性的分布式系统。
同等性：相同的数据同时对所有节点可见。可用性：所有可用节点都须要处理所有传入要求并返回有效相应。分区：集群必须连续事情，只管系统中的节点之间发生了任何数量的通信故障。这意味着一次只能知足 3 个属性中的 2 个。例如，MongoDB 以高可用性换取同等性，它是一个 CP 数据存储。Cassandra 是一种 AP 数据存储——它供应可用性和分区容错性，但不能始终供应同等性。
当前趋势：根据业务需求利用Web做事层的功能分区和不同的数据存储。
缓存用于提高性能和可扩展性，由于它返回即用型结果；考试测验达到更高的缓存命中率（多少次可以重复利用相同的缓存相应）；缓存适用于读取次数多的运用程序，而对付写入次数多的运用程序可能无用；如果须要，可以在稍后阶段添加任何缓存。基于 HTTP 的缓存— 通读缓存（这意味着客户端与缓存对话，并且只有当缓存无法相应客户端时，才会要求 Web 做事）。
基于 HTTP 的缓存类型：
浏览器缓存> 我们将数据存储在浏览器中。缓存代理> 做事器常日安装在本地公司网络中或由 Internet 做事供应商 (ISP) 安装。反向代理（例如 Nginx） > 放置在您自己的数据中央，以减少您自己的 Web 做事器上的负载；> 一种很好的扩展办法。CDN > 用于缓存静态文件，如图像、CSS、JavaScript、视频、PDF（但如果须要也可以供应动态内容）。自定义工具缓存：
客户真个工具缓存> 存储在客户真个设备上。缓存与代码位于同一位置> 位于 Web 做事器（FE 或 BE）上；> 工具可以直接缓存在： a) 运用程序的内存/RAM；b) 共享内存（在同一台机器上运行的多个进程可以访问它们）；c) 缓存做事器可以作为单独的运用程序支配在每个 Web 做事器上（对付小型 Web 运用程序）。分布式工具缓存> 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》一书后，我松了口气，由于我听到了很多关于软件架构和事情中的各种技能的信息，但我总以为“我不完备明白”。我想深入潜水。我很高兴它发生了！
但是还有很多东西要学
感谢您阅读我的简短择要（它真的很短，由于本书包含更多有代价的信息），希望您喜好我的故事并喜好这本书！
下次见！
