为你的微服务选择合适的数据库

微服务架构的应用具有很好的扩展性，因此似乎微服务并不挑数据库，在微服务中使用哪种数据库问题都不是很大。事实真的如此吗？也许对于一些研发能力很强的队伍来说，为微服务选择数据库是很容易的事情，因为选择的数据库无论存在哪方面的缺陷，他们都有办法通过应用方面的优化去解决它。而对于一些普通的研发队伍来说，有时候还真的搞不定。前几天我说过的那个用了上百条OGG复制链路来复制数据库的案例就是一个很好的佐证。 很多企业刚刚转向微服务架构的时候也是交了大量的学费的，很多企业的微服务架构转型是：“开发一时爽，运维两眼泪”。实际上很多设计和开发的缺陷最后都是让运维来想办法填坑的。与传统的集中架构不同，微服务的坑，运维填起来难度大多了。如果微服务应用将一个大数据库拆分成多个小型的领域数据库，那么一条重要的原则就是要永远确保这些数据库是小型数据库，其数据量的增长是缓慢的，随着每年业务的增长率稍微增长一点点的，历史数据一定是能够及时归档的。这样的小型数据库才会在长期运行的时间里保证较好的性能，不会给运维人员带来太大的负担。 从另外一个角度来讲，微服务的数据应该存储到适当的数据库中，而不是在没有掌握数据存取特点的情况下，随意选择一个数据库。目前数据库可选择的种类太多了，以阿里云等云厂商为例，他们就已经为微服务开发者提供了眼花缭乱的选项。

不同的应用场景选择不同的数据库产品，才能让项目今后的发展路径更为顺畅。这么多的数据库产品，我们该如何来选择呢？虽然微应用已经弱化了数据库的很多特性，大大减少了跨服务的数据融合计算，不过针对不同类型的微服务，我们仍然需要十分谨慎的来选择数据库产品。 我们该如何为自己的微服务选择适当的数据库产品呢？这就需要从几个方面去考虑了。首先要考虑的是你的微服务中对数据的访问方式。选择数据库的最重要的因素是你的查询的模式是什么样的。如果你只需要存储某些键值，那么KV数据库可能是比较好的选择，比如你可以选择redis；如果你的应用基本上都是基于主键查询，附加一些主键关联的其他字段，那么一些宽列数据库可能很适合你的微服务，比如Cassandra；如果你的应用主要是访问一些单表中的数据，不过检索条件可能会比较丰富，模式不是十分固定，那么使用文档数据库可能比较好，Mongodb、CouchDB等可能比较对你的胃口；如果你的应用经常有一些多表关联的关系型访问，那么关系型数据库，比如PostgreSQL、Mysql等可能更适合；如果你的应用主要是根据主键做模糊查询，全文检索，那么ES可能会优于其他数据库。 如果有一个场景有多种数据库适合，那么可以根据数据一致性等要求来做出进一步的筛选，比如你的场景中MYSQL和MONGODB都比较适合，那么如果在要求强一致性的情况下，倾向于选择MYSQL，否则可以考虑MONGODB。 实际上，在你的应用系统中，不同的微服务可以选择不同类型的数据库，从而最大限度的优化数据访问。比如你的有很多视频要存储，那么选择S3对象存储来存储视频肯定比把视频存储到关系型数据库的LOB字段中要好得多，在关系型数据库中只需要保存对象的ID就可以了。 在一个应用系统中使用多种数据库也不是多多益善，数据库种类太多会导致系统架构变得臃肿，运维的成本也会大大增加。因此适当的选择几种数据库才是较好的设计方案。这种情况下，一些多模数据库就比较具有优势了。比如说在系统中以RDBMS为主，稍微有一些JSON数据存储、还有少量应用会使用一些时序数据和一些GIS数据，那么选择PostgreSQL就可以满足这些综合要求。本社PG就是一种十分典型的关系型数据库，本身也有一些文档数据库的支持，同时Timescaledb插件可以支持时序数据的存取，PostGIS可以支持空间数据的存储。 阿里云上的Lindorm也提供了对HBase/Cassandra、OpenTSDB、Solr、SQL、HDFS的多模数据支持，如果我们的应用中需要多模数据，那么选择这种数据库也可以大大简化我们的系统架构。 实际上为微服务选择数据库产品不仅仅要考虑这些因素，开发团队的经验、运维能力、成本等因素也是要考虑的。因为微服务架构的特点，我们通过领域建模会将一个大型系统的数据拆分为多个不同的子领域，因此高并发支持能力，性能，大数据量下的复杂SQL性能等方面需要考虑的因素相对少一些。不过对于一些稍微极端一些的应用场景，可能我们需要考虑的会更为复杂一些。 另外一点就是聚合计算的问题，任何应用都有聚合计算的问题，特别是一些实时聚合计算的需求，我们也必须满足。因此在领域建模将数据拆分之后我们依然需要将这些数据汇聚起来进行计算。虽然我们也可以使用ShardingSphere这样的数据库网关来实现一定的聚合计算，不过大数据量的分布式环境的聚合计算在性能上往往会遇到一些问题。解决此类问题的方法不外乎两个，一个是在微服务层面，对明细数据进行准实时汇总，这样聚合计算不需要针对明细数据进行。另外一种方法就是使用ODS或者数据中台作为聚合计算的平台，从而减轻微服务数据层的负担。 原本一个大型数据库拆分为很多个小库后会不会给运维带来压力呢？答案是肯定的，因此微服务的架构师应该对这些小型数据库做一个很好的架构设计，包括高可用、灾备，数据归档，数据自动清理，这些工作运维人员可以参与设计，但是必须在应用中实现自动化的管理，否则这一堆堆的小库上来，运维人员平时要是去监控巡检，平时也没啥事，还浪费时间，一旦出了问题，还不太好处置。 如果你的应用是托管在公有云上的，并且你的每个库的容量、负载都可以比较好的控制，那么采购公有云的RDS是比较省事的做法，不过公有云的特点是入门很便宜，一旦你的库变大了，服务要升级了，那么价钱绝对不是简单的乘以某个倍数的问题。公有云上，大的主机和数据库服务价格会有一个跳跃式的提升，应用架构师要十分注意这一点。私有云对费用相对没有那么敏感，使用私有云的RDS服务可以大大的降低运维的压力。在这方面，微服务的架构师一定要先和云平台部门做好沟通。 如果你不希望管理碎片化的小型数据库（无论是RDS还是运行在容器中的数据库），那么带有多租户、多模存储能力的分布式数据库也许是你喜欢的选择。运维一个大型的云数据库可能比运维几十个小数据库更合你的胃口。这种选择也是合适的，只要和你的企业的整体IT政策与IT基础架构相吻合，那也是不错的选择。