集群,分布式，微服务概念和区别理解

概念:

微服务是啥？

微服务是一种面向服务的架构(SOA)风格（Java开发人员最重要的技能之一），其中，应用程序被构建为多个不同的小型服务的集合而不是单个应用程序。与单个程序不同的是，微服务让你可以同时运行多个独立的应用程序，

而这些独立的应用程序可以使用不同的编码或编程语言来创建。庞大而又复杂的应用程序可以由多个可自行执行的简单而又独立的程序所组成。这些较小的程序组合在一起，可以提供庞大的单程序所具备的所有功能。简单来说微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间可以通过RPC来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。

       微服务是一种面向服务的架构风格,具有灵活性和低成本两个特点.

•        灵活性:由于这些较小的应用程序无需使用相同的编程语言,因此,开发人员可以使用他们最熟悉的语言,这是灵活性.
•        低成本:由于他们都用自己擅长的语言去开发,所以效率会高,相应的开发成本会降低.

微服务架构又是啥？

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

那么分布式又是啥？

分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用

原文链接：https://blog.csdn.net/zhonglunsheng/article/details/83153451

集群是个物理形态，分布式是个工作方式。

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

1：分布式是指将不同的业务分布在不同的地方。而集群指的是将几台服务器集中在一起，实现同一业务。

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

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

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

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

---

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

另外，还有一个概念和分布式比较相似，那就是微服务。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

区别:

1.分布式

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

上面：service A、B、C、D 分别是业务组件，通过API Geteway进行业务访问。

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

分布式事务可参考：微服务架构的分布式事务解决方案

2.集群模式

集群模式是不同服务器部署同一套服务对外访问，实现服务的负载均衡。区别集群的方式是根据部署多台服务器业务是否相同。

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

一般配置Nginx*的负载容器实现：静态资源缓存、Session共享可以附带实现，Nginx支持5000个并发量。

3.分布式是否属于微服务？

答案是肯定的。微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。

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

4.微服务架构

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

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

 去饭店吃饭就是一个完整的业务，饭店的厨师、配菜师、传菜员、服务员就是分布式；厨师、配菜师、传菜员和服务员都不止一个人，这就是集群；分布式就是微服务的一种表现形式，分布式是部署层面，微服务是设计层面。

https://blog.csdn.net/qq_37788067/article/details/79250623

为什么要用分布式架构？

单体架构：

   ——优点：

1. 易于开发：开发的方式简单，方便运行也容易调试。
2. 易于测试。
3. 易于部署。

 ——缺点：

1. 项目过于臃肿，维护成本大，出现bug难定位。
2. 资源无法隔离：共享一个数据库，或者一块内存。
3. 如果一个功能模块突然访问量过大，可能影响整个系统的性能。
4. 无法灵活扩展：单体系统也可以集群部署，但是不够灵活，我明明只是订单系统遇到了瓶颈，只需要将订单模块水平扩展就行，但现在要将整个系统水平扩展。不灵活！

5. 交付周期长：所有功能得一起上线，一起构建，一起部署。任何一个环节出错，都可能影响交付。

分布式架构：

那分布式的优点自然就和单体架构就对立了~
再谈谈分布式架构的缺点：

1. 性能，分布式系统是跨进程，跨网络的，性能很收网络延迟和带宽的影响。
2. 可靠性：由于高度依赖网络状况，任何一次远程调用都可以失败。随着服务的增多，还会出现更多的潜在故障点。
3. 异步：引入各种中间件，异步通信大大增加了功能实现的复杂度。
4. 数据一致性：分布式系统必然会有分布式事务的出现，这时对数据的一致性，
5. 需要在C（一致性）A（可用性）P（分区容错性）中做出选择。
6. 运维成本：一个系统拆成了多个服务，每个服务都得配置，部署，监控，日志处理。

得到的同时也意味着失去，权衡与取舍 始终是架构的魅力

https://blog.csdn.net/world6/article/details/79114105