（一）简介
1.分布式基础
spring cloud 阿里巴巴：Nacos、Sentinel、Seata
spring cloud：openFeign、Gateway
2.架构演进
（1）单体架构：域名、IP、节点、应用、数据库
单体架构：所有的功能模块在同一个项目里
缺点：无法应对高并发
一个服务器就对应一个节点。
DNS协议：负责将我们输入的网址（如http://www.baidu.com）转换成服务器的IP 地址
（2）集群化架构：副本、集群、网关、负载均衡、扩缩容、集群化。
1）集群架构的优点：解决大并发
2）集群架构的缺点模块化升级导致
订单功能经常升级：v1.0，v2.0...
又因为所有的功能都是打成jar包部署在单体架构上，所以更新就很麻烦。
其次，要重新引入一个直播功能。这个直播功能是和流媒体有关的，一般是用C++语言开发直播模块，又要在直播间中上架一个商品（这就涉及到java的功能），所以多语言之间的协作也是一个问题。
服务器多复制几个就是副本，全部服务器构成集群，
为了应对高并发的情况，用户通过域名给服务器发送请求，一般企业会购买一台服务器部署网关，常见的网关是nginx。所以，我们让域名绑定在服务器上（部署网关的那台服务器），网关实际上不处理业务请求，网关会把收来的所有请求分发给处理业务的服务器集群。网关的功能就是路由，同时也要配备负载均衡的算法，把请求的流量均摊给业务服务器。
网关是所有请求流量的入口。
此外，集群架构还有扩缩容的功能，比如双十一过去了，就可以释放一些服务器，这就是缩容。
扩缩容根据当前的请求和业务量来决定。
（3）分布式：微服务（自治）、远程调用、注册中心、配置中心、服务熔断。
1）分布式架构的优点：微服务、独立部署、数据隔离、语言无关。
因为之前的应用全部在一个服务器上，如果要更新代码就要重新打包部署，效率比较低。
以商城应用为例，我们可以把商城应用的每个功能模块进行拆分。把商品订单拆成一个个的小应用，比如商品、订单、支付、物流、用户、直播等。我们把这个每个小应用叫做微服务。每个微服务可以独立部署。
同理可得，数据库也可以进行拆分。可以拆分成商品库、订单库、支付苦、用户库、物流库、直播苦。
每个业务找对应的数据库访问，而不是订单业务直接去找商品库（数据库）访问，实现了数据隔离。
正确做法：订单业务去找商品业务进行访问。商品业务去访问商品库。
商品和订单业务用Java开发，支付和用户业务用PHP开发，物流和直播用C++开发，实现了语言无关。
如果某个服务的并发量比较大，我们可以把该微服务多部署到几个服务器上。
（4）性能：链路追踪、日志收集、指标监控、消息处理。