应用架构图
技术架构是将业务需求转化为技术实现的关键过程，涵盖分层设计、技术选型与系统集成。本文详解单体与分布式架构，包括展现层、业务层、数据层及基础层的设计原则，并阐述应用间及外部系统的调用关系与边界划分。
应用架构图
在业务架构基础上，技术架构将产品需求转化为技术实现。它涵盖分层设计、技术选型与关键组件关系，包括单体四层结构（表现、业务、数据、基础层）和分布式应用间的调用与集成，明确内外系统边界，构建完整技术体系。
应用架构图
技术架构是将业务需求转化为技术实现的关键过程，涵盖分层设计、技术选型与系统间关系梳理。本文详解单体与分布式架构，包括展现层、业务层、数据层及基础层的职责，并阐述应用内外调用关系与边界划分，助力构建清晰的技术体系。
Day01 每日必会
微服务并非绝对优于单体，需结合业务场景。简单应用选单体更轻便，避免分布式复杂性；复杂系统可选微服务，解耦性强、易扩展。常用中间件如Nacos（注册/配置中心）、OpenFeign（远程调用）、Gateway（网关）。Nacos支持心跳机制，区分临时与非临时实例，兼具AP/CP模式，较Eureka更具灵活性。负载均衡常用轮询、加权轮询等，项目中多用轮询策略。
RocketMQ：底层Netty频繁OS OOM
本文记录了一例Java应用因Netty在多个ClassLoader中重复加载PooledByteBufAllocator，导致堆外内存超限引发OS OOM的排查过程。通过NMT、Arthas等工具分析，发现多个中间件独立占用堆外内存，总量远超MaxDirectMemorySize限制。最终定位为RocketMQ客户端大量使用堆外内存所致，建议短期内调整JVM堆内存比例以缓解问题。
应用架构图
在业务架构基础上，技术架构将产品需求转化为技术实现。它涵盖分层设计、技术选型与关键组件关系，包括单体四层结构（表现、业务、数据、基础层）和分布式应用的调用关系，明确内外系统边界，形成完整技术体系图谱。（239字）
RocketMQ：底层Netty频繁OS OOM
前言：此文记录最近一例Java应用OOM问题的排查过程，希望可以给遇到类似问题的同学提供参考。在本地集团，大多数情况下Java堆的大小会设置为容器规格的50%～70%，但如果你设置为50%时还是遇到了OS OOM的问题，会不会无法忍受进而想要知道这是为什么？没错，我也有一样的好奇。
背景
某核心应用的负责同学反馈应用存在少量机器OOM被OS kill的问题。看sunfire监控信息，的确如此。
初步收集到的信息：
容器内存=8G，Java 11，G1 GC=4G，MaxDirectMemorySize=1G。详见下图：
业务同学已经做过Java dump，可以看到堆外对象几乎没有，堆内的使用量
中国境内Vertex AI服务商技术架构深度解析
随着生成式AI发展，Google Vertex AI成企业首选，但中国用户面临网络延迟、数据合规与系统集成难题。专业合规服务商应运而生，通过QUIC传输优化、AST代码脱敏与协议转换网关，构建“逻辑缓冲区”，实现低延迟、高合规的AI服务接入。穿扬科技等企业整合边缘网络、语义分析与智能路由，保障数据主权同时，提升性能并降低成本，助力跨国AI能力本土化落地。（238字）
301重定向深度实战：老手级优化、陷阱规避与性能调优
本文深入解析网页重定向的四大性能陷阱：链式跳转导致的延迟累积、HTTP/2下证书不匹配破坏连接复用、CDN配置不当引发缓存污染，以及框架层重定向带来的中间件开销。通过Nginx合并跳转、统一SSL证书、正确配置CDN回源与缓存策略，可显著降低延迟，提升加载性能与用户体验。
