Questions tagged «soa»

我所看到的在具有微服务的系统中发生的主要问题之一是，事务跨不同服务时的工作方式。在我们自己的体系结构中，我们一直在使用分布式事务来解决此问题，但是它们带有各自的问题。迄今为止，僵局尤其令人痛苦。 另一个选择似乎是某种定制的事务管理器，它知道您系统内的流程，并会为您处理回滚，因为它是跨整个系统的后台进程（因此它将告诉其他服务回滚）如果它们出现故障，请稍后通知他们）。 还有其他可接受的选择吗？两者似乎都有其缺点。第一个可能导致死锁和许多其他问题，第二个可能导致数据不一致。有更好的选择吗？

80 architecture  soa  microservices 

我最近阅读了有关微服务体系结构的出色文章：http : //www.infoq.com/articles/microservices-intro 它指出，当您在Amazon上加载网页时，则有100多个微服务合作提供该页面。 该文章描述了微服务之间的所有通信只能通过API。我的问题是，为什么这么糟糕的说法是所有数据库写操作只能通过API进行，但是您可以自由地直接从各种微服务的数据库中进行读取。例如，可以说微服务外部只能访问少数几个数据库视图，以便维护微服务的团队知道只要保持这些视图不变，那么他们就可以尽可能多地更改其微服务的数据库结构。想。 我在这里想念什么吗？还有其他原因为什么只能通过API读取数据？ 不用说，我的公司要比亚马逊小得多（并且一直会这样），我们可以拥有的最大用户数约为500万。

64 architecture  web-services  soa  microservices  modularization 

如今，每个人都在进行SOA，即使有些人实际上并不了解全部内容。所以他们做错了。以此为类比，我知道REST是什么（或者至少我认为我是这样做的），并且想要做一些。但是我想做对。 所以我的问题是做REST的正确方法是什么？

36 rest  soa  resources  implementations 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 6年前关闭。 今天有人问我是否有“面向服务的体系结构”的经验，尽管我认为可以。在我看来，这个概念太混乱了，我不知道您怎么能诚实地回答这个问题。 我求助于Googling这个术语是为了获得对该概念的简洁定义以及它与其他体系结构的区别。在阅读了许多文章之后，我似乎能够找到的唯一通用线程是一个具有多个组件的系统，这些组件可以通过某种接口相互通信，也许稍微偏爱XML / SOAP。 似乎几乎所有应用程序都可以定义为SOA，尤其是Web应用程序。这个术语是否已经落入“ Web 2.0”陷阱中，并且变成了一个意味着您想要表达的含义的术语？ 我要离开这里吗？当你们听到这个词时，这意味着您有什么特别的意思吗？如果是这样，我希望有一个简洁的定义，可以清楚地说明什么是SOA，什么不是SOA。

25 terminology  soa 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我是Workflow开发的新手，我认为我并没有真正了解“大局”。或者换句话说，这些工具目前并没有在我的脑海中“点击”。 因此，似乎公司喜欢创建用于描述流程的业务图纸，并且在某个时刻有人决定可以使用像状态机这样的程序来实际控制线和方框（如图表）中的流程。十年后，这些工具非常庞大，极其复杂（我的公司目前正在使用WebSphere，并且我参加了一些培训，这是一个怪兽，甚至像Activiti这样的工作流工具的所谓“极简主义”版本也是如此。庞大而复杂，尽管不如WebSphere afaict的野兽那么复杂）。 用这种方法最大的好处是什么？我可以理解简单的折线图和箱形图很有用，但是据我所知，这些东西目前是可视化的编程语言，带有条件和循环。在这里，程序员似乎在行和框层中进行了大量工作，在我看来，这就像是一种非常糟糕的，非常基础的可视化编程语言。 如果要走的那么远，为什么不只使用某种脚本语言呢？人们有没有为此把婴儿和洗澡水一起扔出去？线条和盒子的事物是否被带到了荒谬的水平，或者我只是不理解所有这些的价值？ 我真的很想看到使用此技术的人们对此进行辩护并理解其用途的理由。我看不到其中的价值，但我认识到我对此也很陌生，可能还不太了解。

22 java  workflows  soa  bpm 

假设您正在考虑将应用程序分解为服务。是否有充分的理由采用SOA方法，而不是仅仅创建一个可以由需要它的应用程序加载的库API。

22 api  soa  services 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 今天浏览SO时，我发现了这个 这里问题，它从下面开始： 当然，您会告诉我SOAP已被弃用，而我被迫使用它 到目前为止，在SO上发现了很多这样的声明，这只是触发了我提出这个问题。 REST有它的用途，SOAP有它的用途，在某些地方它们作为功能相交，但不能相互替换。 所以我想知道，为什么人们认为SOAP被“弃用了”？是无知吗？SOAP和WS- *规范的复杂性？REST炒作？什么？ 如果您认为不赞成使用SOAP，请告诉我原因。我很好奇！

20 web-services  soa  soap 

前景 我们正在从单一平台过渡到更加面向服务的体系结构。我们正在应用非常基本的DDD原则，并将我们的域划分为不同的有界上下文。每个域都是分布式的，并通过Web API（REST）公开服务。 由于我们的业务性质，我们提供诸如订舱，服务，客户，产品等服务。 我们还建立了一个Identity Server（基于Thinktecture Identity Server 3），其主要作用是： 集中身份验证（给定颁发令牌的凭据） 在令牌中添加声明，例如：客户范围（按照客户，我是指执行请求的应用程序），客户标识符（按照客户，我是指使用该应用程序的人） 我们还介绍了API网关的作用，它可以集中外部访问我们的服务。API网关提供的功能不需要深入了解内部域，例如： 反向代理：将传入请求路由到适当的内部服务 版本控制：API网关的一个版本映射到内部服务的不同版本 身份验证：客户端请求包括由Identity Server发行的令牌，API网关会验证令牌（确保用户说的是她的身份） 节流：每个客户端的请求数量限制 授权书 与授权有关，这不是在API网关中管理，而是在内部服务本身中进行管理。我们目前正在执行两种主要的授权类型： 基于客户范围的授权。示例：客户端（使用我们的API的外部应用程序）需要范围“ bookings”来访问Bookings服务API端点 基于客户的授权。示例：仅当客户（使用应用程序的自然人）是预订的参与者时，才能从预订服务访问端点GET / bookings 为了能够处理内部服务中的授权，API网关仅转发令牌（在将请求路由到内部服务时），该令牌既包含有关客户端（执行请求的应用程序）的信息，也包含有关客户的信息（作为声明）有人在客户端应用程序中登录的情况）。 问题描述 到目前为止，到目前为止还不错，直到我们引入了服务间通信（某些服务可以与其他服务进行通信以获得一些数据）。 题 在服务间通信中，我们应该如何处理授权？ 考虑的选项 为了讨论不同的选项，我将使用以下示例方案： 我们有一个名为ExternalApp的外部应用程序，该应用程序访问我们的API（可以将ExternalApp视为客户端），以建立预订流程 ExternalApp需要访问预订服务，因此我们授予ExternalApp范围“预订” 在内部（这对于ExternalApp来说是完全透明的），预订服务使服务服务获得预订的默认服务，例如航班，保险或租车 在内部讨论此问题时，会弹出几个选项，但我们不确定哪个选项最好： 当Bookings与Services通信时，它应该只转发他从API网关收到的原始令牌（表明客户端是ExternalApp）。 启示：我们可能需要将不应该被授予的范围授予ExternalApp。示例：ExternalApp可能需要同时具有“预订”和“服务”范围，而只有“预订”范围才足够 当Bookings与Services通信时，它转发一个令牌，指示该客户端现在已成为Bookings（而不是ExternalApp），并且添加了一个声明，表明Bookings模仿了原始客户端ExternalApp 通过还包括原始客户端是信息ExternalApp的服务业务也可以做逻辑如过滤取决于原调用一些服务（如用于内部应用程序，我们应该返回所有的战斗，外部应用程序只有一些） 服务不应相互通信（因此我们甚至不应面对这个问题） 预先感谢您的输入。

18 api  microservices  soa  authorization 

我想将Spring框架集成到我的项目中，尤其是集成到服务器端。 因此，我不想将其放在war文件的WEB-INF文件夹中。 我是否应该将applicationContext.xml放入每个层中（意味着每个项目都被划分为不同的项目？（服务，域和DAO）） 有什么好的做法？

18 java  soa  spring 

我最近一直在阅读Hohpe和Woolf的企业集成模式，Thomas Erl的一些关于SOA的书，以及观看Udi Dahan等人的各种视频和播客。在CQRS和事件驱动系统上。 我工作场所中的系统耦合度很高。尽管理论上每个系统都有其自己的数据库，但是它们之间有很多连接。实际上，这意味着所有系统都使用一个庞大的数据库。例如，只有一张客户数据表。 我读过的大部分内容似乎都建议对数据进行非规范化处理，以便每个系统仅使用其数据库，并且使用消息传递将对一个系统的任何更新传播到所有其他系统。 我认为这是在SOA中强制执行边界的一种方法-每个服务都应该有自己的数据库，但是我读到以下内容： /programming/4019902/soa-joining-data-across-multiple-services 这表明这是错误的做法。 隔离数据库似乎是解耦系统的一种好方法，但是现在我有点困惑。这是一条好路吗？是否曾经建议过在SOA服务，DDD绑定上下文，应用程序等上隔离数据库？

17 soa  integration  cqrs  eai  domain-driven-design 

最近，我一直在阅读有关微服务的很多文章，这是到目前为止我得出的一些结论（如果我在任何时候错了，请更正我）。 微服务架构与域驱动设计配合得很好。通常一个MS代表一个有界上下文。 如果微服务A需要驻留在微服务B中的功能，则我的模型可能是错误的，并且A和B 实际上应该是一个微服务/ BC。 微服务之间的同步通信（直接HTTP请求）很糟糕，导致它违背了微服务的目的，并引入了组件之间的耦合。 服务之间的异步通信是可取的。服务应将事件发布到消息队列，以便其他服务可以订阅和处理事件的一部分，或使用它复制上下文所需的部分数据。这样，服务可以处理请求，甚至其他服务也已关闭，而在同步通信中则不会。 如果微服务A发布事件，微服务B订阅该事件并产生一个新事件作为结果，则微服务A不应是一个正在处理的新创建事件，因为这将是循环依赖性。在这种情况下，我们应该引入第三种微服务，或者将A和B合并到AB微服务中。 微服务实际上是一个误导性术语。我们应该为小环境而努力，但这不是必须的。术语不应该是“微服务”，而是“ 足够大以进行工作服务 ”。 微服务使我们可以更轻松地引入新功能，而不必担心会破坏整个系统。可以通过引入新服务或重构现有服务之一来完成。 每个微服务都应具有自己的数据存储。数据复制/复制是此体系结构中的理想行为。 除了证实我对这种体系结构的理解之外，问题的其他部分主要与服务发现有关。如果服务异步通信，并使用亚马逊SQS之类的中央事件队列，这是否意味着服务发现在这样的体系结构中没有位置？ 服务不应对系统中的其他服务有任何了解。他们只知道应该发布或订阅的上下文和事件吗？

15 architecture  domain-driven-design  soa  microservices 

SOA主要服务设计原则之一是服务可组合性原则（https://en.wikipedia.org/wiki/Service_composability_principle）。 这个想法是，通过使用现有服务作为构建模块来组合新服务，可以迅速开发新服务。类似于实现新方法时如何调用对象的现有方法。这就是SOA可以大大提高生产力的地方。 实际上有人真的这样做吗？我已经在书面文本中看到了无休止的重复，但是我自己还没有在现实世界中工作的经验。本书的大部分内容都没有提及事务处理，这在我看来是实现可组合服务的最大障碍。 首先，在组成任何非平凡的服务之前，您确实确实需要解决交易问题。当然，如果该示例具有服务“ findCurrentTime（）”和“ writeLogMessage（）”，则很容易不必担心事务，但是在具有诸如“ depositMoney（）”和“ withdrawMoney（）”之类的真实示例时则不必担心。 我知道两个选择： 使用WS-Atomic Transaction或类似工具实施真实交易 实施基于补偿的解决方案，使用“ cancelA（）”或类似方法补偿对A的调用，如果对B的调用失败 这两个问题似乎都非常棘手/对我来说几乎无法使用： WS-原子交易 一个很大的复杂性，大多数的建议，我发现只是警告“疼痛的屁股，不这样做” 支持是有限的，例如，如果您使用开源ESB，则主要替代产品ServiceMix，Mule或WSO2不支持它 赔偿金 对我来说，实施赔偿处理似乎很复杂。如果服务A成功并且我们从未从服务B得到答案并且不知道它是失败还是成功，我们该怎么办？手动处理这种逻辑（作为合成服务的实现者）使我想裂开手腕-这是某些工具应该为我完成的工作！ 我也看不到如何在非平凡的服务中使用补偿方法。假设您的服务A是“ depositMoney（）”，并且成功，其他一些操作很快将钱转移到其他地方，然后我们收到“ compensateDepositMoney（）”，我们现在该怎么办？好像一大罐蠕虫。 在我看来，服务组合是SOA的一项基本原则，如果您不能（方便地）组合服务，那么您真的无法获得SOA的好处。现实是什么？90％的SOA用户在没有实际服务组合的情况下使用“ crispled SOA”？还是大多数用户实际上使用服务组合，而我却夸大了它的难度？

15 web-services  soa  transaction 

我正在构建一个新的应用程序，并且正在阅读有关微服务架构的信息。从开发，部署和生命周期管理的角度来看，体系结构本身很有意义。但是出现的一个问题是关于如何处理主数据。 例如，我有2个应用程序-例如销售应用程序和票务应用程序。假设这两个应用都是作为自己的微服务构建的。但是，这两个应用程序在部署时（假设分别部署，例如Sales使用MongoDB，Ticketing使用MariaDB），则需要访问相同的主数据实例，例如Accounts，Products。这意味着将有一个给定主数据实体的所有者应用程序（例如，对于帐户，可能是销售应用程序）和一个有兴趣的一方（例如，票务应用程序将需要有关帐户的信息）。 有多种方法可以实现：-从主方到感兴趣方的数据复制-从感兴趣方到主方的同步读取（微服务体系结构范例不建议同步依赖性）-自己的集中式存储库 即使在客户中，也可能有一个核心部分，对于销售和票务都是通用的（例如，帐户名，地址等）。但是，帐户的某些方面可能仅与销售相关，而其他方面仅与票务相关。 关于上述任何选项有什么想法/最佳实践/意见吗？

14 soa  services 

我正在工作的地方正在尝试建立一些基本规则，而我们现在正在争论的是本地库与Web服务之间的代码重用。Web服务似乎是大多数公司中的热门选择，这就是大多数开发人员都倾向于的。 我只是看不到如何有效地将Web服务用于任何严肃的工作。如果无法使用事务，如何安全地执行多个服务调用？ 假设我有一个Cron工作，它从我们的数据库中获取满足一定条件的客户，这些客户需要通知他们。将向他们发送传真，电子邮件并创建票证以在内部跟踪问题。在for循环中，每个客户将发生3个不同的服务调用。 如果那里的任何地方发生错误，则可能会例如将传真和电子邮件发送给客户，但不会创建故障单。或更糟糕的是，此Cron作业可能包含一个错误，导致每次都在同一时间失败，并反复向同一位客户发送电子邮件。如果所有库都是本地的，则所有内容都可以包装在事务中，而不会发生任何事情。但是在此示例中，我们使用的是Web服务。 请注意，电子邮件和传真方法实际上将数据插入到数据库支持的队列表中，而这些表又由单独的cron作业进程处理。因此，如果需要，可以免费中止对“发送电子邮件”和“发送传真”服务方法的调用。 一种选择是将整个代码块放在Web服务本身中，以便Web服务本身将在事务中调用电子邮件，传真和票证创建方法。但是随后我们创建了一个仅用于事务处理的Web服务方法。没有确凿的理由，我们实际上需要从该cron脚本之外的任何地方调用此方法。 您通常将如何处理此方法？

14 web-services  soa  services 

我们公司正在启动一个相当大的SOA计划。我们正在做很多正确的事情：良好的沟通；在适当的地方购买工具的钱；并且我们已经引进了一些优秀的专业知识来帮助我们过渡。 我们正在尝试制定可以作为一个整体遵循的标准，其中一项提议的标准使我颇为困扰： 我们已经在模式上进行了标准化，其中每个操作都需要一个请求对象并返回一个响应对象。 我意识到这对于许多人来说或多或少是一种标准方法，但是我在问我为什么要打扰？（我对所接受的智慧不是很好，我需要一些理由）。 我将提供的大多数服务是简单的组织元数据检索。例如，找到特定用户的安全策略。这需要一个用户ID，无其他要求。该标准告诉我，我应该将此请求包装在一个对象中，并将返回的策略包装在一个响应对象中。 查看合同产生的WSDL会加剧我的不安。WCF自动生成请求和响应消息，甚至包装请求/响应对象。 我完全理解，如果您要发出复杂的请求，那么就需要一个复杂的输入对象。即使服务不涉及，那也是您要做的。 我的问题是为什么在以下情况下我应该自动包装请求和响应： 它使简单服务的表现力降低 无论如何，您都会为复杂的服务而做 WCF无论如何都会创建请求/响应消息 我发现以下论点支持这种方法： 它通过允许将可选参数放入请求对象中来支持版本控制。 过去，我做了很多的COM，我认为这几乎是版本控制的反模式。对于某些事情，我想它会有所帮助，但我希望它会有所帮助，无论如何您已经有一个参数对象。 它允许将常见数据和行为隔离到基类 这个给我带来一些分量。 它使人们远离RPC样式的行为而转向消息传递的行为 我已经在Microsoft网站上阅读了此内容，并从我们的专家那里听到了，但是我仍然不清楚它们的含义或价值所在。看起来自然的界面是否使人们倾向于忘记他们正在调用远程服务？ 我正在考虑重构大约300种方法的签名，因此这是不小的痛苦。我非常喜欢实现的一致性，因此我愿意承担痛苦，这将有助于知道最终所有这些都是值得的。

12 soa  wcf