爲什麼
一方面是數據庫服務器的計算能力是有限的，另一個很重要的方面是一般數據庫的分區容錯性要比微服務要差很多。微服務可以很容易的水平擴展。但是數據庫水平擴展一般都比較麻煩，且容易出問題，尤其是SQL類的數據庫。下面對數據庫做一個簡單的分析。
SQL 類數據庫： 像MYSQL、PostSql等數據庫，都是CA類型（CAP理論）的數據，如果要對它們進行水平擴展，往往都要對系統架構做出很大的調整。所以儘量節省數據庫服務的計算壓力，當然這個時候會增在傳輸數據的帶寬壓力。
NOSQL 類非內存數據庫： MongoDB、Cassandra、InfluxDB、Hadoop HBase等。這個就比較複雜了，要根據各自的特點來分析了，MongoDB自帶了很多高效的函數，比如aggregate，在內存充足，建議使用MongoDB自帶函數。像Cassandra ，它讀寫性能高，那就只用來做存儲，所有的計算都交給服務層或者大數據分析的工具。Hadoop HBase 適合海量數據存儲，複雜的計算還是要藉助大數據工具的。InfluxDB 是專門用於時序數據統計的，對於監控數據的統計，可以直接使用它的提供的函數來計算。
NOSQL 內存數據庫：Redis、Ignite。內存數據庫，一般不太適合做計算，已嚴重影響性能，就像Redis，即便提供了HyperLogLogs和布隆過濾器這樣的快速概率性統計函數，但是在使用的時候都是非常注意的，使用不當會嚴重影響 Reidis 的讀寫場景。
NewSQL數據庫：TiDB，在這種分佈式數據庫時，最好做簡單的讀寫操作。對於計算量比較到的情況 請Spark 等大數據分析工具，又或者服務層的分佈式定時任務來計算。總之儘量避免在數據庫上做大量的計算操作。
一些建議
（1）如果不是分頁 查詢 ，優先使用Java 的Stream 對查詢出的列表 進行排序 、分組統計、數據格式化、拼接字段等計算 但是count 、sum、 distinct 等簡單的函數還是可以使用MySQL的，這些簡單的函數效率比較高，且可以降低數據庫與微服務之間數據傳輸帶寬壓力。
（2）如果數據量比較大(比如100M以內的數據),且需要實時計算的情況下，比如實時統計報表、彙總分析、聚合計算等，可以使用 Spark 或者Flink 等大數據工具提供的微批處理
（3）如果實時性要求不高，且數據量比較大，GB或者TB級的數據，最好使用離線數據庫來分析數據，這就是屬於OLAP的場景了。
（4）NOSQL 數據庫都有自己的特點，根據各自的特點來判斷。