代码共享技巧

共享工程的使用将会在共享工程中的公共源代码和每个服务工程之间形成编译期的绑定。虽然这使得软件开发和改动变得简单，但它是我最不喜欢的共享技巧，因为它在运行时会引入潜在的问题，使得应用程序变得不那么健壮。共享工程技巧的主要问题是沟通和控制，我们很难知道共享模块的变动及其原因，也很难控制我们服务是否需要特定的更改。想象一下，当你正准备发布你的微服务时，却发现有人对共享模块作了重大修改，从而迫使你不得不对服务代码作改动和重新测试，然后才能进行部署。

如果你想要共享代码，更好的方式是使用共享函数库（例如 .NET assembly 或者 JAR 文件）。但这种方式使得开发更加困难，因为任何对共享库中模块的改动，开发人员都必须首先打包函数库，然后重启服务，最后重新测试。然而共享库的优点是我们可以对库进行版本控制，从而更好的控制服务的部署和运行时的行为。如果共享库作了修改和版本化，那么服务的所有者可以决定何时合并该修改到服务中。

微服务架构中常见的第三种技巧是违反 DRY（Don't Repeat Yourself）原则，它在需要特定功能的所有服务中复制共享模块。虽然这种复制技术有风险，但它避免了依赖共享，并保留了服务的边界上下文。当复制的共享模块需要改动时，尤其是修复某个缺陷时，这种技巧就会出现问题。这种情况下，所有服务都要进行修改。因此这种技巧只对非常稳定的，几乎不会再改动的共享模块有用。

有时可能使用的第四种技巧是服务合并。假设两个或三个服务共享一部分相同的代码，而这些公共模块需要经常改动。由于这几个服务在公共模块改动时也都要跟着测试和部署，所以你可以把这些服务和公共模块整合到一个服务中，从而移除依赖的库。

关于共享库的一个建议是避免把所有共享的代码合并成单一的共享库，例如 common.jar。使用 common.jar 你很难知道你的服务是否需要集成共享代码以及何时使用。更好的方法是把共享库拆分成具有独立上下文的多个库。例如创建基于上下文的 security.jar，persistence.jar 和 dateutils.jar 等。这能够把不经常改变的代码和频繁改动的代码分离开，从而更容易认清每次更改的上下文，以及决定是否要立即把更改的内容集成到我们的服务中。