我最近开始使用Node.js,我必须构建一个应该使用多个Express.js服务的体系结构。其中一些服务必须位于一台服务器上,另一台则位于其他服务器上。我想构建一个基础服务(像API网关),但是我不知道在这个网关和微服务之间,或者在两个微服务之间进行通信的合适方式是什么。
目前我正在研究一个基于此的解决方案:
# inside Gateway server I call another service:
http.get('http://127.0.0.1:5001/users', (service_res) ->
data = ''
service_res.on 'data', (chunk) ->
data += chunk
service_res.on 'end', ->
# some logic on data
).end()
您拥有的逻辑并不是不正确的,但更好的做法可能是在向另一个服务(例如)发出请求的基础上构建一个抽象层。另一个微服务的API网关。让我们只调用这个实例的微服务B(API网关向B发出请求)。
在这种情况下,B应该提供它自己的客户端,说明另一个服务应该如何与它交互,不管是通过HTTP还是WebSockets,协议由B决定,因为B理解应该如何与它通信。客户机和服务一起实现的论点是,这两个组件应该具有更高级别的内聚性,因为从技术上讲,它们受一个合同(例如。如果一个请求需要向一个服务发出,它需要遵守该服务所要求的契约。
在带有Express的简单伪代码中:
// implemented elsewhere, ideally next to the service that it communicates with
function BServiceClient() {
// ...
}
// the API gateway's calling code
app.get('...', function(request, response, next) {
// create an instance of the service client
var bServiceClient = new BServiceClient();
// retrieving the users from an abstracted endpoint
bServiceClient.GetUsers();
// do some processing and then render a response or call next
});
为了使路由更易测试,您可能必须在app
周围编写自己的包装器,以便为注入客户端执行适当的依赖注入,从而使路由更易测试。否则,您可能可以创建另一个函数,该函数可以注入客户端,并在调用新创建函数的处理程序级别创建客户端。然后可以测试新创建的函数。但是,我更喜欢使用包装器的前一种方法。希望这有帮助!
我有一个微服务体系结构,它的日志必须发送到远程Kafka主题。在它旁边,本主题的使用者将把日志发送到麋鹿堆栈(另一个团队) 我想要一个专用的微服务(fwk proxy elasticsearch),其职责是收集其他人的日志,并将其发送到远程Kafka主题。 将从我的微服务聚合的所有日志分派到fwk-代理-弹性搜索微服务的最佳协议是什么? 我希望这个模式不会重复远程Kafka主题的安全配置。我想把它
我经常听说,在微服务架构中,对于每一个微服务,我们都必须创建单独的数据库。 但是,如果我必须在不同的数据库中维护外键约束,这是不可能的。就像我在身份验证微服务中有一个用户表,我想在我的目录服务中使用它(用户表中的用户 ID 列) 那么如何解决呢。 感谢提前
我不清楚如何取回购买服务不保存的数据--例如:用户的全名。当试图通过购买用户名进行更复杂的搜索购买时,问题会变得更严重。 我认为,显然可以通过在两个服务之间同步用户来解决这个问题,方法是在用户创建时广播某种类型的事件(并在购买服务端只保存相关的用户属性)。在我看来,这远非理想。当你有数百万用户时,你如何处理这个问题?您会在每个使用用户数据的服务中创建数百万条记录吗? 另一个明显的选择是在用户服务端
我正在开发具有微服务架构的后端。我对该架构不熟悉,目前我在一个容器中开发了3个微服务(RESTful Web服务,带有Spring Boot)。我想实现OAuth2和JWT Rest Prot和网关。使用授权服务器和资源服务器实现网关是正确的吗?我在架构上做错了什么吗? 谢谢你的回复
总而言之,我们有: 产品类别: 产品ID、产品名称 订单类别: 订单ID、产品ID、用户ID、订单日期 这些方法中的任何一种可以被认为是最佳实践吗?还是有不同的解决方案?
我是事件驱动微服务的新手,也是微服务本身的新手。我正在开发的系统并不大,它处理一堆文件,然后根据调用不同服务的数据。所以在我看来,一个好主意是,不要让服务调用其他服务来完成这项工作,而是将这些消息发送到发布/订阅队列,处理它们并将它们发送到相关主题,然后每个服务将订阅其中一个或几个主题,每隔几分钟,每个服务都会提取它们订阅的消息并发挥它们的魔力。这些服务也可以通过Rest来公开,以防您想强制执行它