2017-02-25 30 views
0

目前我处理微服务并遇到几个问题(关于服务之间的关系),我很难找到一个好的答案/最佳实践。如果你能给我一个提示或建议你如何处理这件事,那将是非常好的。微服务依赖于其他人做任何事

因为这些问题是不针对特定的项目,我尽量做到尽可能明确用下面的例子:

让我们假设你想建什么样的YouTube频道观察员,即日志不同种类的频道(元数据)数据(视频,小时视图/子数,当前订阅),这些数据是以特定时间间隔导入的。

所以有两个主要功能的应用程序所提供的,应该形成一个微服务的每个:

  • 添加/删除要收看的频道(=>管理器服务)
  • 进口信息(=>进口服务)

这两个服务提供了一个API来相互沟通。

管理器服务连接到一个数据库,该数据库包含需要观看的频道及其基本信息(姓名,联系人......)以及这些观察频道当前订阅的频道,而导入服务有一个数据库,其中包含所有其他更多面向时间序列的信息(视频,小时视图/子计数)。

要添加频道只有频道url必须指定。所有其他信息(名称,联系人...)都由导入服务添加(但也可以由用户修改)。

如果没有导入服务可用,所有导入服务在没有管理服务信息的情况下完全没有用,而且管理服务只能显示用户指定的频道信息(最坏情况:只有频道URL)。总的来说:他们非常依赖对方。

这么多的一般架构。

我这里是,该进口服务依赖于管理员服务数据库,以这样一个伟大的程度的数据,并对其进行修改的问题:

  1. 难道是共享经理是个好主意这两个服务之间的服务数据库还是只能通过提供的API访问?
  2. 无论数据库是否共享:两个服务都需要该通道的模型类。分享这些可以吗?
  3. 这种架构是否甚至是一个好主意(如果我们假设还有其他服务需要基本的频道信息)?
+0

我更喜欢每个服务应该有它自己的数据库和缓存。这就是服务如何独立。如果需要一个服务呼叫其他人访问数据。 –

+0

@MAshrafulA感谢您的回应! 所以你会建议,只需坚持API,只是接受,如果经理服务不可用,导入服务不能做任何事情? – Tek

+0

是的,如果您有多个实例运行正确的“服务发现”,那么您可以将请求传输到另一个实例服务 –

回答

1

当两个微服务紧密耦合时,我会建议您想要合并它们。为什么你想要微服务呢?这是一个大型项目,应该增长很多,可能有独立的团队正在努力? 不要仅仅因为它们很酷,而是因为需要而做微服务。在一个相对较小的单人项目中,我通常不会建议使用微服务。

我会做一些阅读微服务。io关于何时使用微服务体系结构以及何处拆分。