未来系统扩展,报表怎么办?

 

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

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

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

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

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

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

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

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

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

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

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

没啥需要注意,开心就好

2、水平拆分

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

3、垂直拆分

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

4、微服务

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

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