结合实际项目理解集群和分布式的关系

1、关于集群和分布式的关系

最近看了篇文章 到底什么是集群&分布式，文中收集了多名网友的回答，一个来自知呼的回答挺明了：

分布式：一个业务分拆多个子业务，部署在不同的服务器上，(我的补充：)具有处理高并发的能力，但一个子业务系统宕机，该子业务功能将无法实现。

集群：同一个业务，部署在多个服务器上，(我的补充：)具有高可用的能力，一个系统宕机，不影响业务实现。

现在所做的项目基本架构为spring + spring MVC + Mybatis，数据库使用mysql，缓存服务器使用的是redis集群，分布式服务使用的是dubbo+zookeeper组合，结合项目说说集群和分布式。

2、先说分布式

主项目简称DAMC，作为其它系统的数据和权限管理中心，为其它系统提供数据服务，该系统属于一次开发，持续使用，后续变更需求极少。

所以为了保障该系统的稳定性和持续性，DAMC并不对外提供接口，而是重新搭建了一套专门提供接口服务的系统，简称MIS，其它业务系统BIZS(泛指所有与MIS对接的业务系统)通过MIS获取DAMC的基础数据

BIZS作为客户端，MIS作为服务端，通过dubbo+zookeeper方式实现客户端(订阅者)与服务端(提供者)之间的通信，MIS就作为DAMC的一个子业务被拆分出来，以分布式的方式为BIZS系统提供服务

后续随着业务的发展，单纯的MIS系统已经不能满足需求了，需要对MIS系统进行拆分，比如专门服务于内部系统的IN-MIS和专门服务于门户、互联网系统的外部系统OUT-MIS，IN-MIS和OUT-MIS同时作为服务端(提供者)，以分布式的方式被部署为DAMC的两个子业务提供服务

这就是分布式所说的【一个业务分拆多个子业务，部署在不同的服务器上】，缩短了单个业务执行的时间，提高了单位时间内处理业务的能力，即处理高并发的能力

3、然后说集群

上面提到的DAMC系统作为基本的数据和权限管理中心，其数据绝大多数的情况是以查询被访问的，修改、删除和新增的情况比较少，数据稳定性比较强，DAMC的分布式系统MIS以及后期的IN-MIS、OUT-MIS都是查询数据

同时随着业务发展，考虑到客户端(订阅者)的数量及访问频次给数据库带来的压力，加入了redis缓存服务器集群(其实就两台)，在减轻mysql数据库压力的同时，保证了数据访问的稳定性和可用性(高可用)，因为一台宕机，还有另一台

这就是集群所说的【同一个业务，部署在多个服务器上】，提供的是高可用能力。

当然集群也有负载均衡集群，比如分布式中作为服务端(提供者)的MIS(IN-MIS、OUT-MIS)，随着访问压力的加大，可以将其部署在多台服务器上，同时作为提供者向zookeeper注册中心注册服务，客户端(订阅者)随机获取任意一台MIS(IN-MIS、OUT-MIS)的服务，实现负载均衡的能力。

====================================分割线====================================

关于项目中使用技术基础的部分整理的差不多，后续继续补充，接下来是时候把项目“大卸八块”了，从功能应用上去分析几一个技术点。。。希望这不是一句空话。。。当然也有可能还是基础。。。