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