很多统一认证中心不是一次性设计出来的，而是十年里一版一版迭代出来的。本文以一类典型的"自研统一认证中心"为原型（十年前基于早期 Spring Security OAuth2 深度定制、经过多轮迭代、支撑千万级用户的真实生产系统的常见形态），完整还原它在签发、鉴权、续期、吊销四个环节的真实执行路径，对照今天从零设计一套 OAuth 2.0 认证中心会怎么做，并给出每一处差异背后的选择背景与风险模式。
自研二进制协议要扛住"省、可切包、可分类、可加密、可演进"五条约束，这些原则听起来抽象，但落到一个真实跑在生产环境的 IM 服务端里，每一条都能在代码里指认到具体的类和字段。这篇文章以飞享IM（FshareIM）服务端 chat-server-pro 为例，从源码层面拆解这套自研协议是怎么把上述原则一条条实现出来的：10 字节包头怎么切包、Signal/SubSignal 两级命令字怎么分发、心跳和 ACK 怎么关联、AES 加密放在协议的哪个环节、版本位怎么预留，以及 TCP 二进制和 WebSocket JSON 这两条通道是怎么在同一个接入层里协同工作的。
本文介绍一套面向 AI 客服 / 问答助手场景的流式 LLM Agent 服务架构，技术栈为 Spring Boot 3 + WebFlux + LangChain4j + Redis + Kafka，采用 Chat Service + Governance Service 双服务分层设计，支持中等规模起步（日活十万级、峰值千级并发会话）并可平滑扩展至大规模。
分库分表不是一个简单的配置问题——它关系到分片键选择、扩容数学性质、跨分片查询策略，以及在不停服前提下如何安全迁移数据。本文以飞享IM（FshareIM）为案例，从现有手动分表方案的瓶颈出发，完整呈现三种技术路线对比、基于 ShardingSphere-JDBC 的新建分库方案、按 2 的幂扩容的数学推导，以及 Canal + 双写的零停机迁移时序，供 IM 系统架构师和 DBA 参考。
架构设计不只是画几张图——它是对整个系统的系统性思考：从业务需求到质量约束，从模块拆分到接口契约，从数据分表到故障容灾，再到 AI 融合与技术演进路线。本文以飞享IM（FshareIM）为参考，完整呈现一位架构师在一个生产级 IM 系统上应当完成的全部设计工作，涵盖六大职责分解、五阶段设计步骤，以及覆盖接入层、业务层、数据层、AI 架构、安全架构和部署架构的完整设计文档，附带技术决策记录（ADR）和架构评审检查单。
飞享IM（FshareIM）是一款支持私有部署的即时通讯系统，服务端采用 Java 实现，核心由 push-connector（接入层） 和 push-group（业务层） 两个服务组成。本文从实际运行角度梳理系统的13个核心技术模块，逐一说明当前方案的设计思路、存在的隐患，以及对应的改进建议，帮助开发者快速理解系统全貌。
