多运行时微服务架构（系列七）

业务逻辑和分布式系统关注不同架构中的耦合

微服务原则有助于通过边界上下文分离不同的业务域，其中每个微服务都可以独立发展。但微服务架构并不能解决将业务逻辑与中间件问题耦合所带来的困难。对于某些较少集成用例的微服务，这可能不是一个重要因素。但是，如果您的域涉及复杂的集成（每个人的情况越来越严重），遵循微服务原则将无法帮助您防止与中间件耦合。即使中间件表示为您包含在微服务中的库，当您开始迁移和更改这些库时，耦合也会变得明显。您需要的分布式原语越多，您就越会耦合到集成平台中。通过预定义的 API 而不是库将中间件作为单独的运行时/进程使用有助于松散耦合并实现每个组件的独立演进。

这也是为供应商分发和维护复杂中间件软件的更好方法。只要与中间件的交互是通过涉及开放API和标准的进程间通信进行的，软件供应商就可以按照自己的节奏自由发布补丁和升级。消费者可以自由使用他们的首选语言、库、运行时、部署方法和流程。

这种架构的主要缺点是什么？

进程间通信。事实上，分布式系统的业务逻辑和中间件机制（您会看到名称的来源）位于不同的运行时中，这需要 HTTP 或 gRPC 调用而不是进程内方法调用。但请注意，这不是应该转到其他计算机或数据中心的网络调用。Micrologic运行时和Mecha应该位于同一主机上，延迟低，网络出现问题的可能性最小。

复杂性。下一个问题是，是否值得复杂的开发，以及维护这样的系统以获得收益。我认为答案将越来越倾向于肯定。分布式系统的要求和发布周期的速度正在增加。此体系结构对此进行了优化。我前段时间写道，未来的开发人员必须具备混合开发技能。这种架构进一步确认并强化了这一趋势。应用程序的一部分将使用更高级的编程语言编写，部分功能将由必须以声明方式配置的现成组件提供。这两个部分不是在编译时互连的，也不是在启动时通过进程内依赖关系注入互连的，而是在部署时通过进程间通信相互连接的。此模型可实现更高的软件重用率和更快的更改速度。