集群架构、分布式架构、微服务架构

单体架构

家里生小宝宝啦，由于自己没有照顾小宝宝的经验，所以请了位经验丰富的月嫂。 这位月嫂从买菜，到做饭，洗衣，拖地，喂奶，哄睡，洗澡，换纸尿裤，擦屁股，做排气操，夜间陪护，给奶妈做月子餐等等，全部都做。 这种叫做单体架构。

集群

什么都做，一个月嫂怎么够呢，肯定忙不过来呀，那就请两个月嫂吧，这叫做集群。

高可用

有一个月嫂过生日，想请假回去和亲戚打一天麻将。如果只有一个月嫂，她走了，就叫做服务中断了。 但是因为做了集群，有两个月嫂，走了一个，另一个还是能用，虽然相比较吃力一些，但是毕竟还是能用的，这个现象叫做高可用。

分布式

一个月嫂，一个月的费用基本上都要1万多，还有房贷，还有车贷，生活费用还高，实在是请不起两位啊，那就还是请一位吧。 可是事情那么多，她实在忙不过来，怎么办呢？ 那就把爷爷请过来买菜，把奶奶请过来做饭。 这样服务本来仅仅是由月嫂一人提供的，变成了和宝宝相关的由月嫂负责，采购由爷爷负责，餐饮由奶奶负责。 这就叫做分布式了。

低耦合

做宝宝服务的月嫂去打麻将了，不影响做饭的奶奶。 做采购的爷爷去喝酒了，也不影响月嫂的宝宝服务，这叫做低耦合。

高内聚

和宝宝相关的事情都是月嫂在做，月嫂兑奶方式快慢，只会影响自己，对爷爷和奶奶的服务没影响. 这叫做高内聚。

集群+分布式

奶奶一个人做饭，做久了也烦啊，也累啊，也想打麻将呀。 那么就把姥姥也请过来吧。 这样做饭这个服务，就由奶奶和姥姥这个集群来承担啦。她们俩，谁想去汗蒸了，都有另一位继续提供做饭服务。 这就叫做集群+分布式。

前面的就当前戏了，看懂更好~

单机结构

我想大家最最最熟悉的就是单机结构，一个系统业务量很小的时候所有的代码都放在一个项目中就好了，然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。那么，单机结构有啥缺点呢？我想缺点是显而易见的，单机的处理能力毕竟是有限的，当你的业务增长到一定程度的时候，单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式，往下接着看。

集群结构

单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。但问题是用户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器。集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。但是，当你的业务发展到一定程度的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不明显了。这时候，你就需要使用微服务结构了。

1. 如果一个几点能让1万个用户同时请求并返回一个helloword，那么每增加一个节点，就会增加一倍承载，集群增加节点对性能提升非常明显
2. 如果单个请求是从1万大电影里面里面找出有王宝强得画面，单个服务器耗尽cpu性能，用尽内存也要1个小时才能完成一次查找，增加多少集群节点也不会缩短单个请求得时间。

这时把这些大电影分给1万个服务器，每个服务器只负责从一个电影里面找王宝强，找完再汇总给一个服务器，就可以极大的缩短单次查找的时间，这就是分布式计算解决的问题之一

分布式结构

先来对前面的知识点做个总结。

从单机结构到集群结构，你的代码基本无需要作任何修改，你要做的仅仅是多部署几台服务器，每台服务器上运行相同的代码就行了。但是，当你要从集群结构演进到微服务结构的时候，之前的那套代码就需要发生较大的改动了。所以对于新系统我们建议，系统设计之初就采用微服务架构，这样后期运维的成本更低。但如果一套老系统需要升级成微服务结构的话，那就得对代码大动干戈了。所以，对于老系统而言，究竟是继续保持集群模式，还是升级成微服务架构，这需要你们的架构师深思熟虑、权衡投入产出比。

OK，下面开始介绍所谓的分布式结构。

分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。举个例子，假设需要开发一个在线商城。按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。如果服务之间有依赖关系，那么通过RPC方式调用。

这样的好处有很多：

1. 系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当容易，开发效率大大提升。
2. 系统之间的耦合度降低，从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促，下单量可能会大大提升，因此我们可以针对性地提升订单系统、产品系统的节点数量，而对于后台管理系统、数据分析系统而言，节点数量维持原有水平即可。
3. 服务的复用性更高。比如，当我们将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。

分布式和微服务的区别

部署的方式不一样，微服务是架构设计方式，分布式是系统部署方式，两者概念不同

比如：
分布式：mysql、java部署在不同的服务器
微服务：一个商场系统，订单的处理逻辑和秒杀活动的处理逻辑分两个不同的服务来部署

分布式：分散压力。
微服务：分散能力。

实际案例说明

分布式和集群都是为了解决两个问题：

• 高吞吐量（throughput）
• 高可用（availability）

那既然他们俩都能解决这两个问题，那择其一为我所用就好啦，可为什么我们的架构通常既是分布式，又是集群呢？这不矛盾了吗？

我们常用的缓存服务器，比如Memcached和Redis，都是集群架构，以Memcached为例，一开始我们只有一个Memcached节点：

Client把一些数据放到Memcached中，省的每次都是数据库查，如果只有一个Memcached，那一旦请求压力大了，Memcached很快就忙不过来（虽然Memcached是多线程），而且一旦Memcached挂了，那就没有缓存可以用了，全部请求都会走数据库，数据库的压力会骤然增加！

所以我们加多了两个Memcached节点，形成Memcached集群。

有人说，请求会被分布到各个Memcached节点，这不就是分布式吗？
严格来说，这只能算是“分布的”（distributed）

整个就是分布式了
因为这些节点各司其职，有专门负责数据持久化存储的（Database），有对外提供业务访问的（Client，姑且认为是一个商品查询服务吧），也有负责数据缓存的（Memcached）

高吞吐量：我们把不同业务拆分到不同的机器上，比如用户信息查询和订单信息查询都是非常频繁的业务操作，现在我们拆成了UserService和OrderService，放在不同的机子上运行，自然比都放在一台机器上，吞吐量要高得多。

高可用：我改了一行UserService的代码，部署过去，编译失败，节点挂掉了，最多就影响需要依赖UserService的业务，不会影响其他的，整个系统整体上还是可用的，而如果所有业务都放在一起，那就危险多了！一行代码编译失败，整个系统垮掉，整段垮掉！

我们常说的分布式，或者说分布式（Distribution）这个术语，指的是各个异构的节点形成的系统，所谓异构，就是结构不同、功能不同的节点。

而Memcached集群的各个节点呢？他们是同构的，一个缓存的请求过来，比如说Set xxKey xxValue，那这个请求最终只会被一个Memcached节点处理，不会需要多个节点来共同完成这个请求。

而分布式呢，假设我有一个下单的请求，请求发给了OrderService，OrderService需要根据请求里头的userId补充用户信息，那就需要调用UserService提供的接口，然后我还要查询这比订单里头的商品信息，所以又得去调用GoodService接口，最后，才能完成下单这个操作。

OrderService、UserService和GoodService共同完成了下单这件事，这才是分布式（Distribution），而Memcached集群最多只能算是“分布的”（Distributed）。