Dubbo如何成为连接异构微服务体系的最佳服务开发框架如何成为连接异构微服务体系的最佳服务开发框架
从编程开发的角度来说,Apache Dubbo (以下简称 Dubbo)首先是一款 RPC 服务框架,它最大的优势在于提供了面向接口
代理的服务编程模型,对开发者屏蔽了底层的远程通信细节。同时 Dubbo 也是一款服务治理框架,它为分布式部署的微服务
提供了服务发现、流量调度等服务治理解决方案。
结合以上基础为背景在实际业务场景中,这可以用来解决异构技术体系共存场景下的通信问题,帮助公司实现在异构技术体系
间作平滑迁移,解决大规模跨区域、多集群部署场景的地址发现及流量调度等问题。
面向接口代理的透明服务开发框架
我们还是从 Dubbo 是一个微服务开发框架 这个大家熟知的概念开始。就像 Spring 是开发 Java 应用的基础框架一样,我们经
常会选用 Dubbo 作为开发微服务业的基础框架。Dubbo 框架的最大优势我认为就在其面向接口的编程模型,使得开发远程服
务调用就像开发本地服务一样(以 Java 语言为例):
1、服务定义
2、消费方调用服务
下图是 Dubbo 的基本工作原理图,服务提供者与服务消费者之间通过注册中心协调地址,通过约定的协议实现数据交换。
同构/异构微服务体系面临的问题
同构/异构微服务体系面临的问题关于 Dubbo 协议本身及其服务治理相关功能细节并不是本文的重点,我们今天将从一个更高
的层次,来看看公司内部构建微服务体系所面的挑战,以及 Dubbo 能为架构选型和迁移等提供哪些解决思路。
一个公司内部的微服务可能都是基于某一个相同的服务框架开发的,比如说 Dubbo,对于这样的架构,我们称之为是同构的
微服务体系;而有些公司的微服务可能是使用多个不同的服务框架所建设,我们称之为异构的微服务体系,多个不同技术栈微
服务体系的共存在大型组织内还是非常普遍的,造成这种局面可能有很多原因。比如,可能是遗留系统带来的,也可能是公司
正在做技术栈迁移,或者就是不同业务部门为了满足各自特殊需求而做的独立选型(这也意味着异构微服务体系的长期共
存)。
1、异构微服务体系共存
我们很容易想到的一个挑战是:不同的体系间通常是使用不同的 RPC 通信协议、部署独立的注册中心集群,面对这种多协
议、多注册中心集群的场景,要如何实现相互之间透明的地址发现和透明的 RPC 调用?如果我们什么都不做,那么每个微服
务体系就只能感知到自己体系内的服务状态,流量也在各自的体系内封闭。而要做到从体系 A 平滑的迁移到体系 B,或者想
长期的保持公司内部多个体系的共存,则解决不同体系间的互联互通,实现流量的透明调度将是非常重要的环节。