分布式、集群、微服务、微前端、负载均衡的概念
分布式、集群、微服务、微前端、负载均衡的概念
0、前言
本人对这些分布式、集群、微服务、微前端、负载均衡的概念很模糊，甚至混淆。
因此收集网上各路大神的博客，在这篇随笔中一口气简述这些概念。
想要详细了解可以点击最下方的链接。
1、分布式
以大家非常熟悉的场景举例，比如完成一项软件开发工作。
小公司的做法就是招一个全栈工程师，所有任务全包，但往往这样的人虽然各方面都懂一点却没有特别精通的方向，很容易达到能力上限。
在一个大团队通常会分为多种角色（UI、前端、后端、DBA、运维等），这些人就构成了一个分布式系统，大家协调完成共同的任务，这中间的协调者就是项目经理或者部门 leader。
这样的好处就是：
- 职责分离：大家各司其职，各自做好擅长的事。
- 平滑扩容：哪个环节缺人就定点补充。
- 负载能力：可以应对更大更多的项目。
当然了有优点就有缺点：
- 网络通信：沟通成本增加，需要标准化工作模式。
- 调度：如何高效率协调所有人员。
- 一致性：如何保证上下游人员信息对齐。
简单来说就是有多台服务器，每一台服务器只部署一个或几个模块的功能，几台服务器共通组成了整个系统。
2、集群
说到分布式就不得不提与之相关的另一个概念，那就是集群。
还是拿前面的例子来说，假如小公司的全栈工程师有点异常情况（请假、跑路、忙不过来等等）老板会考虑招多个这样的人，这就形成了一个集群。
好处就是能干更多的活（负载分流）和互补（高可用），但本质上还是一个人做所有事。
简单来说就是有多台服务器，每一台服务器都部署有一个完整的系统，第一台服务器单点故障或者超过了其能处理的极限，就分流给第二台服务器继续处理。
事实上，分布式和集群是可以搭配使用的，比如上面的大团队例子，每个角色可以配置多个人，这就形成了分布式集群。
3、微服务
3.1、单体架构
单体架构随着系统规模的扩大，它暴露出来的问题也会越来越多：
- 复杂性逐渐变高
- 比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。
- 技术债务逐渐上升
- 公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。
- 部署速度逐渐变慢
- 单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟。
- 阻碍技术创新
- 比如以前的某个项目使用struts2写的，由于各个模块之间有着千丝万缕的联系，代码量大，逻辑不够清楚，如果现在想用spring mvc来重构这个项目将是非常困难的，付出的成本将非常大，所以更多的时候公司不得不硬着头皮继续使用老的struts架构，这就阻碍了技术的创新。
- 无法按需伸缩
- 比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。
3.2、面向服务的架构（SOA）
面向服务的架构(SOA)是一个组件模型，它将应用程序的不同功能单元(称为服务)进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。
3.3、微服务架构
微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。
3.4、微服务与单体架构区别
- 单体架构所有的模块全都耦合在一块，代码量大，维护困难；微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。
- 单体架构所有的模块都共用一个数据库，存储方式比较单一；微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。
- 单体架构所有的模块开发所使用的技术一样；微服务每个模块都可以使用不同的开发技术，开发模式更灵活。
3.5、微服务与SOA区别
微服务，从本质意义上看，还是 SOA 架构，但内涵有所不同。
微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有 Java 编写的服务，也可以有 Python编写的服务，他们是靠Restful架构风格统一成一个系统的。所以微服务本身与具体技术实现无关，扩展性强。
4、微前端
微前端借鉴了微服务的架构理念，将一个庞大的前端应用拆分为多个独立灵活的小型应用，每个应用都可以独立开发、独立运行、独立部署，再将这些小型应用联合为一个完整的应用。
微前端既可以将多个项目融合为一，又可以减少项目之间的耦合，提升项目扩展性，相比一整块的前端仓库，微前端架构下的前端仓库倾向于更小更灵活。
特性
- 技术栈无关
- 主框架不限制接入应用的技术栈，子应用可自主选择技术栈
- 独立开发/部署
- 各个团队之间仓库独立，单独部署，互不依赖
- 增量升级
- 当一个应用庞大之后，技术升级或重构相当麻烦，而微应用具备渐进式升级的特性
- 独立运行
- 微应用之间运行时互不依赖，有独立的状态管理
- 提升效率
- 应用越庞大，越难以维护，协作效率越低下。微应用可以很好拆分，提升效率
5、负载均衡
负载均衡是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。
一个没有负载均衡的 web 架构类似下面这样：
在这里用户是直连到 web 服务器，如果这个服务器宕机了，那么用户自然也就没办法访问了。
另外，如果同时有很多用户试图访问服务器，超过了其能处理的极限，就会出现加载速度缓慢或根本无法连接的情况。
而通过在后端引入一个负载均衡器和至少一个额外的 web 服务器，可以缓解这个故障。通常情况下，所有的后端服务器会保证提供相同的内容，以便用户无论哪个服务器响应，都能收到一致的内容。
从图里可以看到，用户访问负载均衡器，再由负载均衡器将请求转发给后端服务器。在这种情况下，单点故障现在转移到负载均衡器上了。
这里又可以通过引入第二个负载均衡器来缓解......
6、分布式和微服务的区别
简单的说，微服务是架构设计方式，分布式是系统部署方式，两者概念不同。
微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。
这个服务可以单独部署运行，服务之间可以通过RPC来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。
在做微服务架构设计的时候，先做逻辑架构，再做物理架构，当你拿到需求后，估算过最大用户量和并发量后，计算单个应用服务器能否满足需求，如果用户量只有几百人的小应用，单体应用就能搞定，即所有应用部署在一个应用服务器里，如果是很大用户量，且某些功能会被频繁访问，或者某些功能计算量很大，建议将应用拆解为多个子系统，各自负责各自功能，这就是微服务架构。
分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。
微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势， 不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难。
参考文章：
