服务端分布式架构、客户端分布式架构、分布式系统的区别与联系

服务端分布式架构

​

​

起初的时候，多个user直接访问同一台服务器，当用户量暴增的时候，单台服务器无法承受这么大的压力，所以会增加服务器，但是服务器之间的端口号是不能重用的，而且用户默认端口是固定的，所以不同的服务器要使用不同的端口号来监听请求，但是用户并不知道端口号改变了，依然往原来的端口号发送数据

所以增加了一层负载均衡器，负载均衡器使用原来的服务端口，来监听用户的的请求，用户访问的都是负载均衡器（实际上用户并不会感受到）由负载均衡器来分配用户请求到达哪个服务器，从而避免某一台服务器的压力过大。而且这样做还有一个好处，如果用户访问又增加，可以直接增加服务器，而不需要修改其他的服务器（解耦合）

多台服务器也会产生新的问题，即第一次请求是写数据，写在了server1里面，第二次请求被负载到了server2，数据如何同步？我们最直觉的做法是，server1和server2之间的数据相互拷贝，一起开始的集群就是这么做的，但是这涉及到了两个进程之间的数据通信，非常的慢，这是不能容忍的，后来出现了RPC技术，这门技术非常的难，以至于很难普及，所以后来出现了Spring技术（集成了RPC，可以通过依赖注入的方式调用和管理别的服务，使得使用RPC的门槛变低）。 数据通过写缓存的方式，解决数据一致性的问题

这里上面的架构中，也会有一定的问题，如果访问量太大了的话，负载均衡器承受不了。那么这个问题如何解决呢？这就引出了客户端的负载均衡

客户端分布式架构

​

在服务端负载均衡的基础上，我们去掉了负载均衡器，增加了注册中心，我们提供服务的每台服务器都要在注册中心中完成注册，此时如果用户来访问服务器，会先到达注册中心，由注册中心告诉用户哪些服务器在提供服务，然后有用户自己来决定去访问那台服务器。这样一来，之前负载均衡所承担的调度压力就分担到了用户自己的机器上，这样的设计堪称perfect。实际上这里的调度中心就是zookeeper，而zookeeper也是可以组成一个集群的，对外提供分布式锁服务

对比服务端分布式架构和客户端分布式架构

客户端-分布式架构的负载均衡处理是由客户端自己完成的，客户端直接请求服务；而服务端-分布式架构的负载均衡处理在服务端完成，由负载均衡转发用户请求

客户端-分布式架构将核心功能和业务逻辑分散到客户端应用程序中（当然也只是客户端自己负载均衡），这种架构模式通常用于需要在客户端执行复杂逻辑或离线处理的应用场景，比如在线游戏、桌面应用程序等

服务端分布式架构将核心功能和业务逻辑集中到后端分布式服务中，这种架构模式通常用于需要大规模并发处理和数据存储的应用场景，比如互联网应用、大型企业系统等

分布式系统：

接下来我么介绍一下分布式系统，那什么是分布式系统呢？

把一个完整的系统拆分成了一个又一个的子系统，来分别运行，系统和系统之间通过网络进行通信和协作，这样的系统叫做分布式系统

​

​

在非分布式的设计中，订单和管理在同一台服务器中，即单体应用（这里我们以电商为例），这里用户的订单的访问量一定比电商的管理的访问量大，那么订单的访问一定会对管理带来影响，因为大量的用户访问订单的时候，就会分配很多栈空间，而机器的内存是有限的，管理能够分配到的内存就会减少

此时我们很容易想到，再加一台服务器（注意是服务器，不是物理机），这边一台处理订单的业务，另外一台处理管理的业务，这两个可以在同一台机器上，（比如两个不同的 tomcat），那么这个时候订单会不会影响到管理呢？仍然会，因为服务器1和服务器2共用一个机器，该机器的 CPU是有限的资源，所以有必然会产生有影响；那好，我们将两者放在不同的机器上，那么此时订单会不会影响管理呢？

答案是，仍然会，因为此时订单会占用大量网络资源，所以，两台机器应该放置在不同的网络中。如此一来我们不同的服务要设置不同的机器，而且这些机器不能在同一个网络中。这样我们能够很好地支持很大的并发量。另外在需要增加服务的时候，我们直接机器就OK了，并不会对之前的服务器带来影响，我们降低了耦合度。（如图增加了财务，物流）

这就引出了分布式系统，把一个完整的系统拆分成了一个又一个的子系统，叫做分布式系统，来分别运行。但是这样也带来了一个巨大的问题，各个子系统之间如何进行通信呢？当用户下了订单之后，通知财务结账完成之后，通知物流开始发货，如果各个子系统之间是这样通信的话，会增加耦合性，违背了OCP（Open/Closed Principle 对扩展开放，对修改关闭）的开发原则，（比如，我增加一台财务的服务器，订单的服务器中和财务的通信地址至少需要修改，这是不合理的）所以此时，我们引出第三方：

如果此时订单生成了，就会在这个第三方中产生一个消息，而财务和物流定时从这个第三方中取消息，而这时候财务只关心订单消息，而物流只关心财务消息。所以这个第三方还需要将各种消息区分开来（消息队列的分主题），所以这个第三方也被称作是消息系统，在大数据中使用的 Kafka 就是一个消息系统

客户端-分布式架构和服务端分布式架构都是分布式系统的一种实现方式。选择合适的架构取决于系统的需求、复杂度和设计目标，不谈具体的应用场景，没有哪一种架构更好的说法

文章首发在公众号 ： stackoverflow ， 欢迎关注

7年前，还在读书的时候，喜欢一个女生，她也知道我喜欢她。毕业的时候，她选择了另外一个男生，后来那个男的PC，她们 break  out 了，后来她又选了别的男生，最近他们也分开了。

最近的一个深夜，我下班回家洗完澡刚躺在床上，看到了一条好友请求，她时隔多年，重新加了我的微信，一个熟悉的头像附带了一句话：这些年，我心里一直都有你

这！我该怎么回？