Dom*_*oSL 8 node.js microservices
我的目标是创建一个体系结构,其中服务应该能够彼此独立地部署并且是完全自治的,但是如果有2个服务从DB读取相同的对象类型,您会怎么做？
在我的情况下,我有一个套接字服务器(微服务1)和一个http服务器(微服务2).使用http服务器,我的用户创建一个名为A的资产:此资产存储在数据库中,并返回mongoID.然后,使用另一个协议和ID,调用套接字服务器需要检查该ID的有效性,因此需要从DB读取.这两个服务必须共享A的模型才能将其映射到一个对象,但这意味着这两个服务必须共享代码,这是不行的.
我需要其他服务吗？或者我应该只使service1能够从DB读取然后使第二个与服务1进行通信？
...有些调用需要检查该ID的有效性,因此需要从DB读取.这两个服务必须共享A的模型才能将它映射到一个对象,...
嗯 - 不,他们不需要共享代码!他们真正需要的唯一事情就是对数据库架构的共同理解(我假设你使用的是MongoDB).这种理解是来自共享库中的共享类定义还是来自单独库中的重复类定义并不重要.许多开发人员现在都会因为违反DRY(不要重复自己)原则而开始尖叫我,但是对于微服务,许多东西都与我们习惯的东西不同!
在她的回答中,Priti Singh表示:
两个微服务不应共享相同的数据模型
这在微服务环境中是正确的,并被认为是良好的做法!让我告诉你原因:
在微服务模式中,服务应该独立于其他服务并且具有良好定义的接口.有两个不同的服务读取相同的DB使得该DB成为另一个"服务"(我知道,很奇怪,对吧？!？).根据定义,这个数据库现在需要一个定义良好的接口 - 这在无模式数据库中很难;-)不使数据库像服务那样行事的另一个原因是,一个服务的变化总会对另一个服务产生一些影响.服务访问数据.这意味着,更改一个服务上的"架构"可能会强制您更改另一个服务,只是为了让您的系统保持运行!当你考虑一个拥有超过100项服务的成熟微服务系统时,这是一件令人头疼的事.
这就是你的第二个想法:
...或者我应该只使service1能够从DB读取然后使第二个与服务1进行通信？
好多了 使用可定义版本的明确定义的接口将数据库隐藏在服务之后.像这样,您可以根据自己的心愿重构服务1,而不必影响其他服务.一旦您需要在界面上进行重大更改 - 为其提供新版本并开始迁移其他服务以使用新界面.
您的问题中潜在的争议是耦合与复制之间的争议.共享一个接口定义和数据库是耦合的(在一个小的改变之后的类型的耦合中唤醒你),但是将数据库模式复制到两个服务是重复的.我相信耦合会在复制之前很久就会杀了你,但是采取你的第二种方法,让http-service访问socks-service然后访问数据库应该删除重复以及减少耦合!
如果这有用,请告诉我!
| 归档时间： |
|
| 查看次数： |
2363 次 |
| 最近记录： |