TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: How do you manage shared code across microservices?

2 点作者 sruffatti将近 3 年前
We are moving off our legacy monolithic architecture to a microservice based architecture. We are about four years into the project and we have 200 distinct microservices.<p>When we first started out on this endeavor we created a parent POM called common-service. This POM declares dependencies such as Hibernate, Spring Boot, and some homegrown common libraries (the most important being a JAR that handles service discovery, rather than each service having to implement service discovery on their own).<p>Now that we have 200 services running in production, it is a difficult to roll out new versions of common-service for a variety of reasons - some teams don&#x27;t have the capacity, some teams prioritize business requirements over upgrades, etc.<p>How do you handle this in your organization? Do you have shared code across your microservices? Is it an anti-pattern to share code across microservices?<p>PS: We are going to start implementing Kubernetes. Kubernetes will require many changes to our common-service codebase so I figured I would see if anyone had any good ideas out there.<p>Thank you.

2 条评论

emrah将近 3 年前
The benefit of microservices is also its downfall. You need to maintain each one as a separate entity.<p>This is true whether you have &quot;microservices&quot; or &quot;libraries packaged and released individually&quot;.<p>I think when you need to introduce a breaking change, if versioning is not sufficient, you could create a separate library and upgrade each service slowly to it while still maintaining both libraries until all services have moved to the new one. This is more semantics than anything else but might be useful.<p>I&#x27;m afraid there is no silverbullet. I&#x27;d love to hear more suggestions too.
trcarney将近 3 年前
you could set the shared code a submodule in git. you can set this up so the submodule points to a specific commit. this way any changes to the shared library won&#x27;t break your other services. Or the company I work for uses artifactory to store shared libraries and we point our services to a specific version of the shared library. this way not all services need to be upgraded at once.