问题标签 [microservices]

我正在研究微服务架构，我有一个问题。

承认我在不同的主机上有多个服务，如下所示：

• http://80.80.80.80:9000/上的认证服务
• http://90.90.90.90:1234/上的计费服务
• http://70.70.70.70:7412/上的规划服务

我的问题是，当用户在网关上请求时，他发送了一个访问令牌（无状态，oauth2.0 等），然后网关询问身份验证服务，如果用户存在并具有权限，他访问另一个资源服务。

没关系，但是如果我尝试直接从他的主机调用 BillingService 怎么办？你可以告诉我港口已经关闭，我同意。

但这是否意味着它们只允许从某个主机到另一个主机？意味着仅允许从网关机器上的端口 1234 上的计费服务？

我错过了什么吗？

感谢提前

我正在制作一个基于 dockerized 服务的应用程序。有些服务会用meteor编写，有些则不会。

其中一项服务是注册服务，用户可以在其中注册平台。

在做微服务时，通常我会做以下事情：

我想做的是使用该loginWithFacebook方法。问题是Meteor.loginWithFacebook在前端使用将在主前端服务器上调用其后端方法。

但是，我想在 RegistrationService 服务器（具有相关包）上调用其后端方法。原因是因为我使用Accounts.onCreateUser钩子来做额外的事情，也因为我想将注册服务与前端分开。

只是为了清楚起见，即使它不正确，想象我有这个：

但是，我希望该loginWithFacebook方法RegistrationService 在调用客户端方法 .loginWithFacebook 时使用服务器端方法，所以我实际上想做一些事情来达到以下效果：

对此的任何帮助将不胜感激。谢谢！

我正在使用嵌入式码头构建一堆服务。我更喜欢在 Elastic Beanstalk 中部署这些服务。Elastic Beanstalk 支持的环境随 Tomcat 一起提供，这对我来说不是必需的。那么我应该使用哪个环境在 Elastic Beanstalk 中运行我的服务？我只需要一个带有 Java 的准系统 EC2 实例，并且我的嵌入式码头应用程序能够在不同的端口上运行。Docker 容器是否是运行这些服务的最佳方式，即使在这种情况下，我也不确定应该使用哪个环境。

谢谢

我有一个相对较新的项目，它采用了微服务架构。除了我们的安全服务之外，我对各个服务的大小和粒度感觉非常好。

我有三个主要服务，比如说foo-service、bar-service和baz-service。这些服务从不需要通信，但所有三个服务都会定期通过 HTTP 请求与security-service. 我希望这停止有多种原因 - 最大的原因是对我的个人服务的每个请求都会产生对安全服务的请求，一旦考虑到负载平衡等，它可能会变成几个额外的跃点。我一直在阅读Mark Richards 的“软件架构模式”，他建议在这些情况下您应该共享数据库并违反 DRY：将所需的功能复制到每个服务中。尽管如此，他还是将这个示例与较小的“实用程序”类一起使用，这可能并不真正适用于这种情况。

安全服务并没有那么大，所以我绝对可以将它复制到其他每个服务中。也就是说，它足够大，以至于复制和粘贴它时我感觉不太好——根据工作服，有 314 行“相关”代码（java 所以有更多实际代码；-）。我可以很容易地把它变成一个模块，每个服务都会引入——但是我的服务有一个共享的依赖关系，这在过去一直困扰着我。当然，随着我们添加身份验证方法，安全代码会随着时间的推移而增长，但在身份验证方面我们并没有重新发明轮子，所以它主要与其他库和身份验证服务集成。也就是说，我不认为这个特定的代码库会变得庞大。

所以我的问题是，我应该复制并粘贴代码还是构建每个服务都引入的模块？谢谢！

假设我们有许多（无状态的、基于 HTTP 的）（微）服务和一堆“守护进程”，它们通过实际使用所述服务来进行各种后台处理。

现在，我想有一种方法让服务和守护进程能够相互验证和授权。例如，执行订单全文索引的守护进程需要：

• 对Orders、Customers（本身需要对Companies服务具有只读访问权限）和Inventory服务的只读访问权限
• 对OrdersSearch服务的读写访问权限，以便能够更新全文索引。

还有一些应用程序，它们“代表”用户操作。例如，Inventory Web 应用程序需要对Inventory服务的读写权限，但Inventory服务本身需要验证操作应用程序的用户的权限。

说了这么多，我如何实现我刚才描述的？我不想使用庞大的企业框架或标准。根据我的阅读，两足 OAuth2 是我需要的，但我不确定。

我正在考虑建立一个授权服务，该服务将用于回答诸如“嘿，我是库存服务。现在打电话给我的客户服务对我有什么权限？”，但这在分发方面有两个主要弱点共享的秘密。

假设我们有一个用户、钱包 REST 微服务和一个将事物粘合在一起的 API 网关。当 Bob 在我们的网站上注册时，我们的 API 网关需要通过 User 微服务创建一个用户，并通过 Wallet 微服务创建一个钱包。

现在这里有一些情况可能会出错：

• 用户 Bob 创建失败：没关系，我们只是向 Bob 返回一条错误消息。我们正在使用 SQL 事务，所以没有人在系统中看到 Bob。一切都很好:)

• 用户 Bob 已创建，但在我们的钱包创建之前，我们的 API 网关硬崩溃。我们现在有一个没有钱包的用户（数据不一致）。

• 用户 Bob 已创建，当我们创建钱包时，HTTP 连接断开。钱包创建可能已经成功，也可能没有。

有哪些解决方案可以防止这种数据不一致的发生？是否存在允许事务跨越多个 REST 请求的模式？我已经阅读了关于两阶段提交的维基百科页面，这似乎涉及到这个问题，但我不确定如何在实践中应用它。This Atomic Distributed Transactions: a RESTful design paper 似乎也很有趣，虽然我还没有读过。

或者，我知道 REST 可能不适合这个用例。处理这种情况的正确方法可能是完全放弃 REST 并使用不同的通信协议（如消息队列系统）吗？或者我应该在我的应用程序代码中强制执行一致性（例如，通过有一个后台作业来检测不一致并修复它们，或者在我的用户模型上使用“创建”、“创建”值等的“状态”属性）？

我们在微服务中看到的是一个孤立的组件，通过协议通过网络与该组件的父消费者进行通信。

我们在 EJB 1.0 中看到了非常相似的模式。

我的问题是：微服务架构模式是否类似于 EJB 1.0？

我搜索过但找不到直接答案的东西是：

对于给定的服务，如果该服务的两个实例部署到两台机器上，它们是否共享相同的持久存储，或者它们是否具有具有某种同步机制（主/从、集群）的单独存储？

例如，我有一个由 MySQL 支持的 OrderService。我们收到了很多订单，所以我需要扩大这项服务，所以我们部署了第二个 OrderService。它的数据来自哪里？

这听起来可能很愚蠢，但对我来说，每次讨论都让服务和数据库看起来像是一个部署在一起的打包单元。但是很少有讨论提到部署第二个服务时会发生什么。

我不确定这是否是合适的地方，但我提出了一个“概念性”模块化设计架构，将逻辑分离到各个服务中，以允许几乎即插即用的场景，其中没有依赖关系。服务。考虑一个功能列表，只启用您想要的功能。

为了促进这一点，我意识到我需要某种类型的中间件，它将所有这些连接在一起并控制数据流。但是，我不确定实现这一目标的具体细节。

我计划使用基于.NET soap 的服务来实现服务，那么这是使用Tibco 之类的例子吗？

关于什么是最合适的，甚至从哪里开始寻找的任何建议都会很棒。

如果上面的描述没有意义，希望这张图片能更清楚地描述服务之间的关系。

谢谢。

目前，我为一个项目提供了20 个微服务。每个微服务都存储在单独的 GIT 存储库中。随后，服务数量将增加到200 个（或更多）。

每个服务都有单元测试和集成测试。每个服务都内置在 TeamCity（持续集成服务器）中。

问题：如何为一个项目存储200个微服务的源代码？在一个存储库中还是在单独的存储库中？