八股文学习二（spring boot + mybatis）-编程知识

三. 架构

1. spring boot

Spring Boot是一个依靠大量注解实现自动化配置的全新框架。约定优于配置；独立运行的 Spring 项目，内嵌servlet容器；Spring Boot 框架内部已经实现了与Spring以及其他常用第三方库的整合连接，并提供了默认最优化的整合配置，使用时基本上不需要额外生成配置代码和XML配置文件。在需要自定义配置的情况下，Spring Boot更加提倡使用Java config(Java 配置类)替换传统的XML配置方式，这样更加方便查看和管理。

(1) ioc & aop

IOC: 使用Spring框架之后对象的实例不再由调用者来创建，而是直接由Spring容器来创建，Spring容器会负责控制程序之间的关系，而不是调用者的程序代码直接控制。控制权由应用程序转移到Spring容器，控制权发生了反转。

AOP: 为开发者提供了一种描述横切关注点的机制，并能够自动将横切关注点织入到面向对象的软件系统中，从而实现了横切关注点的模块化。
AOP能够将那些与业务无关，却为业务模块所共同调用的逻辑或责任，例如事务处理、日志管理、权限控制等，封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性

实现AOP的主要设计模式就是动态代理。
Spring的动态代理有两种：一是JDK的动态代理(只能代理接口)；

另一个是cglib动态代理(可以代理类和接口)。

JDK动态代理主要涉及java.lang.reflect包下的两个类：Proxy类和InvocationHandler接口。

JDK代理实现的三个要点：

① 通过Java.lang.reflect.Proxy类来动态生成代理类；

② 代理类要实现InvocationHandler接口；

③ JDK代理只能基于接口进行动态代理的；

CGLib采用非常底层的字节码技术，可以为一个类创建子类，并在子类中采用方法去技术拦截所有的父类方法的调用，并顺势织入横切逻辑。

CGLib和JDK的原理类似，也是通过方法去反射调用目标对象的方法。

关于Spring的两三事：傻傻分不清楚的filter和interceptor - 知乎

Spring系列之Filter and Interceptor - 简书

spring事务实现原理

Spring实现原理

2.mybatis

MyBatis是一个优秀的持久层框架，它对jdbc的操作数据库的过程进行封装，使开发者只需要关注SQL本身，而不需要花费精力去处理例如注册驱动、创建connection、创建statement、手动设置参数、结果集检索等jdbc繁杂的过程代码。

下图是MyBatis架构图：

(1)mybatis-config.xml是Mybatis的核心配置文件，通过其中的配置可以生成SqlSessionFactory,也就是SqlSession工厂

(2)基于SqlSessionFactory可以生成SqlSession对象

(3)SqlSession是一个既可以发送SQL去执行，并返回结果，类似于JDBC中的Connection对象，也是Mybatis中至关重要的一个对象。

(4)Executor是SqlSession底层的对象，用于执行SQL语句

(5)MapperStatement对象也是SqlSession底层的对象，用于接收输入映射（SQL语句中的参数），以及做输出映射（即将SQL查询的结果映射成相应的结果）

Mybatis（真的超级超级详细） - 知乎

3.dubbo

(1) dubbo架构

为了学习如何使用Dubbo，首先我们要了解dubbo的架构是怎么样的，如上图所示，dubbo 的核心架构中，分了4个角色：注册中心、服务提供者、服务消费者、监控中心。它们的功能分别是：

Registry：注册中心，负责服务地址的注册和查找，服务的Provider和Consumer只在启动时与注册中心交互，注册中心通过长连接感知Provider的存在，在Provider出现宕机的时候，注册中心会立即推送相关事件通知consumer。
Provider：服务提供者。在它启动的时候，会向Registry进行注册操作，将自己的地址和相关配置信息封装成Url添加到Zookeeper中。
Consumer：服务消费者。在它启动时，会向Registry进行订阅操作。Comsumer和Provider建立的是长连接，且Comsumer会缓存Provider信息，所以一旦建立，即使注册中心宕机，也不会影响已运行的Provider和Consumer。
Monitor：监控中心。用于统计服务的调用次数和调用时间，监控中心宕机不会影响Provider和Consumer，只是丢失监控数据。

Dubbo基本原理和用法讲解 - 知乎

4.zookeeper

ZooKeeper 基础知识基本分为三大模块：数据模型、ACL 权限控制、Watch 监控。

数据模型是最重要的，很多 ZooKeeper 中典型的应用场景都是利用这些基础模块实现的。比如我们可以利用数据模型中的临时节点和 Watch 监控机制来实现一个发布订阅的功能。

(1)数据模型

　　数据模型就是 ZooKeeper 用来存储和处理数据的一种逻辑结构。ZooKeeper 数据模型最根本的功能就像一个数据库。

　　ZooKeeper 中的数据模型是一种树形结构，非常像电脑中的文件系统，有一个根文件夹，下面还有很多子文件夹。ZooKeeper 的数据模型也具有一个固定的根节点（/），我们可以在根节点下创建子节点，并在子节点下继续创建下一级节点。ZooKeeper 树中的每一层级用斜杠（/）分隔开，且只能用绝对路径（如“get /work/task1”）的方式查询 ZooKeeper 节点，而不能使用相对路径。

(2)ACL权限控制

如何使用 ZooKeeper 的 ACL 机制来实现客户端对数据节点的访问控制?

　　一个 ACL 权限设置通常可以分为 3 部分，分别是：权限模式（Scheme）、授权对象（ID）、权限信息（Permission）。最终组成一条例如“scheme:id:permission”格式的 ACL 请求信息。

客户端在 ACL 权限请求发送过程的步骤比较简单：首先是封装该请求的类型，之后将权限信息封装到 request 中并发送给服务端。而服务器的实现比较复杂，首先分析请求类型是否是权限相关操作，之后根据不同的权限模式（scheme）调用不同的实现类验证权限最后存储权限信息。

(3)Watch监控

ZooKeeper 的客户端也可以通过 Watch 机制来订阅当服务器上某一节点的数据或状态发生变化时收到相应的通知，我们可以通过向 ZooKeeper 客户端的构造方法中传递 Watcher 参数的方式实现：

new ZooKeeper(String connectString, int sessionTimeout, Watcher watcher)

客户端 Watch 注册实现过程

　　我们先看一下客户端的实现过程，在发送一个 Watch 监控事件的会话请求时，ZooKeeper 客户端主要做了两个工作：标记该会话是一个带有 Watch 事件的请求、将 Watch 事件存储到 ZKWatchManager。

服务端 Watch 注册实现过程

Zookeeper 服务端处理 Watch 事件基本有 2 个过程：解析收到的请求是否带有 Watch 注册事件、将对应的 Watch 事件存储到 WatchManager。

　　ZooKeeper 实现的方式是通过客服端和服务端分别创建有观察者的信息列表。客户端调用 getData、exist 等接口时，首先将对应的 Watch 事件放到本地的 ZKWatchManager 中进行管理。服务端在接收到客户端的请求后根据请求类型判断是否含有 Watch 事件，并将对应事件放到 WatchManager 中进行管理。

　　在事件触发的时候服务端通过节点的路径信息查询相应的 Watch 事件通知给客户端，客户端在接收到通知后，首先查询本地的 ZKWatchManager 获得对应的 Watch 信息处理回调操作。这种设计不但实现了一个分布式环境下的观察者模式，而且通过将客户端和服务端各自处理 Watch 事件所需要的额外信息分别保存在两端，减少彼此通信的内容。大大提升了服务的处理性能。

ZooKeeper - 知乎

Zookeeper的分布式锁实现

Zookeeper的应用场景