实现微服务架构的意义

时间:2016-01-13 18:26:26

标签: amazon-web-services architecture spring-boot licensing microservices

我是第一次开始学习/实施微服务架构的过程,我有一些与其含义相关的问题。

对于某些背景,我打算使用的技术堆栈是一种非常重要的意义上是在AWS上运行的dockerized spring-boot微服务。

所以我想知道的是......

首先,假设每个微服务都应该是完整的堆栈,包括单独的数据库,这是否意味着我需要3个单独的实例来选择运行的数据库?我猜答案是肯定的。所以,我想我真正的问题是,这不比单个数据库的单片应用程序消耗更多的硬件资源吗?数据库非常耗费内存...

不仅如此,如果我运行5个微服务,那么运行单个spring-boot应用程序所需的全部ram将需要5次?在我看来,这需要远远超过整体应用程序的ram,对吗?

如果您使用Oracle作为数据库呢?它对许可有什么影响?如果你需要为每个微服务提供一个单独的数据库,它会不会变得疯狂?

是否还有其他许可陷阱需要考虑?或者在开始这次旅程之前,应该考虑/了解MSA的任何其他陷阱?

编辑: 另外,假设每个微服务都是全栈,那么如果我想要为每个微服务看一个前端(微服务需要前端)怎么办?我没有看到任何关于此的好建议。特别是给出(如果它们被称为'12因子'),代码库应该位于每个微服务的单独存储库中。如何最好地管理/实现?

2 个答案:

答案 0 :(得分:4)

这是一个很重要的清单,但我会试一试:

数据库: 是的,他们应该拥有自己的数据库。这并不一定意味着他们自己的数据库SERVER,这是一个扩展问题,但你当然不希望将它们结合在一起。绝对最干净的方法是将它们物理地分开,但是从许可的角度来看,没有相互许可的单独模式可能就足够了。

RAM: 是的,这肯定需要更多的空间用于计划领域。这通常是无关紧要的,因为程序的数据通常远远超过程序/框架内存。我相信spring boot框架需要18 mb左右才能运行。除非你的服务非常小,否则你需要一个数量级(或两个)的RAM来运行你的服务,此时spring框架是一个舍入错误。甚至JVM本身也可能是压倒性的。您可以进行一些测试,但请不要花费任何时间来优化2-3 mb的RAM ...当您进行一次或多次演出时进行优化。

许可:除了上面对数据库实例的评论之外,这个问题太广泛了。如果您要授权单个产品/库,那么您将需要查阅许可协议以了解它将如何发布。一些许可证由“服务器”,一些由“应用程序”,一些由过程。

UI:我真的不明白这一点。微服务被组装到一个应用程序中。该应用程序具有UI。服务本身通常没有UI。此应用程序通常是单独的应用程序服务器,或者有时只是一个带有javascript的HTML页面来调用服务。

答案 1 :(得分:2)

以下某些内容可能会根据您的知识进行一些重复,但让我们看看它的部分内容是否对您有用。

微服务的想法是围绕单一责任设计每个服务,或者在单个域中设计相当普遍的服务。这意味着您将拥有处理产品API,订单API,购物篮API和客户API的不同服务。正如您已经猜到的那样,这意味着您将在不同数据库和服务之间分配所有这些数据,并且不会直接访问自己的数据库。

这允许您将所有业务逻辑包含在一个位置并实现以下服务:

  • 独立发布和部署
  • 可更换且更易于升级
  • 独立扩展
  • 更容易&更快的发布
  • 更容易测试

的意义

更多的事情可以下去

这种方法的含义自然是一个更复杂的部署基础架构和更多可能出错的事情,因为服务通常通过HTTP与REST API相互通信,但有时会通过pub-sub,Protocol Buffs或Thrift或其他方式 - 重量消息传递协议这会导致通信,延迟等可能超时。

你需要考虑“事情可以下降”的情况,而不是整体,并根据你的要求处理它。有一些库和工具可以帮助您,例如,Netflix Hystrix中的Spring-Cloud-Netflix项目包含断路器支持,可帮助您处理远程服务通信的超时。

资源使用

在资源使用方面,它取决于你如何看待它。多个服务组合将最有可能使用比monolith更多的资源,特别是如果您考虑多个数据库实例等。但是,让我举例说明部署到AWS并使用AWS提供的自动扩展支持。

在整体中,您将扩展整个应用程序。当应用程序的负载增加时。这意味着你将启动更多的EC2机器,即使它只是处于压力下的某段代码。

在微服务架构中,您可以根据使用情况自行扩展每个服务。这可以带来更好的资源利用率,并且最终会更具成本效益,因为每项服务仅使用巨石的一小部分。

关于UI的几句话

我认为UI也应该被视为一个单独的服务。它应该只提供UI本身,而不是某些操作的业务逻辑 - 它是每个微服务的责任。因此,如果您有网上商店,您最终可能会得到以下服务:

  • 前端用户界面
  • 购买服务
  • 篮子服务
  • 用户服务
  • 产品服务
  • 订购服务
  • 送货服务
  • ......可能还有更多。

您的UI应该具有的唯一逻辑是如何显示不同类型的数据,然后与底层服务进行通信。但是,UI也可以由许多不同的服务组合在一起!例如,亚马逊有许多不同的服务,为您看到的每个页面提供支持,部件或UI可以由不同的UI服务生成和显示。这一切都取决于你想要多么小的服务。

Sam Newman有一本非常好的书“Build Microservices”,我强烈建议你阅读 - 它涵盖了很多这些东西以及更多内容。随着时间的推移,你应该回答很多不同的问题,你越是深入研究美丽的微服务世界。