0.前后端动静分离的登录验证：没有实际的session概念了，通过token实现验证操作
1.SpringCloud主要技术点：

    * Eureka服务发现：
        是Spring Cloud Netflix微服务套件中的一部分，基于Netflix Eureka做了二次封装，主要负责微服务架构中的服务治理功能
    * Ribbon负载均衡、Hystrix断路器、Feign代理
    * Zuul网关/Config/Bus/Stream
        * SpringCloud Bus 分布式消息队列天然实现：Kafka和RabbitMQ
        * Bus：消息总线，基于Config（配置中心）
    * Zuul+Redis实现token登录验证
    * Activiti工作流

2.阿里巴巴的Dubbo中的服务发现（治理）的几个概念：

    * 服务的提供者（Provider）
    * 服务的调用者（Consumer）
    * 注册中心（服务发现配置中心）（Registry）

3.Spring Cloud服务治理（发现）只需要遵循Spring配置文件配置即可：

    * 在pom.xml中引入响应的配置
    * 在主入口（Application类）中加入@EnableEurekaServer注解
    * 在配置文件中对服务中心进行对应的配置
    * 

4.微服务架构：是一项在云中部署应用和服务的新技术（需要合理的定义业务边界）

    * 可以以模块为边界，进行定义微服务（清晰的业务边界）
    * 高度的模块化服务
    * 每个模块都能完成自己的功能，并且每个模块都可以使用自己本身所需的技术
    * 独立部署运行
    * 可以相互进行通信，可以使用Rest方式，也可以使用RPC方式，更可以使用消息中间件进行消息总线处理

5.垂直系统VS微服务

    * 垂直系统：传统行业的业务系统
    * 垂直系统的弊端（微服务的优点）：

        * 随着业务的增加，复杂性逐渐变高，代码耦合太深，不利于开发和维护
        * 技术债务逐渐加剧
        * 阻碍新技术的加入和使用，只能依赖于原有技术框架开发
        * 无法进行高可用，负载均衡、水平扩展和合理的伸缩
        * 部署的服务速度会随着代码的累积，逐渐变慢，性能降低

6.微服务优缺点：

    * 优点：

        * 扩展性强，便于开发和维护，局部修改简单
        * 启动较快，性能，压力测试更有针对性。调节cpu，内存，磁盘IO性能等参数指标方便。
        * 技术栈不受限制，可以使用任何技术框架、编程语言等
        * 可伸缩性、扩展性、高可用性等
    * 缺点：

        * 运维要求比较高，需要分布式监控，自动化部署测试等
        * 分布式的复杂性，逻辑复杂，以及分布式事务等
        * 接口调试，模块与模块之间联调测试比较复杂

7.SpringCloud与Dubbo主要区别：

    * Springcloud主要通过http直连的方式进行通信，而dubbo底层通过netty的方式进行通信
    * Springcloud没有明确的服务提供者和服务发现的概念，任何服务都是可以成为服务提供者，而dubbo具有明显的服务提供者（provider）和服务发现者（consumer）

8.高可用Eureka服务注册中心：只需要建立两个Eureka服务，把两个注册中的地址相互配置，都配置到对方地址即可。
9.服务发现注册机制：

image.png

    * 服务注册：服务提供者在启动时会通过发送REST请求的方式将自己注册到Eureka服务器上，同时带上了自身服务的一些元素信息，Eureka收到这个REST请求后，将元数据信息存储在一个双层结构map中，其中第一层的key是服务名，第二层的key是具体服务实例名。
    * 服务同步：如上图所示，这里的两个服务提供者分别注册到两个不同的注册中心上，也就是说他们的信息分别被两个服务注册中心维护，此时由于服务注册中心也相互注册服务的关系，当服务提供者发送注册请求到一个服务注册中心的时候，他会将该请求转发给集群中的其他注册中心，从而实现注册中心之间服务同步过程。通过服务同步，两个服务提供者的服务信息通过两台服务注册中心的任何一台获取到。（通过HTTP的方式进行数据同步）
    * 服务续约：服务注册完成后，服务提供者会维护一个心跳，来持续告诉注册中心，该服务还活着，以防止注册中心“剔除该服务”
    * 获取服务：当我们启动消费者的时候，它会发送一个REST请求给注册中心，获取上面的所有服务清单，并且为了性能考虑。返回给客户端的清单缓存默认每隔30s更新一次。
    * 服务调用：消费者获得清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。因为有这些服务实例的详细信息，客户端可以根据自己的需求，决定调用哪个服务实例。在ribbon中会默认采用轮询的方式进行服务调用，从而实现负载均衡机制。
    * 服务下线：在系统运行中必然会出现关闭或者重启某个实例的情况，在关闭服务期间，我们自然不希望调用到已经下线的服务，所以在客户端程序中，当服务正常关闭操作时，它会触发一个服务下线的REST请求给注册中心，通知其下线，当然注册中心收到该请求后，把其他服务列表状态改为下线，并把事件传播给集群其他节点。当出现非正常下线（如内存溢出，断电等）时，注册中心可能并没有收到正常的下线通知请求，这种情况，Eureka内部会有个定时任务，每隔一段时间检查超时的清单进行清除操作。（服务下线不是Eureka server挂了，而是服务提供者下线）