使用单一代码仓库管理微服务应用

深碍√TFBOYSˉ_ 2023-10-02 10:39 10阅读 0赞

如何组织源代码，是实现微服务架构中的一个现实问题。由于每个微服务相对独立，一种最直接的做法是为每个微服务使用各自独立的代码仓库。这种做法的好处很明显，就是从源头开始对微服务进行隔离。每个微服务有各自独立的持续集成和部署的流程。

每个微服务使用独立代码仓库的做法，会带来比较大的管理开销，尤其是微服务之间存在共享代码的情况。共享代码的存在，在很多情况下是无法避免的。比如，很多微服务都需要使用的公共库。当共享代码发生改变时，所有使用这些公共代码的微服务，都可能需要进行相应的修改。如何确保对公共代码的修改，能够在多个微服务中保持同步，是一个比较复杂的问题。

对于中小规模的微服务应用来说，另外一种比较现实的做法是使用单一的代码仓库。使用单一的代码库可以方便的管理共享代码。当需要对共享代码进行修改时，对共享代码自身的改动，以及对受影响的微服务的修改，都可以在同一个代码提交（commit）中完成。这非常有利于追踪代码的变化。使用单一代码库的弊端也有一些。由于只有一个代码库，当修改某个微服务的代码时，也会同时构建和部署其他不相关的微服务。

下面以我的《Quarkus云原生微服务开发实战》一书的实战应用来进行说明。该实战实用是一个 Maven 项目。最简单的组织代码的方式是把共享代码和微服务组织成 Maven 中的多个模块。如下图所示，所有模块以扁平化的方式来组织。

![04bcbea6c2d143566da4286b7f94e74c.png][]

在主模块的 `pom.xml` 文件中，子模块的声明如下所示。

<modules>
      <module>restaurant-service-api</module>
      <module>restaurant-service</module>
      <module>common</module>
      <module>file-upload-service</module>
      <module>restaurant-data-loader</module>
      <module>restaurant-search-service</module>
      <module>restaurant-search-service-api</module>
      <module>order-service-api</module>
      <module>order-service</module>
      <module>common-db-entity</module>
      <module>common-event-api</module>
      <module>common-event-producer</module>
      <module>common-event-consumer</module>
      <module>delivery-service</module>
      <module>delivery-service-api</module>
      <module>rider-service-api</module>
      <module>rider-service</module>
      <module>common-json</module>
      <module>common-test</module>
      <module>mobile-api-graphql</module>
    </modules>

这种扁平化的方式虽然简单，但是不容易看出来每个模块的职责。可以进一步优化为分层结构。把微服务应用的模块进行分类，并指定不同的子目录，如下表所示。

<table> 
 <thead> 
  <tr> 
   <th>分类</th> 
   <th>子目录</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>公共库</td> 
   <td><code>lib</code></td> 
  </tr> 
  <tr> 
   <td>微服务 API</td> 
   <td><code>api</code></td> 
  </tr> 
  <tr> 
   <td>微服务的实现</td> 
   <td><code>service</code></td> 
  </tr> 
  <tr> 
   <td>与开发和管理相关的工具</td> 
   <td><code>tool</code></td> 
  </tr> 
 </tbody> 
</table>

通过这个分类，可以把应用的模块组织到对应的目录中。下图是修改之后的目录结构。从中可以看到，修改之后的目录结构层次清晰，更加方便组织和管理。

![10e728b40c38592bad4e4a55e04e6406.png][]

`pom.xml`中的模块声明如下所示。

<modules>
      <module>lib/common/base</module>
      <module>lib/common/json</module>
      <module>lib/common/test</module>
      <module>lib/common/grpc</module>
      <module>lib/db/entity</module>
      <module>lib/event/api</module>
      <module>lib/event/producer</module>
      <module>lib/event/consumer</module>
      <module>api/restaurant-service-api</module>
      <module>api/order-service-api</module>
      <module>api/restaurant-search-service-api</module>
      <module>api/delivery-service-api</module>
      <module>api/rider-service-api</module>
      <module>service/restaurant-service</module>
      <module>service/file-upload-service</module>
      <module>service/restaurant-search-service</module>
      <module>service/order-service</module>
      <module>service/delivery-service</module>
      <module>service/rider-service</module>
      <module>service/mobile-api-graphql</module>
      <module>tool/restaurant-data-loader</module>
    </modules>

每个 Maven 模块的名称都遵循一定的命名规范，如下图所示。

![9d5c7d0192e640c4b5564fcd9c8b45d5.png][]

对于一个微服务架构的应用来说，推荐从单一代码仓库开始。在很多时候，这样简单的组织方式就足够好了。

推一下我的新书《Quarkus云原生微服务开发实战》，对Quarkus感兴趣的朋友可以关注。在京东上搜索书名即可。

![59e1339730789791e58d7e3da1c0dfa4.png][]

[04bcbea6c2d143566da4286b7f94e74c.png]: https://img-blog.csdnimg.cn/img_convert/04bcbea6c2d143566da4286b7f94e74c.png
[10e728b40c38592bad4e4a55e04e6406.png]: https://img-blog.csdnimg.cn/img_convert/10e728b40c38592bad4e4a55e04e6406.png
[9d5c7d0192e640c4b5564fcd9c8b45d5.png]: https://img-blog.csdnimg.cn/img_convert/9d5c7d0192e640c4b5564fcd9c8b45d5.png
[59e1339730789791e58d7e3da1c0dfa4.png]: https://img-blog.csdnimg.cn/img_convert/59e1339730789791e58d7e3da1c0dfa4.png