浅谈集群、分布式、微服务的异同

作者：Mike 2019-05-24 14:45:17

运维

系统运维

分布式 分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。分布式和微服务的架构很相似，只是部署的方式不一样而已。

什么是集群

集群是指将多台服务器集中在一起，每台服务器都实现相同的业务，做相同的事情。但是每台服务器并不是缺一不可，存在的作用主要是缓解并发压力和单点故障转移问题。我们可以利用一些廉价的符合工业标准的硬件构造高扩展、高性能、低成本、高可用的系统。

集群主要具有以下特性：

• 伸缩性(Scalability)

在一些大的系统中，预测最终用户的数量和行为是非常困难的，伸缩性是指系统适应不断增长的用户数的能力。提高这种并发会话能力的一种最直观的方式就是增加资源(CPU，内存，硬盘等)，集群是解决这个问题的另一种方式，它允许一组服务器组在一起，像单个服务器一样分担处理一个繁重的任务，我们只需要将新的服务器加入集群中即可，对于客户来看，服务无论从连续性还是性能上都几乎没有变化，好像系统在不知不觉中完成了升级。

• 高可用性(High availability)

单一服务器的解决方案并不是一个健壮方式，因为容易出现单点失效。像银行、账单处理这样一些关键的应用程序是不能容忍的，哪怕是几分钟的死机。它们需要这样一些服务在任何时间都可以访问并在可预期的合理时间周期内有响应。高可用性集群的出现就是为了使集群的整体服务尽可能可用，以便考虑计算硬件和软件的易错性。如果高可用性集群中的主节点发生了故障，那么这段时间内将由次节点代替它。次节点通常是主节点的镜像，所以当它代替主节点时，它可以完全接管其身份。因此系统环境对于用户是一致的。

• 负载均衡(Load balancing)

负载均衡集群为企业需求提供了更实用的系统。如名称所暗示的，该系统使负载可以在计算机集群中尽可能平均地分摊处理。该负载可能是需要均衡的应用程序处理负载或网络流量负载。这样的系统非常适合于运行同一组应用程序的大量用户。每个节点都可以处理一部分负载，并且可以在节点之间动态分配负载，以实现平衡。

• 高性能 (High Performance)

通常，这种设计的集群是用来开发并行编程应用程序，以解决复杂的科学问题。并行计算(或称平行计算)是相对于串行计算来说的，并行计算能力的目的是用来提高计算速度。它实际是一个计算机集群，其处理能力与真的超级计算机相等。

什么是分布式

分布式服务是指将多台服务器集中在一起，服务是分散部署在不同的机器上的。每台服务器都实现总体中的不同业务，做不同的事情。一个服务可能负责几个功能，是一种面向 SOA 的架构。各分开部署的部分彼此通过各种通讯协议交互信息，并且每台服务器都缺一不可，如果某台服务器故障，则部分功能缺失，或导致整体无法运行。

分布式存在的主要作用是大幅度的提高效率，缓解服务器的访问和存储压力。区别分布式的方式是一个业务分拆多个子业务，部署在不同的服务器上。

例如：将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互。

上图中 Service A、B、C、D 分别是业务组件，通过 API Geteway 进行业务访问。

什么是微服务

微服务的概念和分布式比较相似，微服务是一种架构风格。简单来说微服务就是很小的服务，小到一个服务只对应一个单一的功能。每个微服务仅关注于完成一件任务并很好地完成该任务，这个服务可以单独部署运行。 各个微服务之间是松耦合的，服务之间可以通过 RPC 来相互交互。每个微服务都是由独立的小团队开发、测试、部署，上线，负责它的整个生命周期。

在做架构设计时，当你估算过最大用户量和并发量后，计算出单个应用服务器能否满足需求。如果用户量只有几百人的小应用，单体应用就能搞定，即所有应用部署在一个应用服务器里。如果是很大用户量，且某些功能会被频繁访问，或者某些功能计算量很大，建议将应用拆解为多个子系统，各自负责各自功能，这就是微服务架构。

微服务的设计是为了不因为某个模块的升级和 BUG 影响现有的整个系统业务。微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，它也可以是同一个服务器。

微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低。由于每个微服务都由独立的小团队负责，因此它敏捷性更高。分布式服务最后都会向微服务架构演化，这是一种趋势。不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维难度会增大。

集群、分布式、微服务的异同及联系

1. 分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。

例如：如果一个任务由 10 个子任务组成，每个子任务单独执行需 1 小时，则在一台服务器上执行该任务需 10 小时。

• 采用分布式方案，提供 10 台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，执行完这个任务只需一个小时。(这种工作模式的一个典型代表就是 Hadoop 的 Map/Reduce 分布式计算模型)
• 采用集群方案，同样提供 10 台服务器，每台服务器都能独立处理这个任务。假设有 10 个任务同时到达，10 个服务器将同时工作，1 小时后，10 个任务同时完成。这样整体来看，还是 1 小时内完成一个任务。

注：分布式需要做好事务管理。

2. 集群模式是不同服务器部署同一套服务对外访问，实现服务的负载均衡。区别集群的方式是根据部署多台服务器业务是否相同，分布式中的每一个节点，都可以做集群。而集群并不一定就是分布式的。

举例：就比如新浪网访问的人多了，他可以做一个群集。前面放一个响应服务器，后面几台服务器完成同一业务。如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将任务调度给哪一台去完成。

而分布式，从窄意上理解也跟集群差不多。但是它的组织比较松散，不像集群有一个组织性，一台服务器垮了，其它的服务器可以顶上来。分布式的每一个节点都完成不同的业务，一个节点垮了那这个业务就不可访问了。

注：集群模式需要做好 Session 共享，确保在不同服务器切换的过程中不会因为没有获取到 Session 而引起服务终止。

3. 分布式与微服务的关系

分布式和微服务的架构很相似，只是部署的方式不一样而已。

生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的。比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。

4. 在开发中我们可以将分布式和集群分开吗?

针对这个问题，我们可以根据分布式的介绍看出，其主要的功能是用来将我们的系统模块化，将系统进行解耦的，方便我们以后的维护和开发的。但是其并不能解决我们的并发问题，也无法保证我们的系统在服务器宕机后的正常运转。

而集群恰好弥补了分布式的缺陷，集群就是多个服务器处理相同的业务。这在一方面可以解决或者说改善我们系统的并发问题，一方面可以解决我们服务器如果出现一定数量的宕机后，系统仍然可以正常运转。

好的设计应该是分布式和集群相结合，先分布式再集群。具体实现就是业务拆分成很多子业务，然后针对每个子业务进行集群部署。这样每个子业务如果出了问题，整个系统完全不会受影响。

因此，分布式和集群是一对好基友，谁也离不开谁。