Questions tagged «microservices»

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

5
转向微服务如何造成运行时问题？
以下评论员写道： 微服务将组织功能障碍从编译时问题转移到运行时问题。 该评论员扩展了该问题的说法： 功能不是错误。运行时问题=>产品问题=>向功能负责人反馈更强大，更快速的功能障碍 现在，我通过微服务获得了您： 可能会增加吞吐量的延迟-这是生产和运行时的问题。 增加代码中“网络接口”的数量，其中可能存在潜在的运行时解析错误。 可能会进行蓝绿色部署。接口不匹配可能会阻止这些故障（请参阅网络接口）。但是，如果蓝绿色部署能够正常工作，那么它就更是运行时的问题。 我的问题是：转移到微服务会带来运行时问题，这是什么意思？
7
微服务最被接受的交易策略是什么
我所看到的在具有微服务的系统中发生的主要问题之一是，事务跨不同服务时的工作方式。在我们自己的体系结构中，我们一直在使用分布式事务来解决此问题，但是它们带有各自的问题。迄今为止，僵局尤其令人痛苦。 另一个选择似乎是某种定制的事务管理器，它知道您系统内的流程，并会为您处理回滚，因为它是跨整个系统的后台进程（因此它将告诉其他服务回滚）如果它们出现故障，请稍后通知他们）。 还有其他可接受的选择吗？两者似乎都有其缺点。第一个可能导致死锁和许多其他问题，第二个可能导致数据不一致。有更好的选择吗？
7
微服务系统架构如何避免网络瓶颈？
我已经阅读了很多有关服务器应用程序的微服务架构的信息，并且一直想知道与整体式架构相比，内部网络的使用是不是瓶颈或明显的劣势。 为了精确起见，以下是我对这两个术语的解释： Monolith体系结构：一个用一种语言处理所有功能，数据等的应用程序。负载平衡器将最终用户的请求分布在多台计算机上，每台计算机都运行我们应用程序的一个实例。 微服务体系结构：许多应用程序（微服务）处理一小部分功能和数据。每个微服务都公开通过网络访问的公共API（与同一机器上的进程间通信或共享内存相反）。API调用主要在服务器上进行搜索以生成页面，尽管其中一些工作可能是由客户端查询各个微服务来完成的。 用我天真的想象力，似乎微服务体系结构使用的网络通信速度较慢，而不是同一台计算机（内存和磁盘）上的资源更快。如何确保通过内部网络进行API查询不会减慢整体响应时间？
5
从另一个微服务“拥有”的数据库中读取数据为何如此糟糕
我最近阅读了有关微服务体系结构的出色文章：http : //www.infoq.com/articles/microservices-intro 它指出，当您在Amazon上加载网页时，则有100多个微服务合作提供该页面。 该文章描述了微服务之间的所有通信只能通过API。我的问题是，为什么这么糟糕的说法是所有数据库写操作只能通过API进行，但是您可以自由地直接从各种微服务的数据库中进行读取。例如，可以说微服务外部只能访问少数几个数据库视图，以便维护微服务的团队知道只要保持这些视图不变，那么他们就可以尽可能多地更改其微服务的数据库结构。想。 我在这里想念什么吗？还有其他原因为什么只能通过API读取数据？ 不用说，我的公司要比亚马逊小得多（并且一直会这样），我们可以拥有的最大用户数约为500万。
5
不同微服务之间的共享域模型
想象一下两种不同的微服务的场景。一个负责处理服务中的身份验证，另一个负责用户管理。他们都有用户的概念，并且会通过相互调用来谈论用户。 但是，“用户”的域模型将属于哪里？它们在数据库级别上对用户的身份都有不同的表示吗？当我们有一个UserDTO可以用于API调用时，它们各自的API是否都有一个呢？ 对于这种架构问题，公认的解决方案是什么？
6
在微服务中，每个服务是单个数据库还是单个数据库实例？
我了解微服务架构中的每个服务都应具有自己的数据库。但是，拥有自己的数据库，实际上是在同一个数据库实例中简单地拥有另一个数据库，还是在字面上拥有另一个数据库实例？ 这样，我并不是说共享数据库，这是不对的，而是数据库实例。 例如，如果我使用的是AWS并具有3个服务，那么我是否要在单个RDS实例上为每个服务创建3个数据库，还是要创建3个RDS实例，每个实例都包含一个数据库，供3个服务分别使用？ 如果在单个RDS实例上使用多个数据库是一个更好的主意，那么它会否决拥有独立服务的目的，因为： RDS实例的资源将在服务之间共享。在特定时间可能大量使用数据库的服务A是否会影响使用不同数据库但在同一RDS实例上的服务B？ 所有服务将取决于该RDS实例上的数据库版本。
2
您如何处理微服务架构中的共享概念？
我正在研究我正在开发的应用程序的体系结构模式，微服务方法似乎是一个不错的选择，但是我不确定如何处理服务之间的交互。 该应用程序主要处理用户，用户拥有的配置文件，照片以及代表照片中一对多配置文件的标签。可以想象有一些方法可以返回用户上传的照片，返回包含特定标记个人资料的照片，等等。 这是我设计基于微服务的体系结构的第一步，而我来自于启发式历史的整体式域模型。在那个世界中，控制器会将这些域对象缝合在一起，但是我很难理解如何以微服务方式工作。
5
微服务和存储过程
在微服务体系结构中，存储过程是否被视为不良做法？ 这是我的想法： 大多数有关微服务的书籍建议每个微服务使用一个数据库。存储过程通常在整体数据库上工作。 再次，大多数微服务架构书籍都指出，它们应该是自治的且松散耦合的。使用专门在Oracle中编写的存储过程，可以将微服务与该技术紧密结合。 大多数微服务架构书籍（我已经阅读过）都建议微服务应面向业务（使用域驱动设计（DDD）设计）。通过将业务逻辑转移到数据库中的存储过程中，情况已不再如此。 有什么想法吗？
3
跨微服务共享DTO的方法？
我的情况如下。 我正在设计一个系统，该系统旨在从各种类型的传感器接收数据，然后进行转换并将其持久化，以供以后的各种前端和分析服务使用。 我正在尝试将每个服务设计为尽可能独立，但是遇到了一些麻烦。团队已决定要使用的DTO。面向外部的服务（传感器数据接收者）将以自己独特的方式接收数据，然后将其转换为JSON对象（DTO）并将其发送给Message Broker。消息的使用者将确切地知道如何读取传感器数据消息。 问题是我在几个不同的服务中使用了相同的DTO。必须在多个位置实施更新。显然，我们的设计方式使得此处的DTO中有一些多余或缺失的字段，并且在更新服务之前不会有太大的问题，但这仍然困扰着我，并使我感到自己犯错误。它很容易变成头痛。 我在设计系统时会出错吗？如果没有，那么有什么解决办法，或者至少可以缓解我的担心？
1
我自己开发系统时，应该使用微服务吗？
我正在开始一个新的项目，尽管可能需要一个或两个其他开发人员将现有的应用程序或简单的脚本集成到主项目中，但我几乎将是该项目的唯一开发人员。该项目需要处理小规模的批量和流数据的摄取/处理，以及事件驱动和按需代码执行。框架的某些部分受CPU限制，而某些部分则受I / O限制。大多数数据必须存在于单个计算机上，但是我们能够创建集群并连接虚拟机以增加可用的计算能力。可能会有一个或多个小型Web应用程序依赖于此核心框架提供的服务。主要语言将是适用于几乎所有内容的Python。 我的问题是，考虑到我将自己完成大部分开发工作，我是否应该采用微服务方法来进行此类工作或坚持使用单一应用程序。我的想法是，微服务（使用Nameko）在具有不同执行模型（数据管道，事件启动，按需，Web应用程序等）的框架元素之间提供了自然的分隔，并提供了一种清晰的方式来分配工作负载和跨多个流程的沟通。我担心的是，我可能最终会使用一个Kubernetes集群来管理（我熟悉Docker，但对于Kubernetes来说还很陌生），为了促进系统运行，需要多个服务（rabbitmq，redis等），并可能有很多小的代码块来实际实现我们所需要的所有必要功能 对于只有一个开发人员的项目，微服务是否仍会简化这样的复杂系统的开发和维护？我是否应该考虑使用其他方法/系统/框架，或者减少以这种方式设计系统所涉及的开销？
4
微服务应该互相交谈吗？
我正在设计使用微服务的应用程序，但不确定使用哪种最佳机制从多个服务收集数据。 我相信有两种选择： 集成了“服务间”通信机制，该机制允许服务直接对话。在将合并的响应返回给API网关之前，API网关将调用单个服务，然后再调用其他服务来收集数据。然后，API将响应返回给调用方。（当对serviceB的调用需要serviceA的响应时，这必须是同步调用。IE单独的人和地址服务。） 让API网关直接调用每个服务，并在返回响应之前合并API中的数据。 我倾向于第二种选择，因为使服务彼此交谈会引入耦合，在这种情况下，我最好还是构建一个整体应用程序。但是，使用此选项时，我可以想到一些严重的缺点： 让API执行对多个服务的多次调用会增加API服务器的负载，尤其是在其中某些调用处于阻塞状态时。 这种方法意味着API必须“知道”应用程序正在尝试做什么（IE Logic必须被编程到API中才能依次处理调用服务，然后合并数据），而不仅仅是充当微服务的愚蠢“终点”。 我想知道解决此问题的标准方法是什么，是否还有我遗漏的第三种选择？
4
微服务和数据存储
我正在考虑将整体式REST API移至微服务体系结构，并且对数据存储有些困惑。如我所见，微服务的一些好处是： 水平可伸缩-我可以运行微服务的多个冗余副本以应对负载和/或服务器故障。 松散耦合-我可以更改微服务的内部实现而不必更改其他服务，并且我可以独立部署和更改它们等。 我的问题是数据存储。在我看来，有几种选择： 所有微服务共享一个数据库服务-这似乎完全消除了松耦合的任何好处。 每个微服务上的本地安装的数据库实例-我看不到横向扩展此方法的方法，因此我认为这不是一个选择。 每个微服务都有自己的数据库服务-这似乎是最有前途的，因为它保留了松散耦合和水平扩展的优势（使用冗余数据库副本和/或跨多个分片） 在我看来，第三种选择似乎是唯一的选择，但是对我来说，这似乎是难以置信的沉重负担，并且是一种过度设计的解决方案。如果我理解正确，那么对于具有4-5个微服务的简单应用程序，我将必须运行16-20台服务器-每个微服务两个实际的微服务实例（以防服务器故障，并且在不停机的情况下进行部署），以及每个微服务有两个数据库服务实例（如果发生服务器故障等）。 坦率地说，这似乎有些荒谬。要记住，一个现实的项目可能会提供4-5个以上的服务，而16-20个服务器运行一个简单的API，该不该？我是否缺少一些基本的概念来解释这一点？ 回答时可能会有所帮助的一些事情： 我是该项目的唯一开发人员，并将在可预见的将来。 我正在使用Node.js和MongoDB，但是我对与语言无关的答案很感兴趣-一个答案甚至可能是我使用了错误的技术！
3
分散数据管理-将数据库封装到微服务中
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我最近参加了一门软件设计课程，并且最近对使用“微服务”模型进行了讨论/推荐，在该模型中，服务的各个组成部分被分成了尽可能独立的微服务子组件。 提到的一部分是，不是遵循一种常见的模型，即所有微服务都与之通信的单个数据库，而是为每个微服务运行一个单独的数据库。 可以在此处找到措辞更好且更详细的解释：http : //martinfowler.com/articles/microservices.html在“分散数据管理”部分下 最突出的部分是这样说的： 微服务更喜欢让每个服务管理自己的数据库，或者是相同数据库技术的不同实例，或者是完全不同的数据库系统-一种称为Polyglot Persistence的方法。您可以在整体中使用多语种持久性，但是在微服务中它的出现频率更高。 图4 我喜欢这个概念，除其他外，我认为这是对维护的一项重大改进，并且有多个人在其中进行项目。也就是说，我绝不是经验丰富的软件架构师。有没有人尝试实现它？您遇到了哪些好处和障碍？
4
微服务架构中的大文件/数据传输
我的公司目前正在努力采用微服务架构，但是在此过程中我们遇到了一些麻烦（令人震惊）。我们面临的主要争论点之一是如何在我们的不同服务之间传递大量数据。 作为背景知识，我们有一个文档存储，可作为我们可能需要在公司范围内处理的任何文档的存储库。与所述商店的交互是通过服务完成的，该服务为客户提供了唯一的ID和流文档的位置。以后可以通过使用提供的ID进行查找来访问文档的位置。 问题是-对于我们所有的微服务而言，是否为了与文档进行交互而接受此唯一ID作为其API的一部分有意义吗？在我看来，这本质上是错误的-服务不再是独立的，而是依赖于文档存储的服务。尽管我确实承认这可能会简化API设计，甚至可能会带来一些性能提升，但所产生的耦合效果远不止于此。 有谁知道彩虹独角兽（Netflix，亚马逊，谷歌等）如何处理服务之间的大文件/数据交换？
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.