分布式和微服务是什么？二者的区别又是什么？

一、分布式系统

在《分布式系统原理与范型》一书中有如下定义：

“分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统”；

分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。

分布式系统（distributed system）是建立在网络之上的软件系统。

首先需要明确的是，只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候，且硬件的提升（加内存、加磁盘、使用更好的CPU）高昂到得不偿失的时候，应用程序也不能进一步优化的时候，我们才需要考虑分布式系统。因为，分布式系统要解决的问题本身就是和单机系统一样的，而由于分布式系统多节点、通过网络通信的拓扑结构，会引入很多单机系统没有的问题，为了解决这些问题又会引入更多的机制、协议，带来更多的问题。

因此，随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，急需一个治理系统确保架构有条不紊的演进。

Dubbo由此诞生。

二、微服务架构

任何技术的演进都是有迹可循的，任何新技术的出现都是为了解决原有技术无法解决的需求，所以，微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。微服务的设计就是为了不因为某个模块的升级和BUG影响现有的系统业务。

微服务架构，核心就是为了解决应用微服务化之后的服务治理问题。

在微服务架构之前还有一个概念：SOA（Service-Oriented Architecture）-面向服务的体系架构。

微服务的特征：

单一职责的。一个微服务应该都是单一职责的，这才是“微”的体现，一个微服务解决一个业务问题（注意是一个业务问题而不是一个接口）。
面向服务的。将自己的业务能力封装并对外提供服务，这是继承SOA的核心思想，一个微服务本身也可能使用到其它微服务的能力。

满足以上两点就可以认为是典型的微服务。

应用微服务化之后，会出现一些问题：

服务发现问题。一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件：服务注册中心，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单。
服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件：配置中心。
以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：

在这里插入图片描述

这便是一个典型的微服务架构，当然微服务的服务治理还涉及很多内容，比如：

通过熔断、限流等机制保证高可用；
微服务之间调用的负载均衡；
分布式事务（2PC、3PC、TCC、LCN等）；
服务调用链跟踪等等。

目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo（或者DubboX），但是Dubbo那两年的停更严重打击了开发人员对它的信心，Spring Cloud已经逐渐成为主流

三、分布式和微服务的区别

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

分布式服务架构与微服务架构概念的区别与联系：

分布式：分散压力。
- 不同模块部署在不同服务器上;
- 作用：分布式解决网站高并发带来问题；
- 集群：相同的服务；
- 多台服务器部署相同应用构成一个集群；
- 作用：通过负载均衡设备共同对外提供服务；
- SOA［组装服务/ESB企业服务总线］;
- 业务系统分解为多个组件，让每个组件都独立提供离散，自治，可复用的服务能力;
- 通过服务的组合和编排来实现上层的业务流程;
- 作用：简化维护，降低整体风险，伸缩灵活;
微服务：分散能力。
- 微服务［找到服务/微服务网关open API］;
- 架构设计概念：各服务间隔离（分布式也是隔离），自治（分布式依赖整体组合），其它特性（单一职责，边界，异步通信，独立部署）
- 是分布式概念更加严格的执行;
- SOA到微服务架构的演进过程;
- 作用：各服务可独立应用，组合服务也可系统应用（巨石应用［monolith］的简化实现策略-平台思想）.