architecture - 在微服务之间共享代码和架构

Question

如果您在组织中寻求微服务架构，他们可以通过 zookeeper 共享配置或其等价物。但是，各种服务应该如何共享通用的数据库模式？共同常数？和常用实用程序？

一种方法是将所有微服务放在同一个代码存储库中，但这与微服务带来的解耦相矛盾......

另一种方法是让每个微服务完全独立，但这会导致每个微服务必须保存的单独数据库中出现代码重复和数据重复。

另一种方法是实现没有上下文\状态的功能微服务，但这通常是不现实的，并且会插入架构拥有一个中央集线器来维护上下文\状态以及来自\到它的大量流量。

在微服务之间共享代码和架构的可扩展、高效、实用且美观的方式是什么？

Answer 1

关于通用代码，最佳实践是使用打包系统。因此，如果您使用 Java，则使用 maven，如果您使用 Ruby，则使用 Gems，如果使用 python，则使用 pypi 等。理想情况下，打包系统几乎不会增加摩擦，因此您可能有一个(例如，git)公共(public)库存储库(或多个不同主题的公共(public)库)，并通过工件存储库(例如私有(private) maven/gems/pypi)发布其工件。然后在微服务中添加对所需库的依赖关系。因此代码重用很容易。在某些情况下，打包系统确实会增加一些摩擦(maven 就是其中之一)，因此人们可能更喜欢对所有内容使用单个 git 存储库以及多模块项目设置。这不像第一种方法那么干净，但效果也不错，而且还不错。其他选项是使用 git submodule(不太理想)或 git subtree(更好)，以便将源代码包含在单个“父”存储库中。

关于架构 - 如果您想按书本操作，那么每个微服务都有自己的数据库。他们不接触彼此的数据。这是一种非常模块化的方法，乍一看似乎给您的流程增加了一些摩擦，但最终我认为您会感谢我。它将允许对微服务进行快速迭代，例如，您可能希望将一项特定服务的一种数据库实现替换为另一种数据库实现。想象一下当您的所有服务都使用相同的数据库时执行此操作!祝你好运...但是，如果每个服务都使用自己的数据库，则该服务会正确抽象数据库(例如，它不接受 SQL 查询作为 API 调用；-))，那么将 mysql 更改为 Cassandra 突然变得可行。拥有完全隔离的数据库还有其他好处，例如负载和扩展、找出瓶颈、管理等。

简而言之 - 通用代码(实用程序、常量等) - 使用打包系统或某些源代码链接，例如 git-tree

数据库 - 你不碰我的，我也不碰你的。这是解决这个问题的更好方法。

HTH，兰。