问题描述
我是一家大型金融公司的架构师，我们正开始在不同国家/地区实施面向业务的新信息系统.
从一开始，核心思想就是尽可能遵循面向微服务的原则(并确保工程师已阅读Sam Newman撰写的《构建微服务》一书).
到现在，我已经到了十字路口.我们的服务主要是使用Swagger进行自动化文档编制的JSON REST服务，但是为了在业务流程中使用这些服务并确保不将业务逻辑写入这些服务范围之外的服务中，我们一直在使用Camunda作为业务流程工具. Camunda是很好的(尽管有些人认为Corezoid可以替代)，但是在其他方面却很精致的服务方面有些笨拙.
现在，服务编排是大多数工程师都非常熟悉的概念.但是由于仍然具有驱动所有事物的中央引擎，我对此并不完全满意.在以后的时间进行更换非常昂贵(尽管比整体式的更换仍然便宜).即使将此中央引擎拆分为多个引擎(今天实际上就是这种情况)，也不一定会使它变得更好.
近年来，微服务向编排为(接近事件驱动)架构的方向发展.在这一点上，我正在寻求面临类似十字路口决策点的工程师和建筑师的建议.
我绝对喜欢解耦体系结构的想法，尽管对杀死整体组件和拥有优雅的独立服务感到很满意，但在当前精心设计的解决方案中，我仍然在整个业务流程中发现了很多依赖关系，而这些问题实际上并不存在./p>
这与我们避免事件无关.我们实际上还在我们的体系结构上实现了事件，以便使许多流程与以下核心原则脱钩:如果您不需要同步响应，而只需要通知发生的事情以启动另一个流程，那么可能会发生一个事件.被另一个开始执行的进程捕获.编排更易于解释和可视化，更容易被技术娴熟的业务用户进行调整和修改.而且我认为从业务角度进行测试和验证更容易.这样的(通常)编排架构也期望良好的服务发现和高质量的自动化文档以及非功能性需求，这些都是我非常重视的东西.
所有这些在编排方法中对我来说都是问题，因为我没有大规模运行它的第一手经验，只有一些本地测试原型.
但是我想你知道我来自哪里.我正在尝试考虑替代方案，而不必后悔最终以其他方式推动公司发展.
也许您可以在类似情况下分享自己的经验，或者分享有趣的一两个链接?还是我正在寻找尚不存在的银弹?
服务需要交互-不交互的服务不是同一系统的一部分.搜索需要访问目录，购物车没有从页面中获取价格信息，帐户需要购买历史记录，推荐者需要购买历史记录，购物车需要验证当前可用的优惠券，库存需要了解一些信息已购买等.
设置服务边界以最大程度地减少所需的交互.将服务切成较小的组件可能很有意义，但是如果它们共享数据库(内部结构)，则它们是服务的不同方面.
服务交互时，它会创建一个耦合级别-至少，此耦合是服务必须维护"的某种API(JSON或其他)，以便其他服务可以与其交互.
另一种耦合类型是时间耦合-这是您在请求-答复情况下得到的(并且可以在事件驱动的系统中消除).但是，编排与编排并不是这些差异(即使编排主要与请求相关联)/reply)-这是关于中央控制和治理与灵活性和偶然性的关系.
编排具有将业务逻辑从服务中迁移到编排中的风险，而编排则具有混乱的风险.顺便说一句，直接请求/答复集成在这两个方面都是最糟糕的，但是在系统足够小的情况下，简单性会取胜.
例如，在两者之间进行选择是一种平衡行为(就像大多数架构决策一样)，Netflix在编排上建立了很多时间，但随后发现他们需要一些控制权，并且引入了编排引擎.没什么是银弹:)
我个人更喜欢编舞，因为它减少了耦合和灵活性，并喜欢使用打开Zipkin 之类的工具来订购商品陷入混乱.
I'm an architect in a large scale financial company and we are in the beginning of implementing a new business oriented infosystem across our different countries.
From the very early on the core idea has been to follow microservice oriented principles as much as possible (and making sure engineers have read Building Microservices book by Sam Newman).
By now I've come to crossroads. Our services are primarily JSON REST services using Swagger for automated documentation, but in order to use these services in our business processes and making sure not to write business logic into services outside the domain of those services, we've been using Camunda as an orchestration tool. And Camunda is fine (though some have considered Corezoid as an alternative), but somewhat clumsy in what is an otherwise an elegant set of services.
Now service orchestration is a concept pretty familiar to most engineers. But it is one that I am not entirely happy with due to still having a central engine that drives everything. It is incredibly expensive to replace later down the road (though still cheaper to replace than a monolith). And even if this central engine is split into multiple engines (which is actually the case today), it does not necessarily make it much better.
In recent years there has been a movement with microservices towards choreographed (close to event-driven) architecture. It is at this point where I am looking for advice from engineers and architects who have faced similar crossroad decision points.
I absolutely love the idea of decoupled architecture and despite feeling good about killing monoliths and having elegant independent services, I still detect a lot of dependencies in business process as a whole in current orchestrated solution in where it should not actually exist.
And it's not like we are avoiding events. We have actually implemented events on our architecture as well in order to decouple many processes with the core principle that if you don't need a synchronized response and just need to notify of something happening to initiate another process an event is put up that may be caught by another process that starts executing. And orchestration is easier to explain and visualize, it is easier to tweak and modify by more technical minded business users. And I think it is easier to test and validate from business perspective. Orchestrated architecture like this also (usually) expects a good service discovery and quality automated documentation and non-functional requirements which are all things I value greatly.
All of those things that are a question to me in choreographed approach since I don't have first-hand experience in running this in large scale - just some local test prototypes.
But I think you see where I am coming from. I'm trying to consider alternatives without having to regret driving the company all the other way in the end.
Perhaps you can share your own experience with a similar situation or share an interesting link or two? Or am I looking for a silver bullet that doesn't exist yet?
Services need to interact - services that don't interact are not part of the same system. The search needs access to the catalog, the cart doesn't get the price info from the page, the account needs the purchase history, the recommender needs purchase history, the cart needs to verify the currently available coupons, the inventory needs to know something was purchased etc.
Service boundaries are set to minimize the needed interactions. It can make sense to cut a service to smaller components but if they share a database (internal structure) they are different aspects of the service.
When services interact it creates a level of coupling - at the least, this coupling is some API (JSON or otherwise) that the service has to "maintain" for so other services can interact with it.
Another coupling type is temporal coupling - which is what you get in request-reply situations (and you can eliminate in event driven systems) However, Orchestration vs. Choreography is not about these differences (even though orchestration is mostly associated with request/reply) - it is about central control and governance vs.flexibility and serendipity.
Orchestration has risks like migrating business logic out of services into the orchestration while choreography runs the risk of chaos. By the way, direct request/reply integration has the worst of both worlds but wins on simplicity when systems are small enough.
Choosing between the two is a balancing act (like most architectural decisions) for instance, Netflix built on choreography for a lot of time but then found they need some control back and introduced an orchestration engine. Nothing is a silver bullet :)
Personally, I like choreography better because of the reduced coupling and flexibility and favor tools like open Zipkin to bring some order into the chaos.
You can see a partial example for an orchestration based arch in slides 10-22 of a presentation I did about microservices
这篇关于大规模vs编排的面向服务的体系结构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！