问题描述
背景：由于长期的整体式痛苦，具有联盟模型的国际公司正在转变为微服务。具有快速部署的自治团队是非常可取的。尽管从理论上讲，服务的确确实彼此依赖以获取更高的功能，但它们是自治的（独立开发和部署）。由于这是联邦模式和分散控制，因此我们不能像联合国一样强加严格的规则。没有一个可以管理依赖关系的治理平台，这是由于不同国家生产的版本不同，我们预见到了无法控制的混乱。
Background: an international company with a federation model is transforming into Microservices due to chronic Monolithic pain. Autonomous teams with quick deployment is highly desirable. In spite of theory, services are indeed dependent on each other for higher functionality, but are autonomous (independently developed and deployed). Since this is a federation model and decentralized control, we cannot impose strict rules - just like the UN. Without a governance platform that will manage dependencies else due to the multiple versions in production in different countries, we foresee uncontrollable chaos.
让我们需要协作的一组微服务兼容性集。可以部署服务，但可能无法满足其兼容性集中的更高功能。例如，MicroService A-4.3是完全自治的，已部署且运行良好。但是，要满足BusinessFunctionality 8.6，它必须与MicroService B-5.4和MicroService C-2.9一起使用。它们（A-4.3，B-5.4和C-2.9）一起形成兼容性集。
Let's call set of Microservices that needs to collaborate a "Compatibility Set". A service can be deployed but may not satisfy the higher functionality in its Compatibility Set. For example MicroService A-4.3 is fully autonomous, deployed and working perfectly. However to satisfy BusinessFunctionality 8.6 it must work together with MicroService B-5.4 and MicroService C-2.9. Together (A-4.3 , B-5.4 and C-2.9) they form a "Compatibility Set"
有两种方法可以解决此难题。现实生活中的微服务，橡胶在路上行进，从经验中学习...
There are two approaches to this dilemma. Microservice in real life where the rubber hits the road and the learning from experience begins...
方法1）治理平台
Rationale ：在100多个国家/地区的国际公司中的联邦模式。这意味着中央IT部门可以制定模型，但各个国家/地区可以选择自己的命运-而且他们经常这样做。它经常混乱，中央IT团队陷入困境。 DDD是理想世界的解决方案，在该世界中，版本不一致不会破坏功能，例如发布不适合于兼容性集的服务，这些都是单独责备的，但是它们一起崩溃或导致功能有缺陷或不一致的功能。
Rationale: Federal model in an International company in 100+ countries. Which means Central IT can lay down the model but individual countries can choose their own destiny - and they frequently do. It frequently devolves to chaos and the Central IT team is on the hook. DDD is the solution for an ideal world where version inconsistencies do not derail functionality like releasing services which do not fit into the Compatibility set, individually blameless but together they fall apart or result in flawed or inconsistent functionality.
- 没有同质性，甚至没有术语的标准化
- 开发人员技能混杂，很多初级，很多学习被动编程和云原生技术
- 边界上下文在很大程度上取决于共享词汇表，并且它可能变得微妙，但是在国际化，混合技能，零碎的，具有多个场景的场景中，这是不可能强制实施和幼稚的运行这样的版本
- 在这样的异构系统中，单一业务模型的标准化是不现实的（但很理想）
- There is no homogeneity, there isn't even standardization of terminology
- Developers are mixed skill, many junior, and many learning reactive programming and cloud native technologies
- Bounded Context heavily depends on Shared Vocabulary and it can get subtle, but this is impossible to enforce and naive to assume in an International, mixed skill, fragmented scenario with multiple versions running
- Standardization on a Single Business Model is not realistic in such a heterogeneous system (but ideal)
当中央IT对此混乱负责时，该怎么办？
How what is Central IT to do when they're held responsible for this Chaos?
加强治理平台
创建一个微服务治理系统或框架来实施依赖关系管理。它在设计和运行时通过清单来验证和加强对特定微服务的依赖性，并执行一些检查和平衡以验证所提供的服务实现-兼容性集。
Enforce a Governance PlatformCreate a Microservices governance system or framework to enforce dependency management. It verifies and enforces at design and run time dependencies on a particular Microservice through a manifest and performs some checks and balances to verify the service implementations being offered - the "Compatibility Set".
方法2）域驱动设计（DDD）
DDD是关于不断发展的域建模的领域，其中领域专家（通常是业务利益相关者或分析师）将与开发人员一起设计系统。在每个域中，形成了一种普遍存在的语言，因此在该上下文中，相同的词始终表示相同的事物。要意识到的重要一点是，在系统的一部分中，订单可能意味着一件事，例如可能意味着产品列表。在系统的另一部分中，订单可能意味着其他含义，可能意味着发生了金融交易。如果我的服务需要获取订单列表，那么这里描述的模型可能会崩溃，也许那里有一种功能可以提供订单列表，但是它们是哪些订单？产品清单或财务交易？在这里，尝试协调尽可能多的开发人员，所有人都必须使用相同的语言，这是注定要失败的不可能完成的任务。
Approach 2) Domain Driven Design (DDD)DDD is about modelling domains that are constantly evolving, where domain experts (typically a business stakeholder, or perhaps an analyst) will work alongside developers to design the system. Within each domain, a ubiquitous language is formed, such that within that context, the same word always means the same thing. An important thing to realise is that in one part of your system, "Order" might mean one thing, it might mean for example a list of products. In another part of your system, "Order" might mean something else, it might mean a financial transaction that happened. This is where the model you describe can fall down, if my service needs to get a list of orders, perhaps there is a capability out there that supplies a list of orders, but which orders are they? The list of products or the financial transaction? Trying to coordinate as many developers as you have to all use the same language here is an impossible task that is doomed to fail.
在DDD中，而不是尝试对此进行管理在系统级别上，并强制每个服务使用相同的Order定义，DDD包含了固有的复杂性，即协调涉及大量开发人员的大型部署，并允许每个团队独立工作，根据需要与其他团队进行协调，而无需通过一些集中的依赖管理系统。 DDD中使用的术语是有界上下文，其中在一个上下文中，Order表示一件事，而在另一有界上下文中，Order可以表示另一件事。这些上下文可以真正真正地自主运行-您将服务描述为自主的，但是如果它们必须通过注册并将依赖项提供给中央注册表来使它们的顺序定义与整个系统相匹配，那么实际上它们与其余的紧密耦合在一起。系统以及它所认为的顺序是什么—最终，您将经历所有痛苦的整体耦合，以及构建分布式系统的所有痛苦，并且如果尝试采用此服务，您将不会意识到微服务的许多好处
In DDD, rather than trying to manage this at a system level and force every service to use the same definition of Order, DDD embraces the inherent complexity in coordinating very large deployments with huge numbers of developers involved, and allows each team to work independently, coordinating with other teams as needed, not through some centralised dependency management system. The term used in DDD is bounded contexts, where in one context, Order means one thing, and in another bounded context, Order can mean another thing. These contexts can function truly autonomously – you describe your services as being autonomous, but if they have to match their definition of order with the entire system by registering and supplied dependencies to a central registry, then really they are tightly coupled to the rest of the system and what it considers an order to be – you end up with all the painful coupling of a monolith, with all the pain of building a distributed system, and you won’t realise many of the benefits of microservices if you try to take this approach.
因此，基于DDD的方法从不尝试采用笨拙的方法在系统级别上增强依赖关系或功能，而是允许各个团队无需中央协调即可工作，如果服务A需要与服务B进行交互，则管理服务A的团队将与管理服务B的团队一起工作，他们可以在其有限上下文之间建立接口，并就langua达成协议该接口的ge。这些团队之间必须相互管理依赖关系，在系统级别，事情可以保持不透明/不强制执行。
So a DDD based approach doesn’t ever try to take a heavy handed approach of enforcing dependencies or capabilities at the system level, rather, it allows individual teams to work without needing central coordination, if Service A needs to interact with Service B, then the team who manages Service A will work with the team that manages service B, they can build an interface between their bounded contexts, and come to an agreement on language for that interface. It is up to these teams to manage their dependencies with each other, at the system level things can remain quite opaque / unenforced.
我们经常看到人们实现微服务但最终得到的系统与整体系统相比，即使不是更不灵活，通常也更脆弱。也称为 Minilith或 Monolith 2.0的微服务需要对架构和软件开发流程进行全面的重新思考，不仅需要允许服务自治和独立管理，而且还要求团队独立而不是集中管理。集中管理系统中的依赖关系和功能很可能会阻碍成功构建基于微服务的系统。
Too often we see people implement "Microservices" but end up with a system that is just as, if not more inflexible, and often more fragile, than a monolith. Also called a "Minilith" or "Monolith 2.0" Microservices require a complete rethink of architecture and software development processes, and require not just allowing services to be autonomous and independently managed, but also for teams to be independent, not centrally managed. Centralising the management of dependencies and capabilities in a system is likely to be an inhibitor to successfully building a microservice based system.
邀请了智能，务实的评论...
方法1（治理）是务实和战术性的，旨在解决非常现实的挑战。问题是-它会破坏企业的长期战略DDD模型吗？
Approach 1 (Governance) is pragmatic and tactical and intended to solve very real challenges. Question is - will it undermine the long term strategic DDD model of the Enterprise?
方法2（DDD）是理想且有抱负的解决方案，但没有解决那些真正的挑战我们现在必须处理。
Approach 2 (DDD) is ideal and aspirational but doesn't address the very real challenges that we have to deal with right now.
意见？思想？评论？
推荐答案
我还处理了问题中描述的问题。然后，我想出了一种方法，其中我使用诸如OpenAPI定义之类的API定义来检查两个服务之间的兼容性。 API定义必须作为元数据附加到每个服务，因此可以在运行和设计时进行检查。重要的是，提供API和使用API时，API定义也是元数据的一部分。使用Swagger-Diff或OpenAPI-Diff之类的工具，可以自动执行兼容性检查。
I also dealt with the problem described in the question. And I came up with an approach in which I use API-definitions like OpenAPI-definitions to check compatibility between two services. The API-definitions must be attached as metadata to each service and therefore it is possible to do the check at run and design time. Important is that the API-definitions are part of the metadata as well when the API is offered and when the API is used. With tools like Swagger-Diff or OpenAPI-Diff it is possible to do the compatibility-check automated.
这篇关于微服务依赖管理-治理还是域驱动设计？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！