这几年来技术发展特别快，微服务一词也是比较热门，行内行外的都津津乐道。今天要记录的主角Dubbo是其中的一员，但是它可不能完全代表微服务，Dubbo是基于面向服务的架构体系(SOA)，而微服务其实是SOA某种程度上的扩展。是一种架构风格，新的准则，有兴趣的话可以查看martin fowler写的有关论文
。扯远了，进入正文。
为什么需要Dubbo呢?
这里记录一下这个技术是怎么来的。
我们最早编写一个应用时，往往都把所有的模块都集中在一个应用程序上，并打成一个 (jar/war) 包部署到线上。(反正我是这样)，这个方法有个明显的好处，开发简单，无需考虑太多后期维护的东西，使用现在市面上的SpringBoot可以快速开发出一个小型应用,这种架构也被成为单一应用架构。但是缺点也是很明显的，比如有一天要修改某一个需求，改完之后就要重新打包部署，比较麻烦，因为需求这东西，改动挺频繁的。而且当应用访问流量大了之后，这样子的架构就有点吃不消，因为流量都往一台机器上顶，谁抗的住啊.
于是慢慢出现了一种架构思想，垂直应用架构。这个架构说白了就是把编写好的出现打包部署到多个服务器上，底层通过一些硬件负载均衡来决定它们的工作调配问题。这样流量就从原来的都往一个服务器走，变成分散开往几个服务器走，流量问题解决了。
随着服务器越来越多，服务器之间的调用关系越来越复杂，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？它们之间的启动顺序也有讲究，不同的服务器之间还不能乱了"辈份"…这就导致了内部负载均衡器压力也陡增。没关系，这个社会就是被需求所推动的嘛。于是出现了新的架构:面向服务的架构体系(SOA).将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心,同时增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
Dubbo就是基于该体系的实现框架，它在整个分布式系统的架构中，按照分层的架构来架构，使得各个层级之间最大限度的松耦合。
Dubbo的结构
图来自官网。
这里各个名词介绍一下。
首先有一个Container,它是服务运行容器，它启动之后会加载各种Provider，服务提供者。这些Provider会把自己 注册(register) 到注册中心(Registry),而有了服务提供者，就会有服务消费者(Consumer),这些Consumer就会 订阅(subscribe) 注册中心的内容，当注册中心有什么服务可以提供时，就会去通知(notify) 服务消费者。服务消费者收到通知之后，就会去去找对应的服务提供者，而Monitor就是一个监控中心。它们的结构还有点像消息队列。
整个过程也可以比喻为一个相亲过程，服务提供者比作男方，服务消费者比作女方，当男方想找女朋友时可以去婚介所(注册中心)登记自己的信息,而女方也想找男朋友时，也去婚介所登记，婚介所会根据你的信息，给你推荐适合你的伴侣，给你他的联系地址。于是你就可以去寻找ta，有一场美丽的邂逅。而monitor就像是幕后的"boss",它负责监控这一过程。
这是整个Dubbo的架构，看着比较简单，但其实里面细节特别多，还需慢慢学习，而其中的注册中心,Dubbo是采用Zookeeper来作为注册中心的。后续会慢慢记录有关知识。