今日分享开始啦，请大家多多指教~
就目前来看，dubbo框架是一个目前地位十分优良的RPC框架， 一个必须要学的一个框架。兴许当前它会更加优良，兴许会落寞。然而其设计思维，十分值得开发者去学习。
如果在一个我的项目中有两个service。userService和orderService。咱们想要其中一个service调用另一个。
咱们大来源gaodai#ma#com搞@@代~&码网略会有如下写法：
随着业务的逐步简单，在开发中必定会有业务拆分。初步是通过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拜访较多，咱们能够只对它进行扩容。
今日份分享已完结，请大家多多包涵和指导！
转载请注明原文链接：关于java:实操Java大牛带你梳理dubbo的那些底层原理再也不怕被坑了
