背景：

初代的服务器架构往往比较简单，应用程序、数据库、文件、代码等所有资源都放在一台服务器上，也就是单机结构。随着企业业务量的增多，一台服务器已经难以满足数据处理的需求了，那么对单机进行“复制粘贴”，就能收获一个处理能力高出好几倍的“服务器集群”。

不过，集群式扩展很容易到达物理上限，最直接的反映就是无论怎么增加节点，整个集群的性能似乎也没有被提升多少，这时候，就需要分布式系统登场了。

如果说分布式系统代表着网络服务的发展方向，那么云计算的社会化，可能是其快速普及的重要推手。

集中式架构、分布式架构、微服务架构图解

什么是分布式？

所谓分布式，就是将不同的服务模块部署在多台不同的服务器上，然后通过远程调用协同工作，共同对外提供服务。对于用户来说，就像是一台计算机在服务一样。

在实际业务中，分布式系统可以将不同的业务功能对应到一个个独立的子系统中去，比如针对电商平台，可以将用户服务、产品服务、店铺管理、数据分析等不同的数据处理项目部署在不同的计算机集群上。这些独立的集群可能是在不同的机房，甚至是不同的城市中，有的大型数据中心还会分布在不同的国家和地区。它们之间通过RPC消息传递进行通信和协调，再向用户提供服务。

在分布式系统的背景下，企业架构也由早期的单体式应用架构渐渐转为更加灵活的分布式应用架构，经历了单体分层架构、SOA 服务化架构、微服务架构、云原生架构等不同架构模式的变迁。后端开发不再局限于单一技术栈，并且为了应对更加庞大的集群规模，单纯的分布式系统已经难于驾驭，因此技术圈开启了一个概念爆发的时代：SOA、DevOps、容器、CI/CD、微服务、Service Mesh 等概念层出不穷，而 Docker、Kubernetes、Mesos、Spring Cloud、gRPC、Istio 等一系列产品的出现，标志着云时代已真正到来。

服务端开发与架构全景图

分布式缺点

分布式场景下比较著名的难题就是 CAP 定理。CAP 定理认为，在分布式系统中，系统的一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance），三者不可能同时兼顾。在分布式系统中，由于网络通信的不稳定性，分区容忍性是必须要保证的，因此在设计应用的时候就需要在一致性和可用性之间权衡选择。互联网应用比企业级应用更加偏向保持可用性，因此通常用最终一致性代替传统事务的 ACID 强一致性。

---

参考文档