未來系統擴充套件，報表怎麼辦？

系統擴充套件會有幾種情況，不同的做法報表的應對策略也不同。

1、叢集
把單體應用部署到叢集環境，即每個節點都有一個完整的單體應用。透過負載均衡技術將使用者請求路由到不同節點上從而分擔併發壓力。
這種系統擴充套件方式很常見，目的是解決高併發下的請求響應效率問題，但無法改善大資料量時單個任務的響應效率。

這種情況下，報表開發無需特殊注意，按照單體應用的方式開發，應用叢集部署時隨應用部署即可。

2、水平拆分
為了解決大資料量時的訪問效率問題，可以透過水平拆分來擴充套件系統，常見的做法是資料層分表分庫、應用層採用叢集部署。

這時的報表開發要尤其注意，首先不能使用儲存過程了（其實單體應用我也不建議使用資料庫儲存過程了，參考資料： ），另外分表分庫後做 join 會比較困難，所以最好就不要寫複雜 SQL 了（可能也寫不出來），維護會比較麻煩，替代方案：

3、垂直拆分
面對複雜業務和大資料量還可以進行垂直拆分，梳理業務把業務縱向拆分成多個獨立部分（獨立節點），資料隨之分佈。

這種情況對報表的要求更高，除了要根據業務把報表分佈到不同的業務模組外，如果還有跨業務統計的報表可能還要藉助中間庫，或者資料庫中介軟體，以及其他技術。

這時的報表開發，單業務模組內理論上比較隨意，按單體應用方式開發也沒問題，但我仍強烈建議遵守 不在資料庫中實施複雜計算的開發規範；如果存在跨業務統計報表，則建議所有計算一定要在報表內部實現。

4、微服務
太複雜了不多解釋。微服務下的報表開發要遵守上述 2 和 3 的規則，除此以外，不建議用 JAVA 實現報表資料計算（資料準備），因為報表變化會比較頻繁，經常修改用 JAVA 開發的報表除了要跟業務程式碼緊耦合不好維護外，JAVA 不支援熱切換，報表修改後要重啟應用才能生效，這樣對業務會產生不小的影響。

總結，不同系統擴充套件方式下的報表開發注意事項：
1、叢集擴充套件

沒啥需要注意，開心就好

2、水平拆分

• 不用儲存過程
• 不寫複雜 SQL

3、垂直拆分

• 不用儲存過程
• 不寫複雜 SQL
• 不用中間彙總表

4、微服務

• 不寫儲存過程
• 不寫複雜 SQL
• 不用中間彙總表
• 不用 JAVA

參考資料：
1.
2. 網際網路架構發展