Dubbo概述。
1. 分布式架构图
2. 系统架构的发展
2.1 单体系统架构
当站点功能与流量都很小时，只需一个应用，将所有功能都集中在一个工程中，并部署在一台服务器上，以减少部署节点和成本。例如，将用户模块、订单模块、支付模块等都做在一个工程中，以一个应用的形式部署在一台服务器上。
2.2 集群架构
当站点流量增加而单机已无法应对其访问量时，可通过搭建集群增加主机的方式提升系统的性能。这种方式称为水平扩展。
2.3 分布式架构
当访问量逐渐增大，集群架构的水平扩展所带来的效率提升越来越小。此时可以将项目拆分成多个功能相对独立的子工程以提升效率。例如用户工程、订单工程、支付工程等。这种称为垂直扩展。
2.4 微服务架构
当子工程越来越多时，发现它们可能同时都拥有某功能相同或相似的模块，于是将这些在整个项目中冗余的功能模块抽取出来作为独立的工程，这些工程就是专门为那些调用它们的工程服务的。那么这些抽取出的功能就称为微服务，微服务应用称为服务提供者，而调用微服务的应用就称为服务消费者。
2.5 流动计算微服务架构
随着功能的扩张，微服务就需要越来越多；随着 PV 的增涨，消费者工程就需要越来越多；随着消费者的扩张，为其提供服务的提供者服务器就需要越来越多，且每种提供者都要求创建为集群。这样的话，消费者对于提供者的访问就不能再采用直连方式进行了，此时就需要服务注册中心了。提供者将服务注册到注册中心，而消费者通过注册中心进行消费，消费者无需再与提供者绑定了。提供者的宕机，对消费者不会产生直接的影响。
随着服务的增多，在一些特殊时段（例如双 11）就会出现服务资源浪费的问题：有些服务的 QPS 很低，但其还占用着很多系统资源，而有些 QPS 很高，已经出现了资源紧张，用户体验骤降的情况。此时就需要服务治理中心了。让一些不重要的服务暂时性降级，或为其分配较低的权重等，对整个系统资源进行统一调配。
这里的资源调配分为两种：预调配与实时调配。
- 预调配是根据系统架构师的“系统容量预估”所进行的调配，是一种经验，是一种预处理，就像每年双 11 期间的 PV 与 UV 都会很高，就需要提前对各服务性能进行调配。
- 实时调配指的是根据服务监控中心所提供的基于访问压力的实时系统容量评估数据，对各服务性能进行实时调配的方案。
3. 架构师的基本素养
3.1 常用术语
3.1.1 系统容量与系统容量预估
系统容量指系统所能承受的最大访问量，而系统容量预估则是在峰值流量到达之前系统架构师所给出的若干技术指标值。常用的技术指标值有：QPS、PV、UV、并发量、带宽、CPU使用率、内存硬盘占用率等。系统容量预估是架构师必备的技能之一。
3.1.2 QPS
QPS，Query Per Second，每秒查询量。在分布式系统中 QPS 的定义是，单个进程每秒请求服务器的成功次数。QPS 一般可以通过压力测试工具测得，例如 LoadRunner、Apache JMeter、NeoLoad、http_load 等。
QPS = 总请求数 / 进程总数 / 请求时间 = 总请求数 / ( 进程总数 * 请求时间 )
3.1.3 UV
Unique Visitor，独立访客数量，指一定时间范围内站点访问所来自的 IP 数量。同一 IP多次访问站点只计算一次。一般以 24 小时计算。
3.1.4 PV
Page View，页面访问量，指一定时间范围内打开或刷新页面的次数。一般以 24 小时计算。
3.2 系统容量预估基本计算
3.2.1 带宽计算
平均带宽的计算公式为：
- 平均带宽 = 总流量数（bit） / 产生这些流量的时长（秒）=（PV * 页面平均大小 * 8） / 统计时间（秒）
说明：公式中的 8 指的是将 Byte 转换为 bit，即 8b/B，因为带宽的单位是 bps（比特率），即bit per second，每秒二进制位数，而容量单位一般使用 Byte。
- 带宽需求 = 平均带宽 * 峰值因子
假设某站点的日均 PV 是 10w，页面平均大小 0.4 M，那么其平均带宽需求是：
平均带宽 = （10w * 0.4M * 8） / （60 * 60 * 24）= 3.7 Mbps以上计算的仅仅是平均带宽，我们在进行容量预估时需要的是峰值带宽，即必须要保证站点在峰值流量时能够正常运转。假设，峰值流量是平均流量的 5 倍，这个 5 倍称为峰值因子。按照这个计算，实际需要的带宽大约在 3.7 Mbps * 5=18.5 Mbps 。
3.2.2 并发量计算
并发量，也称为并发连接数，一般是指单台服务器每秒处理的连接数。平均并发连接数的计算公式是：
- 平均并发连接数 = （站点 PV * 页面平均衍生连接数） / (统计时间 * web 服务器数量）；
注：页面平均衍生连接数是指，一个页面请求所产生的 http 连接数量，如对静态资源的 css、js、images 等的请求数量。这个值需要根据实际情况而定。
- 峰值并发量 = 平均并发量 * 峰值因子
例如，一个由 5 台 web 主机构成的集群，其日均 PV 50w，每个页面平均 30 个衍生连接，则其平均并发连接数为：
平均并发量 = (50w * 30) / (60 * 60 * 24 * 5) = 35若峰值因子为 6，则峰值并发量为：
峰值并发量 = 平均并发量 * 峰值因子
= 35 * 6 = 210
3.2.3 服务器预估量
服务器预估量：需要几台服务器的意思。
根据往年同期活动获得的日均 PV、并发量、页面衍生连接数，及公司业务扩展所带来的流量增涨率，就可以计算出服务器预估值。
注意，今年的页面衍生连接数与往年的可能不一样。
服务器预估值 = 站点每秒处理的总连接数 / 单机并发连接数 = (PV * 页面衍生连接数 *（1 + 增涨率）) / 统计时间 /单机并发连接数
注：统计时间，即 PV 的统计时间，一般为一天
4. Dubbo 简介
4.1 官网简介
Dubbo 官网为 http://dubbo.apache.org。该官网是 Dubbo 正式进入 Apache 开源孵化器后改的。Dubbo 原官网为：http://dubbo.io 。
Dubbo 官网已做过了中英文国际化，用户可在中英文间任何切换。
三大功能：
- 面相接口的远程方法调用
- 智能容错和负载均衡
- 服务自动注册和发现
4.2 什么是 PRC？
RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC 协议假定某些传输协议的存在，如 TCP 或 UDP，为通信程序之间携带信息数据。在 OSI 网络通信模型（OSI 七层网络模型，OSI，Open System Interconnection，开放系统互联）中，RPC 跨越了传输层和应用层。RPC 使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC采用客户机/服务器模式（即 C/S 模式）。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。
4.3 Dubbo 重要时间点
Dubbo 发展过程中的重要时间点：
- 2011 年开源，之后就迅速成为了国内该类开源项目的佼佼者。2011 年时，优秀的、可在生产环境使用的 RPC 框架很少，Dubbo 的出现迅速给人眼前一亮的感觉，迅速受到了开发者的亲睐。
- 2012 年 10 月之后就基本停止了重要升级，改为阶段性维护。
- 2014 年 10 月 30 日发布 2.4.11 版本后，Dubbo 停止更新。
- 2017 年 10 月云栖大会上，阿里宣布 Dubbo 被列入集团重点维护开源项目，这也就意味着 Dubbo 起死回生，开始重新进入快车道。
- 2018 年 2 月 15 日，大年三十，经过一系列紧张的投票，宣布 Dubbo 正式进入Apache 孵化器。
5. Dubbo 四大组件
Dubbo 中存在四大组件：
- Provider：服务提供者。
- Consumer：服务消费者。
- Registry：服务注册与发现的中心，提供目录服务，亦称为服务注册中心
- Monitor：统计服务的调用次数、调用时间等信息的日志服务，并可以对服务设置权限、降级处理等，称为服务管控中心
async：异步
sync：同步
6. 版本号
6.1 Dubbo 版本号与 zk 客户端
Dubbo 在 2.6.0 及其以前版本时，默认使用的客户端为 zkClient。2.6.1 版本，将默认客户端由 zkClient 修改为 curator。至于 curator 的版本，与 Dubbo 及所要连接的 Zookeeper 的版本有关。目前其支持的版本为 2.x.x 版本，最高版本为 2.13.0。（curator更高的版本跑不起来）
6.2 Dubbo 与 Spring 的版本号
Dubbo 的使用是基于 Spring 环境下的，即 Dubbo 是依赖于 Spring 框架的。Dubbo2.7.0依赖的Spring是4.3.16。所以，在Dubbo的开发过程中最好使用与该Spring版本相同的Spring，这样可以避免可能的版本冲突问题。