适用场景：

如果从服务器获取数据，js可以直接解析。 使用JSONP，如果服务器程序的返回值需要进一步处理。 在这种情况下，使用

1.30 你们的单点登录是如何称呼的？

流程图：

原则：

实施步骤：

用户登录后，通过nginx访问jt-web中的任意服务器，输入用户名和密码即可访问JT-SSO单点登录服务器。

获取用户的登录信息并查询数据库验证用户名和密码是否正确。 如果用户名和密码正确，则将用户信息转换为JSON字符串。 然后生成加密秘钥TOKEN（MD5（盐值+随机数））。 保存token：在redis中，并将token信息返回给客户端（jt-web）。

Jt-web接收到服务器数据时，首先验证数据是否有效。 如果数据准确，则将令牌信息写入浏览器（4K）

当用户再次访问jt-web时，首先要获取用户的Token信息，然后查询redis缓存服务器获取数据，然后将其转换为User对象使用。 实现免密码登录。 如果令牌数据为空，则允许用户访问登录页面。

1.31 如何在同一个线程内共享数据（）

名称：局部线程变量

功能：实现同一线程内的数据共享。

原则：

描述：它是线程安全的，可以在同一线程内共享数据。

注意：使用完后记得销毁对象，否则gc将无法回收，造成JVM内存泄漏。

班级 {

//如果保存数据有多个,则使用Map集合
private static ThreadLocal userThread = new ThreadLocal();public static void set(User user){userThread.set(user);
}public static User get(){return userThread.get();
}//线程销毁方法
public static void remove(){userThread.remove();
}

1.32 如何实现单点登录SSO

问题：由于后端服务器采用集群部署方式，所以必须有多台服务器。 如果用户的登录信息保存到服务器上，则无法在多个服务器之间共享。 因此，共享的实现方式各不相同，导致用户频繁登录。

初级：使用 Nginx 提供的内容

先进的：

1. 用户登录时，首选访问方式是单点登录服务器。 执行登录操作。

2. 如果登录正确，则生成用户的密钥令牌。 将用户信息转换为JSON字符串，与token一起保存到redis缓存中。

3. 返回token信息给客户端。 将数据保存到客户端浏览器。

4、当用户需要使用用户信息进行其他操作时，首先检查是否有token，其次检查redis中的数据是否为空。 如果一切正确，则允许跳转到指定页面。 如果有一项出现错误，则说明用户登录出现异常。 让用户再次登录。

1.33 当zk宕机时，消费者能否正确消费？？？

阐明：

答：是的

因为zk会动态更新服务列表信息给客户端。 当zk宕机时，由于之前zk的服务列表信息已经同步，客户端可以根据其缓存的列表进行访问。 如果服务器程序在这段时间内发现宕机现象，那么在访问故障机器时，无法进行通信，服务器会等待超时时间，然后再访问下一台服务器。

如果此时所有服务器程序都宕机了，整个服务就会瘫痪。

1.34 微服务治理计划（）

注意：添加服务器或减少服务器是自动完成的。

业务逻辑描述：

1、服务提供者启动时，会将服务名:IP:端口写入注册中心。

2、注册中心内部维护一份服务清单

3、消费者需要访问服务时，需要先访问注册中心获取服务列表信息。 然后将服务列表保存到本地缓存，方便后续访问。 客户端内部有一个负载均衡算法来选择一个服务器，然后进行访问。

4、如果后端服务器宕机，注册中心会通过心跳检测来判断服务器是否宕机。 如果服务器宕机，服务器信息将从服务列表中删除。 然后新的服务列表将被发送给消费者。 （客户端）更新。

1.35如何理解SOA（面向服务）

面向服务的体系结构 (SOA) 是一种组件模型，它通过这些服务之间定义良好的接口和契约来连接应用程序的不同功能单元（称为服务）。 接口以中立的方式定义，应该独立于实现服务的硬件平台、操作系统和编程语言。 这使得各种系统中构建的服务能够以统一且通用的方式进行交互。

1.36 你知道RPC协议吗？

总结：RPC调用的规则可以传输java对象。 底层实现将数据转换为流，并且流是加密的。 并且rpc内部使用的是UTF-8编码格式。

要求：传递的java对象必须是序列化的

1.37 什么是Dubbo框架

Dubbo是[1]阿里巴巴开源的高性能、卓越的服务框架（SOA），使应用程序能够通过高性能RPC实现服务输出和输入功能，并可以与框架无缝集成。

1、与ZK的区别

nginx：

1.Nginx主要用于反向代理（Http）

2.负载均衡

3.Nginx主要构建在公司的网关服务器上

zk：通过RPC进行远程方法调用，是一个服务器程序

主要功能是实现服务器的高可用性。 它建立在内部网上。

1.39 你知道什么是消息队列吗？并说出一些常用的消息队列吗？

消息队列可以缓解服务器的访问压力。 当请求被服务器访问时，首先写入到消息队列中，这样可以实现请求的异步操作，起到平峰截骨的作用。

但缺点是消耗了用户的实际等待时间。

常见的消息队列产品包括（爱立信的）

1.40 消息队列有几种工作模式

1. 简单模式 2. 工作模式 3. 发布订阅模式 4. 路由模式

5.主题模式 6.RPC模式

1.41 倒排索引

倒排索引源于实际应用中根据属性值查找记录的需要。 这种索引表中的每个条目包括属性值和具有该属性值的每个记录的地址。 由于属性值不是由记录决定，而是由属性值决定记录的位置，所以称为倒排索引（index）。 带有倒排索引的文件称为倒排索引文件，简称倒排文件。

1. 简介/ES

Solr是一个独立的企业级搜索应用服务器，对外提供类似Web的API接口。 用户可以通过http请求向搜索引擎服务器提交一定格式的XML文件，生成索引； 他们还可以通过Http Get操作发出搜索请求并获取XML格式的返回结果。

基于全文搜索服务器。 同时进行了扩展，提供更丰富的查询语言，同时可配置、可扩展、优化查询性能，并提供完整的功能管理界面。 它是一个优秀的全文搜索引擎。

特征：

1、Solr可以根据数据库表自动生成索引文件。

2.Solr可以自动动态定期更新索引（针对更新的数据修改索引）

1 简介

它是一个开源的应用程序容器引擎，允许开发人员将他们的应用程序和依赖包打包到一个可移植的容器中，然后将其发布到任何流行的Linux机器上。 它还可以虚拟化。 容器完全采用沙箱机制。 ，它们之间不会有任何接口。

一个完整的系统由以下几部分组成：

客户

守护进程客户端与容器交互的媒介

用于镜像应用程序的图像模板

容器启动后的应用

1. 调用原理

模块说明：

1.

客户程序

2.

它一般运行在宿主主机的后台，作为服务器接收客户端请求，并处理这些请求（创建/运行/分发容器）。

客户端和服务器既可以运行在一台主机上，也可以通过 / 进行通信

3.图片：

中的图像文件是应用程序的模板，一般是只读的，不允许修改。

图像文件有两个来源：

1.官网图片文件

2.本地镜像文件

4.：

容器，通过镜像镜像创建容器后，运行容器中的应用程序（类似于新建一个对象）

5.：

管理镜像的仓库类似于管理jar包文件的Maven仓库。

调用原理：

1、客户端通过请求创建容器

2.收到请求后，搜索所需的Image镜像文件

3.找到对应的镜像文件后，创建容器

4.调用容器完成特定任务（redis/nginx//mysql等）

1. 镜像拉取流程

1、客户端获取到图片文件后，会向服务器发起请求。

2. 引擎会首先检查本地是否有镜像文件。 如果没有，它将在线下载图像文件。

3. 从公有云获取Image镜像文件并保存到本地。

4、当用户需要使用应用程序时，通过镜像文件创建容器，为用户提供服务。

灾难

1.46 晶涛项目人员配置

开发周期：4个月开发但不断更新迭代

购物车产品展示页面的产品规格

评价体系

订单物流系统京东物流/调用菜鸟包装并调用第三方接口获取数据进行展示（http）

支付系统：银行接口/第三方支付http

推荐系统：……

产品经理：3人，确定需求并提供产品原型图纸

项目经理：1人，项目管理。

前端团队：5人，根据产品经理给的原型制作静态页面。

后端团队：20人，实现产品功能。

测试团队：5人，测试所有功能。 2 人 3 人脚本 shell

运维团队：3人，项目发布和维护。

1.47 日常活动/并发

日活跃量：200万

并发量：1500-2300左右

单点并发压力18台服务器

服务器事业部

mysql 2

Mycat服务器1

索尔3

雷迪斯3

图像服务器2

nginx 2

登记中心3

2

18台服务器

捷特5号

Jt-web 10

Jt-sso 3

京东购物车5

Jt-订单 5

捷特5号

33 单位

1、新开发方式的特点

创建独立的应用程序

嵌入式，无需部署WAR文件

简化Maven配置

自动配置

提供生产就绪的功能，例如指标、运行状况检查和外部配置

1.49什么是微服务架构？

“微服务”来自这篇博文。

说：微服务是系统架构中的一种设计风格。 其主要目的是将一个原本独立的系统拆分成多个小服务。 这些小服务都在自己独立的进程中运行。 这些服务通过基于 HTTP 的 API 连接以进行通信和协作。 拆分出来的每一个小服务都是围绕系统中的某个项或者一些高度耦合的业务功能构建的，每个服务都维护着自己的数据存储、业务开发、自动化测试用例和独立的部署机制。 由于轻量级的通信和协作基础，这些微服务可以用不同的语言编写。

1.50 核心特性

 配置中心

 服务发现

 断路器

 智能路由

micro-proxy 微代理

 总线控制总线

一次性代币

 锁全局锁

 选举算法

分布式会话

 状态集群状态

1.51 核心组件架构图

1.52 扩展：CAP定理

CAP原理，又称CAP定理，是指在分布式系统中，（一致性）、（可用性）、（分区容错）不能同时实现。 它是分布式系统中最核心、最重要的理论。

分布式系统的CAP理论：该理论首先总结了分布式系统的三个特点：

一致性（C）：分布式系统中所有数据备份是否同时具有相同的值。 （相当于所有节点访问相同的最新数据副本）

可用性（A）：集群中部分节点发生故障后，整个集群是否还能响应客户端的读写请求。 （数据更新的高可用性）

分区容错（P）：实际上，分区相当于通信的时限要求。 如果系统在时限内无法达到数据一致性，则说明发生了分区，当前操作必须在C和A之间进行选择。

CAP理论意味着在分布式系统中，最多只能实现以上两点。 由于现在的网络硬件肯定会存在延迟丢包等问题，所以分区容错是我们必须要实现的。 所以我们只能在一致性和可用性之间进行权衡，要么选择CP，要么选择AP。 没有一个分布式系统能够同时保证这三点。

1、比较

它是一个开源产品，提供服务注册和发现，并提供相应的Java封装。 在其实现中，节点之间是平等的，注册中心的某些节点发生故障不会影响集群。 即使集群只剩下一个节点，仍然可以正常提供发现服务。 即使所有服务注册节点宕机，服务调用信息也会缓存在（客户端）上。 这确保了我们的微服务之间的相互调用足够稳健。

主要为大规模分布式计算提供开源的分布式配置服务、同步服务和命名注册服务。 它曾经是项目中的一个子项目，用于控制集群中的数据，现已升级为独立的顶级项目。 它还在许多场景中用作发现服务解决方案。

比较的

根据著名的CAP定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错），CAP的这三个特性在任何分布式系统中都无法同时满足，最多有两个CP或者AP可以同时满足。 ）。

它是基于CP设计的，即任何时候的访问请求都能获得一致的数据结果，系统对网络分段具有容错能力，但不能保证每个服务请求的可用性。 从实际情况分析，在使用获取服务列表时，如果正在选或者集群中有超过一半的机器不可用，将无法获取数据。 因此，无法保证服务可用性。

诚然，在大多数分布式环境中，尤其是涉及数据存储的场景，首先应该保证数据的一致性，这也是CP被设计的原因。 但对于服务发现场景，情况就不同了：对于同一个服务，即使注册中心不同节点存储的服务提供者信息不同，也不会造成灾难性的后果。 因为对于服务消费者来说，最重要的是能够消费——拿到可能不正确的服务实例信息后尝试消费，比因为无法获取实例信息而不去消费要好。 （尝试一下，很快失败，然后可以更新配置，再试一次。）因此，对于服务发现，可用性比数据一致性更重要——AP胜过CP。

Cloud在设计时遵循AP原则。 也可以运行多个实例构建集群来解决单点问题，但与选举过程不同的是，使用的是Peer to Peer点对点通信。 这是一个去中心化的架构，没有/从属的区别，每个对等点都是平等的。 在这种架构中，节点相互注册以提高可用性，每个节点都需要添加一个或多个指向其他节点的有效指针。 每个节点都可以被认为是其他节点的副本。

如果某个服务器宕机，请求会自动切换到新节点。 当宕机的服务器恢复后，将重新纳入服务器集群管理。 当节点开始接受客户端请求时，将执行所有操作（节点间复制），将请求复制到所有其他当前已知的节点。

新节点启动后，首先会尝试从邻居节点获取所有实例注册信息来完成初始化。 所有节点都是通过()方法获取的，并且会通过心跳更新的方式定期更新。 默认配置下，如果在一定时间内没有收到服务实例的心跳，该实例将被注销（默认为90秒，通过..lease---in-配置）。 当节点在短时间内丢失过多心跳（例如网络分区故障）时，节点将进入自我保护模式。

总结

基于CP，不保证高可用性。 如果正在选举，或者集群中有超过一半的机器不可用，将无法获取数据。 基于AP，可以保证高可用性。 即使所有机器都宕机了，你仍然可以获得本地缓存的数据。 作为一个注册中心，配置其实并不经常改变。 仅当版本发布（发布新版本）以及机器出现故障时才会发生变化。 对于不经常更改的配置，CP 不适合。 当AP遇到问题时，可以通过返回旧数据和缓存数据的方式牺牲一致性来保证可用性。

所以理论上来说，做登记中心比较合适。 在现实环境中，大多数项目可能会使用它，因为集群不够大，用作注册中心的机器一半以上宕机的情况基本不太可能发生。 所以这其实并不是什么大问题。

1.54 扩展：对关系数据库的分布式影响

对于Web网站来说，关系数据库的许多主要功能往往是无用的。

数据库事务一致性要求

很多Web实时系统不需要严格的数据库事务，对读一致性的要求很低。 有些情况下，对写入一致性的要求并不高。 允许最终一致性。

数据库的实时读写要求

对于关系型数据库来说，如果插入一条数据后立即查询，肯定可以读取到该数据。 然而，对于许多Web应用程序来说，并不需要如此高的实时性能。 例如，发送消息后，几秒钟后，我的订阅者仅十秒钟后看到此更新是完全可以接受的。 例如：MQ消息队列机制，意思是，它可以解决瞬时高并发，消峰填谷。

复杂SQL查询的需求，特别是多表相关查询

任何一个数据量大的Web系统都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，尤其是SNS类型的网站。 这种情况从需求和产品设计的角度是可以避免的。 生产。 往往只有单表的主键查询和简单的单表条件分页查询。 SQL的功能被大大削弱。

SNS：全称，专指社交网络服务，包括社交软件和社交网站。 例如：、腾讯QQ、微信等。

1.55 自我保护模式

什么是自我保护模式？ 默认配置下，如果每分钟收到的心跳更新次数低于阈值（次数（60/心跳间隔秒数）自我保护系数）并持续15分钟，就会触发自我保护。 在自我保护模式下，服务注册表中的信息将受到保护，并且不会注销任何服务实例。 当收到的心跳数恢复到阈值以上时，节点自动退出自我保护模式。 前面提到了它的设计理念，即宁愿保留不正确的服务注册信息，也不愿盲目取消任何潜在健康的服务实例。 可以通过 ..-self- = false 禁用此模式，而 ..lease---in- 可用于更改心跳间隔。

1.

从注册中心服务器获取服务注册信息列表，缓存在本地，然后在本地实施轮转负载均衡策略。 与nginx不同的是，它是客户端负载均衡。

Nginx适合服务器端负载均衡。 例如适合微服务中的RPC远程调用，实现本地服务负载均衡。 例如Dubbo和中国都采用本地负载均衡。

Feign 是开发的声明式模板化 http 客户端。 使用时就像调用本地（服务消费者自己的）方法一样，帮助我们更优雅地调用服务提供者的API。 Feign 本身是支持的，同时也集成了 ，这大大简化了 Feign 的使用。 就集成而言，只需配置普通服务的信息就足够了。 集成意味着实例化后不再需要调用@标记的服务提供者方法。 Feign只需定义一个接口就可以实现负载均衡。

1.57 负载均衡策略

常用的负载均衡算法有以下三种：

默认第一个是轮询

第二种是随机的

第三种是Rule，响应时间

1. 概念

Feigh 是一个声明式 Web 服务客户端。 它使开发 Web 服务变得容易。 要使用Feign，您需要创建一个接口并对其进行注释。 它具有可插入支持，包括 Feign 注释和 JAX-RS 注释。 它还支持可插拔编码器和解码器。 云支持 MVC，并使用与 Web 中相同的默认值。 使用 Feign 时，Cloud 会集成并提供负载平衡的 HTTP 客户端。