微服务 - Spring Cloud

@Configuration(proxyBeanMethods = false)

• 标记了@Configuration Spring底层会给配置创建cglib动态代理。 作用：就是防止每次调用本类的Bean方法而重新创建对象，Bean是默认单例的。

Spring Boot的Jar应用的大致启动流程是怎么样的？

总结一下Spring Boot应用的启动流程：
（1）Spring Boot应用打包之后，生成一个Fat jar，包含了应用依赖的jar包和Spring Boot loader相关的类。
（2）Fat jar的启动Main函数是JarLauncher，它负责创建一个LaunchedURLClassLoader来加载/lib下面的jar，并以一个新线程启动应用的Main函数。

SpringBoot 事件监听器发布顺序是怎么样的？

1.ApplicationStartingEvent在运行开始时发送，但在进行任何处理之前（侦听器和初始化程序的注册除外）发送。

2.在创建上下文之前，将发送ApplicationEnvironmentPreparedEvent。

3.准备ApplicationContext并调用ApplicationContextInitializers之后，将发送ApplicationContextInitializedEvent。

4.读取完配置类后发送ApplicationPreparedEvent。

5.在刷新上下文之后但在调用任何应用程序和命令行运行程序之前，将发送ApplicationStartedEvent。

6.紧随其后发送带有LivenessState.CORRECT的AvailabilityChangeEvent，以指示该应用程序被视为处于活动状态。

7.在调用任何应用程序和命令行运行程序之后，将发送ApplicationReadyEvent。

8.紧随其后发送ReadabilityState.ACCEPTING_TRAFFIC的AvailabilityChangeEvent，以指示应用程序已准备就绪，可以处理请求。 如果启动时发生异常，则发送ApplicationFailedEvent。

SpringBoot是如何启动Spring容器的？

1. 初始化SpringApplication 从spring.factories 读取 listener ApplicationContextInitializer 。

2.运行run方法

3.读取 环境变量 配置信息.....

4. 创建springApplication上下文:ServletWebServerApplicationContext

5. 预初始化上下文 ： 读取启动类

6.调用refresh 加载ioc容器

　　加载所有的自动配置类

　　创建servlet容器

ps.在这个过程中springboot会调用很多监听器对外进行扩展

分布式事务Seata的整体流程是怎么样的？

1.TM 请求 TC 开启一个全局事务。TC 会生成一个 XID 作为该全局事务的编号。XID，会在微服务的调用链路中传播，保证将多个微服务的子事务关联在一起。

2.RM 请求 TC 将本地事务注册为全局事务的分支事务，通过全局事务的 XID 进行关联。

3.TM 请求 TC 告诉 XID 对应的全局事务是进行提交还是回滚。

4.TC 驱动 RM 们将 XID 对应的自己的本地事务进行提交还是回滚。

分布式事务的设计亮点有哪些？

相比与其它分布式事务框架，Seata架构的亮点主要有几个:

1. 应用层基于SQL解析实现了自动补偿，从而最大程度的降低业务侵入性；
2. 将分布式事务中TC（事务协调者）独立部署，负责事务的注册、回滚；
3. 通过全局锁实现了写隔离与读隔离。

Seata存在的问题

性能损耗

一条Update的SQL，则需要全局事务xid获取（与TC通讯）、before image（解析SQL，查询一次数据库）、after image（查询一次数据库）、insert undo log（写一次数据库）、before commit（与TC通讯，判断锁冲突），这些操作都需要一次远程通讯RPC，而且是同步的。另外undo log写入时blob字段的插入性能也是不高的。每条写SQL都会增加这么多开销,粗略估计会增加5倍响应时间。

性价比

为了进行自动补偿，需要对所有交易生成前后镜像并持久化，可是在实际业务场景下，这个是成功率有多高，或者说分布式事务失败需要回滚的有多少比率？按照二八原则预估，为了20%的交易回滚，需要将80%的成功交易的响应时间增加5倍，这样的代价相比于让应用开发一个补偿交易是否是值得？

全局锁

热点数据

相比XA，Seata 虽然在一阶段成功后会释放数据库锁，但一阶段在commit前全局锁的判定也拉长了对数据锁的占有时间，这个开销比XA的prepare低多少需要根据实际业务场景进行测试。全局锁的引入实现了隔离性，但带来的问题就是阻塞，降低并发性，尤其是热点数据，这个问题会更加严重。

回滚锁释放时间

Seata在回滚时，需要先删除各节点的undo log，然后才能释放TC内存中的锁，所以如果第二阶段是回滚，释放锁的时间会更长。

死锁问题

Seata的引入全局锁会额外增加死锁的风险，但如果出现死锁，会不断进行重试，最后靠等待全局锁超时，这种方式并不优雅，也延长了对数据库锁的占有时间。

什么是Spring Cloud Gateway？

网关作为流量的入口，常用的功能包括路由转发，权限校验，限流等。

Spring Cloud Gateway 是Spring Cloud官方推出的第二代网关框架，定位于取代 Netflix Zuul。相比 Zuul 来说，Spring Cloud Gateway 提供更优秀的性能，更强大的有功能。

Spring Cloud Gateway 是由 WebFlux + Netty + Reactor 实现的响应式的 API 网关。它不能在传统的 servlet 容器中工作，也不能构建成 war 包。

Spring Cloud Gateway 旨在为微服务架构提供一种简单且有效的 API 路由的管理方式，并基于 Filter 的方式提供网关的基本功能，例如说安全认证、监控、限流等等。

怎么拆分微服务? 怎样设计出高内聚、低耦合的微服务? 有没有了解过DDD领域驱动设计? 什么是中台? 中台和微服务有什么关系?

拆分微服务的时候，为了尽量保证微服务的稳定，会有一些基本的准则:
1、微服务之间尽量不要有业务交叉。
2、微服务之前只能通过接口进行服务调用，而不能绕过接口直接访问对方的数据。
3、高内聚，低耦合。
高内聚低糊合，是一种从上而下指导微服务设计的方法。实现高内聚低耦合的工具主要有 同步的接口调用 和 异步的事件驱动两种方式。
什么是DDD: 在2004年，由Eric Evans提出了，DDD是面对软件复杂之道。Domain-Driven-Design。
Martin Fowler - 贫血模型-》贫血失忆症。充血模型。

所谓中台，就是将各个业务线中可以复用的一些功能抽取出来，剥离个性，提取共性，形成一些可复用的组件。
大体上，中台可以分为三类 业务中台、数据中台和技术中台。如大数据杀熟-数据中台电商 收银中台 支付风控中台；
中台跟DDD结合: DDD会通过限界上下文将系统拆分成一个一个的领域，而这种限界上下文，天生就成了中台之间的逻辑屏障。
DDD在技术与资源调度方面都能够给中台建设提供不错的指导。
DDD分为战略设计和战术设计。 上层的战略设计能够很好的指导中台划分，下层的战术设计能够很好的指导微服务搭建。在目前阶段，DDD还大都处在小范围实验的阶段。

JWT令牌的优点？

1. jwt基于json，非常方便解析。
2. 可以在令牌中自定义丰富的内容，易扩展。
3. 通过非对称加密算法及数字签名技术，JWT防止篡改，安全性高。
4. 资源服务使用JWT可不依赖授权服务即可完成授权。

JWT组成？

一个JWT实际上就是一个字符串，它由三部分组成，头部（header）、载荷（payload）与签名（signature）。

头部用于描述关于该JWT的最基本的信息：类型（即JWT）以及签名所用的算法（如HMACSHA256或RSA）等。

第二部分是载荷，就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分：

• 标准中注册的声明（建议但不强制使用）

• 公共的声明

• 私有的声明

签名（signature）

jwt的第三部分是一个签证信息，这个签证信息由三部分组成：

• header (base64后的)
• payload (base64后的)
• secret(盐，一定要保密）

这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。

谈谈你对微服务的理解，微服务有哪些优缺点?

微服务是由Martin Fower大师提出的。微服务是一种架构风格，通过将大型的单体应用划分为比较小的服务单元，从而降低整个系统的复杂度。
优点:
1、服务部署更灵活: 每个应用都可以是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性降低。
2、技术更新灵活: 在大型单体应用中，技术要进行更新，往往是非常困难的。而微服务可以根据业务特点，灵活选择技术栈。
3、应用的性能得到提高: 大型单体应用中，往往启动就会成为一个很大的难关。而采用微服务之后，整个系统的性能是能够得到提高的。
4、更容易组合专门的团队: 在单体应用时，团队成员往往需要对系统的各个部分都要有深入的了解，门槛是很高的。而采用微服务之后，可以给每个微服务组建专门的团队。
5、代码复用: 很多底层服务可以以REST AP的方式对外提供统一的服务，所有基础服务可以在整个微服务系统中通用。

缺点:
1、服务调用的复杂性提高了: 网络问题、容错问题、负载问题、高并发问题。。。。
2、分布式事务:尽量不要使用微服务事务。
3、测试的难度提升了:
4、运维难度提升:单体架构只要维护一个环境，而到了微服务是很多个环境，并且运维方式还都不一样。所以对部署、监控、告警等要求就会变得非常困难。

你的项目中是怎么保证微服务敏捷开发的?微服务的链路追踪持续集成、AB发布要怎么做?

开发运维一体化。
敏捷开发: 目的就是为了提高团队的交付效率，快速迭代，快速试错.
每个月固定发布新版本，以分支的形式保存到代码仓库中。快速入职。任务面板、站立会议。团队人员灵活流动，同时形成各个专家代表。测试环境- 生产环境 -》开发测试环境SIT、集成测试环境、压测环境STR、预投产环境、生产环境PRD。文档优先。晨会、周会、需求拆分会。
链路追踪: 1、基于日志。形成全局事务ID，落地到日志文件。 filebeat- logstash-Elasticsearch 形成大型报表。2、基于MQ，往往需要架构支持。经过流式计算形成一些可视化的结果。
持续集成: SpringBoot maven pom ->build -> shell ;Jenkins.
AB发布: 1、蓝绿发布、红黑发布 老版本和新版本是同时存在的。2、灰度发布、金丝雀发布。

spring cloud 的核心组件及其作用？

Eureka: 服务注册与发现
注册:每个服务都向Eureka登记自己提供服务的元数据，包括服务的ip地址、端口号、版本号、通信协议等。eureka将各个服务维护在了一个服务清单中(双层Map，第一层key是服务名，第二层key是实例名，value是服务地址加端口)。同时对服务维持心跳，剔除不可用的服务，eureka集群各节点相互注册每个实例中都有一样的服务清单。
发现: eureka注册的服务之间调用不需要指定服务地址，而是通过服务名向注册中心咨询，并获取所有服务实例清单(缓存到本地)，然后实现服务的请求访问。
Ribbon: 服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台(被调用方的服务地址有多个)，Ribbon也是通过发起http请求，来进行的调用，只不过是通过调用服务名的地址来实现的。虽然说Ribbon不用去具体请求服务实例的ip地址或域名了，但是每调用一个接口都还要手动去发起Http请求
Feign: 基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求，简化服务间的调用，在Ribbon的基础上进行了进一步的封装。单独抽出了一个组件，就是Spring Cloud Feign。在引入SpringCloud Feign后，我们只需要创建一个接口并用注解的方式来配置它，即可完成对服务提供方的接口绑定。
Hystrix:发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，通过统计接口超时次数返回默认值，实现服务熔断和降级.

什么是Hystrix? 简述实现机制

分布式容错框架
。阻止故障的连锁反应，实现熔断
。快速失败，实现优雅降级
。提供实时的监控和告警
资源隔离: 线程隔离，信号量隔离
。线程隔离: Hystrix会给每一个Command分配一个单独的线程池，这样在进行单个服务调用的时候，就可以在独立的线程池里面进行，而不会对其他线程池造成影响
。信号量隔离:客户端需向依赖服务发起请求时，首先要获取一个信号量才能真正发起调用，由于信号量的数量有限，当并发请求量超过信号量个数时，后续的请求都会直接拒绝，进入fallback流程。信号量隔离主要是通过控制并发请求量，防止请求线程大面积阻塞，从而达到限流和防止雪崩的目的。
熔断和降级: 调用服务失败后快速失败
熔断是为了防止异常不扩散，保证系统的稳定性。
降级:编写好调用失败的补救逻辑，然后对服务直接停止运行，这样这些接口就无法正常调用，但又不至于直接报错，只是服务水平下降。

通过HvstrixCommand 或者HvstrixobservableCommand 将所有的外部系统(或者称为依赖) 包装起来，整个包装对象是单独运行在一个线程之中 (这是典型的命令模式)。
超时请求应该超过你定义的阈值
为每个依赖关系维护一个小的线程池(或信号量);如果它变满了，那么依赖关系的请求将立即被拒绝，而不是排队等待。
统计成功，失败(由客户端抛出的异常) ，超时和线程拒绝.
打开断路器可以在一段时间内停止对特定服务的所有请求，如果服务的错误百分比通过阈值，手动或自动的关闭断路器。
当请求被拒绝、连接超时或者断路器打开，直接执行fallback逻辑。
近乎实时监控指标和配置变化。

SpringCloud和SpringCloudAlibaba都有哪些组件? 都解决了什么问题?

SpringCloud: 提供了构建微服务系统所需要的一组通用开发模式以及一系列快速实现这些开发模式的工具。
通常所说的SpringCloud是指SpringCloud NetFlix，他和SpringCloudAlibaba都是Springloud这一系列开发模式的具体实现。

---

如果您觉得阅读本文对您有帮助，请点一下“推荐”按钮，您的“推荐”将是我最大的写作动力！欢迎各位转载，但是未经作者本人同意，转载文章之后必须在文章页面明显位置给出作者和原文连接，否则保留追究法律责任的权利。