微服务相关

SpringBoot的启动流程

1. SpringApplication初始化模块。通过main方法入口，调用run方法后会创建一个SpringApplication实例，并在SpringApplication构造器中调用initialize方法初始操作。包括创建应用的监听器(SpringApplicationRunListeners)、配置是否为web环境、配置资源resource等其他对象的操作。
2. 在完成第一部分各个模块实例的创建后，接着会执行SpringApplication的run方法，该方法主要执行启动应用监听模块、环境配置模块、Banner模块以及应用上下文模块的初始化工作，当初始化工作完成之后SpringBoot启动流程完成。
3. SpringBoot自动化配置模块，这个模块是SpringBoot的准备工作部分(第一部分实例创建)以及初始化配置工作(第二部分初始化)过程都需要使用的模块，该模块的自动配置文件收集器会收集配置文件中的配置工厂类，在ApplicationContext环境中创建组件所需的bean实例。并存在容器中。

Spring四大核心组件

• Auto-configuration：针对Spring应用程序和常见的应用功能，Springboot能自动提供相关配置，从而实现简化配置甚至零配置。
• Starter：简化jar包的引用，解决jar版本冲突问题。
• Cli：springboot可选特性，主要针对Groovy语言使用。
• Actuator：是SpringBoot的程序监控器，可监控Spring应用程序上下文中的Bean、查看自动配置决策、Controller映射、线程活动、应用程序健康状况等。

SpringCloud用到哪些组件

• Eureka：实现了服务治理(服务注册与发现)。
• Ribbon：客户端负载均衡组件。提供一系列完善的配置选项，比如连接超时、重试等负载均衡算法。
• Hystrix：熔断器，类似于物理电路图中的断路器。用于保护系统，控制故障范围。如果某个服务器所有的机器都挂了，hystrix会迅速失败，马上返回，保证被调用方法不会有大量的线程堆积。hystrix执行断路操作以后，并不表示这条路永远断了，而是会一定时间间隔内缓慢尝试去请求这条路，如果能请求成功，断路就会恢复。
• Zuul：是一个网关组件，类似nginx，反向代理的功能。提供动态路由，监控，弹性，安全等边缘服务的组件。zuul只需要简单配置一下properties文件，不需要写具体的代码就可以实现将请求转发到相应的服务上去。还可以定制化一些filter做验证、隔离、限流、文件处理等切面，对于网关来说，使用zuul能减少大量的代码。
• Config：远程配置服务组件。用于配置管理。Config提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。

微服务与分布式的区别

• 微服务是指很小的服务，可以把一个系统的功能切割，划分为多个子系统，小到只完成一个功能，根据用户访问量，业务处理的响应时间，分开部署提高性能，或者合并在一台服务器里面，节约成本。这个服务可以单独部署运行，不同服务之间通过rpc调用。
• 分布式是指部署在不同的机器上，一个服务可以提供一个或多个功能，服务之间也是通过rpc来交互或者是webservice来交互的。
• 两者的关系是，系统应用部署在超过一台服务器或虚拟机上，且各个分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。

微服务如何实现高可用，高并发的需求

• Eureka是注册所有服务的注册中心，getaway就是通过调用eureke的注册信息(可以是ip，可以是id)，请求到对应的子服务模块里面。所有 eureka必须要是高可用，不然会导致整个系统瘫痪，启动指定不同端口，再互相注册eureka信息到其他eureka里面。就是eureka集群，保证了高可用。还有就是高并发，所有用户都不一定是买东西，有些是在查询订单，做调查统计，但是所有人都会经过在首页，所有首页的访问量是最大，首页设计到一些产品的分类，还有各种商品广告，商家广告，大批量的图片信息，如果不做优化，在访问量打的情况可能会因为并发高而瘫痪。所以我们做两级缓存架构，使用nginx访问缓存图片文件在服务器上，还有就是存储信息在redis上加快响应速度，处理更多的并发。

微服务的服务间调用的组件有用过吗？

1. 有springcloud提供了feign，配置该应用为feign客户端，编写接口使用注解声明调用哪个应用服务id，编写方法使用注解@getMapping指定远端服务访问的访问路径。用@AutoWried引用定义的feign接口，直接使用。
2. 还有一种是spring的RestTemplate，我们在网关获取token的时候，就是用这个来调用认证服务获取token的。指定路径，httpentity封装请求头，请求体携带参数。再用指定类型接收返回结果。

dubbo和springcloud的区别

• Dubbo只是实现了服务治理，而SpringCloud下面有17个子项目(可能还会新增)分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面。
• SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供放和调用方的依赖指依靠一纸契约，不存在代码级别的强依赖，这是在强调快速演化的微服务环境下，显得更加合适。

Zookeeper和Eureka的区别

• 先介绍几个概念，CAP：
• C：Consistency(一致性)。在分布式系统中的所有数据备份，在同一时刻是否同样的值(等同于所有节点访问同一份最新的数据副本)。
• A：Availability(可用性)。在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求(对数据更新具备高可用性)。
• P：Partition tolerance(分区容错性)。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
• CA — 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
• CP — 满足一致性，分区容忍的系统，通常性能不是特别高。
• AP — 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

了解了以上几个概念后，我们再来说说Zookeeper和Eureka的区别。

• Zookeeper保存CP
  当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接收服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事情，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
• Eureka保证AP
  Eureka看明白了这一点，因此在设计的时候就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点以然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：①Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。②Eureka仍然能够接收新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点已然可用)。③当网络稳定时，当前实例新的注册信息会被同步到其它节点中。
• 因此，Eureka可用很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。