采集层：多端事件统一上报
覆盖安卓、iOS、小游戏与网页端，各端按同一套事件模型上报，字段命名保持一致。采集失败时本地会暂存并重试，避免因为一次网络抖动丢掉整段数据。每个端侧都内置了本地缓冲队列，断网或超时的事件会在恢复后按序补发，服务端通过事件唯一标识做去重，保证不重不漏。新增端类型时只需实现同一套事件协议即可接入，不需要改动下游任何环节。
技术架构 - 米兰(AC·中文)官方网站
技术架构栏目是米兰中国官网面向合作客户集中说明底层系统设计思路的窗口。我们把从数据采集、传输、存储、计算到应用输出的完整链路拆开来讲，让每一位正在评估合作的客户都能看清楚数据是怎么流进来的、经过了哪些处理、最终以什么形式呈现。这里不做概念包装，只讲实际做法：采集端如何统一事件模型、传输层如何削峰填谷、存储层如何兼顾明细与聚合、计算层如何统一指标口径、应用层如何保证看板与接口结果一致。读懂这几层，你就能判断一套数据系统是否值得长期依赖，也能在对接时提出更准确的问题。无论你是业务负责人还是技术对接人，本栏目都提供了足够的细节来支撑你的判断。
五层架构详解
传输层：异步管道与流量削峰
上报请求先进入消息队列再落库，高峰期可以按消费能力平滑处理，不会因为瞬时流量把写入打满。队列积压时会有监控告警，运维可以及时扩容。消息队列采用多分区并行消费，单个分区内保证顺序，跨分区按业务主键做局部有序。消费端支持动态增减实例，扩容后延迟通常在分钟级回落，业务侧不需要感知底层变化。
存储层：明细与聚合分层存放
原始明细按时间分区保存，常用指标提前聚合好，查询时优先走聚合结果。这样既保留了回溯明细的能力，又让日常看板的响应保持在可接受范围内。明细数据设置合理的保留周期，过期后自动归档到低成本存储，需要时仍可恢复查询。聚合层按小时与天两个粒度预计算，看板默认读天粒度，下钻时切换到小时粒度，避免每次都扫描全量明细。
计算层：指标口径集中定义
所有指标的计算逻辑集中在配置中维护，改口径只需改一处，报表与接口同步生效。避免了同一指标在多个脚本里各写一遍、时间久了无人敢动的情况。配置化口径还带来版本管理能力，每次修改都有记录可追溯，出现异常时可以快速回滚到上一版本。新增指标时先在配置中注册，计算任务会自动纳入调度，不需要额外部署。
应用层：看板与接口双出口
对内提供可视化看板，对外提供数据接口供业务系统调用，两侧使用同一份计算结果。运营在页面上看到的数字，与系统自动拉取的完全一致。接口层做了鉴权与限流，不同调用方按权限获取对应范围的数据，避免越权访问。看板支持自定义时间范围与维度组合，所有筛选条件在接口层同样可用，方便业务方按需集成到自有系统中。
合作前如何评估一套技术架构
如果你正在考虑与米兰中国官网背后的技术团队合作，技术架构这一块通常是最值得花时间了解的部分。它决定了你后续拿到的数据是否稳定、口径是否可信、出问题时能否快速定位。以下从客户视角整理几个关键判断点。
数据链路是否完整可追溯
好的架构从采集到应用每一层都有明确职责，任何一条数据都能从看板上的数字反查到原始上报记录。评估时可以问：如果某个指标突然异常，你们能在多长时间内定位到是哪一层出了问题？链路完整意味着排查有路径，而不是靠猜。
峰值场景下是否稳定
业务总有高峰低谷，关键在于高峰时系统是否还能保持写入不丢、查询不超时。可以了解对方在传输层是否有缓冲机制、存储层是否有冷热分离、计算层是否能弹性调度。这些设计决定了你在业务放量时会不会遇到数据延迟或丢失。
指标口径是否统一管理
同一组数据在不同报表里出现不同结果，是最常见也最消耗信任的问题。判断方法是问对方：改一个指标定义需要动几处？如果答案是“一处配置”，说明口径是集中管理的；如果需要改多个脚本，后续维护成本会很高。
新增需求时接入成本如何
合作过程中难免要加新端、加新指标、加新接口。好的架构在这些场景下只需按既有协议扩展，不需要推倒重来。可以请对方举一个最近新增端或新增指标的实例，看改动范围有多大、上线周期有多长。
第一次接触这类系统的人容易忽略的一点是：架构的好坏不体现在功能列表上，而体现在边界情况下的表现。正常运行时大家看起来都差不多，真正拉开差距的是断网重试是否生效、队列积压是否告警、口径变更是否同步。建议在评估时多问“如果……会怎样”，比只看演示更能看清底子。