关键词： 报表应用扩展 报表应用拆分 报表集群部署 报表高可用 报表水平拆分 报表微服务

系统扩展会有几种情况，不同的做法报表的应对策略也不同。

1、集群
把单体应用部署到集群环境，即每个节点都有一个完整的单体应用。通过负载均衡技术将用户请求路由到不同节点上从而分担并发压力。
这种系统扩展方式很常见，目的是解决高并发下的请求响应效率问题，但无法改善大数据量时单个任务的响应效率。

这种情况下，报表开发无需特殊注意，按照单体应用的方式开发，应用集群部署时随应用部署即可。

2、水平拆分
为了解决大数据量时的访问效率问题，可以通过水平拆分来扩展系统，常见的做法是数据层分表分库、应用层采用集群部署。

这时的报表开发要尤其注意，首先不能使用存储过程了（其实单体应用我也不建议使用数据库存储过程了，参考资料： 怎样减少报表开发中对存储过程的依赖 ），另外分表分库后做 join 会比较困难，所以最好就不要写复杂 SQL 了（可能也写不出来），维护会比较麻烦，替代方案： 如何应对报表开发中的复杂逻辑

3、垂直拆分
面对复杂业务和大数据量还可以进行垂直拆分，梳理业务把业务纵向拆分成多个独立部分（独立节点），数据随之分布。

这种情况对报表的要求更高，除了要根据业务把报表分布到不同的业务模块外，如果还有跨业务统计的报表可能还要借助中间库，或者数据库中间件，以及其他技术。

这时的报表开发，单业务模块内理论上比较随意，按单体应用方式开发也没问题，但我仍强烈建议遵守不在数据库中实施复杂计算的开发规范；如果存在跨业务统计报表，则建议所有计算一定要在报表内部实现。

4、微服务
太复杂了不多解释。微服务下的报表开发要遵守上述 2 和 3 的规则，除此以外，不建议用 JAVA 实现报表数据计算（数据准备），因为报表变化会比较频繁，经常修改用 JAVA 开发的报表除了要跟业务代码紧耦合不好维护外，JAVA 不支持热切换，报表修改后要重启应用才能生效，这样对业务会产生不小的影响。

总结，不同系统扩展方式下的报表开发注意事项：
1、集群扩展

没啥需要注意，开心就好

2、水平拆分

• 不用存储过程
• 不写复杂 SQL

3、垂直拆分

• 不用存储过程
• 不写复杂 SQL
• 不用中间汇总表

4、微服务

• 不写存储过程
• 不写复杂 SQL
• 不用中间汇总表
• 不用 JAVA

参考资料：
1. 如何降低报表应用的耦合度
2. 互联网架构发展