Automannn的学习园地

# springCloud

  • SpringCloud并不是Spring团队全新研发的框架,它本身只是一套规范.
  • springCloud规范的常见实现有:SpringCloud-Netflix,SpringCloud-Alibaba,SpringCloud-Consul

# springCloud的版本管理

  • springCloud整合了各大公司开源技术的规范，但开源技术的版本发布由各个公司维护，每个子项目都有自己的发布版本号
  • 因此它不像传统意义上的版本命名，而是采用伦敦地铁站顺序进行命名;

# spring团队的故事

  • Spring团队在于很少重复造轮子，只有在别人提供的东西不够好的情况下，spring团队才考虑自己研发
  • struts2经常有安全漏洞,于是spring团队研发了Spring MVC框架，并成为现在非常主流的MVC框架
  • netflix的zuul网关由于性能及迭代慢，spring团队孵化了SpringCloudGateway来取代zuul
  • spring团队一致为开发者解决一些复杂度高的问题，使开发者能够更高效的专注于业务开发，从spring到springBoot到springCloud皆是如此。

# springCloud-Netflix

  • 其主要为微服务架构下的服务治理，提供解决方案
  • 为SpringBoot和Netflix OSS(Open Source Software)在 springCloud规范下的集成

# 组件

  • Eureka,服务注册与发现
  • Zuul,服务网关
  • Ribbon,负载均衡
  • Feign,远程服务的客户端代理
  • Hystrix,断路器，提供熔断和限流功能
  • Hystrix Dashboard,监控面板
  • Turbine, 将Hystrix的监控信息进行统一聚合

# 组件的开源危机

  • netflix对zuul1,Ribbon,archaius等组件进入维护模式，意味着不会有大的功能更新，只会进行修复
  • 部分组件不再开源，如Eureka2,zuul2等

# spring官方替代建议

current replacement
Hystrix Resilience4j
Hystrix Dashboard+Turbine MicroMeter + Monitoring System
Ribbon Spring Cloud Loadbalancer
zuul1 Spring Cloud Gateway
Archaius1(动态属性配置框架) SpringBoot external config + Spring Cloud Config

# springCloud-Alibaba

  • 2018.10.31入驻SpringCloud官方孵化器
  • 2019.8.1在Alibaba仓库发布第一个毕业版本

# 组件

  • Sentinel,流量控制和服务降级
  • Nacos,服务注册与发现，分布式配置中心
  • RocketMQ,消息驱动
  • Seata,分布式事务
  • Dubbo，RPC通信，服务治理
  • OSS,阿里云对象存储(付费云产品)

# nacos配置中心

  • spring.cloud.nacos.config.server-addr设置配置中心的地址，即使监听端口为80，也需要将80端口带上

  • spring.cloud.nacos.config.prefix表示配置中心的Data ID的前缀,默认为${spring.application.name}

  • spring.cloud.nacos.config.file-extension,配置中心配置文件的后缀，默认为properties

  • spring.cloud.nacos.config.name,也可配置Data ID,但是它是一个鸡肋配置，优先级最低

  • spring.cloud.nacos.config.namespace,配置中心环境隔离信息

  • 配置中心的配置，应该放在bootstrap上下文

  • 配置中心的配置会自动刷新，但是如果以bean的形式获取参数，则需要添加**@RefreshScode**才会实时刷新

    class Test{
    //通过bean的方式获取配置时，需要添加@RefreshScode才能实时获取配置刷新
    @Configuration
    public class GetConfigBean {

        @Value("${myName}")
        private String value;

        public void touchProperty() {
            System.out.println("==当前环境的参数为:" + value);
        }
    }
    
    //可以实时刷新配置
    public void getConfig(ApplicationContext context){
        ontext.getEnvironment().getProperty("myName")
    }
}

# 配置规则

  • 读取nacos配置中心的配置规则为:${prefix:${spring.application.name}}-${spring.profile.active}.${file-extension:properties}
  • 在使用yaml格式配置的时候，需要指定spring.cloud.nacos.config.file-extension=yaml,注意yaml与yml的区别，nacos没有yml选项

# Sentinel服务防护

  • springCloudStarterSentinel会自动为所有的web服务埋点，但是需要首次访问后，才会推送到dashboard

  • sentinel-dashboard默认将资源配置信息存储在内存中，意味着服务重启后，资源会丢失

  • sentinel可以使用nacos作为配置中心配置持久化流控规则,但是二者的配置信息并不能同步(1.8.1版本尚未实现该功能);

  • 对于path路径，可以通过UrlCleaner进行规则的管理

    class Test{
     @Configuration
    public class CustomerUrlCleaner implements UrlCleaner{

        @Override
        public String clean(String s) {
            if(StringUtils.isEmpty(s)){
                return s;
            }
            //sentinel对于路径 /somePath/${id}路径，会当作不同的路径进行流控，导致限流统计不准确，以及 sentinel资源数量过多的问题
            if(s.startsWith("/somePath/")){
                return "/somePath/*";
            }

            return s;
        }
    }
}

# seata分布式事务

# 两阶段提交协议

  • XA协议时X/Open提出的分布式事务处理规范,也是分布式事务处理的工业标准, 该标准提出：**使用两阶段提交（2PC）**来保证分布式事务的完整性.
  • 该规范包括三种角色：AP(应用程序),RM(资源管理器,如数据库)，TM（事务管理器）
  • 目前ORACLE,MYSQL,DB2都实现了XA接口,因此它们都可以作为RM；

# 两阶段提交协议的优缺点

  • 优点
    • 简单
  • 缺点
    • 同步阻塞：对于任何一次指令，都必须要有明确的响应，才能继续进行下一步。否则会处于阻塞状态，占用资源一直被锁定；
    • 事务协调者的单点故障：如果事务协调者，在第二阶段出现了故障，将导致RM一直处于锁定状态
    • 过于保守：任意一个参与者失败都会导致数据回滚;
    • 脑裂导致数据不一致问题：第二阶段，如果局部网络异常，导致部分RM收到commit请求，部分未收到，导致数据不一致问题.

# 三阶段提交协议

  • 二阶段的改进版本，利用超时机制，解决同步阻塞的问题
  • 不管是两阶段提交协议，还是三阶段提交协议，都是数据一致性解决方案的实现，可以在实际应用中灵活调整
  • Zookeeper使用了优化版的两阶段提交协议，它不需要所有参与者在第一阶段返回成功才能提交事务，而是利用少数服从多数的投票机制来完成事务操作

# CAP定理

  • Consistency一致性、Availability可用性、PartitionTolerance分区容错性
  • 分布式系统中，不可能同时满足CAP,要么满足CP,要么满足AP，不可能实现CAP或者CA

# BASE理论

  • Basically Available基本可用、Soft State软状态(数据的中间状态)、Eventually Consistent最终一致性
  • 通过牺牲数据的强一致性，允许数据在一段时间内不一致，但数据最终会在某个时间点实现一致

# 分布式事务的常见解决方案

  • TCC补偿型方案：一种两阶段提交的思想
  • 基于可靠性消息的最终一致性方案： 互联网公司比较常用的分布式数据一致性解决方案。
  • 最大努力通知型：接口没有返回消息确认时，不断进行重试，知道收到消息确认或达到最大重试次数(如支付宝支付结果的通知流程);

# seata分布式事务框架

详见博客-分布式事务章节;