共计 3042 个字符，预计需要花费 8 分钟才能阅读完成。
今日分享开始啦，请大家多多指教~
就目前来看，dubbo 框架是一个目前地位十分优良的 RPC 框架，一个必须要学的一个框架。兴许当前它会更加优良，兴许会落寞。然而其设计思维，十分值得开发者去学习。
如果在一个我的项目中有两个 service。userService 和 orderService。咱们想要其中一个 service 调用另一个。
咱们大略会有如下写法：
随着业务的逐步简单，在开发中必定会有业务拆分。初步是通过 maven 进行模块的拆分。
如下图，才是咱们最终想要的计划，对于这种计划，orderService 端，咱们称之为服务提供者，调用 orderService 的端，咱们称之为服务消费者。这种思维，也为 dubbo 的呈现埋下了伏笔。
jvm 的 userService 如何调用 orderService 呢？
在 java 近程调用多年的积淀，一个接着一个框架的呈现，在一点点地优化这个调用的过程。
首先是 socket 调用。在 orderService 中凋谢 socket 服务，在 userService 中进行近程调用。
- 长处：解决了单机调用的问题。
- 毛病：代码简单，不易于扩大。
这可能是最后的一个近程调用解决方案，笔者未曾遇到过纯 socket 调用的框架。
如何跨语言调用？
咱们发现，在 java 的对象是不能够间接通过 socket 进行传输的，须要有一个序列化的过程。而且 java 的默认的序列化，是无奈被其余语言解析的。这样导致如果有其余语言提供的服务，是无奈通过 java 调用。因而对于 socket 进行了降级，通过 http+xml 进行信息的传输。这就呈现了 webservice。
Web Service 技术，能使得运行在不同机器上的不同利用毋庸借助附加的、专门的第三方软件或硬件，就可相互交换数据或集成。根据 Web Service 标准施行的利用之间，无论它们所应用的语言、平台或外部协定是什么，都能够相互交换数据。
Web Service 尽管晚期很多人应用，然而到当初看来，这是一种过期的框架。因为，同样的一些数据，通过 json 会比 xml 少很多。通过 json 会更少的占用带宽。如上面数据。
外部调用协定
http 协定是应用层的一种协定，对于凋谢给内部零碎时，是一个很好的抉择，它能够实现跨语言调用。如果是本人的 java 服务外部调用时，应用 http 协定，就有点浪费资源。
如上图，http 协定在交互之前须要进行 tcp 三次握手，握手胜利之后进行数据传输。一个 http 交互下来，有申请头、申请体、响应头、响应体。这些数据，在外部调用时，很多无关紧要的数据。兴许能够自定义协定，简化传输数据。这就呈现了 dubbo 协定，一种外部调用的协定。
dubbo 协定谋求的是数据量小，小则快，协定的设计也合乎 dubbo 框框架的理念，实用与外部服务之间的数据交互。安全性就没有 https 做得那么好, 然而也不须要，毕竟 dubbo 协定设计的初衷就是外部应用的。
spring cloud 的 feign 组件外部应用 http 协定，外部调用可能有一些资源的节约，然而 http 协定能够实现跨语言调用。
RPC 框架
对于一个 RPC 框架来说，只是能实现近程调用，并不算完满。
个别开发一个服务须要多个机器进行部署，为了防止出现单点故障。对于一个较为欠缺的 RPC 框架来说，在多个机器提供同样的一个服务的时候，须要主动做出抉择。好比上图，userServuce 在调用 orderService 的时候，须要自动识别集群信息，并且主动抉择机器进行调用。
目前，orderService 只有一个服务，三台机器，兴许能够在 userServuce 中配置三个 ip，而后自行编写路由规定即可。然而随着业务的简单，机器的变动，兴许，咱们起初无奈得悉机器的 ip 信息。
为了实现动静的机器增加与移除。最终，增加了一个机器的协调者，所有凋谢服务的机器在这个协调者中增加本人的凋谢服务的信息，这个协调者中会有哪些机器凋谢了哪些服务。这样看来这个协调者相似一个 ” 通讯录 ”。咱们称这个 ” 通讯录 ” 为注册核心。
这样一个较为欠缺的 RPC 框架，就有了雏形。
- 服务提供者启动之后向注册核心，提交本人提供服务的信息。
- 服务消费者，在生产时，去注册核心查问是否有机器提供对应的服务。例如调用 orderService 时，能够发现有 192.168.1.1 和 192.168.1.2 机器有提供对应的服务。消费者能够依据随机、轮训等规定抉择调用哪个服务。
- 在有服务上线或者下线时，注册核心能够对批改的信息进行告诉。
这样一套流程下来，就完满地实现的服务的动静部署，能够任意部署服务。
注册核心的抉择
作为协调者的注册核心，占据着一个重要位置。这样来看，注册核心次要实现了长期数据存储的性能。能够有多种抉择数据库、redis、zookeeper、eureka、nacos、或者本人实现。
期初 dubbo 框架官网举荐应用 zookeeper 为注册核心，呈现 nacos 之后，逐步从 zookeeper 转为 nacos。
为什么 zookeeper 转为 nacos？
论断为：zookeeper 在大数据计算时做注册核心是一个好的抉择，然而在服务调用时，兴许数据不须要超强的一致性。nacos 是目前来说很敌对的一个注册核心，他提供了 CP+AP。还有可视化界面，还有配置核心等性能。性能相当欠缺。
springcloud 与 dubbo 的历史
在 17 年时，这两个词才进入我的眼帘。过后还有一个超级火的 springboot。那个时候招聘，简直每个岗位都要求会 springboot。一时间，成为了一个 java 开发的必备功底。
因为 springboot 在大大开发了开发的速度，而且 springcloud 的各个组件都比较完善，feign、网关、配置核心、熔断等等。spring、springcloud 和 springboot 显著是一家人。这让一个孤身的 dubbo 有点不好立足，一些公司从 dubbo 框架转为 springcloud 全家桶。
2018 年 7 月份，eureka 进行更新。就目前来说 eureka 的性能单单作为注册核心，曾经足够优良了。然而对于节奏如此快的互联网时代，进行更新，就意味着会缓缓地隐没。
2019 年 7 月 24 日晚，Spring Cloud 官网发布公告 Spring Cloud Alibaba 行将毕业。提供了很多组件，对于大部分开发者而言，nacos、dubbo、seata 应该是较为罕用的组件。
- nacos：注册核心。
- dubbo：一个基于 Java 的高性能开源 RPC 框架。
- seata：一种高性能且易于应用的分布式事务解决方案，可用于微服务架构。
nacos 是一个新推出的注册核心，其中最亮眼的性能是提供了可视化界面，而且还附带配置核心。霎时 dubbo 就找到了家人。这些组件的呈现让 dubbo 又崛起了起来。而且 dubbo 原本扩展性就很好。能够进行协定扩大、调用拦挡扩大、援用监听扩大、集群扩大等等
另外 dubbo3.0 主力应用 Triple 协定。残缺兼容 gRPC over HTTP/2。举荐应用 protobuf 作为默认序列化，在性能和跨语言上的成果都会更好。
结束语
不论 maven 如何拆分，都始终是在一个 jvm 中运行，这样只是在代码开发时会分明不便一点。然而，某一个 service 在有较大压力的状况下，没有方法单单对此 service 做出调整。最终，咱们是想要 userService 和 orderService 在不同的 jvm 中运行，如果 orderService 拜访较多，咱们能够只对它进行扩容。
今日份分享已完结，请大家多多包涵和指导！
