• AOP (Aspect Orient Programming) 面向切面编程是从动态角度考虑程序的运行过程
• AOP底层，就是采用动态代理模式实现的，采用了两种代理，JDK的动态代理和CGLib的动态代理
• 实际上AOP就是动态代理的一种规范化，因为动态代理种类繁多，掌握较难，所以就规范了一套统一的方式，这就是AOP
• AOP把动态代理的实现步骤，方式都定义好了，让开发人员用一种统一的方式，去用动态代理。
JDK:
• jdk动态代理，要求jdk中有Proxy，Method，InvocationHandler创建代理对象
• jdk代理要求目标类必须实现接口
CGLib：
• 第三方的工具库，创建代理对象，原理是继承，通过继承目标类创建子类，子类就是代理对象
• CGLib要求目标类不能是final的 方法也不能是final的
• 是基于spring的一个框架，实际上就是spring的一个模块，专门做web开发的
• 可以理解为Servlet的升级
• web开发底层就是Servlet，框架是在Servlet基础上面添加一些功能，做web项目更方便
• SpringMVC能够创建对象，放入到容器中（SpringMVC的容器） SpringMVC里面放的是控制器对象
• 我们要做的是使用@Controller注解创建控制器对象，把对象放入到SpringMVC容器中，把创建的对象作为控制器使用
• 这个控制器对象能接收用户的请求，显示处理结果，就当作是一个servlet使用【并不是servlet，就是普通对象】
• 使用@Controller创建的对象，其实就是个普通的对象，springMVC赋予了他控制器的能力
• Springmvc底层访问依然是DispatcherServlet 他的两大作用：
• 创建WebApplicationContext对象，读取配置文件，进而控制控制器对象
• 本身就是一个Servlet，要接收请求，显示结果
源码下载：下载
原文：https://blog.csdn.net/unique_perfect/article/details/109380996
MQ(Message Quene) : 翻译为消息队列,通过典型的生产者和消费者模型,生产者不断向消息队列中生产消息，消费者不断的从队列中获取消息。因为消息的生产和消费都是异步的，而且只关心消息的发送和接收，没有业务逻辑的侵入,轻松的实现系统间解耦。别名为 消息中间件通过利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。
当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等。
原文链接：https://blog.csdn.net/u011863024/article/details/114298270
为什么需要分布式全局唯一 ID 以及分布式 ID 的业务需求？集群高并发情况下如何保证分布式唯一全局 ID 生成？
在复杂分布式系统中，往往需婴对大量的数据和消息进行唯一标识，如在美团点评的金融、支付、餐饮、酒店，猫眼电影等产品的系统中数据日渐增长，对数据分库分表后需要有一个唯一 ID 来标识一条数据或消息。特别一点的如订单、骑手、优惠券也都雷要有唯一 ID 做标识。此时一个能够生成全局唯一 ID 的系统是非常必要的。
ID 生成规则部分硬性要求
全局唯一：不能出现重复的 ID 号，既然是唯一-标识，这是最基本的要求
趋势递增：在 MySQL 的 InnoDB 引擎中使用的是聚集索引，由于多数 RDBMS 使用 Btree 的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
单调递增：保证下一个 ID 一定大于上一个 ID，例如事务版本号、IM 增量消息、排序等特殊需求
信息安全：如果 ID 是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可。如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，需要ID无规则不规则，让竞争对手否好猜。
含时间戳：这样就能够在开发中快速了解这个分布式id的生成时间。
ID 号生成系统的可用性要求
高可用：发一个获取分布式 ID 的请求，服务器就要保证 99.999% 的情况下给我创建一个唯一分布式 ID。
低延迟：发一个获取分布式 ID 的请求，服务器就要快，极速。
高 QPS：假如并发一口气 10 万个创建分布式 ID 请求同时杀过来，服务器要顶的住且一下子成功创建 10 万个分布式 ID。
原文链接：https://blog.csdn.net/u011863024/article/details/114298270
分布式前
单机单库没这个问题
从1:1 -> 1:N -> N:N
单体应用被拆分成微服务应用，原来的三个模块被拆分成三个独立的应用,分别使用三个独立的数据源，业务操作需要调用三三 个服务来完成。此时每个服务内部的数据一致性由本地事务来保证， 但是全局的数据一致性问题没法保证。
一句话：一次业务操作需要跨多个数据源或需要跨多个系统进行远程调用，就会产生分布式事务问题。
本文代码：下载
原文链接：https://blog.csdn.net/u011863024/article/details/114298270
官方Github: https://github.com/alibaba/Sentinel
官方文档: https://sentinelguard.io/zh-cn/docs/introduction.html
随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Sentinel 具有以下特征:
**丰富的应用场景：**Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
**完备的实时监控：**Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
**广泛的开源生态：**Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
**完善的 SPI 扩展点：**Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
本文代码：下载
原文链接：https://blog.csdn.net/u011863024/article/details/114298270
为什么叫Nacos
前四个字母分别为Naming和Configuration的前两个字母，最后的s为Service。
是什么
一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
Nacos: Dynamic Naming and Configuration Service
Nacos就是注册中心＋配置中心的组合 -> Nacos = Eureka+Config+Bus
能干嘛
替代Eureka做服务注册中心
替代Config做服务配置中心
去哪下
https://github.com/alibaba/nacos/releases
各中注册中心比较
| 服务注册与发现框架 | CAP模型 | 控制台管理 | 社区活跃度 |
|---|---|---|---|
| Eureka | AP | 支持 | 低(2.x版本闭源) |
| Zookeeper | CP | 不支持 | 中 |
| consul | CP | 支持 | 高 |
| Nacos | AP 或 CP | 支持 | 高 |
据说Nacos在阿里巴巴内部有超过10万的实例运行，已经过了类似双十一等各种大型流量的考验。
Spring Cloud Netflix项目进入维护模式
https://spring.io/blog/2018/12/12/spring-cloud-greenwich-rc1-available-now
什么是维护模式？
将模块置于维护模式，意味着Spring Cloud团队将不会再向模块添加新功能。
他们将修复block级别的 bug 以及安全问题，他们也会考虑并审查社区的小型pull request。
该篇文档，参考代码：下载
原文链接：https://blog.csdn.net/u011863024/article/details/114298270
为什么会出现这个技术？要解决哪些问题？
在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。