谷粒商城学习笔记，第一天：分布式概述与商城架构

谷粒商城学习笔记，第一天：概述

一、分布式基础概念

1、微服务

拒绝大型单体应用，基于业务边界进行服务微化拆分，各个服务独立部署运行

2、集群、分布式、节点

##集群
是一种物理形态
将几台服务器集中在一起，实现同一业务

##分布式
是一种工作方式
若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统
将不同的业务分布在不同的地方

##节点
集群中的一个服务器

3、远程调用

分布式系统中，各个服务可能处于不同主机，但是服务之间不可避免的需要互相调用，我们称为远程调用。

SpringCloud中使用HTTP+JSON的方式完成远程调用。

4、负载均衡

A服务调用B服务，B服务部署在多台机器，A发送请求到任意一个服务器均可完成调用。

为了使每台服务器不至于忙于处理请求，可以将请求均衡到每一个服务器，提升网站的可用性。

##常用负载均衡：

轮询：请求依次按顺序分发到不同的可用服务器执行，循环分发请求。

最小连接：分发请求到连接数最少的服务器。场景：处理请求用时较长的场景。

散列：根据用户请求的IP地址的散列（hash）来选择要转发的服务器。场景：需要处理状态而要求用户能连接到相同服务器。

5、注册中心：服务注册&发现

A服务调用B服务、C服务，但是A服务不知道B、C服务所在的服务器是正常还是掉线，注册中心可以帮助解决。

注册中心实时知道哪些服务正常，哪些服务下线，也能记录新增的正常服务。
服务之间调用不需要去判断哪些服务正常，注册中心会告诉服务有效的调用地址。

##概念

服务注册：服务将自己的IP和端口报告给注册中心的过程。

服务发现：查询可用微服务列表及其网络地址的机制。

注册中心：集中记录每个服务的地址，注册和注销服务。

服务检查：检查已注册的服务，如发现某服务长时间无法访问，则会从注册中心移除该服务。

6、配置中心

每个服务都有大量配置，更新一个配置，需要同步到每个服务，如何修改每个服务的配置呢？

每个服务从配置中心获取配置，自动更新自己的配置。

7、服务熔断&降级

场景：用户下单了一个商品，客户端调用订单服务来生成预付款订单，订单服务调用商品服务查看下单的哪款商品，商品服务调用库存服务判断这款商品是否有库存，如有库存，则可以生成预付款订单。

##服务雪崩service avalanche：

假设服务存在如上调用，"订单服务"流量波动很大，流量经常会突然性增加！那么在这种情况下，就算"订单服务"能扛得住
请求，"商品服务"和"库存服务"未必能扛得住这突发的请求。

此时，如果"库存服务"因为抗不住请求，变得不可用。那么"商品服务"的请求也会阻塞，慢慢耗尽"商品服务"的线程资
源，"商品服务"就会变得不可用。紧接着，对"库存服务"的调用就会占用越来越多的资源，进而引起系统崩溃。


如上，一个服务失败，导致整条链路的服务都失败的情形，我们称之为服务雪崩。

##服务熔断

设置服务的超时，当被调用的服务某段时间内失败率达到某个阈值，则对该服务开启短路保护，
后来的请求不调用这个服务，直接返回默认的数据。

##服务降级

对非核心业务降级运行：某些服务不处理，或者简单处理（抛异常、返回Null、返回Mock数据）

服务熔断 与 服务降级 的区别：

##服务熔断

举个例子解释，生活中每家每户都在用电，小明家的电线因为故障导致了小明家停电了。
而小李、小张家的电是正常使用的。电力公司没有因为小明家有故障线路而停掉其他人家的电，
同时小明家没有使用有故障的电路的电。这时即为熔断。

熔断的目的是当A服务模块中的某块程序出现故障后为了不影响其他客户端的请求而做出的及时回应。

服务熔断是应对雪崩效应的一种微服务链路保护机制。
就像上面例子所说在高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。
同样，在微服务架构中，熔断机制也是起着类似的作用。当调用链路的某个微服务不可用或者响应时间太长时，
会进行服务熔断，不再有该节点微服务的调用，快速返回错误的响应信息。
当检测到该节点微服务调用响应正常后，恢复调用链路。



##服务降级

举个例子解释，我们去银行排队办理业务，大部分的银行分为普通窗口、特殊窗口（VIP窗口，老年窗口）。
某一天银行大厅排普通窗口的人巨多。这时特殊窗口贴出告示说某时刻之后再开放。那么这时特殊窗口的工作
人员就可以空出来去帮其他窗口办理业务，提高办事效率，已达到解决普通窗口排队的人过的目的。这时即为降级，

降级的目的是为了解决整体项目的压力，而牺牲掉某一服务模块而采取的措施。

服务降级是指 当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式
处理，从而释放服务器资源以保证核心业务正常运作或高效运作。说白了，就是尽可能的把系统资源让给优先级高的服务。

资源有限，而请求是无限的。如果在并发高峰期，不做服务降级处理，一方面肯定会影响整体服务的性能，
严重的话可能会导致宕机某些重要的服务不可用。
所以，一般在高峰期，为了保证核心功能服务的可用性，都要对某些服务降级处理。
比如当双11活动时，把交易无关的服务统统降级，如查看蚂蚁深林，查看历史订单等等。


##区别

触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；

管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），
而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）

实现方式不太一样，服务降级具有代码侵入性(由控制器完成/或自动降级)，熔断一般称为自我熔断。

8、网关

API网关的出现的原因是微服务架构的出现，不同的微服务一般有不同的网络地址，而外部客户端可能需要调用多个服务的接
口才能完成完成一个业务需求，如果让客户端直接与各个微服务通信，会出现以下的问题:

1、客户端会多次请求不同的微服务，增加了客户端的复杂性。
2、存在跨域请求，在一定场景下处理相对复制。
3、认证复杂，每个服务都需要独立的认证。
4、难以重构，随着项目的迭代。可能需要重新划分微服务。如果客户端与微服务直接通信，那么重构将会很复杂。
5、某些微服务可能使用了防火墙/浏览器不友好的协议，直接访问会有一定的困难。


抽象了微服务中都需要的公共功能
提供了负载均衡、自动熔断、灰度发布、统一认证、限流、日志统计功能

二、项目架构

三、项目微服务划分