微服务架构风格，就像是把一个单独的应用程序，就像是把一个单独的应用程序开发为一套小服务，每个小服务运行在自己的进程中，并使用轻量级机制通信，通常是http api。这些服务围绕业务能力来构建。并且通过完全自动化部署机制来独立部署，这些服务使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。
简而言之，拒绝大型单体应用，基于业务边界进行服务微化拆分，各个服务独立部署运行。
集群是个物理状态，分布式是个工作方式，分布式中每个节点，都可以做集群。而集群并不一定就是分布式。
节点：集群中的一个服务器
在分布式系统中，各个服务可能处于不同主机，但是服务之间不可避免的需要调用，成为远程调用。
分布式系统中，A服务需要调用B服务，B服务在多台机器中都存在，A调用任意一个服务器均可完成功能。为了使每个服务器不要太忙还是太闲，我们可以负载均衡的调用每一个服务器，提升网站的健壮性。
常见的负载均衡算法：
A服务调用B服务，A服务并不知道B服务当前在哪几台服务器有，哪些正常的，哪些服务已经下线。解决这个问题可以引入注册中心。如果某些服务下线，我们其他人可以实时得到最新状态。
用来集中管理微服务的配置信息
在微服务中，微服务之间通过网络进行通信，存在相互依存，当其中一个服务不可用时，会造成雪崩效应。要防止这样的情况，必须需要容错机制。
设置服务的超时，当被调用的服务经常失败到达某个阈值。我们可以开启短路保护机制，后来的服务不再去调用这个服务。本地直接返回默认数据。
在运维期间，当系统处于高峰期，系统资源紧张，我们可以让非核心业务降级运行。降级：某些服务不处理，或者简单处理【抛异常、返回NUll、调用Mock数据、调用Fallback处理逻辑】
API网关是整体架构的重要组件，它抽象了微服务中需要的公共功能，同时提供了客户端负载均衡、服务自动熔断、灰度分布、统一认证、限流、日志统计等丰富功能。