写在前面
什么是行为型的设计模式
主要是类和对象如何交互，划分相应的责任和算法
为什么要用
不仅解决了类和对象如何划分而且还描述了他们之间如何通信，也是为了更好的完成抽象，保证了代码的扩展性和稳定性，在写代码迷茫纠结的时候让你不迷茫
设计模式-创建型
发表于
|
更新于
|
分类于
设计模式
写在前面
发现对于落地这件事情还是要静下心一个一个目标完成，设计模式一直搁浅了好久也没个系统整理，作为网上标配开篇，最近还是补上这个作业吧
为什么用设计模式
- 设计模式是前人总结下来的经验，对于扩展性和可维护性有很大帮助
- 也是为了使设计变得简单，容易阅读
设计模式原则（SOLID）
- 单一职责原则（Single Responsibility Principle）：可以理解为最好一个类只负责一项职责
- 开闭原则（Open Close Priciple）：尽量对扩展开放，对修改关闭
- 里氏替换原则（Liskov Substitution Principle）：引用父类处可以用任意子类代替
- 接口隔离原则（Interface Segregation priciple）：建立单一接口，最好是一个类依赖一个接口，而不是多个类依赖一个接口
- 依赖倒置原则 (Dependency InVersion Principle) ：调用方和实现方都应该依赖抽象，彼此相互独立，实现类应该依赖抽象，而不能反过来
- 迪米特法则（Law of Demeter）：一个对象保持对其他对象最少的了解
- 合成复用原则（Composite/Aggregate Reuse Principle）：尽量使用组合/聚合，不要使用继承，继承基类会暴露实现破坏封装；基类改变，子类实现也需要改变；实现是静态的，不够灵活
如何使用设计模式
以上原则只是设计参考的一个约束，并不绝对，对于“最好的设计模式就是不用设计模式”，我们还没有达到这个境界，只有合适的场景用更合适的方法。
微服务之熔断降级
发表于
|
更新于
|
分类于
微服务
Keys
- 滑动窗口: 滑动窗口协议（Sliding Window Protocol），属于TCP协议的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输，提高网络吞吐量
常用熔断框架比较
| 对比 | Sentinel | Hystrix | resilience4j |
|---|---|---|---|
| 隔离策略 | 信号量隔离（并发线程数限流） | 线程池隔离/信号量隔离 | 信号量隔离 |
| 熔断降级策略 | 基于响应时间、异常比率、异常数 | 基于异常比率 | 基于异常比率、响应时间 |
| 实时统计实现 | 滑动窗口（LeapArray） | 滑动窗口（基于 RxJava） | Ring Bit Buffer |
| 动态规则配置 | 支持多种数据源 | 支持多种数据源 | 有限支持 |
| 扩展性 | 多个扩展点 | 插件的形式 | 接口的形式 |
| 基于注解的支持 | 支持 | 支持 | 支持 |
| 限流 | 基于 QPS，支持基于调用关系的限流 | 有限的支持 | Rate Limiter |
| 流量整形 | 支持预热模式、匀速器模式、预热排队模式 | 不支持 | 简单的 Rate Limiter 模式 |
| 系统自适应保护 | 支持 | 不支持 | 不支持 |
| 控制台 | 提供开箱即用的控制台，可配置规则、查看秒级监控、机器发现等 | 简单的监控查看 | 不提供控制台，可对接其它监控系统 |