集群、分布式、微服务概念和区别

集群（物理部署方式）

将同一个业务，部署到不同的服务器上

例如：一个网页访问的量很大，然后可以做一个集群，设置一个响应服务器，看部署了同一服务的服务器哪个比较“有空”，就将任务下发给它

• 优点：在单位时间内，通过服务器的数量有效的解决了同一时间内，任务过多的问题，可以分发给不同的服务器处理

• 缺点： 如果是有依赖关系的任务，从根本上还是只能由一台服务器处理，效率低下
  
  外部访问服务通过Nginx下发任务，集群中会存在session共享的问题，因为同一个接入有可能会切换到不同的服务

例如：假如用户的请求通过Nginx被转发到tomcat1上，这时一些当前用户的信息放入session中，比如登录信息让用户一直处于登录状态。那么Nginx负载均衡后，可能用户刷新页面后重新跳转到了tomcat2，而tomcat2上没有Session，系统就会要求用户再次去登录，这样明显会给用户带来不好的体验

分布式（业务处理方式）

将一个业务，分成若干个子业务，分布到不同的服务器上

例如：将一个任务分割成任意个小的子业务，通过不同的服务器上部署不同的业务，相互通信完成“大”任务

• 优点：将每一个子任务分割出来，可以有效的提高业务的处理效率，将耗时的子任务分配更多的资源以此提高效率

• 缺点：子任务逻辑如果由于其中一环（一台服务器上的子任务）失败而导致脱节，那么整一个任务将会失败

每一个模块通过接口交互，任务下发的时候需要一个“控制中心”，监听一个任务的处理情况，需要保证原子性

微服务（架构风格）

将一个应用分割成不同的模块，每一个模块做成一个微服务，可以独立部署，可以独立完成一件任务

• 优点：上面的单体系统全部运行于一个进程之内，资源相互影响，添加功能可能会影响其它功能，导致维护麻烦。 而微服务一切分为不同的模块，运行于自身进程内，而且不同的服务可以使用不同的语言充分发挥优势。

• 缺点：引入了分布式的复杂性，如接口一致性。 不过很多问题强大的Spring Cloud都已经提供了解决方案！
  
  微服务设计的目的是因为不想因为某一个模块的升级和BUG影响现有的系统业务。区别于分布式的是微服务的应用不一定是分散在多个服务器上，它也可以是同一个服务器
  
  这是一个微服务的架构