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 历史读的第一本书，推荐。飞机不会像鸟上下扇动翅膀，但是可以在天上...