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

　　软件架构：我希望我早点知道这一点
　　作为一个非技术人员，我一直在努力理解应用程序的底层。随着时间的推移，它变得更好了：感谢各种书籍、文章、聚会、我的技术朋友，当然还有一位Java开发人员，他也是我的丈夫：）
　　嗯
　　在这个故事中，我想推荐和回顾一本书，我认为对于没有技术背景或教育（或拥有但在工作环境中不确定）的每个人来说都是必须的。这是ArturEjsmont的面向初创工程师的Web可扩展性一书。虽然这本书是关于Web应用程序可扩展性的，但它实际上解释了软件架构的核心概念和组件。我不能告诉你这本书是如何清晰和明确的！重要笔记
　　这个故事完全基于ArturEjsmont的专业知识和知识。我不会假装自己不是技术专家（至少现在）。
　　我在这个故事中分享的内容非常有限。在阅读这本书时，我为自己准备了包含20页GoogleDocs的摘要。如果您想提高对软件架构的理解，我建议您阅读本书，准备摘要，并与技术朋友或同事讨论您所学到的知识。要记住的一张图片
　　Web应用程序架构概述（面向初创工程师的Web可扩展性，2015年，ArturEjsmont，第23页）
　　0。客户：您的Web应用程序的最终用户。
　　1。域名系统（DNS）：基于域名（例如olgamitroshyna。com）定义IP地址（将处理用户请求的服务器的地址）。
　　2。负载均衡器：在多台服务器之间分配流量以分担负载。
　　3，5。缓存：存储数据以更快地满足用户请求。
　　4。前端应用（Frontend）：这是用户界面，一个应用皮肤，一个表现层。
　　6。消息队列：存储用户请求以供Web服务进一步处理。
　　7。Web服务（后端）：业务逻辑（应用程序功能）所在的位置。
　　8。数据存储：Web服务从哪里写入数据和读取数据。
　　9。搜索引擎：负责数据存储无法有效处理的复杂搜索查询。
　　10。内容交付网络（CDN）：存储静态文件，如图像、CSS和JavaScript文件，以更快地满足用户请求。
　　11。QueueWorkers：处理来自消息队列的请求（即消息）的附加服务器。前端层
　　前端层组件有：域名系统；内容分发网络；负载均衡器反向代理。可以是以下三种类型之一：
　　a）托管服务（例如Amazon的ElasticLoadBalancer）；
　　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更轻量。以资源为中心（RESTJSON）
　　资源被视为对象，可以对对象进行4种操作：读取、创建、更新和删除（GET、POST、PUT、DELETE）；
　　REST需要身份验证才能访问资源（OAuth2）；
　　取决于传输层安全性（HTTPS）。
　　扩展RESTWeb服务：进入功能块功能分区
　　一种将服务拆分为更小的、独立的Web服务的方法，其中每个Web服务都专注于特定的功能；
　　Web服务之间可能存在一些依赖关系这没关系（例如，当用户从目录中保存一些产品时，在用户（UserProfileService）和产品目录（ProductCatalogService）之间）；
　　每个Web服务都可以独立扩展；
　　服务集成可能具有挑战性；
　　作者建议仅在技术团队超过1020名工程师时才使用面向服务的架构和Web服务。添加克隆HTTP协议缓存
　　缓存GET响应时（从缓存返回响应，而不是向Web服务请求响应）。可扩展性解决方案添加更多克隆服务器（最简单、最便宜的选择）；按功能划分（服务器专业化，代表面向服务的架构（SOA）；需要更多努力；功能有限）；按数据划分（请参阅下面的数据层段落）。数据层
　　传统扩展垂直（购买更强大的服务器、添加RAM、更多硬盘等）。
　　扩展关系数据存储（例如MySQL）：复制
　　将相同数据的多个副本存储在不同的机器上；
　　需要同步两台服务器的状态：源副本；
　　数据修改只能通过源服务器，但读取查询可以分布在副本之间；
　　复制的挑战：a）仅扩展读取（非常适合读取繁重的应用程序）；b）不是解决数据集活跃增长问题的方法；c）副本可以返回过时的数据。数据分区分片
　　将数据集划分为更小的部分（无需处理整个数据集）；
　　分片键是划分的标准（例如我们在一个网店有用户，一个用户id可以代表一个分片，所以任何用户信息如订单都存储在那个分片中）；
　　缺点：a）增加了大量的工作量和复杂性；b）你不能跨多个分片执行查询；c）根据您从分片键映射到服务器编号的方式，可能难以将更多服务器添加到您的基础架构；
　　AzureSQL数据库ElasticScale是一个现成的分片解决方案。
　　使用NoSQL进行扩展（例如Cassandra、Redis、MongoDB、Riak、CouchDB）：
　　EricBrewer的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）类似守护进程（推模型）。
　　消息平台：AmazonSimpleQueueService（SQS）（简单、实用；适合早期初创公司的良好解决方案）；RabbitMQ（提供许多特性（包括复杂的路由），相当简单、灵活）；ActiveMQ（基于Java，延迟低得多，路由不太灵活，可能对发布的大量消息很敏感）。事件驱动架构不是请求响应模型，组件宣布已经发生的事件（而不是请求完成的工作）；事件是表示某事发生的对象或消息；我们的发布者和消费者对彼此一无所知他们只知道事件消息的格式和含义。搜索数据全表扫描是一种普通的搜索（需要扫描整个数据集才能找到要查找的行）；索引用于加速搜索：
　　索引示例至于数据模型，关系数据模型是具有关系的表的表示。在非关系数据模型中，您专注于用例并设计相应的查询，例如返回产品集合（通常是带有产品列表的JSON）。建议使用搜索引擎进行复杂的搜索查询。他们通常使用允许搜索短语或单个单词的倒排索引。现成的搜索引擎有：AmazonCloudSearch、AzureSearch、Elasticsearch、Solr、Sphinx。和更多
　　可扩展性不仅与架构有关，还与：各种流程的自动化（无论是测试、构建和部署流程、监控和警报，还是日志聚合）；扩展自己：
　　更聪明地工作，而不是更努力地工作；
　　避免加班，因为这会导致精神问题和倦怠；
　　按优先级管理您的任务，了解其真正价值；
　　构建简单、简约的功能；
　　代表；
　　分享知识、协作；
　　使用第三方服务，不要重新发明轮子；
　　协商截止日期；
　　小块发布，收集反馈，不要在真空中开发；
　　为特定产品领域创建49人的小型跨职能自治团队（例如，围绕结账功能的团队）；
　　保持所有项目程序和标准的灵活性，因为它们限制了创造力和创新；
　　调整团队，设定共同目标，建立良好的工程文化；
　　还有更多有用的建议！结论
　　说实话，读了ArturEjsmont的《WebScalabilityforStartupEngineers》一书后，我松了口气，因为我听到了很多关于软件架构和工作中的各种技术的信息，但我总觉得我不完全明白。我想深入潜水。我很高兴它发生了！
　　但是还有很多东西要学
　　感谢您阅读我的简短摘要（它真的很短，因为本书包含更多有价值的信息），希望您喜欢我的故事并喜欢这本书！
　　下次见！