Home

这篇笔记，继续沿着 Spring Cloud Gateway，来聊一聊 WebFlux. 1. 响应式编程 优秀的系统实现，特点之一就是对于线程的控制，能够让线程专注在一件事情上，降低系统线程间切换的开销。 比如当我们发起一次耗时的 IO 操作： String foo() { String s = fetch_from_remote_long_long_time(); return s; } 当前线程会阻塞，直到 IO 返回。当调用变多，就会有大量线程阻塞在这个位置，由于线程本身需要栈空间、上下文切换等操作，当面临高并发时，就会出现性能问题。 响应式编程会优化为非阻塞的过程，当前线程在请求完成后能够立刻“释放”，不会阻塞在当前位置。 举个访问 redis 的例...

这篇笔记总结当我们通过网关转发一条 http 请求时，网关的处理流程。 1. 什么时候需要网关？ 简单的系统不需要网关，只有当系统变得越来越复杂，就不得不面临以下问题： 流量难以控制：系统里有多个模块，每个模块都对系统外部开放了入口。入口多导致系统频出问题；为了控制流量，每个模块都不得不做重复的工作。 外部调用成本高：久而久之，内部单个模块迁移，也需要协调大量外部工作。更别说系统级别的重构了。 重复工作：除了流量控制，重复工作还有安全认证、服务鉴权、日志监控、协议转换与统一等基础能力。 上述问题单独看，也可以通过统一基础库等方式解决。但是整体解决的话，就需要网关，同时无论从开发还是部署，都与原来的模块是解耦的，在实际推进时也更加容易落地。 不止微服务，业务架构、...

这篇笔记是对 Istio 文档1的一个初步总结。 1. Istio 是什么? Istio 是服务网格的一种实现。AWS 对 Service Mesh 是这么描述的2： 服务网格是一个软件层，用于处理应用程序中服务之间的所有通信。该层由容器化微服务组成。随着应用程序的扩展和微服务数量的增加，监控服务的性能变得越来越困难。为了管理服务之间的连接，服务网格提供了监控、记录、跟踪和流量控制等新功能。它独立于每项服务的代码，这使它能够跨网络边界和多个服务管理系统工作。 即服务网格托管了以下功能： 负载均衡 服务发现 熔断 动态路由 安全通信 多语言、多协议支持 指标和分布式跟踪 支持访问控制、限流和配额的可插入策略层和配置 API 我的理解，...

1. 工作 2024 换了工作，互联网还是央企，对于很多程序员来说，To do or not to do,that is a question. 我们不可避免的置身于 AI 的浪潮之中，以后对于我们来说，未来究竟是全栈还是专业。对于许多中小公司，是更依赖云厂商，还是会依赖内部员工。我也思考不清楚，不如把这个问题放到 2025 年拭目以待吧。 2. 读书 下半年读书很少，但是见识涨了很多。曹雪芹老先生说：世事洞明皆学问 人情练达即文章。所以也算是间接读了很多书吧。 书名 一句话总结 智慧的疆界 想要去了解 AI 历史读的第一本书，推荐。飞机不会像鸟上下扇动翅膀，但是可以在天上...

1. Timer 系统收到 1 条数据，计算，输出 0~N 条数据，这种 Event-driven 的方式是最简单和自然的。 但实际上，由于存在乱序、丟数，以及业务周期性更新的需求，计算还会依赖于时间触发，例如Dataflow Model的第三节 IMPLEMENTATION & DESIGN 的场景。 这些场景依赖于 Timer，Flink 的窗口也是基于 Timer 实现。 Timer 不是简单的时间触发回调，Process Function#Timers文档介绍了 Timers，主要有几点： ProcessingTime 和 EventTime 都是由 TimerService 维护的，定时触发用户的 onTimer 方法 TimerService 会...

1. Theory - Dataflow Model Dataflow Model这篇论文，对大数据的处理范式做了总结，并且提出了一套处理模型。 1.1. Window 数据转换操作，有两种： ParDo: 1->N，例如 map/flatmap/filter 等，这类操作在 unbound 和 bound 数据集上没有区别 GroupByKey: 聚合操作在 bound 数据集很自然；在 unbound 数据集上，既然数据不会结束，就需要解决何时聚合的问题。 之前在批处理和流处理的思考这篇笔记里提到过，bound 数据集其实也是在 unbound 数据集的一个划分，通常情况是 1 天/小时的数据。而论文则用更抽象的角度，提出了 window 的概念，用于在u...