大家好
今天，已经向您的法院提出了Tugberk Ugurlu文章的翻译，该文章花了相对较少的资金来阐明设计现代软件系统的原理。 这是作者在底线中对自己的评价：
由于截至2019年，在建筑文章中绝对不可能涵盖这样一个巨大的话题，例如建筑模式+设计模式，因此我们不仅推荐Uruglu先生的文字，还推荐他亲切放置的大量链接。 如果您愿意，我们将发布有关分布式系统设计的更专业的文章。
艾萨克·史密斯如果您从未面临过从头开始设计软件系统之类的挑战，那么当您开始进行此类工作时，有时甚至不清楚从哪里开始。 我认为，首先需要概述边界，以便或多或少地自信地想象要设计的内容，然后卷起袖子并在不超出这些边界的情况下工作。 首先，您可以获取一些产品或服务（理想情况下-您真正喜欢的产品或服务）并了解其实现。 您可能会惊讶于该产品的外观如此简单，以及实际上隐藏了多么巨大的复杂性。 请记住：
简单通常很复杂 ，这很正常。
我认为我可以给那些开始设计系统的人最好的建议是：不要做任何假设！ 从一开始，就必须具体化有关该系统的已知事实以及与此相关的期望。 以下是一些可以帮助您开始设计的好问题：
- 我们要解决的问题是什么？
- 与我们的系统进行交互的高峰用户数是多少？
- 我们将使用哪种写和读数据方式？
- 预期的失败是什么，我们将如何应对？
- 对一致性和系统可用性有什么期望？
- 在处理与外部验证和法规相关的任何要求时，您是否必须考虑？
- 我们将存储什么类型的机密数据？
这些只是对我和那些多年来在我的专业活动中有机会参加的团队有用的几个问题。 如果您知道这些问题的答案（以及与您所从事的工作有关的其他问题），则可以逐步研究该任务的技术细节。
设置初始水平我在这里所说的“基准”是什么意思？ 实际上，在当今时代，可以使用现有方法和技术来“解决”软件行业中的大多数问题。 因此，在这种情况下，您将获得一定的领先优势，面临着别人必须在您面前解决的任务。 不要忘记编写程序来解决业务和用户的问题，因此我们努力以最直接，最简单的方式（从用户的角度）解决问题。 为什么需要记住这一点？ 也许在您的坐标系中，您希望为所有任务寻找独特的解决方案，因为您会认为：“如果我到处都遵循模式，那我是什么样的程序员？” 实际上，
这里的
技术是决定在哪里和做什么 。 当然，我们每个人都不时要面对独特的问题，而每个问题都是真正的挑战。 但是，如果清楚地描述了我们的初始水平，那么我们就会知道该花些什么：寻找现成的解决方案，以解决摆在我们面前的问题，或者对其进行进一步的研究和加深理解。
我想我已经说服了您，如果专家自信地理解某些优秀软件系统的体系结构组成部分，那么对于掌握建筑师的技术和发展该领域的坚实基础而言，这些知识将是必不可少的。
好，那你从哪里开始呢？
Donna Martin在GitHub上拥有一个名为
system-design-primer的存储库，您可以在该存储库上学习如何设计大型系统以及准备就此主题进行访谈。 该存储库的一节包含
实际架构的示例，尤其是在其中检查了
一些知名公司 （例如Twitter，Uber等）如何进行系统设计。
但是，在继续学习本材料之前，让我们仔细研究一下在实践中必须处理的最重要的体系结构挑战。 这很重要，因为您必须指定棘手的多方面问题的许多方面，然后在该系统中有效的法规框架内加以解决。 前Facebook员工
杰克逊·加巴德 （
Jackson Gabbard）录制了一段长达
50分钟的视频，内容涉及系统设计面试 ，他分享了自己的经验，审查了数百名求职者。 尽管视频明确指出了大型系统的设计和成功标准，这对于寻找这样一个职位的候选人很重要，但它仍将作为详尽的资源，说明在设计系统时最重要的事情。 我还提供了该视频的
摘要 。
掌握有关数据存储和检索的知识通常，您决定如何长时间存储和显示数据的决定会严重影响系统性能。 因此，您必须首先了解系统中写入和读取数据的预期特性。 然后，您需要能够评估这些指标并根据所做的估算做出选择。 但是，只有了解了现有数据存储模式后，您才能有效地管理这项工作。 原则上，这意味着与
数据库选择有关的可靠知识。
数据库可以认为是具有出色的可伸缩性和持久性的数据结构。 因此，在选择一个或另一个数据库时，数据结构的知识对您将非常有用。 例如，
Redis是一个支持各种值的数据结构服务器。 它使您可以处理诸如列表和集合之类的数据结构，使用众所周知的算法（例如
LRU）读取数据，以持久且易于访问的方式组织此类工作。
塞缪尔·泽勒（Samuel Zeller）的 Unsplash快照对数据存储的各种模式有充分的了解后，请继续研究数据的一致性和可用性。 首先，您至少需要通俗地了解
CAP定理，然后通过更详细地检查已建立的
一致性和
可访问性模式来完善此知识。 因此，您将在这一领域发展自己的视野，并了解读取和写入数据实际上是两个非常不同的问题，并且每个问题都有其自身的特殊挑战。 拥有多种模式来确保一致性和可访问性，您可以显着提高系统性能，同时确保不间断地向应用程序传输数据。
最后，在结束有关数据存储问题的讨论时，还应提及缓存。 它应该同时在客户端和服务器上运行吗？ 缓存中将包含哪些数据？ 又为什么呢？ 您如何组织缓存失效？ 是否会定期定期进行？ 如果是这样，多久一次？ 我建议从上述系统设计入门的
下一部分开始研究这些主题。
沟通方式系统由各种组件组成； 它可以是在同一物理节点内运行的不同进程，也可以是在网络的不同部分运行的不同计算机。 您网络中的某些资源可能是私有的，但其他资源必须是公开的，并且对从外部访问它们的消费者开放。
必须确保这些资源之间的通信，以及整个系统与外界之间的信息交换。 在系统设计的背景下，我们再次面临一系列新的独特挑战。 我们弄清楚了
异步任务流如何有用，以及
各种可用的通信模式 。
Tony Stoddard的 Unsplash快照在组织与外界的通信时，
安全始终非常重要，必须认真对待并积极参与其中。
连接分配我不确定将这个主题放在一个独立的部分对每个人来说都是合理的。 尽管如此，我将在这里阐述这个概念，并且我相信用“连接分布”这一术语可以最准确地描述本节中的内容。
系统是通过正确连接许多组件而形成的，它们之间的通信通常是基于已建立的协议（例如TCP和UDP）进行组织的。 但是，这些协议本身通常不足以满足现代系统的所有需求，而现代系统通常在高负载下运行，并且很大程度上取决于用户的需求。 通常有必要找到分配化合物以应对如此高的系统负载的方法。
此分发基于众所周知的
域名系统 （DNS）。 这样的系统允许您转换域名，例如加权轮循和基于延迟的方法，这有助于分配负载。
负载平衡从根本上来说很重要，我们今天要处理的几乎所有大型互联网系统都位于一个或多个负载平衡器的后面。 负载平衡器可帮助您在许多可用实例之间分配客户端请求。 负载均衡器可以是硬件，也可以是软件，但是，实际上，您经常需要处理软件，例如
HAProxy和
ELB 。
反向代理在概念上与负载均衡器非常相似，尽管第一和第二之间有许多
明显的区别 。 在根据您的需求设计系统时，必须考虑这些差异。
您还应该注意
内容交付网络 （CDN）。 CDN是代理服务器的全球分布式网络，可从地理位置更靠近特定用户的那些节点传递信息。 如果要使用以JavaScript，CSS和HTML编写的静态文件，则CDN是首选。 此外，此类云服务在今天很流行，它提供了流量管理器，例如
Azure Traffic Manager ，当您处理动态内容时，它可以为您提供全局分布并减少延迟。 但是，在必须使用Web服务而不保存状态的情况下，此类服务通常很有用。
让我们谈谈业务逻辑。 构建业务逻辑，任务流和组件因此，我们设法讨论了系统的各种基础结构方面。 用户很可能甚至不会考虑系统的所有这些元素，并且坦率地说，根本不担心它们。 用户对如何与您的系统交互，通过交互可以实现什么以及系统如何执行用户命令，如何以及如何处理用户数据感兴趣。
就像本文的名称所暗示的那样，我将在其中讲述软件体系结构和系统设计。 因此，我不打算涵盖描述软件组件创建方式的软件设计模式。 但是，我考虑得越多，在我看来，软件设计模式和体系结构模式之间的界限就变得非常模糊，并且这两个概念紧密相关。 以事件源为例。 如果采用这种体系结构模式，它将影响系统的几乎所有方面：长期数据存储，系统采用的一致性级别，系统中的组件概述等。 因此，我决定提及一些与业务逻辑直接相关的架构模式。 即使在本文中您必须将自己限制在一个简单的列表中，我还是建议您熟悉它，并考虑与这些模式有关的想法。 您在这里：
协作方法您最终不可能完全由负责系统设计过程的参与者参与该项目。 相反，最有可能的是，您将不得不与在您的任务范围内及以后工作的同事互动。 在这种情况下，您可能需要与同事一起评估所选的技术解决方案，隔离业务需求并了解如何更好地并行化任务。
来自Unsplash的Kaleidico快照首先，有必要对您要实现的业务目标是什么以及必须处理哪些动态元素提出准确而普遍公认的想法。 小组建模技术（尤其是事件风暴）可以大大加快此过程，并增加成功的机会。 您可以在概述
服务边界之前或之后进行此工作，然后在产品成熟时加深它。 基于此处将实现的一致性级别，您还可以针对您所使用的有限上下文来制定一种
语言 。 当您需要讨论系统的体系结构时，可以使用
西蒙·布朗 （
Simon Brown）提出
的C4模型 ，尤其是当您需要通过可视化要报告的内容来了解要深入研究问题的细节时。
在本主题中，可能还有另一种成熟的技术，其用途不比面向主题的设计有用。 但是，无论哪种方式，我们都会回到对主题领域的理解，因此
面向主题的设计领域的知识和经验对您应该是有用的。