微服务
微服务架构风格，就像是把一个单独的应用程序开发为一套小服务，每个小服务运行在自
己的进程中，并使用轻量级机制通信，通常是 HTTP API。这些服务围绕业务能力来构建，
并通过完全自动化部署机制来独立部署。这些服务使用不同的编程语言书写，以及不同数据
存储技术，并保持最低限度的集中式管理。
简而言之：拒绝大型单体应用，基于业务边界进行服务微化拆分 ，各个服务独立部署运行。
集群、分布式、节点
集群
集群的特点：
- 通过多台计算机完成同一个工作，达到更高的效率。
- 两机或多机内容、工作过程等完全一样。如果一台死机，另一台可以起作用。
如上图，集群就是把服务器A的应用在服务器B上重新部署一次，应用的代码是一模一样的，有点类似复制。
分布式
分布式系统是一组计算机，通过网络相互连接传递消息与通信后并协调它们的行为而形成的系统。组件之间彼此进行交互以实现一个共同的目标。
优点：
- 模块之间独立，各做各的事，便于扩展，复用性高。
- 高吞吐量。某个任务需要一个机器运行10个小时，将该任务用10台机器的分布式跑(将这个任务拆分成10个小任务)，可能2个小时就跑完了。
以上面例子为例，把应用拆分为订单服务和支付服务，分别部署在不同的服务器上，这样可以根据实际需求来对每个服务进行扩展。比如目前的场景是支付模块并发量很高，但是订单服务的并发量不高（这里只是假设场景），我们可以增加一台服务器C来跑支付服务，这样把系统拆分不同模块，扩展性更加灵活。
节点
节点就相当于集群中的一个服务器。
分布式和集群的区别
分布式是将同一个业务拆分成不同的子模块放在不同的服务器上执行。而集群是将多个服务器集成到一起，实现同一个业务。分布式上的节点都能看作是一个集群。集群不一定是分布式的。分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
远程调用
在分布式系统中，各个服务可能处于不同主机，但是服务之间不可避免的需要互相调用，我 们称为远程调用。
SpringCloud 中使用 HTTP+JSON 的方式完成远程调用
负载均衡
分布式系统中，A 服务需要调用 B 服务，B 服务在多台机器中都存在，A 调用任意一个 服务器均可完成功能。
为了使每一个服务器都不要太忙或者太闲，我们可以负载均衡的调用每一个服务器，提升网站的健壮性。
常见的负载均衡算法：
轮询：为第一个请求选择健康池中的第一个后端服务器，然后按顺序往后依次选择，直到最后一个，然后循环。
最小连接：优先选择连接数最少，也就是压力最小的后端服务器，在会话较长的情况下 可以考虑采取这种方式。
散列：根据请求源的 IP 的散列（hash）来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器。如果你的应用需要处理状态而要求用户能连接到和之前相同的服务器，可以考虑采取这种方式。
服务注册/发现&注册中心
A 服务调用 B 服务，A 服务并不知道 B 服务当前在哪几台服务器有，哪些正常的，哪些服务 已经下线。解决这个问题可以引入注册中心；
如果某些服务下线，我们其他人可以实时的感知到其他服务的状态，从而避免调用不可用的 服务
服务熔断&服务降级
在微服务架构中，微服务之间通过网络进行通信，存在相互依赖，当其中一个服务不可用时，有可能会造成雪崩效应。要防止这样的情况，必须要有容错机制来保护服务。
如果库存服务出现问题，商品服务在调用库存服务时一直等待库存服务返回，当并发量高时，商品服务资源耗尽。同理，订单服务也因为一直等待商品服务返回而导致资源耗尽。最终，由于库存服务出现问题，最后导致商品服务、订单服务等一系列服务不可用，这就是雪崩效应。
为了解决这个问题，我们来了解一下服务熔断和服务降级
1）、服务熔断
a. 设置服务的超时，当被调用的服务经常失败到达某个阈值，我们可以开 启断路保护机制，后来的请求不再去调用这个服务。本地直接返回默认 的数据
2）、服务降级
a. 在运维期间，当系统处于高峰期，系统资源紧张，我们可以让非核心业 务降级运行。降级：某些服务不处理，或者简单处理【抛异常、返回 NULL、 调用 Mock 数据、调用 Fallback 处理逻辑】。
API网关
在微服务架构中，API Gateway 作为整体架构的重要组件，它抽象了微服务中都需要的公共 功能，同时提供了客户端负载均衡，服务自动熔断，灰度发布，统一认证，限流流控，日 志统计等丰富的功能，帮助我们解决很多 API 管理难题。
## 微服务
微服务架构风格，就像是把一个单独的应用程序开发为一套小服务，每个小服务运行在自
己的进程中，并使用轻量级机制通信，通常是 HTTP API。这些服务围绕业务能力来构建，
并通过完全自动化部署机制来独立部署。这些服务使用不同的编程语言书写，以及不同数据
存储技术，并保持最低限度的集中式管理。
简而言之：拒绝大型单体应用，基于业务边界进行服务微化拆分 ，各个服务独立部署运行。
集群、分布式、节点
集群
集群的特点：
- 通过多台计算机完成同一个工作，达到更高的效率。
- 两机或多机内容、工作过程等完全一样。如果一台死机，另一台可以起作用。
如上图，集群就是把服务器A的应用在服务器B上重新部署一次，应用的代码是一模一样的，有点类似复制。
分布式
分布式系统是一组计算机，通过网络相互连接传递消息与通信后并协调它们的行为而形成的系统。组件之间彼此进行交互以实现一个共同的目标。
优点：
- 模块之间独立，各做各的事，便于扩展，复用性高。
- 高吞吐量。某个任务需要一个机器运行10个小时，将该任务用10台机器的分布式跑(将这个任务拆分成10个小任务)，可能2个小时就跑完了。
以上面例子为例，把应用拆分为订单服务和支付服务，分别部署在不同的服务器上，这样可以根据实际需求来对每个服务进行扩展。比如目前的场景是支付模块并发量很高，但是订单服务的并发量不高（这里只是假设场景），我们可以增加一台服务器C来跑支付服务，这样把系统拆分不同模块，扩展性更加灵活。
节点
节点就相当于集群中的一个服务器。
分布式和集群的区别
分布式是将同一个业务拆分成不同的子模块放在不同的服务器上执行。而集群是将多个服务器集成到一起，实现同一个业务。分布式上的节点都能看作是一个集群。集群不一定是分布式的。分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
远程调用
在分布式系统中，各个服务可能处于不同主机，但是服务之间不可避免的需要互相调用，我 们称为远程调用。
SpringCloud 中使用 HTTP+JSON 的方式完成远程调用
负载均衡
分布式系统中，A 服务需要调用 B 服务，B 服务在多台机器中都存在，A 调用任意一个 服务器均可完成功能。
为了使每一个服务器都不要太忙或者太闲，我们可以负载均衡的调用每一个服务器，提升网站的健壮性。
常见的负载均衡算法：
轮询：为第一个请求选择健康池中的第一个后端服务器，然后按顺序往后依次选择，直到最后一个，然后循环。
最小连接：优先选择连接数最少，也就是压力最小的后端服务器，在会话较长的情况下 可以考虑采取这种方式。
散列：根据请求源的 IP 的散列（hash）来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器。如果你的应用需要处理状态而要求用户能连接到和之前相同的服务器，可以考虑采取这种方式。
服务注册/发现&注册中心
A 服务调用 B 服务，A 服务并不知道 B 服务当前在哪几台服务器有，哪些正常的，哪些服务 已经下线。解决这个问题可以引入注册中心；
如果某些服务下线，我们其他人可以实时的感知到其他服务的状态，从而避免调用不可用的 服务
服务熔断&服务降级
在微服务架构中，微服务之间通过网络进行通信，存在相互依赖，当其中一个服务不可用时，有可能会造成雪崩效应。要防止这样的情况，必须要有容错机制来保护服务。
如果库存服务出现问题，商品服务在调用库存服务时一直等待库存服务返回，当并发量高时，商品服务资源耗尽。同理，订单服务也因为一直等待商品服务返回而导致资源耗尽。最终，由于库存服务出现问题，最后导致商品服务、订单服务等一系列服务不可用，这就是雪崩效应。
为了解决这个问题，我们来了解一下服务熔断和服务降级
1）、服务熔断
a. 设置服务的超时，当被调用的服务经常失败到达某个阈值，我们可以开 启断路保护机制，后来的请求不再去调用这个服务。本地直接返回默认 的数据
2）、服务降级
a. 在运维期间，当系统处于高峰期，系统资源紧张，我们可以让非核心业 务降级运行。降级：某些服务不处理，或者简单处理【抛异常、返回 NULL、 调用 Mock 数据、调用 Fallback 处理逻辑】。
API网关
在微服务架构中，API Gateway 作为整体架构的重要组件，它抽象了微服务中都需要的公共 功能，同时提供了客户端负载均衡，服务自动熔断，灰度发布，统一认证，限流流控，日 志统计等丰富的功能，帮助我们解决很多 API 管理难题。