Questions tagged «microservices»

微服务是相互独立的小型，独立进程，相互通信以形成利用与语言无关的API的复杂应用程序。这些服务是小型构建块，高度分离，并且专注于执行小任务，从而促进了模块化的系统构建方法。

2
多租户微服务设计
我们正在将单片应用程序迁移到微服务架构。由于某些法规要求，我们必须将来自不同国家/地区的客户数据保存在单独的（特定于国家/地区）数据库中。即美国客户的美国数据库，英国客户的英国数据库... 我们正在考虑的以下设计如下： 选项1：具有休眠多租户支持的多租户应用程序，可以根据需求扩展到N次（例如kubernetes pod）。该应用程序的单个实例将能够连接到所有数据库。 选项2：每个国家/地区数据库部署1个微服务实例。通过它们前面的API网关路由流量 如果要设计这种类型的系统，您会选择什么？
2
微服务架构共享域模型
假设我们有一个使用微服务架构的Spring Boot应用程序。每个服务都有其自己的域模型，但是每个服务必须引用一个User域对象。解决该问题的最佳方法是什么？为每个服务仅拥有一个userId会更好，然后在需要时向用户服务询问用户详细信息，或者为所有微服务都拥有一个共享域库会更好吗？
2
如果其中一项失败，您如何设计更新多个微服务的软件？
我是否可以使用设计模式或实践来帮助出现故障或停机的服务，而其他服务却保持稳定？ 如果我有三个微服务，其中两个很好，又在POST中间死了怎么办？有两个将获得POST，而一个则不会。我认为我无法进行交易，因为我正在将请求发送给服务。 我该如何设计？我不想在各种数据库中孤立数据。
4
当需要大量输入数据时，如何在微服务架构中使用规则引擎？
现在的情况 我们正在微服务架构中实现（现在正在维护）在线购物Web应用程序。 要求之一是，企业必须能够对客户添加到购物车中的商品应用规则，以自定义其体验和最终订单。很显然，必须建立业务规则引擎，并且为此我们实现了一个特定的“微服务”（如果仍然可以这样）。 在过去的一年中，此规则引擎变得越来越复杂，需要越来越多的数据（例如购物车的内容以及用户信息，他的角色，他的现有服务，一些账单信息等）才能计算这些规则。 目前，我们的shopping-cart微服务正在从其他微服务收集所有这些数据。即使部分资料已由所使用shopping-cart，大部分时间主要还是用来提供规则引擎。 新要求 现在，需要其他应用程序/微服务来重用规则引擎以实现类似的需求。因此，在当前情况下，他们将必须传输相同类型的数据，调用相同的微服务并构建（几乎）相同的资源才能调用规则引擎。 照原样继续，我们将面临几个问题： 每个人（称为规则引擎）都必须重新实现对数据的获取，即使他们自己不需要数据也是如此。 对规则引擎的请求很复杂； 继续朝这个方向发展，我们将不得不在整个网络上传输许多请求的数据（想想μsA调用μsB调用规则引擎，但是A已经有了规则引擎需要的一些数据）； shopping-cart 由于所有数据的获取而变得巨大； 我可能会忘记很多…… 我们怎样做才能避免这些麻烦？ 理想情况下，我们将避免为规则引擎增加更多的复杂性。我们还必须确保它不会成为瓶颈-例如，某些数据的获取速度相当慢（10 s甚至更多），因此我们实施了预提取，shopping-cart以便在调用规则之前数据更有可能存在引擎，并保持可接受的用户体验。 一些想法 让规则引擎获取所需的数据。这将增加它的复杂性，违反了单一责任原则（甚至更多……）； 在规则引擎获取数据之前实施代理μs； 实施规则引擎调用的“数据获取程序”μs，以一次获取其所需的所有数据（复合查询）。
1
为什么在服务器和客户端之间共享接口是一个坏主意？
当我发现一种在HTTP服务器与其客户端之间共享接口的方法时，我正在阅读Spring Cloud Netflix文档。他们将这个示例用于微服务，尽管没有理由不能将其扩展到通用HTTP通信： // The shared interface, in a common library public interface UserService { @RequestMapping(method = GET, value = "/users/{id}") User getUser(@PathVariable long id); } // The controller, on the server @RestController public class UserResource implements UserService { } // The same interface used for the client @FeignClient("users") public …
2
微服务的用户授权
微服务是否应该负责处理自己的授权，或者您认为最好有一个单独的授权服务，该服务在微服务的全部或子集（在同一业务域内）共享？ 对我而言，后者更有意义，因为它使更改，执行策略变得更加容易。它是DRY等。但是，通过各种将其规则转储到一个地方的服务，它也很容易失控，并且还担心网络开销。 有什么想法吗？
3
微服务架构中的业务逻辑应该放在哪里？
由于我习惯于采用单片方法，因此仍在尝试围绕微服务架构 假设我们尝试构建一个极其简化的 Uber预订系统。为简单起见，我们假设我们有3个服务和客户端的网关API： ，，Booking 和我们有以下流程：DriversNotification 创建新预订时： 检查现有用户是否已有预订 获取可用驱动程序列表 发送通知给司机以领取预订 司机接机 假设所有消息传递都是通过http调用完成的，而不是通过类似kafka的消息传递总线来完成的。 因此，在这种情况下，我认为该Booking服务可以对现有预订进行检查。但是，谁应该得到可用驱动程序和通知的列表呢？我正在考虑在网关级别执行此操作，但是现在逻辑可以分为两个地方： Gateway -获取可用驱动程序列表+发送通知 Booking -检查现有预订 而且我很确定网关不是正确的选择，但是我觉得如果我们在Booking服务中使用它，它将变得紧密相连吗？ 更复杂的是，如果我们有另一个项目想要重用预订系统，但又要有其自己的业务逻辑，该怎么办？这就是为什么我考虑在网关级别执行此操作，以便新项目网关可以将其自己的业务逻辑与现有逻辑分开。 我想的另一种做法是，每个项目都有自己的预订服务，该服务将与核心预订服务对话，但是我不确定这里最好的方法是什么:-)
1
API网关后面的微服务是否需要验证访问令牌？
我有一堆只能通过API网关从外部访问的微服务。 我的API网关设置为OAuth资源，并在将请求下游传递给一个或多个微服务之前验证令牌（检查签名等）。 虽然我的微服务需要令牌才能验证范围和声明，但现在是否还需要该服务来验证令牌？ 似乎有些矫kill过正，但我​​无法在线找到有关此情况的任何建议。 在API网关上验证令牌是否足够好？还是最好的做法是稍后再进行验证？
4
如果微服务架构需要每个微服务单独的数据库，那么它的成本太高且难以管理。为什么我们甚至需要它？
我读到有关微服务的信息，对于每个服务创建一个单独的DB来实现隔离似乎不合逻辑。我可以仅使用Web服务和单个数据库来实现相同的目的。为什么我们甚至需要它？分开数据库的东西是无聊的。还是我明明是错？你能指导我吗？
7
服务应该在微服务架构中直接相互通信吗？
我有许多构成Web应用程序的Web服务。客户端可以通过REST API调用访问这些服务。 这些服务应该能够彼此直接对话吗？如果是这样，这是否会使他们成为夫妇，这违背了微服务的概念？ 客户端是否应该一个接一个地直接调用它们以获取在客户端上加载网页所需的数据？ 还是我应该在服务之上设置另一层来处理来自客户端的请求，获取该请求的数据，然后将其发送回客户端？
3
如何通过Symfony使用外部RESTful API？
我们正在为我们的项目构建微服务架构，其中大多数前端Symfony应用程序与后端RESTful API进行交互。 问题在于，这种方法打破了严重依赖带有数据库的Doctrine的Symfony实体管理。Symfony通常使用Doctrine处理实体，从而使大部分工作自动化，而当我们必须从API访问外部数据时，就很难轻松地重现这一点。 例如，对于客户实体： 使用Doctrine，我们只需要定义Client类，现在就可以轻松地创建，更新和检索客户 使用REST API方法，可以通过API访问客户端，但是我们还有很多工作来定义如何创建（POST），更新（PUT），检索（GET）客户端等。 需要注意的是，客户端被多个应用程序使用，不仅是前端应用程序，还有专用的API。 我们是否应该使用类似于实体的方法来创建类，从而隐藏API调用的复杂性，在本地导入所有API数据并通过Doctrine或其他方式访问它们？
2
SOA和微服务之间的真正区别是什么
免责声明 我希望我不要踩任何人的脚趾或冒犯任何一个概念的狂热者 背景 我一直在寻找面向服务的体系结构和微服务之间的真正区别，而没有找到明确的答案。 我读到以下内容： SOA的副作用 SOA是反模式 微服务来修复SOA的故障 ESB并不是真正的ESB，而是EAI 对消息中介的过度依赖 供应商正在滥用SOA的概念并试图出售其产品 SOA不受控制地增长 但是，仍然没有明确定义面向服务的体系结构（作为一个概念）和微服务（作为一个概念）之间的体系结构差异 据我了解，它们都具有： 服务提供商，只做一件事 服务网关/ ESB将这些服务提供给消费者 服务使用者，通过ESB /服务网关访问服务 题 那么，除了将SOA重新标记为微服务之外，还有什么不同吗？限制微服务成为宏的技术约束吗？ 注意：我不是在寻找观点，只是在寻找事实，希望在要点中 参考文献 软件工程问题 马丁·福勒（Martin Fowler）的网站（我认为他讨厌这段时间） 信息世界 迈克尔·富瑟斯的网站 堆栈溢出问题 更新资料 似乎在Stack溢出问题中也发生了类似的辩论，无论是否区分微服务都是变相的面向服务架构。 SO问题的结论： MS是SOA 的特例 MS支持较小规模的应用程序托管服务 MS取决于技术（使用HTTP而非开放协议选项） MS依靠技术来加强纪律（服务的自动部署） MS考虑使用ESB（邪恶），但使用API​​网关，IMHO是ESB的一种 如果满足以下条件，那么可以得出结论，MS是SOA： MS是否支持编排概念？一个或多个主流程管理工作流程 MS中是否有消息代理层？一组适配器，将消息格式从服务生产者的消息空间转换为服务使用者 微服务可以从整体企业应用程序读取数据吗？可以是单片应用程序的API吗？还是必须是能够独立运行的独立的自包含应用程序？ 如果最后一个问题的答案为否，那么微服务将无法处理复杂的工作流程系统，例如信用卡管理系统或对帐系统
5
微服务：MonolithFirst？
我一直在研究微服务体系结构，以期全面了解所有优缺点，何时何地为什么。等等。我正在阅读/观看的许多信息都来自ThoughtWorks（Martin Fowler，Neal Ford等）。 al）。 马丁·福勒（Martin Fowler）在该主题上的大部分工作都还存在数年，那时微服务（如果不是一般实践，在编程中是家喻户晓的名字）还很年轻，因此，我对其中的大部分内容持保留态度。 特别要注意的是： 当我听到有关使用微服务架构的团队的故事时，我注意到了一种常见的模式。 几乎所有成功的微服务故事都始于一个庞大的整体，并且被分解了 在几乎所有我听说过从头构建为微服务系统的系统的情况下，它都遇到了严重的麻烦。 这种模式使我的许多同事争辩说，即使您确定应用程序足够大，也值得这样做，但您不应该使用微服务启动新项目。。 （参考：https : //martinfowler.com/bliki/MonolithFirst.html-强调他们的） 现在，三年后的今天，微服务这个词更普遍了，人们普遍同意一个新系统通常可以通过拥有更大（比微服务大但比整体式小）的服务块来更好地服务，并且作为进化措施的一部分，它们是否更细化？ 或者，与上述陈述相比，是否有规范从头开始使用粒度微服务架构开始项目？ 似乎是理智的一般方法，但对社区的思想感到好奇。
3
在松散耦合的微服务架构中，如何跟踪依赖关系？
现代程序中流行的高级体系结构选择是基于REST的微服务系统。这具有几个优点，例如松耦合，易于重用，对可用技术的限制有限，高可伸缩性等。 但是我预见到的这种架构中的问题之一是对应用程序依赖项的可见性不佳。例如，假设我有一个应用程序，该应用程序每天使用一组REST调用。该应用程序还使用第二组REST调用，但每季度仅使用一次。如果我要扫描过去一周的日志，我会看到所有的每日校准数据，但可能看不到季度调用。当需要重构时，每季度调用的中断风险很高。 可以使用什么模式或工具来减少这种风险，并提供对松散耦合体系结构的依赖性的更大可见性？
2
微服务和规范模型
当我在该网站上阅读有关微服务的信息时，遇到了以下声明。规范架构是什么意思？与域模型不一样吗？ 微服务架构模式还拒绝了SOA的其他部分，例如规范架构的概念。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.