第一次听到「麒麟网站7061」这个名字，很多人会以为这是一个内部代号，或者某个实验室里的原型项目。实际上，它是一个已经在线运行了相当长一段时间的Web服务平台，承载着日均百万级的请求量。7061这个数字并非随机——它对应的是项目立项时内部工单的编号，团队后来干脆把它保留下来当作正式名称。这篇文章不打算复述官方文档里的架构图，而是想从实际运维和迭代过程中暴露出来的问题出发，聊聊这套系统为什么长成了现在这个样子。

从单体到服务化：一次被迫的拆分

麒麟网站7061最早的版本其实非常简单。一台8核16G的云服务器，上面跑着一个Node.js应用，前端静态资源直接由Nginx托管，数据层用的是单实例MySQL。这套配置支撑了前八个月的运营，直到日活用户突破三万之后，问题开始集中爆发。最典型的表现是每天上午十点到十一点之间，接口响应时间从平均80毫秒飙升到2秒以上，偶尔还会出现数据库连接池耗尽导致的503错误。

团队最初的反应是垂直扩容——把服务器升到16核32G，数据库换成更高规格的RDS实例。这确实缓解了大约六周的压力，但很快又碰到了新的天花板。真正促使他们下决心做服务化拆分的，是一次由慢查询引发的连锁故障。当时一个运营后台的统计报表SQL没有走索引，拖垮了整个数据库实例，导致面向用户的核心接口全部超时。这件事让团队意识到，不同业务模块之间的资源隔离不能再拖了。

拆分的原则很务实：按照数据访问模式和流量特征来切，而不是按照组织架构或者DDD的理论边界来切。最终分出了四个核心服务——用户认证服务、内容服务、搜索服务和消息通知服务。每个服务独立部署、独立数据库，服务之间顺利获得内部RPC框架通信。这个决定带来的直接好处是，搜索服务因为要做全文索引，内存消耗大，可以单独部署在高内存机型上，而消息通知服务IO密集，可以用SSD云盘，两者互不影响。

网关层的设计：不只是反向代理

服务拆分之后，客户端直接调用各个微服务的地址显然不现实。麒麟网站7061在服务前面加了一层API网关，但他们的网关实现和很多项目不太一样。市面上常见的做法是直接用Kong或者APISIX，配置一堆路由规则就完事。7061的团队一开始也试过Kong，后来发现两个问题：一是他们的鉴权逻辑比较特殊，需要在网关层解析JWT之后还要查一次Redis里的会话状态，Kong的插件机制做这个很别扭；二是他们需要对不同来源的请求做差异化的限流策略，比如来自小程序的请求和来自Web端的请求，限流阈值完全不同，Kong的配置管理起来很痛苦。

最终他们用Go语言自己写了一个轻量级网关。核心逻辑不复杂：接收请求、解析路由、执行中间件链、转发到后端服务。中间件链包括鉴权、限流、日志记录、链路追踪注入这几个环节。自己写的好处是灵活，比如限流策略他们实现了一套基于滑动窗口的算法，支持按用户ID、IP、接口路径三个维度组合限流，而且规则可以动态下发，不需要重启网关。这个网关单实例在4核8G的机器上能跑到每秒一万两千次转发，对于7061当时的流量规模来说绰绰有余。

值得一提的是，他们在网关层做了一个看似不起眼但后来被证明很有价值的设计：请求指纹。每个进入网关的请求都会根据用户ID、接口路径、请求参数生成一个哈希值，这个哈希值会随着请求一路传递到后端服务。当某个接口出现异常时，运维人员可以顺利获得请求指纹快速定位到是哪些用户在什么条件下触发了问题，而不是像以前那样只能看聚合后的监控曲线干瞪眼。

数据层的取舍：MySQL、Redis和Elasticsearch的分工

麒麟网站7061的数据层用了三种存储：MySQL、Redis和Elasticsearch。这三种存储的分工不是一开始就规划好的，而是在实际使用中逐步明确的。

MySQL承担的是核心业务数据的持久化，比如用户账户、订单记录、内容元数据。团队对MySQL的使用有一条硬性规定：所有面向用户的查询必须走索引，任何可能导致全表扫描的SQL都不允许上线。为了落实这条规定，他们在CI流程里加了一个SQL审查环节，用pt-query-digest对测试环境的慢查询日志做分析，如果有新的慢查询出现，直接阻断发布。这个做法听起来有点激进，但确实有效——上线至今，MySQL的慢查询数量不断控制在个位数。

Redis在7061里不只是缓存，还承担了会话管理、分布式锁和简单消息队列的职责。会话管理用Redis是常规操作，这里不展开。分布式锁主要用于内容发布时的并发控制，防止同一篇内容被多个运营人员同时编辑导致覆盖。消息队列用的是Redis的Stream数据结构，虽然功能比不上Kafka那么完善，但对于7061这种规模的应用来说够用了，而且运维成本低很多。唯一需要注意的是Redis的内存使用，他们设置了两级淘汰策略：volatile-lru用于设置了过期时间的key，noeviction用于持久化的key，这样即使内存吃紧，也不会把重要数据淘汰掉。

Elasticsearch的引入比较晚，是在内容量突破五十万条之后。之前用MySQL的LIKE查询做搜索，性能还能勉强接受，但已经出现了明显的延迟。切换到Elasticsearch之后，搜索响应时间从平均400毫秒降到了30毫秒以内。不过ES也带来了新的问题——数据同步。他们的做法是业务写入MySQL之后，顺利获得binlog监听把变更事件推送到一个内部消息总线，再由一个独立的同步服务写入ES。这个同步链路有大约1到2秒的延迟，对于搜索场景来说可以接受，但如果业务上要求实时搜索，这个方案就不适用了。

部署与运维：容器化不是银弹

麒麟网站7061的部署方式经历过两次大的变化。最早是直接在云服务器上跑Node.js进程，用PM2做进程管理。后来迁移到了Docker Swarm，再后来换成了Kubernetes。每次迁移都有具体的触发原因，不是为了追新技术。

从PM2到Docker Swarm的迁移，主要是因为环境一致性问题。开发环境跑得好好的代码，部署到生产环境就出问题，排查半天发现是Node.js版本不一致或者某个系统依赖缺失。Docker解决了这个问题，但Swarm的编排能力有限，滚动更新的时候经常出现服务短暂不可用的情况。这对于7061这种要求99.9%可用性的平台来说是不可接受的。

迁移到Kubernetes之后，滚动更新和健康检查的问题解决了，但新的复杂性也随之而来。K8s的学习曲线陡峭，团队花了将近两个月才把网络策略、资源限制、探针配置这些东西调到一个比较稳定的状态。他们总结出来的经验是：不要一上来就用Helm或者Operator这些高级工具，先用原生的Deployment和Service把基本流程跑通，理解每个资源对象的作用，再考虑要不要引入更上层的抽象。

监控方面，7061用的是Prometheus加Grafana的组合。指标采集覆盖了三个层面：基础设施层（CPU、内存、磁盘IO）、应用层（QPS、响应时间、错误率）和业务层（注册转化率、内容发布量、搜索点击率）。告警规则设置得比较克制，只对真正影响用户体验的指标做告警，比如核心接口的P99响应时间超过500毫秒，或者错误率超过1%。其他指标只做记录和展示，不触发告警。这样做的好处是告警疲劳问题比较轻，运维人员对每一条告警都会认真对待。

那些踩过的坑和后来的调整

没有任何一个线上系统是一帆风顺的，7061也不例外。这里说几个比较典型的教训。

第一个坑是缓存穿透。早期做内容详情页缓存的时候，只考虑了正常情况下的缓存读写，没有处理查询不存在的内容时的情况。结果有人写脚本用随机ID疯狂请求详情接口，每次缓存都不命中，请求全部打到MySQL上，差点把数据库打挂。后来的解决方案是加了一层布隆过滤器，对于明显不存在的ID直接返回空，同时在缓存层对空结果也做短时间的缓存，防止同一个不存在的ID被反复查询。

第二个坑是跨服务调用的事务问题。用户注册的时候需要同时写入用户表和发送欢迎消息，这两个操作分别在用户服务和消息服务里。最初的实现是先写用户表，再调用消息服务，如果消息服务调用失败就回滚用户表。但这个方案在消息服务超时但实际处理成功的情况下会导致数据不一致——用户表回滚了，但欢迎消息已经发出去了。后来改成了基于本地消息表的最终一致性方案：用户服务在写用户表的同时往本地消息表里插一条记录，然后异步投递消息，投递成功后再删除消息表记录。这个方案牺牲了强一致性，但换来了更高的可用性，对于注册这个场景来说是合理的取舍。

第三个坑是配置管理。7061的配置项分散在环境变量、配置文件、数据库和配置中心四个地方，时间一长连团队自己都搞不清楚某个配置到底在哪里生效。后来做了一次彻底的梳理，把所有配置统一收敛到配置中心，环境变量只保留启动时必须知道的那几个（比如配置中心的地址和认证密钥）。这个整理过程花了整整一周，但之后的配置变更效率提升非常明显。

关于技术选型的一些思考

回头看麒麟网站7061的技术架构，有一个特点贯穿始终：选型偏保守，但落地很扎实。他们没有用Service Mesh，没有上Serverless，也没有追gRPC-Web这些比较新的东西。每一项技术的引入都有明确的触发条件和退出机制。比如Redis的引入是因为会话管理的需求，如果将来会话管理有了更好的方案，Redis这部分是可以替换的。这种思路的好处是系统整体复杂度可控，团队每个人都能理解系统的全貌，出了问题知道从哪里查起。

另一个值得说的点是文档。7061团队有一个硬性要求：任何架构上的变更，必须同步更新一份叫做「架构决策记录」的文档。这份文档不追求文采，只要求说清楚三件事：我们遇到了什么问题、考虑了哪些方案、为什么选了这个方案。这个习惯坚持了两年多，积累了近百份决策记录。新成员入职的时候，读一遍这些记录，基本就能理解系统为什么是现在这个样子，而不是对着代码猜。

技术架构从来不是一成不变的，麒麟网站7061的架构也在持续演进。最近他们正在评估把部分服务从虚拟机迁移到ARM架构的实例上，主要是出于成本考虑。初步测试显示，对于计算密集型的服务，ARM实例的性价比确实更高，但一些依赖特定x86指令集的库需要重新编译和测试。这件事还在推进中，结果如何还有待观察。不过按照他们一贯的风格，应该会先在小范围做灰度，确认稳定之后再逐步扩大范围。