如何在一个模块 (A) 中创建一个类，该类实现另一个模块 (B) 的抽象类
我使用带有 Spring-cloud 堆栈的微服务架构。
对于服务之间的通信，我决定使用 gRPC。
我有一个名为 Accounting 的服务，今天我实现了一个 gRPC-interface 项目并将其添加到 Git 存储库中。
我使用以下命令使用 Git-submodules 将 gRPC-interface 添加到 Accounting 服务：
git submodule add -b master <Git-Repo-URL>
git submodule init
现在我想在 中创建一个服务类会计实现来自gRPC-interface的一个类，但它无法识别来自gRPC-interface模块的任何类！
我想我需要对 Accounting 模块中的 setting.gradle 和 build.gradle 文件进行一些更改，但我不知道发生了什么变化我应该做什么，甚至不知道该在互联网上寻找什么主题。
任何帮助或线索将不胜感激！
I use Microservices architecture with Spring-cloud stack.
For communication between services I decided to use gRPC.
I had an service named Accounting and today I implemented a gRPC-interface project and added it to Git repository.
I added gRPC-interface to the Accounting service using Git-submodules using following commands:
git submodule add -b master <Git-Repo-URL>
git submodule init
Now I want to create a service class in Accounting that implements one class from gRPC-interface but it doesn't recognize any class from gRPC-interface module!!
I think I need to make some changes in setting.gradle and build.gradle files in Accounting module, but I don't know what changes should I do and even don't know what topic to look for on the internet.
Any help or clue would be appreciated!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来您对微服务有些不知所措，但是，为了回答所述问题：
想想“twitter API”。 Twitter 有 2 个“项目”（不是 git 子模块意义上的，而是英语单词意义上的）。有 twitter-the-website，它是运行所有内容的非公开代码，特别是包括当您连接到
api.twitter.com时进行应答的代码。但是，还有一个开源（或者至少是公开可用的）库，您可以将其包含在 Java 项目中，让您可以与 twitter API 进行对话。这个公共 API 包括与 twitterverse 中的概念相匹配的模型类（例如“一条推文”、“一个用户”、“一条直接消息”、“一个用户决定关注另一个用户的概念”等）以及函数（大概是在“api”对象上）您使用参数调用并返回这些模型类的实例。你需要做同样的事情。微服务由两个项目组成：另一个微服务自身包含的 API（类似于 Twitter 提供的公共“java API”库）和实际代码。可能是一个项目，也可能是一百万个项目，微服务的一个重要部分是：从依赖于微服务 B 的微服务 A 的角度来看，除了描述的部分之外，您根本不需要了解有关 B 的任何信息它的公共 API。就服务 A 而言，其他一切都是实现细节，并不重要。
如果您将一个微服务的所有代码包含在另一个微服务中，那么您最终会得到每个“微服务”，其中包括所有其他微服务的所有代码，并且您的服务不再有任何微服务了。
是的，这很烦人。您并不完全需要重复代码（定义模型的“公共 API”部分也可以是微服务本身的依赖项），但每个微服务都会变成维护 2 个单独的微服务，并且您需要找到一种方法来“公共 API”部分可以像 Twitter API 一样进行分发。您可能不想将其放在 maven 中央，但这就是为什么 maven（实际上是 sonatype）、gradle 等都提供了公司范围的中间依赖服务器的概念 - 可以托管您的“公共 API”项目。以及本地依赖项 - 阅读构建系统的文档，了解如何处理非开源公开（即不在 Maven 中心）依赖项。
It sounds like you're in over your head on microservices here, but, in the interests of answering the question as stated:
Think 'twitter API'. Twitter has 2 'projects' (not in the git submodule sense, in the english word sense). There's twitter-the-website, which is non-public code that runs it all, notably including the code that answers when you connect to
api.twitter.com. But there's also an open source (or at least, publicly available) library that you can include in your java projects that lets you talk to the twitter API. This public API includes model classes that match concepts in the twitterverse (such as 'a tweet', 'a user', 'a direct message', 'the concept of one user deciding to follow another', etc), as well as functions (presumably on an 'api' object) that you call with parameters and which returns instances of these model classes.You need to do the same thing. A microservice consists of two projects: Its API which another microservice includes in itself, which is analogous to the public 'java API' library that twitter offers, and the actual code. Which could be one project or a million, a significant part of the point of microservices is: From the point of view of microservice A that depends on microservice B, you don't need to know anything about B at all except the part that describes its public API. Everything else is an implementation detail that just doesn't matter, as far as service A is concerned.
If you included all the code of a microservice in another, then you end up with every 'microservice' including all code of all others, and there's nothing micro about your services anymore.
Yes, this is annoying. You don't exactly need to duplicate code (the 'public API' part that defines the models can also be a dependency of the microservice itself), but every microservice turns into maintaining 2 separate ones, and you need to find a way for the 'public API' part to be distributable as if it was the twitter API. You probably don't want to put it on maven central, but that's why maven (sonatype, really), gradle, etc all offer the notion of a company-wide intermediate dependency server - that one can host your 'public API' projects. As well as local dependencies - read the docs of your build system on how to deal with non-open-source-publicized (I.e. not on maven central) dependencies.