微服务:共享库与代码重复

常见逻辑:基本上，这里应用相同的规则.但是，通常使用一些第三方库来解决常见的微服务问题，例如超时和重试.我还可以建议看一下service mesh实现，例如istio和linkerd.服务网格将这些问题的可能性带到了基础架构层，因此您可以专注于编写业务逻辑.Similar questions were asked a few times, but as every use-case can be different I thought it worth to ask it again with the specific case I'm facing with.So, we are developing micro-services using .netCore. Let's call these services ServiceA, ServiceB, ServiceC.Common entitiesIf ServiceA calls ServiceC, then ServiceC responds with a JSON content which can be serialized into ResponseC object.This means, that both ServiceA and ServiceC should know ResponseC class.At this point I see two possibilities. ResponseC class can be in a shared library and both ServiceA and ServiceC should have a reference to this shared library.However I read statements like do not share libraries among micro-services. This leads to an other possible solution. Let's introduce ResponseC class in both micro-services, but then somehow I find this a bit against maintainability, because of code duplication.Common logicBoth ServiceA and ServiceB communicates with ServiceC. When communicating with ServiceC we intend to have some policy regarding read and connection timeout and regarding the maximum number of retries. These values are configurable and there is also some common parts in the retry logic to be able to read the relevant values from the configuration file and to wrap the http calls. The question is pretty much the same like in the previous case, because I either put these classes into a shared library or I basically introduce the same classes in both ServiceA and ServiceB. These classes are quite simple and generic, so at the moment I cannot imagine, that these classes will change frequently.So the question is, that what is better in these cases, duplicate code and having independent micro-services or introduce a shared library which makes these services dependent? 解决方案 Of course there is DRY rule in programming. But, as Sam Newman said in his book "Building Microservice": Don't Repeat Yourself inside one microservice.Common entities:Let's look at your example with ResponseC. Imagine that something in ServiceB has changed so now one of the field from the response have changed - now you have to update each service that uses this shared library, even if the service don't need this changed field. If you had the ResponseA, ResponseB and ResponseC for each service, you didn't had to update each service with the new dependency.Common logic:Basically the same rules are applied here. However it's common to use some third party libraries for common microservices issues like time-outs and retries. What else I can suggest is to look at service mesh implementation like istio and linkerd. Service mesh will give the possibility to these issue to the infrastructure layer so you can focus on writing business logic. 这篇关于微服务:共享库与代码重复的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！