一、产生的背景
随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进。下面我们用一个图来具体说明架构和开发框架的演进过程。
单一应用架构 当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的数据访问框架(ORM)是关键。
垂直应用架构 当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。此时,用于加速前端页面开发的Web框架(MVC)是关键。
分布式服务架构 当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,用于提高业务复用及整合的分布式服务框架(RPC)是关键。
流动计算架构 当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键。 二、服务治理的需求
微服务架构是互联网很热门的话题,是互联网技术发展的必然结果。它提倡将单体应用程序划分成一组若干小的服务,服务之间互相协调、互相配合,为用户提供最终价值。
单体应用程序拆分成微服务后,服务治理是关键。那么有没有好的服务治理方案呢?答案是有的,而且很多人都在用这个框架,它就是Dubbo。Dubbo是一个带有服务治理功能的RPC框架,提供了一套较为完整的服务治理方案,所以企业如果要实现服务化的话,Dubbo 是很好的一个选择。这里简单介绍一下Dubbo服务治理的几个基本需求。
在大规模服务化之前,应用可能只是通过 RMI 或 Hessian 等工具,简单的暴露和引用远程服务,通过配置服务的URL地址进行调用,通过 F5 等硬件进行负载均衡。
当服务越来越多时,服务 URL 配置管理变得非常困难,F5 硬件负载均衡器的单点压力也越来越大。此时需要一个服务注册中心,动态的注册和发现服务,使服务的位置透明。并通过在消费方获取服务提供方地址列表,实现软负载均衡和 Failover,降低对 F5 硬件负载均衡器的依赖,也能减少部分成本。
当进一步发展,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。这时,需要自动画出应用间的依赖关系图,以帮助架构师理清关系。
接着,服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器? 为了解决这些问题,第一步,要将服务现在每天的调用量,响应时间,都统计出来,作为容量规划的参考指标。其次,要可以动态调整权重,在线上,将某台机器的权重一直加大,并在加大的过程中记录响应时间的变化,直到响应时间到达阈值,记录此时的访问量,再以此访问量乘以机器数反推总容量。
以上是 Dubbo 最基本的几个需求。简单的说,Dubbo就是个服务调用的框架,如果没有分布式的需求,其实是不需要用的,只有在分布式的时候,才有使用Dubbo这样的分布式服务框架的需求,并且本质上是个服务调用的东东。其核心部分包含:
说完产生的背景和需求后,下面具体谈下Dubbo的总体架构以及Dubbo的特点。
如上图所示,Dubbo总体架构设计一共划分了10层,而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。图中左边淡蓝背景的为服务消费方使用的接口,右边淡绿色背景的为服务提供方使用的接口,位于中轴线上的为双方都用到的接口。
下面,结合Dubbo官方文档,理解一下总体架构分层中,各个层次的设计要点:
从上图可以看出,Dubbo对于服务提供方和服务消费方,从框架的10层中分别提供了各自需要关心和扩展的接口,构建整个服务生态系统(服务提供方和服务消费方本身就是一个以服务为中心的)。
下图是从Dubbo官网直接拿来的,看一下基于RPC层,服务提供方和服务消费方之间的调用关系,如图所示:
节点角色说明:
调用关系说明: 0:服务容器负责启动,加载,运行服务提供者。
1:服务提供者在启动时,向注册中心注册自己提供的服务。
2:服务消费者在启动时,向注册中心订阅自己所需的服务。
3:注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
4:服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
5:服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。
Dubbo架构采用的是一种非常简单的模型,要么是提供方提供服务,要么是消费方消费服务,所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色。另外Dubbo架构还具有以下几个特点,连通性、健壮性、伸缩性、升级性,有关注册中心、协议支持、服务监控等内容,也在特点里有详细的描述。
连通性(服务消费者和服务提供者的关联)
健壮性(任意节点宕掉后,服务仍然可用)
伸缩性(节点可以自动增加)
升级性(可平滑升级) 当服务集群规模进一步扩大,带动IT治理结构进一步升级,需要实现动态部署,进行流动计算,不会给现有分布式服务架构带来阻力。下图是未来可能的一种调用架构:
节点角色说明:
四、总结
Dubbo是Alibaba开源的分布式服务框架,并被广泛应用于各互联网公司。Dubbo只需要通过Spring配置的方式即可完成服务化,对于应用无***,其框架本身的成熟度以及文档的完善程度,基本都能满足各互联网公司的业务需求。
如果你需要使用配置中心、分布式跟踪这些内容则需要自己去集成,有一些定制化难度。另外一款开源分布式服务框架Spring Cloud 发展到现在,几乎考虑了服务治理的方方面面,开发起来非常的便利和简单。因此,企业需要根据自身的研发水平和所处阶段选择合适的架构来解决业务问题,不管是Dubbo还是Spring Cloud都是实现微服务有效的工具。