《后端技术面试 38 讲》学习笔记 Day 05
17 | 设计模式应用：编程框架中的设计模式
框架是对某一类架构方案可复用的设计与实现。
框架应该满足开闭原则，即面对不同应用场景，框架本身是不需要修改的，需要对修改关闭。
同时框架还应该满足依赖倒置原则，即框架不应该依赖应用程序，因为开发框架的时候，应用程序还没有呢
一般说来，我们使用框架编程的时候，需要遵循框架的规范编写代码。比如 Tomcat、Spring、Mybatis、Junit 等，这些框架会调用我们编写的代码，而我们编写的代码则会调用工具完成某些特定的功能，比如输出日志，进行正则表达式匹配等。
人们对架构师的工作有一种常见的误解，认为架构师做架构设计就可以了，架构师不需要写代码。事实上，架构师如果只是画画架构图，写写设计文档，那么如何保证自己的架构设计能被整个开发团队遵守、落到实处？
架构师应该通过代码落实自己的架构设计，也就是通过开发编程框架，约定软件开发的规范。
心得体会
- 框架和工具的区分，在于哪个被应用调用，哪个调用应用。
- 架构师既要保持文档输出，也要有精髓的代码输出。
- 用代码进行规范约束、落到实处。
工作体验
- 框架的设计者需要考虑的更全面。在恒生许多框架在应用中发现设计问题、实现问题。甚至都是应用开发者反向向框架输出。你说是吧，jres。
- 用代码规范约束，我觉得模板方法模式就很好，主要是约束其对模板骨架的修改，代码主流程就不会走样。
18 | 反应式编程框架设计：如何使程序调用不阻塞等待，立即响应？
原文摘抄
反应式宣言，认为反应式系统应该具备如下特质：
即时响应，应用的调用者可以即时得到响应，无需等到整个应用程序执行完毕。也就是说应用调用是非阻塞的。
回弹性，当应用程序部分功能失效的时候，应用系统本身能够进行自我修复，保证正常运行，保证响应，不会出现系统崩溃和宕机的情况。
弹性，系统能够对应用负载压力做出响应，能够自动伸缩以适应应用负载压力，根据压力自动调整自身的处理能力，或者根据自身的处理能力，调整进入系统中的访问请求数量。
消息驱动，功能模块之间，服务之间，通过消息进行驱动，完成服务的流程。
心得体会
- 反应式编程就像epoll的核心思想，许多IO会阻塞，并不需要每一个IO都分配一个线程，而是由数个线程去管理这些IO连接即可。
- 消息驱动需要对业务解耦十分彻底，甚至进行编号，就像票交所的报文、TIPS前置的报文等，这种在前期的设计十分的重。对于一个未成型，未定型的系统，可能后续的修改也会很多。
- 消息驱动应该是业务不太复杂，流程明显，没有复杂依赖链路的业务更合适。
工作体验
- 反应式编程有点像消息队列的变化，从中间件工具变成了框架，更深入的落实了异步，但是需要其他生态都加入反应式编程，性能才是真正的提高。
