微服务模式系列之十：共享数据库
译者自序：
熟悉我的朋友都知道，我很不喜欢翻译东西，因为在两种语言的思维方式之间做频繁切换对我来说是件很痛苦的事情。但是这次不一样，公司和同事的大力支持降低了我的痛苦指数，让我能够坚持把Chris Richardson的微服务模式系列文章翻译完，今天发布第十篇——《共享数据库》。
译者评论：
微服务模式中最为头疼的问题就是数据问题 —— 因为数据会散布在多个微服务之间，这通常意味着数据被分散到多个数据库中，这时微服务必须自行保证跨微服务的数据一致性，而无法利用数据库本身的机制解决。随之而来的是微服务滚动升级时数据库同步升级的问题。
本系列文章的第九篇和第十篇会初步的呈现这个问题，之后的几篇文章会介绍问题的解决方案，但是这些解决方案实现起来比较复杂、学习门槛较高，远不够完美。在我们今后的工作中，也会对这部分问题做较大的投入，致力在实践中总结出更为完善的方案。
背景
如果用微服务模式开发网店应用，那么大部分的服务都需要用某种数据库保存数据。例如，订单服务存储订单信息，客户服务存储客户信息。
问题
在微服务应用中，应该采用什么数据库架构？
需求
- 服务必须松耦合，以确保可以独立进行开发，部署和扩展。
- 一些业务事务必须在多个服务之间保持数据一致性。例如，下单用例必须保证新的订单不会超过客户的信用限额。其他业务事务必须更新多个服务的数据。
- 一些业务事务需要查询多个服务的数据。例如，查询可用信用必须查询客户信息以获取客户的信用限额，并查询订单信息以获取该客户的全部未结订单（才可以得到该客户的剩余可用信用）。
- 一些查询必须Join来自多个服务的数据。例如，查询某一特点区域的客户和这些客户的近期订单，需要Join来自客户信息服务和订单信息服务的数据。
- 为进行扩展，数据库有时必须进行复制和Sharding。参见ScaleCube。
- 不同的服务有不同的数据存储需求。对于某些服务，关系型数据库就是最好的选择。其他一些服务可能会需要NoSQL数据库，如善于存储复杂、非结构化数据的MongoDB，或者能够有效存储和查询图数据的Neo4J。
案例
订单服务和客户服务可自由访问对方的表。例如，订单服务可以用下列ACID事务以确保新订单不会超过客户的信用限额。
当同一客户同时下了两个不同的订单，数据库要确保订单不超过该客户的信用限额。
结果
该模式有以下优势：
- 开发者可以用熟悉和简洁的ACID事务来保证数据的一致性
- 单一数据库易于操作
该模式有以下劣势：
- 开发时间耦合——例如，一个负责订单服务的开发者需要和其他服务的开发者协调模式发生的变化，因为其他服务也要访问同样的表。这种耦合和额外的协调工作会拖延开发工作的进展。
- 运行时间耦合——由于所有的服务访问同一数据库，他们便可能会互相干扰。例如，如果长时间运行的客户服务事务锁定了订单表，那么订单服务就会被阻塞。
- 单一数据库可能满足不了所有服务的数据存储和访问需求。
相关模式
- 独享数据库是备选方案
微服务模式系列文章持续连载，欢迎保持关注此公众号。
相关文章链接：
原文链接：http://microservices.io/patterns/data/shared-database.html
关于译者：
宋潇男
EAII-企业架构创新研究院 专家委员
现任普元云计算架构师，曾在华为云计算负责产品与解决方案的规划和管理工作 。曾负责国家电网第一代云资源管理平台以及中国银联基于OpenStack的金融云的技术方案、架构设计和技术原型工作。
原著作者
Chris Richardson
世界十大软件架构师之一，《POJOS IN ACTION》一书的作者。他的研究领域包括Spring、Scala、微服务架构设计、NoSQL数据库、分布式数据库、分布式数据管理、事件驱动的应用编程等。