问题描述
我是一家大型金融公司的架构师，我们正着手在不同国家/地区实施面向业务的新信息系统.
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.
从一开始，核心思想就是尽可能遵循面向微服务的原则(并确保工程师阅读 Sam Newman 的《构建微服务》一书).
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).
现在我已经走到了十字路口.我们的服务主要是使用 Swagger 进行自动化文档编制的 JSON REST 服务，但为了在我们的业务流程中使用这些服务并确保不将业务逻辑写入这些服务域之外的服务中，我们一直使用 Camunda 作为编排工具.Camunda 很好(尽管有些人认为 Corezoid 是替代品)，但在其他优雅的服务集方面有些笨拙.
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.
当服务交互时，它会创建一个耦合级别——至少，这种耦合是服务必须维护"的一些 API(JSON 或其他)，以便其他服务可以与其交互.
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.
另一种耦合类型是时间耦合 - 这是您在请求-回复情况下得到的(并且您可以在事件驱动的系统中消除)但是，编排与编排与这些差异无关(即使编排主要与请求相关联)/reply) - 它是关于中央控制和治理 vs. 灵活性和偶然性.
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.
在两者之间进行选择是一种平衡行为(就像大多数架构决策一样)，例如，Netflix 建立在编排上很长时间，但后来发现他们需要一些控制权和 引入了编排引擎.没有什么是灵丹妙药:)
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 :)
就个人而言，我更喜欢编舞，因为它减少了耦合性和灵活性，并且喜欢打开 Zipkin 之类的工具来带来一些秩序陷入混乱.
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.
这篇关于大规模编排与编排的面向服务的架构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！