微服务下的数据架构

LD is tigger forever，CG are not brothers forever， throw the pot and shine forever.
Modesty is not false, solid is not naive, treacherous but not deceitful, stay with good people, and stay away from poor people.
talk is cheap, show others the code and KPI， Keep progress，make a better result.
Survive during the day and develop at night。

目录

概 述

一库一服还是一库多服
无论是单体应用，还是微服务应用，有一点是肯定的：应用的各个模块之间都需要进行较为频繁的通信，通过一起协同合作，来实现应用的整体价值。在单体应用中，这种通信是通过方法调用来完成的。在微服务中，则通过 API 调用来完成。这些模块或者服务间调用，大部分时候是为了共享数据。 共享数据最贱的方式当然就是采用一种共享数据库的模式，也就是单体应用常用的方式 - 应用可以有多个系统模块，但一般都是只有一个数据库。如下图左边，3 个微服务模块，后面共享一个数据库，简称一库多服务：
6.jpg

这种架构模式通常会被认为是微服务架构下的反范式，它的问题在于：
单点故障：一个数据库倒下，整批服务全部停止。何来的服务独立性？
数据在同一个地方，会给贪图方便的开发或者 DBA 工程师编写很多数据间高度依赖的程序或者工具；
无法针对某一个服务进行精准优化或扩展，如上文所讲的 Snapchat 的例子。

所以一般推荐的做法，是为每一个微服务准备一个单独的数据库，也即一库一服（database per service）模式。如上图右侧所示。这种模式更加适合微服务架构 - 它满足每一个服务是独立开发、独立部署、独立扩展的特性。当需要对一个服务进行升级或者数据架构改动的时候，无须影响到其他的服务。需要对某个服务进行扩展的时候，也可以手术式的对某一个服务进行局部扩容。另外，如果某些服务对数据库有特殊的需求，这种模式也为下文所讲的混合持久化（Polyglot Persistence）提供了可能性。

小结

数据库模式。

参考资料和推荐阅读

1.链接: 参考资料.