微服务，分布式，集群的概念及区分

现在微服务比较流行，很多人动不动就微服务，我觉得还是先要了解什么是微服务，再考虑项目开发是不是需要微服务。所以去网上搜集了一些说法并摘录。另外推荐springboot+springcloud的一个文章，网易技术团队的：http://tech.lede.com/2017/03/15/rd/server/SpringCloud0/  关于介绍springcloud的相对系统些的。

1：分布式：一个业务分拆多个子业务，部署在不同的服务器上。

其实这个从机器的数量上来说分布式也是集群的一种解释，但是从功能上来说不是，因为如果一个应用在一个服务器上，这个应用挂掉了，那么整个系统所有服务器就不能使用了。所以没有达到集群的目的。

分布式系统的核心理念是让多台服务器协同工作，完成单台服务器无法处理的任务，尤其是高并发或者大数据量的任务。分布式系统由独立的服务器通过网络松散耦合组成的。每个服务器都是一台独立的PC机，服务器之间通过内部网络连接，内部网络速度一般比较快。因为分布式集群里的服务器是通过内部网络松散耦合，各节点之间的通讯有一定的网络开销，因此分布式系统在设计上尽可能减少节点间通讯。此外，因为网络传输瓶颈，单个节点的性能高低对分布式系统整体性能影响不大。比如，对分布式应用来说，采用不同编程语言开发带来的单个应用服务的性能差异，跟网络开销比起来都可以忽略不计。因此，分布式系统每个节点一般不采用高性能的服务器，而是性能相对一般的普通PC服务器。提升分布式系统的整体性能是要通过横向扩展（增加更多的服务器），而不是纵向扩展（提升每个节点的服务器性能）。

2集群：同一个业务，部署在多个服务器上。

2.1分布式中的每一个节点，都可以做集群。而集群并不一定就是分布式的。

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

而分布式，从窄意上理解，也跟集群差不多，但是它的组织比较松散，不像集群，有一个组织性，一台服务器垮了，其它的服务器可以顶上来。

分布式的每一个节点，都完成不同的业务，一个节点垮了，那这个业务就不可访问了。

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

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

采用分布式方案，提供 10 台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，执行完这个任务只需一个小时。(这种工作模式的一个典型代表就是 Hadoop 的 Map/Reduce 分布式计算模型）

而采用集群方案，同样提供 10 台服务器，每台服务器都能独立处理这个任务。假设有 10 个任务同时到达，10 个服务器将同时工作，1 小时后，10 个任务同时完成，这样，整身来看，还是 1 小时内完成一个任务！

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

 

3：3.1微服务架构和整体架构： 我觉得微服务的核心就是拆分。为什么要拆分？处理系统边界。

      3.2: 微服务和分布式的区别是什么？ 微服务是可以部署在一台机器上的，而分布式不是。

3.3微服务的最大意义是在于对待处理系统边界的问题，使得业务 /模块易于拆分，业务之间仅关注于接口而不是实现。微服务能够解决的不仅仅是高并发问题，还能解决开发问题。
举个例子，现在流行 restful 架构就是很好的一种拆分方式。前端在进行开发的时候，完全不需要关注后端的实现。前端只要写完逻辑，做好单元测试接口测试就完事了。管他后端是 PHP 还是 Java，何必自寻烦恼。
至于楼主提到多个微服务就要多个 tomcat 吃资源的事情。首先这个利和弊是要根据客观条件来判断的。当我们的业务只需要通过增加服务器资源，几乎不需要修改代码就能解决高并发的时候，我认为老板还是很乐意看到这种情况的。当然，如果你们根本就没有这么大的业务量，平白无故的开几个 tomcat 确实吃资源。同样，制定接口和拆分业务也需要占用开发时间。如何进行取舍，怎么进行合理的拆分，这个就是架构师的活了。

开发人员选择使用微服务，最大的好处就是 处理系统边界的问题， 这个系统边界 指的便是代码逻辑的边界，微服务正是遵从了被所有开放人员奉如圭泉的经典理念 关注点分离原则 -> 分开是为了更好的相聚。

这种系统其实没有必要去做微服务，为什么？系统边界太模糊了。无法界定边界，就无法解耦合。

3.4 负载均衡和分布式的区别？其实负载均衡是集群的解决方案之一。负载均衡是通过添加服务器达到解决高并发的问题。而分布式是解决模块过度耦合的问题。当然因为分布式把模块拆分，单个服务器的压力也减小了。也达到了减少服务器压力的问题。但是分布式不是主要解决高并发问题的方法。集群才是。当然，分布式的这种部署方式达到了以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。

问：就是负载均衡和分布式的区别，因为我身边的同事几乎很少会 spring cloud 的，而项目经理也说，并发问题可以通过负载均衡来解决，那么像 zookeeper，dubbo，eureka 这些分布式框架的意义何在？因为我刚从成都回来，成都那边确实很多公司都要 spring cloud，我估计深圳杭州那边可能会对 spring cloud 要求更高？如果说只有项目量级达到淘宝京东这种级别才用得上 spring cloud，那为何需求会这么大？另外负载均衡也是通过增加服务器就可以解决并发问题，但是 spring cloud 却会高出很多的人员成本，那到底 spring cloud 或者说 dubbo，zookeeper 这种分布式框架应该什么时候用？跟负载均衡比又有什么样的优势呢？

答：分布式和负载均衡，简单的说就是多个服务器跑不同的项目和多个服务器跑相同的项目。举个实际的例子。因为我是做游戏服务端开发的我就用游戏举例子。魔兽世界知道吧，我们都知道魔兽世界有很多个区服，玩家通常都会选择不需要排队，延迟低的区服。所以，如果我们把游戏的逻辑服务端看成一个业务，通过增加多个服务器来跑游戏的逻辑服务端提供多个区服，这个就是负载均衡，用来解决服务器压力。

同样的，刚刚说的是以游戏服务端这个看成一个业务，然而一个完整的网络游戏可不止这么一个业务比如我们需要有一个公用的账号系统，因为我不可能换个区就要重新注册一个账号。我们还需要日志分析，用户行为分析，GM 工具等等各种其他的业务，这些业务肯定是跑在其他服务器上的，那么由这一堆业务所组成的完整的游戏运营服务，这个就是用分布式，用来解决模块的过度耦合。

然后，楼主你有一个误区，就是分布式主要是用来解决高并发或者其他因为系统资源不足所导致的瓶颈，这是错误的。我个人的观点是，分布式主要解决的是模块重用和系统边界问题，注重的是业务问题。依旧用上面那个例子，假如我们不采用分布式开发游戏整体业务，把账号系统在逻辑服务端里实现，那么就会出现换个区需要重新注册账号的问题。

 

3.5 多个 tomcat 对资源的消耗，可以去了解一下 docker。

4： 分布式和集群 的重合点在都有多台物理服务器。集群是多台服务器提高时间内的效率和容错。

分布式是业务拆分，提高单个任务的访问时间。而且集群的组织性更强。

    分布式和微服务的重合点在于都是拆分。微服务更注重业务边界的划分，这样开发人员的任务就更明确，而且后续的开发部署也会方便很多。但是分布式只是把业务拆分部署。虽然都是拆分但是不一样