面试之微服务架构
分布式事务解决方案
分布式事务解决方案-CSDN博客
微服务解决方案有哪些？
1. Dubbo
最初是alibaba与2011年开源， 提供了服务注册发现、负载均衡、容错、分布式调用等功能，基于RPC通信模型， 被认为是一个高效的RPC调用框架， 一些服务治理功能依赖于第三方组件，比如Zookeeper、Apollo（服务配置）
2. Spring Cloud Netflix
是Spring Cloud的一个子项目，包含多种组件，自2018年停止维护和更新，许多流行的Netflix组件：Eureka（服务注册与发现）、Ribbon(客户端负载均衡)、Hystrix(断路器、限流、降级)、Zuul(API网关)。
3. Spring Cloud Alibaba
Spring cloud的一个子项目，提供了一整套与Alibaba生态系统集成的解决方案。
HTTP与RPC
微服务理解
微服务是一种架构风格，是将大型的单体应用拆分成多个小应用，从而降低系统的复杂度。
优点：
- 部署更加灵活， 启动时间也更快
- 不同微服务可以选型不同的技术框架
- 不同的微服务可以由不同的团队管理
- 项目开发节奏更灵活，更方便的迭代发布
- 代码复用。通用的能力可以抽离出来单独部署，通过Rest API的方式统一对外提供服务
缺点：
- 服务之间调用网络问题、负载问题、高并发问题等
- 分布式事务
- 运维复杂，需要维护多个环境，而且运维方式也可能不一样，对部署、监控、告警都会变的更困难。
微服务拆分
拆分准则：
- 高内聚、低耦合。 实现高内聚低耦合的工具是：服务之间的调用通过接口调用和异步的事件驱动两种方式
- 接口具备可扩展性，服务内部的变更，依赖该服务的其他服务无需修改
- 避免循环调用
微服务敏捷开发
DDD领域驱动设计
DDD: Domian Driver Design 领域驱动设计
1. MVC架构：贫血模型， 从下往上拆分。
特点：POJO中只能看到数据模型信息，没有这个数据模型相关的业务服务，业务服务都是在Service层实现。
2. DDD架构：充血模型，从上往下拆分。
说明
- Domain Service(领域服务): 操作到多个领域
- 领域和领域之间通过接口的形式或者事件驱动的形式 访问
思考一个业务场景：产品下单后，发物流
MVC
1. 在MVC架构下， 如果是单体架构，下单服务和物流服务，都操作到产品，这两个服务关乎的产品的属性是不一样的。那么对产品这个POJO， 里面的内容会很大，对Service， 也会有更多的业务逻辑。
2. MVC架构，做微服务拆分，分成下单微服务和物流微服务两个，但是产品模型都还是一样的，随着一个微服务的业务逻辑越来越复杂，一个微服务的DAO也会膨胀。
所以说，MVC架构的设计，不利于微服务的拆分，拆分出的微服务依然容易膨胀。
DDD
- 不同领域拥有不能的领域模型，每个领域的内容只和本领域的信息相关。
- 在单体架构下，每个领域可以是一个独立的模块，在拆分成微服务时，只需将各个领域的调用方式改下。
中台
中台这个概念是阿里2015年提出的"小前台，大中台"战略思想。
所谓中台，就是将业务线中可以服用的部分抽取出来，剥离个性、提供共性，形成一些可以服用的组件。成功案例：盒马鲜生、团购。
中台大体上可以分为三类：业务中台、数据中台、技术中台。
- 业务中台：在各个业务线都可以共用的组件，比如会员管理、权限管理、移动支付
- 数据中台：对各个业务域的数据做整合存储、分析、建模，为各个系统的数据分析提供支持，比如芝麻信用、大数据杀熟。
- 技术中台：封装各个业务系统用到的技术框架，降低上游系统的技术门槛。比如电商收银中台、风控中台。
中台跟DDD结合， DDD通过限界上下文将系统拆分成一个个领域，而这种限界上下文，天生就成为中台之间的逻辑屏障。
在技术与资源调度方面，DDD能给中台提供不错的指导。
DDD分为战略设计和战术设计。上层战略设计能够很好的指导中台划分，下层的战术设计能够很好的指导微服务搭建。
服务血崩
A服务 -》B服务 -》C服务
如果C服务性能比较低，在流量突然增大的情况下，会导致B、A的请求堆积，从而导致整体服务不可用，即服务血崩。
服务限流
压测、配置限流值
服务降级
在流量暴增的场景下，非核心功能暂时关闭，或则异步处理
服务熔断
A ->B -> C
需要熔断的场景：
- 如果C服务性能比较低，在流量突然增大的情况下，C响应变慢或者大量失败
- C的服务异常或者网络问题， B调用C服务大量失败
为了保护系统不会因为下游系统的异常 或者 外部大流量的调用 而拖垮。
Spring Cloud核心组件
参考：Spring Cloud Alibaba-CSDN博客
服务注册发现Eureka
负载均衡Ribbon
服务调用Feign：动态代理机制
流量控制Hystrix（断路器）:
通过Hystrix的线程池来执行，不同的服务使用不同的线程池，实现了不同服务调用的隔离。统计接口超时次数返回默认值，实现服务熔断与降级。
网关服务Zuul :
如实是前端、移动端调用后端系统，统一从Zuul网关转发请求给对应的服务。通过与Eureka进行整合，将自身注册成为Eureka下的应用，从Eureka获取所有服务实例，来进行服务的路由。Zuul还提供了一套过滤机制，开发真可以自己制定哪些规则的请求需要执行校验逻辑，只有通过校验的请求才路由到对应服务器，否则返回错误提示。
并非只有前端调用后端才能走网关，微服务之间其实也可以通过网关，只是没有那个必要。
Hystrix（断路器）
- 实现熔断
- 快速失败，实现优雅降级
- 提供实时的监控和告警
实现方式：资源隔离，包括线程隔离、信号量隔离
- 线程隔离：Hystrix的线程池来执行，不同的服务使用不同的线程池，实现了不同服务调用的隔离。
- 信号量隔离：向依赖的服务发起请求时，首选获取一个信号量才能真正发起调用。由于信号量的个数有限，当并发请求量超过信号量个数是，后续请求都会直接拒绝，进入fallback流程。
实现过程：
- 通过HystrixCommand或者HystrixObservableCommand将所有的外部服务包装起来，整个包装对象是单独运行在一个线程之中。
- 超时请求，配置超时阈值。
- 为每个依赖的服务维护一个线程池，或者维护一个整体的信号量， 但拿不到线程或者信号量时，请求直接被拒绝
- 统计不同的响应结果
- 当请求被拒绝。连接超时或者断路器打开时，直接执行fallback降级逻辑
- 近乎实时的监控指标和配置变化
高并发场景实现系统限流
压测
限流算法：计数器、滑动窗口、漏桶算法、令牌桶算法。
Spring Cloud 与Dubbo
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, short lived microservices and contract testing).
(Spring Cloud为开发者提供了在分布式系统下，快速构建通用模式的工具， 比如配置中心、服务发现、断路器、智能路由（负载均衡）.....)
Spring Cloud是一个微服务框架，提供了微服务领域总的很多组件，Dubbo一开始只是个体RPC调用框架，核心是解决分布式系统之间的调用。Spring Cloud是个大而全的框架，Dubbo侧重服务调用，但是Dubbo的服务调用性能比Spring Cloud高，不过两者并不是对立的，可以结合起来使用。
SOA/微服务/分布式
分布式架构指的是将单体架构拆分成多个部分，然后部署到不同的机器或进程中去，简单来说就是由不同的进程组成的整体服务 是分布式架构。 SOA和微服务都是分布式架构。
SOA是一种面向服务的架构，系统中所有的服务都注册到总线上，当有服务调用时，从总线上查询服务信息，然后调用。
微服务时一种更称帝的面向服务的架构，更系统中各个功能抽象成一个个独立的应用程序，基本保持一个应用对应一个微服务架构。