1. 1、Zookeeper是一个由java编写的分布式协调工具，它以节点形式存储数据，有三大特点：
    2.     节点名称不可以重复；
    4.     节点类型可以分为两种或者四种，一种是持久节点，另一种是临时节点，持久节点会持久化到硬盘上，而临时节点和会话连接保持，如果连接断开，那么节点就会被删除；ephemaral,persistent,
    5.     这两种节点又分为是否带_sequential的两种，不带则说明相同名称的节点只能创建一次，如果带有_sequential则表示相同节点名称可以创建多次，其实节点的名称是不同的，只是代替我们做了节点名称后边追加了001,002的操作；
    7.     节点的变动，增加、修改、删除都会有相应的事件通知；
    9. 2、上边第三个特点十分重要，Zookeeper可以做Dubbo的注册中心，当我们服务启动的时候，会以我们的我们的服务名称创建父节点，将我们的ip+port创建出子节点，当我们调用服务的时候，先从zookeeper中以我们的服务名称获取到所有服务器ip和端口号，这样就可以根据调用接口的次数取余服务器的数量做本地的负载均衡，再根据相应 的ip和端口号调用socket进行通信；
    10. 当我们的服务器宕机了或者出现异常了，与zookeeper的连接就会断，zookeeper上相应的临时节点就会删除，但我们在客户端应用了zookeeper监听事件的机制，一旦节点又变动，就会连接更改可调用机器的信息，保证了调用服务安全的问题；
    1. 什么是跨域问题：
    2.     当浏览器请求的域名、端口号与ajax请求的域名、端口号不同的时候，由于浏览器的安全机制，就会出现可以访问接口但是获取不到结果的问题，这就是跨域问题
    4. 跨域问题的解决方案：
    5.     使用jsonp解决跨域问题：不推荐，因为只能处理get请求；
    6.     使用HttpClient进行转发：不推荐，因为效率比较低，会发送两次请求；
    7.     设置相应头允许跨域：可以推荐，适合小公司快速解决问题；
    8.     使用Nginx搭建API接口网关：强烈推荐，因为保证域名和端口号都一致，以项目区分反向代理到真实的服务器地址；
    9.     使用Zuul微服务搭建API网关接口：强烈推荐，SpringCloud  Zuul搭建属于java微服务模块 注册中心 网关服务  a项目 b项目  
    10.     微服务之间的通讯会产生跨域问题吗？不会，因为rpc之间的通讯走的是后端访问，与浏览器无关；
    2. 什么是分布式配置中心：
    3.     在我们传统的项目中，如果我们要修改application.properties配置文件的话，修改完必须提交代码重新部署才可以让本次修改生效，因为我们的项目会有各种环境，并且我们大多数项目都是集群式的，所以重启项目这个过程很费时间，在这种情况下分布式配置中心就诞生了，Apollo分布式配置中心就是其中一种，它主要有potal,admin-service,config-servier,Eureka,client这几个项目，potal就是我们登录apollo平台的接收我们所有操作请求的，config-service就是将前端发过来的请求进行逻辑处理保存到数据库里的，admin-service与config-service公用同一个数据库，config-service是处理我们apollo客户端所发送的请求的，Eureka是所admin-service与config-service的服务注册中心的，client是我们项目需要整合的，当我们在配置中心中发布配置的时候，admin-service会请求config-service,config-service会将配置更改通知给client，client会更改我们jvm内存中相应的key-value，同时也将配置信息缓存到本地文件，防止配置中心挂掉的情况；同时client还会定时向config-service发出拉取配置的请求，防止网络延迟或者直接更改数据库不可同步配置的问题，默认是一分钟一次；
    1. 网站架构演变过程：
    2. 传统架构（单点应用）---分布式架构（以项目进行拆分）---SOA架构（面向服务架构）---微服务架构
    4. 传统架构:把所有的业务模块都放在一个项目中进行开发，这样耦合度很高，开发过程中相互影响比较大，代码冲突较多；
    6. 分布式架构：分布式架构是基于传统架构演变过来的，将传统项目按照功能模块拆分成N多个子项目，比如把邮政的速递系统拆分成基础项目，订单项目，财务项目等项目；本质特征就是打成多个war包进行部署；
    8. SOA架构：面向服务架构，俗称服务化，将共同的业务代码进行抽取出来，提供给其他接口进行调用，服务与服务之间的通讯采用rpc远程调用技术。
    9. rpc远程调用框架：httpclient、spingcloud、dubbo,rpc核心底层是socket技术或者netty实现；
    10. eg:我们很多公司系统都分为前台系统和后台系统，应用soa架构，我们会将两个视图层分别做两个项目，而由于业务层有很多相似的逻辑，数据库已是同一个数据库，所以业务层就公用一个项目；
    12. 微服务架构：微服务架构是由SOA架构演变过来的，继承了SOA架构的优点，在微服务架构中修改了SOA架构中的EJB消息总线，就是采用http+xml传输数据，微服务应用http+json传输；
    13. 微服务架构比SOA架构粒度对服务的划分更加精细；并且每个服务的数据库都是独立的，而SOA架构可以多个服务用一个数据库；这样就保证了服务与服务之间互不影响；
    15. 微服务可扩展性比较强，当我们新接入一个需求的时候我们可以新开一个项目将它完成；按照功能进行划分；比如我做的分发系统，
    19. SpringCloud是一套完整的微服务解决方案框架，不像其他微服务框架，只是解决微服务中的某个问题，springCloud不需要集成其他框架就可以完成分布式配置中心、分布式锁、分布式调度、分布式服务治理，分布式跟踪等；
    1. client只会注册到server中的一台，如果宕机，则会将注册信息转移到其他server；
    3. Eureka为了防止出现由于网络问题造成EurekaClient与EurekaServer暂时无法通讯，但是EurekaClient还可以正常访问，EurekaServer将client剔除的情况，设置有自我保护机制，默认90s内EurekaServer没有接收到EurekaClient发送的心跳包，则将相应的EurekaClient剔除；
    4. 在生产环境中可能会出现这种情况，但是在开发环境中，我们应该禁止这种保护机制，因为我们可能在重启某个服务，要避免我们在重启服务的时候其他服务调用本服务；
    2. 服务的雪崩效应：
    3.     默认情况下tomcat只有一个线程池去处理客户端发送的所有服务请求，这样的话在高并发情况下，如果客户端所有请求堆积到同一个服务接口上，就会产生tomcat的所有线程去处理这个服务接口，可能就会导致其他服务接口无法访问的问题；
    7. Hystrix是开源的高可用框架；主要用来解决服务的雪崩效应；
    9.     服务降级：
    10.         在高并发情况下，防止用户一直等待，使用服务降级方式，也就是返回一个友好的提示，目的是为了用户的体验；
    11.         如果调用其他接口超时的时候（默认是1s），如果1s没有完成请求，则直接采用服务降级的形式来返回给客户端
    12.     服务熔断：
    13.         服务熔断是为了保护服务，在高并发情况下，如果请求达到了一定得极限（可以自己设定阈值）；如果流量超出了阈值，自动开启自我保护机制，使用服务降级的方式返回客户短信息；
    14.     服务隔离：默认开启了线程池隔离机制，这个只适用于会出现问题的核心接口上，因为会造成CPU的占用率非常高；
    19. 在高并发的时候，定会产生堆积请求，如果大量请求正在等待，如果堆积请求过多，可能会造成服务器瘫痪；
    21. 服务的雪崩效应：在同一时刻有大量请求来访问某个服务接口的时候，这个造成tomcat线程池会被完全占用，会造成其他服务接口无法正常访问的问题，
    23. Hystrix有服务降级、服务熔断、服务隔离的功能；
    25. 服务降级：在服务不可用的时候（连接超时、网络延迟、服务器响应慢）,避免让客户一直等待的尴尬现象，则直接返回给客户端一个友好的提示，比如此时服务忙，请稍后重试；目的解决用户体验；
    27. 服务熔断：在高并发的时候，我们知道tomcat默认会共用同一个线程池来处理所以的客户端请求，如果这个线程池最大线程数是100，队列可存放的元素的个数是500，那么当我们并发请求书超过600的时候，已经达到了服务器最大承受能力，如果再增加并发量，则直接拒绝访问服务，以服务降级的方式返回给客户端；目的是保护服务安全性，防止宕机；
    29. 服务隔离：不同的服务接口在高并发情况下互不影响；方法有线程池方式与信号量方式；线程池方式是最好的，这个会造成CPU占用率升高，但的确可以解决服务雪崩效应；
    1. 1、Dubbo:分布式服务治理框架 主要由四个主要组成部分，注册中心，生产者，消费者，监控中心
    3. 生产者的注册：
    4. Dubbo支持四种注册中心，常用的只有Zookeeper与Redis，推荐使用Zookeeper，我们先启动我们的注册中心，当我们的服务启动的时候，我们会将接口全路径作为节点名称在Zookeeper上创建，还有创建一个子节点名称为providers,在provider下还会创建一个子节点，那就是rpc调用服务的接口地址；
    6. 消费者的订阅：
    7. 消费者在启动的时候，就会将根据接口的全路径从zookeeper中查找相应的provider,并且注册相应的节点变化的事件通知，可以在生产者服务出现异常的时候及时更新本地内存中的provider的信息；
    9. 消费者获取到调用地址，进行rpc调用访问接口；
    11. 在这个调用过程与结果被监控中心Monitor记录和监控；
    13. 2、Dubbo的优缺点
    14. 优点：
    15.     透明化的远程方法调用，只需要简单配置，不需要知道服务提供者地址，就可以像调用本地方法一样调用远程方法，并且实现了本地负载均衡与容错机制；
    16.     Dubbo-admin与Dubbo-monitor提供了完善的服务接口管理与监控管理；，可以进行 多版本，多协议，多注册中心管理
    17. 缺点：只支持Java语言；
    20. 3、软负载与硬负载的区别：
    21.     软负载均衡是通过服务器上安装负载均衡软件或者使用本地负载均很算法实现负载均衡算法，例如Ngix,Ribbon
    22.     硬负载：F5负载均衡是硬件负载均衡的一种，硬件负载均衡，在服务器节点之间安装专门的硬件进行负载的工作；
    24. 4、为什么会出现渐渐放弃Dubbo,更多的使用SpringCloud的趋势；
    2. 网关就是一个网络连接到另一个网络的网络关口，是网间连接器；
    4. 网关的作用，可以实现负载均衡、路由转发、日志、权限控制、监控等
    1. 分布式事务产生的背景：
    2. 传统项目中应用了多数据源；
    3. 分布式项目，服务与服务之间通讯采用RPC远程调用技术，但是每个服务都有自己独立的数据源，独立的本地事务，服务通讯的时候，两个本地事务在某些时候互不影响，从而出现分布式事务；
    4. a调用b，但是b报错，如果现在终止掉通过判断状态码而判断是否需要抛异常解决事务一致性就不会产生问题；如果a后边的代码报错，则b无法回滚，就会出现问题；
    6. CAP与Base理论
    8. C：
    9. Consistency，一致性。在分布式系统中，完成写的操作后任何读的操作都可以读到刚写入的新值；
    11. A:
    12. Availability,可用性，客户端一致可以正常访问并得到系统的正常响应，也就是说服务都会在有限时间内处理完成并作出响应；
    14. P：
    15. Partition Tolerance分区容错性，分布式系统中出现某个节点故障的时候，仍然能够对外提供满足一致性或可用性的服务；
    16. 柔性事务与刚性事务
    20. Base思想：
    21. Base思想与ACID原理截然不同，它满足CAP原理，通过牺牲一致性获得可用性，一般应用与微服务系统中，通过达到最终一致性来尽量满足业务中的绝大多数需求
    23. Base模型包含如下三个元素：
    24. BA:Basically Available 基本可用
    25. S ：soft state，软状态，状态可以在一段时间内不同步；
    26. E ：Eventually consistent,最终一致，在一定时间内，最终数据达成一致即可；
    29. 柔性事务和刚性事务
    30. 柔性事务满足BASE理论，基本可用，最终一致；
    31. 刚性事务满足ACID理论；
    35. JTA+XA
    38. 两阶段与三阶段提交
    39. 两阶段提交：
    40.     第一阶段提交中协调者会向参与者发送准备通知的，如果参与者接收到通知，都会把该业务逻辑是否执行成功返回给协调者。如果参与者都返回为执行成功，协调者在第二阶段发送提交事务通知，有过有一方执行失败，就会终止提交事务；
    41. 三阶段通知就是在两阶段提交上做了改进，增加了询问阶段，协调者询问参与者是否可以完成指令，如果在一定时间内没有返回，就会超时终止，事务进行回滚，有了这个阶段就不会避免由于网络或者服务超时的原因事务得不到事务而导致的数据库问题，
    43. jta+atomickos:
    44. JTA是操作java事务的API
    45. Atomickos:Atomikos TransactionsEssentials是一个为Java平台提供的开源的事务管理器框架，这个框架的底层就是转训XA协议开发的，XA事务的基础就是两阶段提交协议；
    48. LCN的概念：
    49. 基于LCN框架解决分布式事务；LCN并不生产事务，LCN只是本地事务的搬运工；兼容dubbo,springcloud，motan框架，支持各种关系型数据库；
    51. LCN的原理：
    52. LCN原理模型有三个重要组成部分发起方、参与方，事务协调者TxManager,当我们调用方法的前判断是否加上了@TxTransaction注解，如果加上了，那么此方法应用了LCN分布式事务，如果属性isStart值为true，则为服务发起者，如果为false则为参与者；在调用方法前发起方与参与方都会这测到事务协调者中，建立一个长连接，
    54. 然后发起者会向事务协调者中创建一个分组id；当调用参与者的时候，会将在分组id存放在请求头中，发送给参与者；
    55. 如果参与者获取到请求头中的事务分组id，如果参与者代码正常运行完毕，由于lcn框架重写了DataSource中的close方法，采用了假关闭的形式，并不会提交事务，然后将操作结果返回给发起者，当发起者在之后执行过程中出现了异常，发起者会将事务分组id通知给事务协调者，事务协调者接收到发起者的事务分组id，会向相同的事务分组id的参与者服务发起通知让其进行事务回滚；如果发起者后续执行顺利，也会以相同的方式提交事务；这样就实现了分布式事务；
    2.     在复杂的微服务系统中，当我们都发出一个Http请求，会调用多个不同的微服务接口来处理请求才能得到最后的结果，如果一个请求出现了异常的情况，我们需要查找具体原因的时候对请求调用的监控与记录就显得尤为重要了；Spring Cloud Sleuth提供了分布式微服务服务链路监控的解决方案，当我们从客户端发出一个Http请求的时候，请求会到达第一个微服务接口，spring cloud sleuth会创建以个traceid和spanid，traceId是整个请求链路的id，而spanid是微服务接口的id，第一接口子在运行过程中又调用了另一个接口，那么spring cloud sleuth再次创建一个spanId，与这个spanid对应有traceId,也就链路id,同时也有parentid，也就是上个微服务接口的spanid，调用下个接口也是这样的操作，spring cloud sleuth 会将生成的数据通过我们项目中集成的zipkin 
    5.     client发送到zipkin服务器上进行保存，我们就可以通过Zipkin可视化界面中查询到我们请求链路的信息；