微服务之间共享数据库易犯的错误

　　欢迎各位阅读本篇文章，本篇文章讲述了微服务之间共享数据库易犯的错误，数据库(Database)是按照 数据结构来组织、 存储和管理数据的仓库。课课家教育平台提醒各位：本篇文章纯干货~因此大家一定要认真阅读本篇文章哦!

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

　　几年前，我是一个团队的首席开发人员，该团队为客户端开发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来开启部署之旅的时候就对你有所启示。

　　知识分享：数据库结构

　　数据库的基本结构分三个层次，反映了观察数据库的三种不同角度。

　　以 内模式为 框架所组成的数据库叫做物理数据库;以 概念模式为框架所组成的数据叫概念数据库;以 外模式为框架所组成的数据库叫用户数据库。

　　⑴ 物理 数据层。

　　它是数据库的最内层，是物理存贮设备上实际存储的数据的集合。这些数据是 原始数据，是用户加工的对象，由内部模式描述的 指令操作处理的位串、字符和字组成。

　　⑵ 概念 数据层。

　　它是数据库的中间一层，是数据库的整体 逻辑表示。指出了每个数据的逻辑定义及数据间的逻辑联系，是存贮记录的集合。它所涉及的是数据库所有对象的逻辑关系，而不是它们的物理情况，是 数据库管理员概念下的数据库。

　　⑶ 用户 数据层。

　　它是用户所看到和使用的数据库，表示了一个或一些特定用户使用的数据集合，即 逻辑记录的集合。

　　数据库不同层次之间的联系是通过 映射进行转换的。

　　小结：在信息化社会，充分有效地管理和利用各类信息资源，是进行科学研究和决策管理的前提条件。当然如果大家还想了解更多方面的详细内容的话呢，不妨关注课课家教育平台，在这里你肯定会有意想不到的收获的!