本文摘要
- 单体应用时代如何过渡到分布式服务时代的
- 分布式服务下跨服务调用
- 聊聊RPC
- 聊聊服务治理
- Dubbo的全景图
单体应用时代
单体应用时代，我们开发、部署都相对容易。但是我们的业务是不断增长的，业务增长带来的变化就是我们应用服务的增长，本来从一个单体应用10个接口服务，增加到100个接口服务，甚至上千个接口服务。
服务堆在一个庞大的单体应用里会带来什么问题？
- 多人维护一个大项目不容易，容易代码覆盖、冲突
- 庞大的项目对IDE不友好，吃资源
- 庞大的单体从编译、发布、到启动速度，每一步都吃力
- 启动后不同接口的访问频率、热度不同，存在资源竞争问题
- 庞大的单体应用不适合做扩容，因为并不是所有的接口服务都需要扩容
分布式服务时代
将一个庞大的单体服务拆分后解决了接口、服务之间的资源竞争问题。这些服务可以部署在一台机器上或多台机器上，服务于服务之间不再是进程内调用，而是跨进程以至于跨机器调用，从而正式进入分布式服务时代。
跨服务调用
分布式服务存在的问题
我们想要让服务于服务之间调用，需要走网络，走网络就得需要知道要调用的服务所在的服务IP以及其暴露的端口。
调用方式
有了注册中心之后我们需要通过一定的协议、方式进行调用。调用方式可以有很多种：HTTP接口调用、TCP调用、走MQ等异步调用。
聊聊RPC
上面我们提到了跨服务调用我们可以走HTTP、TCP、MQ异步。那么这里就要提到RPC了，我们在使用远程调用的时候，比如走HTTP协议，我们可以使用HttpCilent这种http客户端向服务端发起请求，这种对于使用方来说还是有感知的，那么能不能将其包装起来，像调用本地服务一样调用远程服务呢，那么就需要对远程调用进行包装。
注册中心
刚开始我们可以在配置文件里配置目标服务的IP、端口或者是URL地址，然后通过RPC发起请求。
随着服务数量的增加，服务器数量的增加，同时也为了高可用我们都会多节点部署，那么我们要管理这些地址配置是非常不容易的，那么就需要一个中间存储来存储我们的接口列表、服务列表、机器列表。这就有了注册中心。
服务治理
被调用服务有好多节点，这么多节点我们应该访问哪一个？如果访问的那个节点出错了怎么办？这就涉及到了服务治理的一些东西，我们可以通过负载均衡来进行决定调用哪个节点；通过容错处理机制决定调用错误后我们应该如何处理(快速失败返回还是选择下个节点重试)。
聊聊Dubbo
前面讲了这么多，那么接下来我们来正式的认识一下Dubbo，实际上前面的铺垫就是为了引出Dubbo。
Dubbo 我们可以将其理解：RPC + 服务治理 = Dubbo。
也就是说Dubbo本质上是一个Java语言实现的RPC和其扩展的服务治理能力。
Dubbo的能力
RPC核心
代理、协议、传输、序列化
服务治理
容错处理、负载均衡、注册中心、配置中心、monitor、断路器
Dubbo的生态
原文链接：https://blog.csdn.net/weixin_33327380/article/details/113067967
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/6877
