先把后台拆开，再决定怎么拼
在金边做软件这12年，团队维持在28个人，每年交付的项目量在100个左右。客户覆盖柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚，主攻电商、娱乐、金融交易、地产、物流五个行业。项目量到这个规模以后，管理后台的架构方式基本收敛成一套固定路径：第一版原型出来之前，先把业务边界拆清楚。用户管理、订单处理、报表分析、监控告警各自作为可独立部署的功能单元，每个单元持有自己的服务和数据存储，通过统一API网关对外通信。这样拆的好处是边界清晰，某个模块出问题不会把整个后台拖垮，后续加功能也不用动全局结构。反过来，拆得太碎也不行，服务间调用链拉长之后，排查一个跨模块问题的时间成本会明显增加。
技术选型上，API网关用Spring Cloud Gateway，Nacos负责服务注册与发现。前端用qiankun把不同模块的React或Vue应用集成到同一个控制面板里，按需加载、独立部署，单个模块发版不需要整个前端重新构建。后端服务之间用gRPC通信。这套组合在电商、娱乐、金融交易、地产、物流的后台项目里都实际跑过，底层可以复用，但每个行业在数据权限和报表口径上要单独处理。比如金融交易类后台对操作留痕的要求远高于普通电商后台，地产类后台则更看重楼盘维度的数据隔离。
模块化要真正跑起来，前后端之间的数据契约必须固定。团队内部维护一套统一的DTO规范，所有模块的CRUD操作遵循相同的JSON Schema。用户列表、订单列表、报表数据可以复用同一套表格、表单和图表组件，不需要每个页面单独写一遍。小项目几天能交付，大项目大约2个月，靠的就是这个复用能力。电商类系统有成品，开箱即用，交付速度比纯定制快，部分成品系统已经有几十家客户在运营使用。
权限不只是“能不能进页面”，要做数据级隔离
用户管理和权限控制是后台的地基，但不少项目只做到“这个角色能不能打开某个菜单”，到数据层面就全放开了。团队采用RBAC模型，支持多级角色与细粒度权限划分，内置超级管理员、运营主管、数据分析师、客服等角色，也允许自定义角色，精确到页面或按钮级别。
实现分三层。前端路由守卫通过JWT Token携带用户角色信息，页面和按钮按权限渲染；后端接口层用Spring Security注解校验，比如@PreAuthorize("hasPermission('order', 'view')")；第三层是数据权限，同一角色下不同用户只能查看自己所属机构或地域的数据。这一层通过SQL拦截器动态拼接过滤条件实现，拼接逻辑在后端完成，前端拿不到越权数据。过滤条件基于当前用户的机构ID和地域编码生成，参数化绑定，不直接拼接字符串。金融交易和地产类客户对数据隔离的要求尤其高。地产项目里，同一个后台中不同楼盘的项目方只能看到自己楼盘的数据，这一层曾经在验收时被客户打回来过一次，原因是数据隔离维度没按楼盘ID做彻底。
用户管理界面本身需要支持批量导入导出、密码重置、登录日志查询。会话信息放Redis，Token设短有效期并绑定客户端IP与User-Agent，降低泄露风险。删除订单、修改权限这类敏感操作必须记录审计日志。审计日志不是只记“谁在什么时间做了什么”，要把操作前后的字段值都记录下来，否则事后追溯时无法还原具体改动内容。
订单与报表：一个管写入，一个管分析
订单管理要扛高并发写入和实时查询。团队按用户ID哈希做分库分表，把订单数据分散到多个MySQL实例。同时引入Elasticsearch，支持模糊查询、范围过滤和聚合分析。运营人员可以快速检索某时间段内所有“待处理”订单并按金额排序。东南亚客户的运营习惯差异很大，有的团队只看日活，有的只看流水，还有的盯着客单价和复购率，检索条件必须做得足够灵活，不能把报表口径写死。
报表是运营决策的依据。用Apache Flink做实时流计算，每5分钟聚合一次新增用户数、订单总量、收入趋势等指标，输出到ClickHouse。前端用ECharts渲染图表，支持钻取和对比分析，导出支持CSV和Excel。下面是一组典型报表指标的处理方式：
| 指标名称 | 数据来源 | 计算逻辑 | 刷新频率 |
|---|---|---|---|
| 日活跃用户(DAU) | 用户行为日志 | 按用户ID去重计数 | 每5分钟滚动更新，T+1出最终值 |
| 订单转化率 | 访问日志+订单表 | 完成订单数/独立访客数（按用户ID或设备指纹去重） | 每5分钟 |
| 收入总额 | 订单表 | SUM(实际支付金额)，仅统计支付成功且未全额退款的订单 | 实时 |
支付对接单独说明：支付通道由客户提供资源，团队负责对接，不提供支付通道。柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚的支付环境差异很大，部分国家的本地钱包和网银渠道对接文档不完整，客户自己掌握通道资源，上线和运维都更灵活。团队只保证订单状态回写和回调处理的可靠性，包括回调乱序、重复通知、超时重试这些场景。
监控要能看见业务，不只是服务器指标
基础监控用Prometheus + Grafana，采集服务器CPU、内存、磁盘IO、网络流量。但运营控制面板真正需要的是业务层监控。团队开发自定义Exporter，采集订单处理延迟、API响应时间、用户登录失败率等指标。采集方式是在应用内部埋点，通过指标接口暴露给Prometheus拉取，埋点本身对主流程的性能开销控制在可忽略范围。
告警通过Alertmanager配置，支持邮件、短信、钉钉/企业微信机器人。订单处理队列堆积到一定程度时自动告警，并触发弹性伸缩增加Pod实例。具体阈值没有固定值，因为每个项目的业务量级不同，静态阈值容易造成告警频繁误报或该报不报。团队引入基于历史数据的动态阈值，用过去一段时间的指标均值加偏移量作为告警基线。监控面板用WebSocket推送实时数据，时序数据存InfluxDB，支持历史回放。运营方在后台看到的数据刷新延迟，比传统的轮询方案要低。
监控体系上线后，团队提供TG分钟级响应，并有AI运维辅助处理告警分类和初步定位。系统bug修复免费，新增功能按工作量收费。客户在东南亚多国运营时，时差和语言不会成为障碍，因为服务语言是中文。
安全设计从传输层一直做到审计层
管理后台的安全问题，很多出在流程执行而不是技术方案本身。团队按五层来做：
- 传输层：全站HTTPS，TLS 1.3，防中间人攻击。
- 认证层：JWT短有效期（通常30分钟），绑定客户端IP与User-Agent。
- 权限层：最小权限原则，每个接口经Spring Security注解校验，未授权直接返回403。
- 数据层：密码、手机号等敏感字段AES-256加密存储，查询脱敏显示，SQL全部参数化。
- 审计层：所有用户操作记录到Elasticsearch，保留周期按客户合规要求配置，支持关键字搜索回溯。
审计日志的存储成本和索引策略按项目规模单独设计，不是所有项目都无差别保留同样时长。定期做渗透测试和代码审计，第三方依赖用Maven/Gradle插件自动识别有CVE的库并升级。这个过程不是交付完就结束了，而是长期运维的一部分。遇到过客户自己改配置把审计日志关掉的情况，后来在验收复盘时才发现，所以现在审计日志的开关也做进了权限控制里，普通管理员无权关闭。
实际交付周期和协作方式
管理后台定制开发的周期取决于功能复杂度和并发规模。下面是团队内部排期的参考，具体人天会按功能清单逐项核算：
| 阶段 | 内容 | 时间（人天） | 备注 |
|---|---|---|---|
| 需求分析 | 功能梳理、原型设计、技术选型 | 5-10 | 含客户确认 |
| 模块开发 | 用户管理、权限模块、订单模块 | 20-30 | 基础功能 |
| 报表与监控 | 数据聚合、图表与告警集成 | 10-15 | 依赖大数据组件 |
| 安全加固 | 加密、审计、渗透测试 | 5-8 | 非功能需求 |
| 测试与部署 | 集成测试、压力测试、文档 | 8-12 | 含灰度发布 |
报价不在公开渠道写具体数字，因为每个项目的功能清单差异很大。实际做法是面谈或Telegram详谈，按功能清单评估。付款方式是先付30%，验收后结清尾款。如果客户需要高并发优化，比如分布式部署和缓存策略，工作量会额外增加，具体比例按项目评估。
团队28人，在金边做软件开发12年，每年交付约100个项目。如果业务面向柬埔寨、菲律宾、越南、老挝、泰国、印尼或马来西亚，需要一套能支撑日常运营的管理后台，可以通过Telegram直接沟通，按功能清单逐项确认需求和周期。