How to distribute a database among microservices

在为相对复杂的企业域构建微服务时，我们需要找到在这个域中不同责任的边界。在每个边界中，我们会创建领域模型，这个模型是针对业务责任所设计的，并反映了这种业务责任。针对每个边界的数据模型会由同一个边界中的领域模型来驱动。采用DDD的方式我们能够找到这些边界，并会为每个边界创建一个 有界上下文（bounded context） ，每个上下文将会成为一个微服务。

http://www.tuicool.com/articles/UNRZ3mm

【编者的话】如何在微服务之间共享使用数据库？本文介绍了一个该领域很容易犯错的架构问题，并且提出了解决方案和反思。

几年前，我是一个团队的首席开发人员，该团队为客户端开发Java web应用程序。本文里我们称之为“项目A”。我们在客户现场构建web应用，还有其他团队在相关项目上共同工作。因为我们在项目早期沟通合作一直很愉快深入，所以会定期在团队间交换软件的架构思想。

一天，一个新项目（项目B）启动了。该项目会由另外一个团队完成。我认为在这个新项目中我们也能有所贡献，我们将项目A的记录用户，角色和权限的通用认证的数据库schema共享给了项目B。最终，这两个项目都是使用相同用户数据库的内部web应用程序。对了，还忘记说一点，这些应用程序没有中央的用户数据库 -- 每个新项目都是从头开始的。我们发现通过共享已有的基础架构和最佳实践，不仅仅可以节省开发时间，而且还能够节省很多客户支持的时间，因为他们不需要处理单独的用户目录了。

项目进展顺利，第二个项目使用单独的数据库用户账号访问我们的数据库表，这样两个项目可以隔离开从而避免混乱。

一段时间之后。。。

毕竟存储用户，角色和权限不是什么难事。大概一年后，我们计划开发项目A的新版本。我们都很兴奋，因为有机会可以将项目A中工作不太好的地方改进，同时保留好的功能。我们也改进了一些项目A里工作得还可以的部分 -- 其中，包括改进了存储用户，角色和权限的数据库表的schema。老实说，当时根本没有想到会影响项目B。

当然，很快项目B就崩溃了。我们的错误之处在于给了项目B直接访问数据库的权限。不仅仅就现在的标准而言，就算是根据以前的标准，正确的决定也是去创建一个单独的认证服务，来共享通用的API，而不是直接共享数据库访问。

还有更多的。。。

因此，我们犯了一个严重的架构错误，但是这里还有另外一个问题。具有讽刺意味的是，项目B使用的人不多。当时要求项目B的团队都没怎么使用项目B。这个项目就一直停滞着，可以使用，但一直没有正式启用。因此在两周之后才有人发现项目B不工作了。

 

在第一个可怜的用户报告出问题的时候，我们的开发人员已经到其他项目上工作去了。在做问题定位分析的时候，我们检查了错误日志，尝试找出是什么问题。现在来看，我们当时没有规划精细的监控方案，能够自动监测到应用程序的问题，这也是失误决策的一部分。

虽然这次事故听上去很古老，但是我真的希望大家能够从中学习到经验教训。

一定要确保通过稳定的API来访问数据库，从而将简单的数据库转变为服务，也使得共享使用更为容易。
并且确保正确监控应用程序和服务。
围绕API构建的环境会长期保持基础架构的动态性。监控则能确保能够有效控制日益增长的复杂度。

我期望这篇文章的问题能够在你在Eclipse IDE里打开File菜单，选择Export as .war来开启部署之旅的时候就对你有所启示。

原文链接： How to distribute a database among microservices