假设我们有5个服务(用户和授权,产品,订单,库存,历史)公开基于REST的API,并通过这些公开的API在服务之间进行内部通信。现在,在Microeservice Architectural模式中进行开发时,这些将是不同的单独服务,这些服务将通过REST /队列自我依赖并相互通信。
从开始开始,我们考虑到现在在单个节点上部署它,其中所有5个服务仅部署在此单个节点上。所以一种方法是
选项2 是一个可行的选择,可以使用作为单独的webapp开发的不同服务,并且可以自行依赖于它自己的架构部署在单个tomcat实例中并被消费从UI层开始,然后在下一阶段使用这个单独和单独服务的基本代码,并转向发现/注册表方法。
但我在选项2 中预见到的挑战是每个服务是一个单独的战争(没有发现/注册表)是 路由 - 作为每个请求的主要条目,例如https://ip:port/ productservice / api / v1 / products / {id},然后转到 productservice webapp需要通过&#34 ;认证服务"应用程序然后被路由到适当的服务并在单独的战争机制中处理此路由(虽然在单个实例上)具有以下选项
答案 0 :(得分:0)
选项2,因此在每个节点的单个tomcat实例上运行所有单独的webapp是迈向成熟的微服务架构的第一步。实际上,您无论如何都需要此步骤以便稍后实现服务发现/注册。在你写的时候 - 它已经为你提供了一定程度的隔离和执行独立迁移的能力(单独的战争)。
只需确保将用于获取服务URL的代码包装到一个类中,这样只有在添加Service Discovery时才会在一个位置进行更改(与应用程序中多个位置的服务的硬编码URL相比)。
在选项2上停止一段时间的缺点是您将失去在每个服务级别上扩展的能力。您需要回答这个问题在特定情况下的重要性。
我在帖子中没有看到的是您使用队列的方法。老实说,如果您的解决方案可以使用异步通信,我会强烈鼓励它(请注意,Netflix堆栈主要针对直接REST通信)。