去过饭店的人都看懂了dubbo

Posted 2021-04-06 代号巨鱼

本文内容核心：类别dubbo与饭店的模型关系,通俗易懂的解释dubbo的作用

预计阅读时间：10分钟

    dubbo是一个分布式架构的应用场景中会使用的应用各模块间内部(服务层)调用过程的管理技术框架。围绕这句话，我们将提取这样几个关键语汇：

1. 分布式架构   

2. 模块内部调用   

   3. 过程管理

    现在，我们将架设一个以饭店为背景的模型，实现对以上三个语义的映射。从而帮助我们理解dubbo的作用。我们会一步一步来，分析映射dubbo到这种背景的过程，使读者能够学习这种抽象到具象的过程。需要注意的是，在此过程中，笔者并不一定能够保证总能找到合适的具象来描述这些抽象，所以不足之处或者勉强为之的地方，需要读者多包涵和仔细理解取其正解。

    我们先给饭店取一个名字，叫做dubbo大饭店，有了名字之后，我们就要认真对待它了，嘎嘎。

分布式架构

___________________

    接下来，我们就先搞定分布式架构这个关键语汇的映射。所谓分布式，就是把一个完整的服务，拆分成单个的模块，各个模块之间互相独立又互相调（依赖）来实现完整的服务。那么我们就按照这个思路来整理一下大饭店，使之成为一个分布式架构。

    首先从整体上看，饭店的对我们而言的功能就是“吃饭”。本来我们作为顾客不需要关心吃的菜是谁做的，吃的饭是谁煮的，配菜是谁买的，米是谁买的等等。但是，因为我们要把饭店的功能变成分布式，所以我们需要关心内部细节，并且我们需要提取出几个主要”模块“来搭建我们的"分布式架构"。

提取的“模块”如下：

1.一个上菜的服务员（小查），这个服务员负责的事情是：向顾客提供菜谱、向厨师传达点菜订单，这两件核心的工作。（前台系统）

2.四个厨师，两个厨师只做西餐，另外两个厨师只做中餐，他们都有能力开发新的菜品更新到菜谱。（数据处理、业务逻辑层，成对出现类似于集群）

3.一个每天会更新的菜谱，包含西餐菜谱和中餐菜谱（搜索系统）

4.一个库房人员，负责提供给厨师食材，和采购食品原料。（后台管理系统）

    这样看上面的4个“功能模块”，已经足够支持一个饭店的运营，其他的细节请不必过于纠结。

    现在，大饭店已经被我们分布式了。这个“分布式”的大饭店已经远比路边摊小吃点的一个人又当服务员又当厨师又当采购的情况好太多了，因为大饭店能处理的客人数量的需求种类都多得多。

    以上就是饭店的分布式架构了。

思考时刻：

    关于分布式，笔者的想法是类似于瓶颈工位分解，一方面一定程度上解开了执行顺序的依赖缩短了产品周期，另一方面又降低了原先工位的操作工的工作强度，当然工位的分解和成本的增加又是矛盾问题，类似于服务器增加引起的成本。关于这个问题，又可以写一篇文章来好好聊一聊，当然如果有经验的朋友可以来讨论。

内部模块调用

___________________

    接着，我们再来实现对关键词“模块内部调用”的映射。我们来看看“分布式架构”的大饭店里的“模块”之间的关系：

1.服务员根据客户的口味需求获取菜谱。  用开发语言来说，就是调用菜单服务的获取菜单接口，入参就是客户的口味需求，菜单接口的返回值就是菜谱（中餐菜谱或者西餐菜谱）。

2.服务员和厨师联系，让厨师把菜做出来。用开发语言来说，就是服务员调用厨师的做菜接口，入参就是客户点的菜名，厨师这个接口的返回值就是做好的菜。

3.厨师与库房联系，负责给厨师提供食材。用开发语言来说，就是厨师调用库房的提供食材接口，入参就是原料清单，库房接口返回值就是需要的食材原料。

4.厨师开发新的菜系后增加到菜谱中去。  用开发语言来说，就是厨师调用菜谱的增加菜名接口，入参就是新研发的菜系名称，无返回值（可以给厨师加薪，呵呵）。

这样看上面的关系，就可以看出来每个模块之间的调用关系了。

这个就是模块内部调用。

思考时刻：

    关于模块拓展，分布式场景下，我们可以很方便的扩展模块（业务）。为什么这么说呢？举饭店的例子来说，我们有一个需求，现在需要增加一个烧烤模块。如果是在单一服务的场景里，比如说对于路边小摊来说，这个老板就需要学习如何烧烤，购置烧烤设备，如果开始卖烧烤，还需要考虑和原先的业务（卖手抓饼）之间的平衡，这中间的过程，用开发语言来说，就是需要在原有的功能上添加新的业务代码，还需要考虑和原先的代码的关系，这样势必造成代码混乱，开发周期长，业务不稳定等情况。

    如果是分布式架构，我们只需要再增加一个烧烤系统，类似于增加一个做烧烤的厨师就基本可以，从而快速迭代了业务功能。

过程管理

___________________

    再接着，我们来看看最后一个关键词：过程管理。这个过程管理就是dubbo的功能了，我们前面说的两个关键词，都是关于这个应用的，与dubbo无关的应用本身内容。

    那么我们为什么需要过程管理呢？ 有了前面对分布式架构的模块内部调用进行具象映射的大饭店，我们就可以从大饭店入手，去考虑这个问题。

    我们知道饭店也是需要管理的，这些管理深入到饭店的每个细节，比如说工作人员的出勤，工作态度的监督，日常的工作调整等等。那么笔者就从这三个角度来说一说，dubbo干了啥。

    我们终于可以祭出这样图了（duboode 注册中心register、监督中心monitor、消费者provider、服务者模型图consumer）

---

    怎样去对比理解呢？（注：以下对比场景只能一定程度帮助读者理解dubbo,全面性的功能请参照官方manual）

1.“注册中心” VS 工作出勤表

    我们先来看看大饭店的出勤管理规则：来上班的人都需要打卡，正常上班的人在的当天的考勤表中都存在，同时这张考勤表对于所有员工都是可见的。

    我们来假设这样一种场景，有一天其中一个做中餐的厨师的请假没有来上班，那么服务员从当天的考勤表里就获知了这个情况，再接下来服务员找厨师做中餐菜品的时候，他就不会去找那个没有来上班的厨师，而是去找另外一个厨师。你看，有了这张考勤表，我们就避免了 服务员找那个请假厨师找不人的情况，否则还要抛出一个异常（厨师失踪了）来呢。

  

    在dubbo中，也是类似的道理，所有的模块在注册中心注册自己的消息，当然这些模块需要符合消费者和服务者的身份关系（请求方【消费者】和被调用方的接口【服务方】）。这样，消费者就可以在dubbo的帮助下找到在线的服务者，避免调用接口异常（超时）的情况发生。

      

2.“监督中心” VS 工作监督和调整

    我们来假设这样一个场景，中餐的两个厨师中厨师B是新来的，服务员小查不放心他的做菜水平，所以总是找厨师A做菜，结果厨师A很忙，影响了上菜的效率，厨师B却很闲，大饭店的老板发现了这个情况后，批评了小查，让他要均衡着分配炒菜，不能影响上菜效率。

    接着，大饭店的生意越来越好了，食客络绎不绝，特别是点中餐的客人，服务员不断的去和厨师下菜单调菜，尽管厨师A和厨师B都很忙，但是还是来不及上菜，导致客人的流失，大饭店的老板及时的观察到了这个情况，立即又招聘一个中餐厨师，使上菜的速度得到保证。

    同时，老板通过对菜单系统的调用，发现顾客最喜欢吃的就是淮扬菜，因此老板及时的调整了策略，选择招聘的厨师是淮阳菜系厨师，这样减少了厨师A响应多种菜品的复杂性，使每个厨师专注于单一菜系，做菜又快又好吃。

      

    在dubbo中，也是类似道理。监控中心负责监控，它能记录消费者对服务者的调用状态（次数，时长），我们可以利用服务负载，及时调整部署服务器集群，同时它采用负载均衡算法，合理的分配客户的请求，我们也可以手动分配服务者权重，实现能者多劳。

      以上，就是dubbo的过程管理的具象，dubbo就类似于饭店老板的管理角色，它负责管理整个分布式应用的系统内部接口的调用情况，能够适应性调整应用内部的接口调用网路， 给开发者提供了管理和监督模块之间的关联关系的工具，帮助开发者联合调试和决策，提高了整个应用的性能。

      

    文章到这里就结束了，希望读者们能借助这篇文章轻松的理解dubbo的作用。回到我们开头所说的， 笔者希望在分析映射dubbo与饭店的模型关系中，读者能够学习这种抽象到具象的过程。那么关于dubbo其他的特性，聪明的读者一定能够找到合适的具象来解释。因为笔者相信，抽象来源于具象，技术逻辑与生活场景同源。