-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
【2020 InfoQ】Multi-Runtime Microservices Architecture #8
Comments
分布式应用的需求在文章中 Bilgin Ibryam 首先总结了现代分布式应用的四大需求: 生命周期(Lifecycle)、网络(Networking)、状态(State)、捆绑(Binding) 传统中间件限制然后列举了传统解决方案如企业服务总线(ESB)及其变体在现代分布式应用四大需求方面的限制
生命周期(Lifecycle)在传统的中间件中,通常只有一个受支持的语言运行时(例如 Java),它规定了软件的打包方式、可用的库、需要维护的频率等。业务服务必须使用这些库,使其与平台(平台编写语言与业务服务是一样的)紧密结合。在生产实践中,这导致服务和平台的升级必须要协调,常规服务与平台的发布不能够独立进行 网络(Networking)尽管传统中间件具有与内部和外部服务交互的高级功能,但它有一些主要缺点,网络功能集中于一种主要语言及其相关技术,更重要的是,网络问题和语义也深深地刻在业务服务中。有一些抽象能力的库来解决网络问题,但是该库的抽象“泄漏”到了服务的编程模型、交换模式、错误处理语义以及库本身中。意味着该库与业务逻辑耦合在一个实现中。 状态(State)为了进行可靠的服务编排、业务流程管理等,需要对数据库进行集群化和弹性,但主要约束在于与状态交互的库和接口没有完全抽象出来,也没有与服务运行时分离。通常,这些库必须配置有数据库详细信息,并且它们存在于服务中,从而将语义和依赖关系泄漏到应用程序域中。 捆绑(Binding)使用集成中间件的一个主要原因是能够使用不同的协议、数据格式和消息交换模式连接到其它各种系统。但是,这些连接器必须与应用程序一起使用,这意味着必须将这些依赖与业务逻辑一起进行更新和维护 企业服务总线(ESB)无法满足现代应用快速扩展和维护更改的能力,这也是微服务架构出现及解决的问题 未来架构的趋势下图展示了传统中间件平台和云原生平台的对比,云原生平台则通过各种外围 Runtime 实现了业务逻辑与平台的解耦分离,不过还没有完全分离,许多分布式原语,例如经典的企业集成模式(EIP):分离器、聚合器、过滤器、基于内容的路由器;流处理模式:映射、过滤、折叠、联接、合并、滑动窗口;仍然必须包含在业务逻辑运行时中。 因此作者引入了 Multiple Runtime 的概念,下图中,将不同领域的各类创新性云原生项目进行汇总并特意选择了一些代表性项目并将其映射到一组分布式原语上。
多运行时微服务多个运行时,不是因为有多个微服务,而是因为每个微服务由多个运行时组成:一个用于自定义微业务逻辑的运行时(Micrologic runtime),以及一个用于分布式原语的现成的可配置运行时(Mecha runtime)。 下图展示了多运行时(进程外)微服务架构 其中 Mecha runctime就好比《阿凡达》电影中的机甲套装,它们为类人驾驶员赋予超能力,穿上套装就能获得力量以及破坏性武器。 这是一个类似于客户端--服务器架构的两组件模型,其中每个组件都是独立的运行时。它与纯粹的客户端--服务器架构的不同之处在于,这两个组件都位于同一主机上,彼此之间有可靠的网络连接。这两个组件的重要性相当,它们可以在任一方向上发起操作并充当客户端或服务器。其中的一个组件称为 Micrologic,在剥离所有分布式系统问题后,它只拥有非常少的业务逻辑。另一个随附的组件是Mecha,它提供了我们在本文中一直讨论的所有分布式系统功能(生命周期除外,它是一个平台功能)。 Micrologic和Mecha可能是一对一的部署(称为sidecar模型),也可以是几个Micrologic运行时共享一个Mecha。第一种模型最适用于Kubernetes等环境,而第二种模型则适用于边缘部署。 这种架构的主要好处是什么?Mecha的好处和未来 好处是业务逻辑和越来越多分布式系统问题之间的松耦合。软件系统的这两部分具有完全不同的动态特征。业务逻辑始终是内部编写的、唯一自定义代码。它经常更改,取决于你的组织优先级和执行能力。另一方面,分布式原语则负责解决本文中列出的众所周知的问题。这些由软件供应商开发,并作为库、容器或服务使用。这些代码的修改取决于供应商的优先级、发布周期、安全补丁、开放源代码管理规则等。这两个组之间几乎不可见,也无法相互控制。 微服务通过限界上下文实现不同业务领域之间的解耦,每个微服务都可以独立发展。但是微服务架构无法解决业务逻辑与中间件关注(concern)耦合带来的难题。对于某些依赖于集成用例的微服务,这可能不算一个大问题。但是,如果你的领域涉及复杂的集成(情况越来越普遍),那么遵循微服务原则也难以让你摆脱与中间件耦合。即使中间件只是你微服务中的依赖库,当你开始迁移和更改这些库时,这种耦合也将会变得明显。另外随着你需要越来越多的分布原语,你与集成平台的耦合也会越多。通过预定义的API(而不是库),将中间件作为独立运行时/进程来使用,有助于降低耦合,并实现每个组件的独立演化。 这是供应商发行和维护复杂中间件更好的一种方法。只要与中间件的交互是通过开放API和标准的进程间通信进行,软件供应商就可以按照自己的节奏自由发布补丁和升级。消费者也可以自由使用他们喜欢的开发语言、库、运行时、部署方法和过程。
|
在介绍完 Mecha/Multiple Runtime 的理念之后,我们来看看目前微软新推出来的 Dapr 项目 —— 这应该是业界第一个 Multiple Runtime 的开源实践项目。 |
Bilgin Ibryam 博客原文
https://www.infoq.com/articles/multi-runtime-microservice-architecture/
The text was updated successfully, but these errors were encountered: