大规模分布式系统通常具有数据量大、并发用户多、可扩展性要求和吞吐量要求(例如延迟等)的特点。
大规模分布式系统的主要挑战是平台已经变得非常大，现在它无法满足系统中的每一个要求。同样在如此大规模的情况下，也很难进行开发和测试实践。该技术已被 GIT、Hadoop 等多家公司使用。
大规模系统架构：
- 架构必须在显着理解领域方面发挥重要作用。了解利益相关者和产品所有者的领域非常重要。此外，他们还必须了解未来将要进行的与平台的集成类型。
- 另一个重要的方面是关于平台的安全性和合规性要求，这些也是必须从项目开始就做出的决定，以免影响未来的开发过程。
分布式系统：
- 现在让我们先谈谈分布式系统。分布式系统包含多个物理上分开但使用网络链接在一起的节点。这些节点中的每一个都包含一小部分分布式操作系统软件。为了更好地理解，请参阅分布式系统的文章
- 大型分布式系统非常复杂，这意味着在容错方面(您的系统有多少弹性)。这意味着您是否考虑了系统崩溃并可以从中恢复的所有可能情况。
- 为了使分布式系统正常工作，我们使用微服务架构。您可以从文章中阅读有关微服务架构的信息。但是挑战在于拥有基于微服务的架构，您应该划定微服务的边界，否则您可能会对系统进行过度设计，并且可能会将其分解为不自然的边界，并且系统无法在自然条件下协同工作。我们所组成的微服务架构的另一面是 Cap 定理。
微服务中的边界必须明确。
CAP定理：
- Cap 定理指出，您可以拥有一致性、可用性和分区的所有三个方面。在这三件事中，你只能拥有两件事。现在您应该非常清楚根据您的领域要求，您想在这三个方面中选择哪两个。
选择这三个方面中的任意两个
消息队列：
消息队列很棒，就像一些微服务发布一些消息，而一些微服务正在消费消息并执行流程，但在进入微服务架构之前，您必须在这里考虑的挑战是消息的顺序。如果您不关心消息的顺序，那么您可以在没有消息顺序的情况下存储消息，这很棒。进入流程的一件更重要的事情是事件溯源。
事件采购：
事件溯源是一个伟大的模式，你可以在其中拥有不可变的系统。如果我们可以拥有模型，在其中我们可以将所有事物视为一段时间内的事件流，并且我们只是一个接一个地处理事件，并且我们还跟踪这些事件，那么您就可以利用不可变架构。不可变意味着我们总是可以回放我们存储的消息以到达最新状态。这意味着在部署和迁移时，您很容易来回走动，并且还说明了通常在处理异常时发生的数据损坏。
笔记 –
事件溯源和消息队列将齐头并进，它们有助于使系统在大规模上具有弹性。
部署方法：
- 你不能让一个团队在一个地方做所有事情，你必须考虑将你的团队分成小的跨职能团队。你必须有一个小团队，他们不断地开发这些部件并开发他们的微服务并与其他人开发的其他微服务进行交互。
- 这里还要提到一件事，这些事情是由 Uber、Netflix 等组织推动的。这些组织拥有出色的团队，拥有惊人的技能。所以问题是你应该总是根据你的团队实力而不是理想的团队来比赛。
单一团队在一个地方做事
小团队不断开发零件/微服务
安全和 TDD(测试驱动开发)：
团队中的开发人员必须确保编码实践和开发系统的安全，其中根据合规性和监管框架对动态数据和静态数据进行加密。
TDD(测试驱动开发)是关于同时开发代码和测试用例，以便您可以使用您开发的正确测试用例测试特定代码的每个抽象。通过这种方式，您可以在开发过程中获得反馈，说明一切都在按计划进行，而不是等到开发完成。