Home Tags Posts tagged with "服务治理"

服务治理

0 41

久仰 Dubbo 大名,正好公司需要使用,特此学习

 

一、学习方法 —> 带有目的去看官方文档

因为我本身了解过RPC框架的大体架构和原理(理论+简单的实现),零散的学习过分布式,微服务的概念,使用 Dubbo+zookeeper 实现了简单的远程调用,有一定的基础,因此现阶段最需要的是 系统的梳理 + 知识的整合。

官方文档是最全面(利于整合),最顶层(利于梳理)的。

因此,我建议在开发过程中,如果需要学习一门新的技术,先思考自己是否有一定的基础,如果有,那么在学习官方文档的时候,就应该带有两个目的去学习

  1. 系统的梳理 
  2. 知识的整合(缺少的则趁此补充)

这样下来,不仅学会了其使用方法,也夯实了所有知识,打通全身脉络。

 

二、开始分析

Apache Dubbo 是一款微服务开发框架,它提供了 RPC通信 与 微服务治理 两大关键能力。这

意味着,使用 Dubbo 开发的微服务,将具备相互之间的远程发现与通信能力, 同时利用 Dubbo 提供的丰富服务治理能力,可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩展的,用户几乎可以在任意功能点去定制自己的实现,以改变框架的默认行为来满足自己的业务需求。Dubbo3 基于 Dubbo2 演进而来,在保持原有核心功能特性的同时, Dubbo3 在易用性、超大规模微服务实践、云原生基础设施适配、安全设计等几大方向上进行了全面升级。 以下文档都将基于 Dubbo3 展开。

上述为Dubbo3简介的第一段话,可分析得出:

(1)Dubbo服务于 微服务开发框架

1.什么是微服务架构(组件化,服务化,以关联的业务逻辑为边界)

微服务架构强调“业务需要彻底的组件化和服务化”,原有的单个业务系统会拆分为多个可以独立开发,涉及,运行的小应用,这些小应用之间通过服务完成交互和集成微服务架构将相关联的业务逻辑及数据放在一起形成独立的边界,其目的是能在不影响其他应用组件(微服务)的情况下更快地交付并推出市

举例:航班预定应用

将航班预订应用划分为预订航班、时间表查询、计算票价、分配座位、管理奖励、更新客户、调整库存七个微服务实施

举例:先享后付应用

将先享后付应用划分为信用审核,资格申请,商家接入,交易完成四个微服务实施。

2.总结

Dubbo服务于 微服务架构,通过Dubbo可以将应用业务彻底的组件化和服务化,通过组件化和服务化,各个微服务可以自行部署,设计,开发,使得应用更加灵活,开发更加敏捷,服务的可用性更高。(例如信用审核由A小组开发,资格申请由B小组开发,这样两个小组同时进行,可加快开发效率;业务的组件化增强服务可用性,例如商家接入组件的更新不会影响到用户的信用审核及资格申请;微服务的语言无关性使应用更加灵活,例如商家接入组件使用Java语言开发,完成交易组件可以使用追求效率的Go语言)

 

(2)Dubbo提供的两大关键能力—RPC通信 与 微服务治理

RPC通信

1.首先明确RPC通信是一种通信方式(进程间8种通信方式详解 – 云+社区 – 腾讯云 (tencent.com)进程间通信的几种方式 – 云+社区 – 腾讯云 (tencent.com)

通信方式包括:

  • 管道(pipe)
  • 消息队列(消息传递系统)
  • 信号量通信(消息传递系统)
  • 信号(消息传递系统)
  • 共享内存通信(共享存储器系统)
  • 套接字通信(C/S系统)
  • RPC(C/S系统)

2.RPC通信具体描述

RPC—远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据。在OSI网络通信模型中,RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

3.RPC通信所带来的问题(谁能用通俗的语言解释一下什么是 RPC 框架? – 知乎 (zhihu.com)

  • Call ID映射(即服务注册,发现)
  • 序列化和反序列化(序列化协议,如hessian,dubbo)
  • 网络传输(数据发送模型)

4.总结

进程间的通信方式有多种,而RPC通信是一种基于C/S系统的通信方式,RPC通信屏蔽应用层和传输层(可理解为RPC框架完成了这两层的功能,实现方式可以自定义),这种方式使得远程调用和本地调用一样简单,但与此同时,RPC通信带来一些问题,如服务注册,服务发现,序列化和网络传输等;

Dubbo则是RPC通信的一种实现,提供Client-Based的服务发现机制,通过部署额外的第三方注册中心组件来协调服务发现过程,如Nacos,Zookeeper等;它支持多种通信协议(如Dubbo3,Dubbo2)实现序列化+网络传输。

 

微服务治理

1.什么是服务治理?

因为某些原因,我们选择了微服务架构,而微服务架构的特点和实现决定了它有一些待解决的问题。我们的目的是使项目通过微服务架构运行起来,那么我们就必须解决这些问题。

可以用这个例子来思考:

微服务运行起来—>人是健康的

微服务待解决的问题—>人生病了(可能是咳嗽(服务不问题))…

服务治理—>给人治病,而且是对症下药

总结:服务治理就是为了完成项目在微服务架构下的部署和运行这个目的,而对该架构的问题的解决。

2.服务治理究竟要治的是什么?

让我们先放下微服务,像《微服务设计》那本书中说的一样,把自己想象成一个城市规划师,我们的目标不是治理微服务,而是要治理一个城市的交通,那么我们会怎么思考?

 

在进行城市交通规划之前首先要做的第一个事情是收集信息,要能够知道这个城市发生了什么,所以在各个路口需要安装采集探头,记录车来车往的信息。有了信息以后就需要对信息进行分析,那么就需要可视化的图形界面,能够一眼就看出什么地方出了问题,通往哪个工厂的路坏了。发现了问题就要解决问题了,限制一下拥堵路段的流量,把去往一个公园的车辆导向到另外一个类似的公园。最后,如果把城市作为一个国家来考虑,那么每个进入这个城市的车辆都需要进行检查,看看有没有携带违禁品,最后给这些不熟悉道路的外地车规划路线。通过上面这个思考的过程,我们发现要对一个城市进行治理的时候,第一要采集信息,然后要能够对采集的信息进行监控和分析,最后根据分析的结果采取对应的治理策略。另外从整体安全的角度考虑还需要一个守门人

守门人—>采集信息—>监控和分析—>治理

因此我们也用同样的思路来思考服务治理,网关就是整个整体的守门人,日志采集,追踪工具,服务注册发现都是用来采集信息的,然后需要监控平台来展现这些采集的信息,并进行监控和分析。最后根据分析的结果采取治理策略,有的服务快撑不住了要限流,有的服务坏了要熔断,并且还能够及时的调整这些服务的配置。

下面的脑图就从这四个方面构建了一个简易的服务治理体系:请求网关,信息采集,信息分析,治理策略总结:微服务治理可以简易的分成四个方面,分别是请求网关,信息采集,信息分析,治理策略

 三、参考