分布式与微服务
- 分布式
分布式系统是由多台计算机（或节点）组成的网络，这些计算机通过网络协议进行协调和合作，共同完成任务或提供服务。在分布式系统中，各个计算机可以分担不同的任务或功能，通过相互通信和协调来实现整体的目标。分布式系统可以在不同的地理位置上运行，可以提高系统的可扩展性、可靠性和性能。 - 微服务
微服务是一种软件架构风格，将一个大型应用程序拆分成多个小型、独立的服务。每个服务都专注于完成特定的业务功能，并且可以独立部署、扩展和维护。这些服务之间通过网络通信协议进行交互，通常使用轻量级的通信机制，如HTTP或消息队列。微服务架构的目标是使开发团队能够更快速地进行开发、测试和部署，同时提供更好的可维护性和可扩展性。
两者的区别
- 规模和粒度：分布式系统是一个更宽泛的概念，指的是多台计算机协同工作以实现共同目标。微服务是一种特定的架构风格，关注于将应用程序拆分成小型独立服务，每个服务专注于一个特定的业务功能。
- 关注点：分布式系统强调多个计算机之间的协同工作和资源共享，以提供更大的系统能力。微服务架构强调在开发和维护阶段将应用程序分解为独立的服务，以促进敏捷开发和部署。
- 通信方式：分布式系统中的各个组件可以通过不同的通信方式进行交互，可以是远程调用、消息传递等。微服务架构通常使用HTTP、RESTful API、消息队列等轻量级通信机制。
- 部署和维护：微服务架构的服务可以独立部署和维护，这使得团队可以更灵活地更新、扩展或替换单个服务。在分布式系统中，更强调多个计算机之间的协调和一致性，这可能会引入更复杂的部署和维护问题。
总之，分布式系统是一个更广泛的概念，指的是多台计算机的协同工作，而微服务是一种特定的架构风格，强调将应用程序拆分成小型独立服务来提高开发效率和系统灵活性。微服务架构可以在分布式系统的基础上实现，但并不是唯一的分布式系统实现方式。
分布式
CAP理论
CAP也就是
- Consistency（一致性）：所有节点访问同一份最新的数据副本
- Availability（可用性）：非故障的节点在合理的时间内返回合理的响应
- Partition Tolerance（分区容错性）：分布式系统出现网络分区的时候，仍然能够对外提供服务
总结
- CAP理论中，分区容错性P一定要满足的，在此基础上，只能满足可用性A或一致性C。
- 分布式系统理论上，不可能选择CA架构，只能选择CP或AP架构。
- ZooKeeper、HBase就是CP架构
- Eureka是AP架构
- Nacos不仅支持CP架构也支持AP架构
- 为啥不能选择CA架构呢？ 举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。
BASE
ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。
Gateway
Spring Cloud Gateway 属于 Spring Cloud 生态系统中的网关，其诞生的目标是为了替代老牌网关 Zuul。
- 路由判断：客户端的请求到达网关后，先经过 Gateway Handler Mapping 处理，这里面会做断言（Predicate）判断，看下符合哪个路由规则，这个路由映射后端的某个服务。
- 请求过滤：然后请求到达 Gateway Web Handler，这里面有很多过滤器，组成过滤器链（Filter Chain），这些过滤器可以对请求进行拦截和修改，比如添加请求头、参数校验等等，有点像净化污水。然后将请求转发到实际的后端服务。这些过滤器逻辑上可以称作 Pre-Filters，Pre 可以理解为“在…之前”。
- 服务处理：后端服务会对请求进行处理。响应过滤：后端处理完结果后，返回给 Gateway 的过滤器再次做处理，逻辑上可以称作 Post-Filters，Post 可以理解为“在…之后”。
- 响应返回：响应经过过滤处理后，返回给客户端。
总结：客户端的请求先通过匹配规则找到合适的路由，就能映射到具体的服务。然后请求经过过滤器处理后转发给具体的服务，服务处理后，再次经过过滤器处理，最后返回给客户端。
