文章目录
- 一，微服务
- 二，集群、分布式
- 三，远程调用
- 四，负载均衡
- 五，服务注册、服务发现、注册中心
- 六，配置中心
- 七，服务熔断、服务降级
- [八，API 网关](#八，API 网关)
这一节内容比较干，全部是概念性的内容，不需要实操。
一，微服务
对于谷粒商城的架构，无论是从理论上还是从实际开发角度，可以把所有功能在一个服务里实现，互联网早期很多项目都是这样落地的。
我们常常把这种架构称之为"大单体"。
当功能越来越多、系统越来越庞大、用户越来越多、研发团队越来越大，"大单体架构"会暴露有很多问题，比如性能问题、开发效率问题。
出现了这些问题之后，很自然的想到把大单体服务拆分为多个小的服务，微服务就在这个背景下诞生了。
微服务就像是把一个单独的应用程序开发为一套小服务，比方说每个小服务运行在自己的进程中，并使用轻量级机制通信，通常是 HTTP API。这些服务围绕业务能力来构建，并通过完全自动化部署机制来独立部署。
这些服务使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。
简而言之：拒绝大型单体应用，基于业务边界进行服务微化拆分，各个服务独立部署运行。
拆分在计算机世界是一个非常重要的思想和手段，当我们开发过程中遇到难题时，拆分通常是非常有效的解决方案。比如大单体拆分为微服务、分库分表、冷热分类、读写分离、主从分离、主备分离，都是常见的架构技巧，也是遇到问题后的解决手段。
当然，微服务架构也会带来很多挑战，典型的问题是像下图一样，众多的微服务，再加上彼此之间相互调用，成为一团乱码，如何管理和治理就是我们必须面对的挑战，这套课程的第二阶段就是解决这个问题的。
二，集群、分布式
这里有点咬文嚼字，了解即可。
集群是个名词，分布式可以理解为副词，起修饰作用。
比如，我们通常说MySQL集群，不会说MySQL分布式；会说Redis集群，不会说Redis分布式。
集群是个物理形态，分布式是个工作方式。
只要是一堆机器，就可以叫集群，机器之间有无协作，无关紧要。
分布式描述了这样一种工作方式：一个工作被拆分为多个任务，分发到多个集群上执行。
所以分布式系统的不同服务之间是有协作关系的。
分布式系统必然是集群式部署，但是集群上运行的软件不一定能称之为分布式系统。
比如用户在商城系统下单，涉及订单系统、库存系统、商品系统、结算系统，需要这些系统协作才能完成这个功能，商城系统就是一个分布式系统。
MySQL集群 虽然是部署在多台集群上，但彼此并不需要协作，所以不能称之为分布式系统。
三，远程调用
在分布式系统中，各个服务可能处于不同主机，但是服务之间不可避免的需要互相调用，这种调用称为远程调用。
SpringCloud 中使用 HTTP+JSON 的方式完成远程调用。
四，负载均衡
分布式系统中，A 服务需要调用B服务，B服务是集群部署，在多台机器中都存在，从需求实现的角度，A 调用任意一个即可。
这种情况下，可能出现的一种情况是，A发出的请求始终固定打到其中一台机器上(比如图中的B1），导致这台服务器压力非常大，而另外两台服务器又很空闲。
最好是让A的请求均匀的分发到B服务的三台服务器上，避免某台服务器很忙其他服务器很闲的情况，这种效果通过负载均衡来实现。
常见的负载均衡算法：
- ①轮询。为第一个请求选择健康池中的第一个后端服务器，然后按顺序往后依次选择，直到最后一个，然后循环。
- ②最小连接。优先选择连接数最少，也就是压力最小的后端服务器，在会话较长的情况下，可以考虑采取这种方式。
- ③散列。根据请求源的 IP 的散列（hash）来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器。如果你的应用需要处理状态而要求用户能连接到和之前相同的服务器，可以考虑采取这种方式。
- ④随机。将请求随机转发到一台服务器上，在大样本下，不同服务器接收到的请求数大致均衡。
五，服务注册、服务发现、注册中心
A 服务调用 B 服务时，A 服务需要知道 B 服务所在服务器的IP。
我们当然可以考虑把B服务的IP写死在A服务的配置文件中，但是一旦B服务的IP发生变化，就要修改A服务的配置文件，低效且不安全。
更大的问题在于，如果服务非常多，比方说A服务除了调用B服务之外，还可能调用其他的几十个服务，如果全部都在A服务中写死IP，其运维难度之大、出错概率之高，是不能被容忍的。
我们还必须意识到，在现在K8S容器部署已经成为微服务部署的标准方案，服务的IP是动态分配的，不可预知且经常变化。
这就要求必须以一种更科学灵活的方式来保存每个服务的IP。
这就是注册中心的作用。
所有的服务在部署完成后，将服务名和IP注册到注册中心。
调用方根据要调用的服务的名称从注册中心获取IP，然后向这个IP发送请求。
注册中心还能动态感知服务是否可用，将不可用的服务剔除，避免出现无效的调用。
六，配置中心
每一个服务最终都有大量的配置，并且每个服务都可能部署在多台机器上。
变更配置是经常性的，在微服务架构下，有大量的服务器，如果每次变更都要去服务器上修改，是不可行的，不仅工作量大，效率低，风险也很大。
配置中心就可以完美解决这个问题，配置中心用来集中管理微服务的配置信息。每个服务启动后，自动从配置中心获取自己的配置。
七，服务熔断、服务降级
在微服务架构中，微服务之间通过网络进行通信，存在相互依赖，当其中一个服务不可用时，有可能会造成雪崩效应。
如图所示，假设库存服务不可用：
- ①商品服务调用库存服务时，库存服务没有响应，商品服务就会一直等待
- ②越来越多的请求到达商品服务，都等在商品服务，导致商品服务的资源被消耗殆尽，最终商品服务不可用
- ③商品服务不可用后，订单服务请求商品服务，没有响应，一直等待
- ④越来越多的请求到达订单服务，进入等待状态，导致订单服务的资源被耗尽，不能接收新的订单请求，订单服务也变成不可用的服务了
最终导致整个系统所有的服务都不可用了，这就是雪崩。
要防止这样的情况，必须要有容错机制来保护服务。
1，服务熔断
服务熔断是指调用方发现服务不可用后，不再发出请求。
通常的策略是设置请求超时时间，当被调用的服务经常失败到达某个阈值，可以开启断路保护机制，后来的请求不再去调用这个服务。
2，服务降级
服务降级是指被调用方感知到系统资源紧张，无法处理更多的请求时，不再对请求做常规的处理，而是基于降级规则直接做出简单的响应，避免本机资源消耗和调用方的阻塞。
3，区别
服务熔断是调用方的手段，服务降级是被调用方的策略。
八，API 网关
在微服务架构中，API Gateway 作为整体架构的重要组件，它抽象了微服务中都需要的公共功能，同时提供了客户端负载均衡，服务自动熔断，灰度发布，统一认证，限流流控，日志统计等丰富的功能，帮助我们解决很多 API 管理难题。