大规模的精心策划与精心设计的面向服务的架构？

作者: 镜乃Kagamino
发布时间: 2024-06-11 07:22:40 (1月前)
转自：

3 条回复

0#
回复此人
逆转的风 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 我想我知道你来自哪里，最近将系统重新设计为“微服务”架构。我喜欢（并使用）这些人的方法： <a href="http://scs-architecture.org/" rel="nofollow noreferrer"> http://scs-architecture.org/ </A> 重点是，你试图避免你的“服务”之间的交叉依赖，这基本上使编排过时。困难的部分是将您的问题域分解为块，这些块对于任何已执行的业务案例都不需要彼此。它们可能需要不同类型的数据，这些数据可能是“共享”，也可能不是“共享”，如同在多个系统中一样，但是对于任何给定的业务案例，它们不需要它们之间的同步调用。 这与Netflix正在做的事情完全不同。那些人/女孩正在通过不同的服务层进行链式调用，每个服务层都将其逻辑添加到“进程”中。在某些情况下，此模型可能适合，并且可能适合Netflix的情况。但对你来说可能没有必要。 理想的自包含系统将完全独立于其他自包含系统，涵盖一个或多个高度凝聚力 业务功能 （从UI到Persistence的全面深度！），并且不会同步调用任何其他系统。理想的系统只需通过其Web（HTML）界面提供链接，即可让客户“协调”。 想想更像亚马逊。 “登陆页面”是与“搜索”不同的应用程序，它仍然与“结帐”不同。它们完全不同，有时甚至看起来有点不同！由HTML中的链接和表单集成，未明确编排。 这可能就是你要找的东西。 一些警告：一些人的第一直觉是拥有“客户”微服务，或“产品存储库”微服务，类似。这不会导致自包含系统，因为您需要同步调用这些东西，使它们成为“中心”组件。关键是要分割业务领域，因此有限的背景是Eric Evans。 </DIV>

编辑
1#
回复此人
你抱着孩子@先跑 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 服务需要交互 - 不交互的服务不属于同一系统。搜索需要访问目录，购物车不从页面获取价格信息，帐户需要购买历史记录，推荐者需要购买历史记录，购物车需要验证当前可用的优惠券，库存需要知道某些内容被购买等 设置服务边界以最小化所需的交互。将服务切割为较小的组件是有意义的，但如果它们共享数据库（内部结构），则它们是 <a href="http://arnon.me/2017/03/services-aspects/" rel="nofollow noreferrer"> 服务的不同方面 </A> 。 当服务交互时，它会创建一个耦合级别 - 至少，这种耦合是服务必须“维护”的一些API（JSON或其他），以便其他服务可以与之交互。 另一种耦合类型是时间耦合 - 这是您在请求 - 回复情况下获得的（并且您可以在事件驱动系统中消除）但是，Orchestration vs. Choreography不是关于这些差异（即使编排主要与请求/回复相关联） - 它涉及中央控制和治理与灵活性和偶然性。 业务流程存在风险，例如将业务逻辑从服务迁移到业务流程中，而编排则存在混乱的风险。顺便说一下，直接请求/回复集成在两个世界中都是最糟糕的，但是当系统足够小时，它会在简单性上获胜。 在两者之间进行选择是一种平衡行为（就像大多数架构决策一样），例如，Netflix在编排的基础上建立了很长时间但后来发现它们需要一些控制和 <a href="https://github.com/Netflix/conductor" rel="nofollow noreferrer"> 介绍了一个编排引擎 </A> 。什么都不是银弹:) 就个人而言，我更喜欢编舞，因为它减少了耦合和灵活性，并且喜欢这样的工具 <a href="http://zipkin.io" rel="nofollow noreferrer"> 打开Zipkin </A> 把一些秩序带入混乱。 您可以看到基于业务流程的arch的部分示例 <a href="https://www.slideshare.net/arnonrgo/microservices-past-and-future-its-dj-vu-all-over-again" rel="nofollow noreferrer"> 我做了关于微服务的演示文稿的10-22页 </A> </DIV>

编辑

登录后才能参与评论