Crunch团队分享SpringCloud微服务的使用经验

从单体应用程序迁移到微服务并不容易，尤其是在部署困难时，因为你还没有充分认识到您的微服务应该有多大。你怎么避免一堆“迷你”巨石单体呢？

这些是帮助我们管理几十个微服务的一些关键原则。我们相信它们广泛适用，并将在可预见的未来为我们服务。

不断重构

我们编写软件以满足客户不断变化的需求，而不仅仅是完成项目。因此，一旦项目结束，或者让我们每隔几年从头开始重新开始，我们不是收集灰尘做维护，而是通过不断刷新它来保持其商业价值和我们的投资。这意味着更新其技术：版本和框架，以及优化和错误修复。通过一些服务，这很容易。一旦您为每个开发人员超过一项服务，您需要一个新计划; 每个开发人员需要2、5或10个，您开始需要一些组织和编排。

良好的自动化测试是最低限度的：坚固的单元，集成和各种黑盒测试将使您有信心追求持续交付，并且这种信心对您的开发团队具有积极的感染力。

更安全的部署可以加快部署速度，缩短反馈循环。反过来，这些鼓励小型部署：每个功能区域一个而不是每个项目一个，允许更多的专业化，更少的重复，更清晰的架构，以及这些组件在您的部门中可能更高的可重用性。

一致性和惯例

连续重构是有效的，但如果没有一致性，则可能会造成浪费。管理框架和依赖关系的多个不同版本的代价很高，并且这些差异不太可能是有充分理由的。

我们在 Java 8 / Kotlin和Maven中使用Spring Boot ，我们最好的决定之一是引入我们自己的“父”POM。这让我们集中了Spring Boot版本、内部依赖项的版本和插件配置，生成了我们可以应用于所有服务的单个版本号，以及使一致性可测量的度量。

然后，我们通过引入少量的“入门POM”来引入我们服务所涵盖的主要技术领域，例如使用 SQL 数据库，使用Redis，使用JUnit 5.我们不仅仅使用单个SpringBoot启动器替换多个依赖项。减少了我们的POM的规模和复杂性，但它整理了它们并帮助区分真正的技术选择和惯例。

最后，我们采用了Spring Cloud Config。这使我们能够将数百个单独的应用程序属性移动到单个Git存储库中，以实现最大可见性。它允许我们为所有当前和未来的服务构建和策划一组共享的默认属性，因此典型的服务只需要少量的自定义值。这些在服务启动时解决，无论是在桌面上运行，还是在测试中运行，还是在生产中运行。

在新系统中，一致性是一个奖励，但很可能是紧急的，只有成熟。然而，一旦达到一定的规模，这一点至关重要，而迅速发展的技术债务就是时候解决它了。

生成和验证

只有在易于理解和无误应用的情况下，约定才有用。一致性很好，但识别不一致的速度有多快？即使具有良好的黑盒测试覆盖率，快速部署以及在几分钟内回滚不良部署的能力，在最后时刻找到我们的问题也是浪费。我们应该尽可能早地在构建/发布周期中检测可避免的问题。

为此，我们使用内部Maven插件。在那些定制很少的领域，我们让它在编译时从模板生成服务配置。例如，记录配置和Helm图表。由于它可以完全看到正在构建的服务的代码和依赖关系 - 更不用说使用 ASM 的字节码 - 它允许我们在编译时强制执行我们自己的约定，在它们可以造成任何伤害之前查找违规。这些自定义静态分析规则可以为我们的团队提供比IDE提供的通用规则更多的价值，这些规则对我们的基础架构或部署要求一无所知。

无论我们多聪明，开发人员都会犯错误。在Crunch中帮助我们的是从编译时到部署时间，从服务引导到启动，最后在运行时，我们自己的代码 - 而不是通用代码 - 正在努力验证我们提供的内容。

发布列车

在过去的日子里，我们尝试逐个项目地维护个人服务和库版本。这些版本变得毫无意义：它们没有描述成熟度或功能，是主观的，很少被维护。相比之下，在2018年，版本突然变得有意义。

我们称之为发布列车的愿望和能力是保留大量服务，所有服务都涵盖不同的功能区域，或多或少在技术上保持一致。当Spring Boot版本发生变化，新的Java版本发布，或正在试用新的创新时，我们将尽快通过选择一个或两个服务作为我们的“豚鼠”进行测试。我们将尝试通过共享库，配置更改和自动生成来提供升级，例如通过我们的Maven插件，最少的服务代码更改，将最终结果汇总到一个新的Parent POM版本中。

在许多情况下，单个版本号更改足以让其他服务跟随领导者，但即使需要更改代码，行程方向也很明确。我们已经扩展了这种方法，使库和实用程序成为相同的统一版本控制方案。与此方法提供的清晰度和可测量性相比，可能会丢失任何微妙的差异，而个人编号则会变得苍白。

结论

无论你忙于其他项目，都不要让你的软件在藤蔓上枯萎。通过正确的测试和部署基础架构，您可以使维护变得愉快，而不是繁琐。通过不断行动不断偿还技术债务，经常投入时间和精力可以带来回报。