https://blog.yogalin.xyz/ElIaukHalo v2.27.3zh-cnSat, 14 Nov 2026 07:40:29 GMT/archives/java-backend-roadmap-20262026 年市场要什么 初级岗位在收缩，这是这两年最明显的变化。原因不复杂：CRUD 和样板代码已经被框架、脚手架和 AI 辅助工具吃掉大半，企业不再为“会写接口”付费，而是为“能把系统跑稳、能定位线上问题、能控制成本”付费。 所以能力要求从“会用一个框架”变成了“理解一整条链路”：请求怎么进来、经]]>/archives/java-backend-roadmap-2026AdministratorJava 基础Thu, 22 Oct 2026 12:00:00 GMT/archives/monolith-to-microservices演进不是重写 架构演进最常见的失败方式是“推倒重写”。新系统从零开始，需求在开发过程中还在变，旧系统也不能停，两套代码并行维护半年，最后新系统上线时功能比旧系统少了三成，只能继续双跑，团队被拖垮。 可控的演进一定是增量替换：旧系统继续提供服务，新实现从一条接口、一个模块开始接管流量，随时可以切回去。]]>/archives/monolith-to-microservicesAdministrator架构与性能Thu, 15 Oct 2026 12:00:00 GMT/archives/db-connection-pool连接池不是越大越好 连接池最常见的误用是把它当成“并发上限调节旋钮”：接口慢了就把池子从 20 调到 100。结果往往是数据库 CPU 打满、锁等待变长、整体 QPS 反而下降。 原因很简单：一个数据库连接在后端对应一个线程和一份内存，数据库能真正并行执行的会话数是有限的，通常和核数同量级。池子开到]]>/archives/db-connection-poolAdministrator数据库Thu, 8 Oct 2026 12:00:00 GMT/archives/kafka-partition-consumer分区是并行的最小单位 Kafka 的一个 topic 由若干分区组成，分区才是有序的日志，topic 级别没有全局顺序。消息按 key 哈希到分区，同一个 key 永远进同一个分区，所以“同一订单的消息有序”是可以保证的，“所有消息全局有序”则要付出单分区的代价，吞吐直接砍到单线程水平。 分区数决定]]>/archives/kafka-partition-consumerAdministrator中间件Tue, 22 Sep 2026 12:00:00 GMT/archives/gray-release灰度是按用户路由，不是按机器 很多人把灰度理解成“先发一台机器，观察一天”。这在单体时代勉强可用，在微服务里基本无效：一次下单请求会经过网关、订单、库存、支付、优惠券五个服务，只把订单服务的一台机器换成新版本，请求照样会打到老版本的下游，新逻辑根本走不完整。 真正的灰度要解决的是一个请求在整条链路上]]>/archives/gray-releaseAdministratorSpring CloudTue, 8 Sep 2026 12:00:00 GMT/archives/ddd-introDDD 解决的是复杂度失控 领域驱动设计经常被讲成一堆名词：聚合、值对象、领域事件、仓储。但它真正要解决的是一个问题：当业务规则越来越复杂，代码里的 if 越来越多，谁都不敢改的时候，怎么让代码结构重新对应业务结构。 它分两层。战略层关注“系统该切成几块、边界在哪、每块内部用什么语言描述业务”，这一]]>/archives/ddd-introAdministrator架构与性能Sat, 22 Aug 2026 12:00:00 GMT/archives/multi-tenant-architecture隔离模型的决定因素是成本与合规 多租户的第一道选择题不是技术，而是“每个租户的数据放在哪里”。三种主流模型各有明确的代价： 模型 隔离强度 成本 适用 每租户独立库 最强，故障与备份完全隔离 最高，几百个租户就是几百套库 大客户、金融、有合规要求 每租户独立 schema 较强，共享实例 中等，连接]]>/archives/multi-tenant-architectureAdministrator架构与性能Sat, 8 Aug 2026 12:00:00 GMT/archives/api-security-idor越权不是“没登录” 接口鉴权最常见的漏洞不是匿名访问，而是登录了、也能通过身份校验，但访问了不属于自己的数据。典型场景：把 /api/orders/10086 改成 /api/orders/10087，只要对方订单存在，接口就把完整信息返回了。 这类问题在安全领域叫 IDOR（不安全的直接对象引用）]]>/archives/api-security-idorAdministrator踩坑排查Wed, 22 Jul 2026 12:00:00 GMT/archives/oauth2-oidc-spring-security授权与认证是两件事 OAuth2 解决的是授权：某个客户端在用户同意下，能拿到一个访问令牌，去访问限定范围内的资源。它的产物是 access token 和 scope。OIDC 在 OAuth2 之上加了一层认证：通过 id_token 告诉你“这个人是谁”，并提供 userinfo 端点和发现文]]>/archives/oauth2-oidc-spring-securityAdministratorSpring CloudWed, 15 Jul 2026 12:00:00 GMT/archives/chaos-engineering混沌工程不是随机搞破坏 很多人把混沌工程理解成“在线上随便杀几个 Pod，看系统会不会挂”，这既危险又没意义。它的真实目的是用受控的实验，把系统在故障下的行为从“未知”变成“已知”：哪个依赖断了会降级、哪个超时配置会导致级联失败、告警能不能在 1 分钟内触发。 关键在“受控”。没有稳态假设、没有爆炸]]>/archives/chaos-engineeringAdministratorDevOpsWed, 8 Jul 2026 12:00:00 GMT/archives/performance-testing-jmeter压测要回答的问题 压测不是为了得到一个漂亮的 QPS 数字，而是为了回答三个问题：当前配置下的容量拐点在哪、瓶颈在哪个组件、限流和扩容的阈值该设成多少。没有这三个答案，压测报告上那个“峰值 12000 TPS”除了贴在大屏上没有任何用处。 所以压测的第一件事是写下目标，比如“在 P99 小于 300]]>/archives/performance-testing-jmeterAdministrator架构与性能Mon, 22 Jun 2026 12:00:00 GMT/archives/jvm-g1-zgc先量再调，不要先改参数 GC 调优最常见的错误是先抄一组参数。堆大小、Region 大小、暂停目标都跟具体应用的内存分配模式强相关，别人的参数在你这里可能直接把吞吐砍掉三成。 正确的顺序是：先明确目标（是低延迟还是高吞吐），再打开 GC 日志把现状量出来，最后才动参数，并且一次只动一个。没有数据的调]]>/archives/jvm-g1-zgcAdministrator架构与性能Mon, 8 Jun 2026 12:00:00 GMT/archives/distributed-id-clock雪花结构再拆一遍 标准雪花 ID 是一个 64 位长整型：1 位符号位恒为 0、41 位毫秒时间戳、10 位工作节点、12 位毫秒内序列号。41 位从自定义纪元开始算，能覆盖约 69 年；12 位序列号意味着单节点每毫秒最多 4096 个 ID，也就是约 409 万 QPS。 这套结构最大的优点是趋]]>/archives/distributed-id-clockAdministrator架构与性能Fri, 22 May 2026 12:00:00 GMT/archives/sharding-global-query-migration分片键一选错，查询就开始变形 分库分表最难的不是把数据切开，而是切开之后那些“不按分片键查”的需求。以订单表按 user_id 分片为例：C 端“我的订单”走单分片，非常好；运营后台按订单号查、按商家查、按时间段导出，全都没有 user_id，只能把 SQL 广播到所有分片再归并。 广播查询的成本随]]>/archives/sharding-global-query-migrationAdministrator架构与性能Fri, 8 May 2026 12:00:00 GMT/archives/redis-cluster-hashRedis Cluster 分的是槽，不是环 面试里经常把 Redis Cluster 说成“一致性哈希”，其实两者机制完全不同。一致性哈希是把节点和 key 映射到一个环上，节点增减只影响相邻区段，靠虚拟节点均衡；Redis Cluster 用的是固定的 16384 个哈希槽，CRC16(key)]]>/archives/redis-cluster-hashAdministrator数据库Wed, 22 Apr 2026 12:00:00 GMT/archives/seckill-inventory秒杀的问题不是“卖出去”，是“抢进来” 一场一万件商品的活动，开场瞬间可能有几十万请求涌进来，而系统真正需要处理的只有一万次成功扣减。剩下 95% 以上的流量的正确归宿是“被快速拒绝”，而不是“排进数据库慢慢算”。 所以秒杀设计的第一原则是把无效流量挡在离数据库最远的地方：越靠前拒绝，成本越低。网关]]>/archives/seckill-inventoryAdministrator架构与性能Wed, 15 Apr 2026 12:00:00 GMT/archives/high-concurrency-read-heavy读多写少的瓶颈到底在哪 典型的内容型业务读写比可能到 100:1，甚至 1000:1。这时候数据库的 CPU 大部分花在重复执行同一条查询、重复做同样的行解析上，缓存的价值就是把“重复”消掉。 但缓存收益不是线性的。命中率 95% 意味着 5% 的请求打到数据库，命中率 99% 只剩 1%——命中率]]>/archives/high-concurrency-read-heavyAdministrator架构与性能Wed, 8 Apr 2026 12:00:00 GMT/archives/cloud-native-observability三根柱子撑的是同一件事 指标、日志、链路追踪经常被当成三套独立系统，各自采购、各自接入，最后出了故障还是靠人肉翻。它们真正的分工是回答不同粒度的问题：指标告诉你“什么时候、哪个服务、多严重”，链路告诉你“这一个请求慢在了哪一跳”，日志告诉你“那一刻到底发生了什么”。 云原生环境下还多了一层约束：Po]]>/archives/cloud-native-observabilityAdministratorDevOpsSun, 22 Mar 2026 12:00:00 GMT/archives/istio-service-meshSidecar 之后，流量路径变了 接入 Istio 之后，一个 Pod 里的应用发出的请求不再直接出网卡：出站流量被 iptables 规则劫持到 istio-proxy 的 15001 端口，由 Envoy 按 Listener、Route、Cluster 三层决策后再转发；入站同理，先过 15]]>/archives/istio-service-meshAdministratorDevOpsSun, 8 Mar 2026 12:00:00 GMT/archives/k8s-config-secret改完 ConfigMap，应用却没反应 这是最常见的困惑：kubectl edit configmap 保存成功，kubectl describe 也显示新值，但容器里读到的还是老配置。于是有人怀疑集群坏了，其实只是没搞清更新的传播路径——ConfigMap 变了，不等于进程里的配置变了，更不等于]]>/archives/k8s-config-secretAdministratorDevOpsSun, 22 Feb 2026 12:00:00 GMT