怎样在微服务之间共享使用数据库?本文介绍了一个该领域非常容易犯错的架构问题，且提出了解决方案和反思。几年前，我是一个团队的首席开发人员，该团队为客户端开发Java web应用程序。这个文章里我们称之为“项目A”。我们在客户现场构建web应用，还有其他团队在相关项目上共同工作。由于我们在项目早期沟通合作一直很愉快深入，因此会定期在团队间交换软件的架构思想。

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

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

　　一段时间之后。。。

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

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

　　还有更多的。。。

　　因此，我们犯了一个严重的架构错误，但这里还有另外一个问题。具有讽刺意味的是，项目B使用的人不多。当时要求项目B的团队都没怎么使用项目B。这个项目就一直停滞着，可使用，但是一直没正式启用。因此在两周之后才有人发现项目B不工作了。在第一个可怜的用户报告出问题时，我们的开发人员已到其他项目上工作去了。在做问题定位分析时，我们检查了错误日志，尝试找出是什么问题。现在来看，我们当时没规划精细的监控方案，能自动监测到应用程序的问题，这也是失误决策的一部分。

　　虽然这次事故听上去很古老，但我真的希望大家能从中学习到经验教训。一定要确保通过稳定的API来访问数据库，从而将简单的数据库转变为服务，也使得共享使用更为容易。且确保正确监控应用程序和服务。围绕API构建的环境会长期保持基础架构的动态性。监控则能够确保有效控制日益增长的复杂度。