随着互联网项目用户量急剧增加，访问并发量的徒然增加，一个应用中的所有的功能都集中在一个项目中，已经完全不能满足需要了，系统的性能提升，一般是搭建负载均衡的集群来解决，但是由于主机的的能力有限，需要将项目分解成一个个独立运行的子项目，如登录子项目，订单子项目，支付子项目等等，即，将原来项目中的业务模块编程独立工程，这种情况若想能还需要进一步提高，也可以为子项目搭建集群.
这种将一个项目使用多个独立的工程实现的系统架构，称之为SOA系统架构，即面向服务系统架构。这些子工程原本是一个应用服务，都是一个工程，各个模块都处于一个主机的JVM中，一个类的对象调用另一个类的对象，即各个模块间进行通信是没有问题，但是现在每个子工程分布在不同的主机，即不同的JVM，他们的通讯是如何实现呢，因此就可以使用RPC协议完成通讯，Dubbo就是RPC协议的实现这之一。
什么是SOA
SOA，Service Oriented Architecture，面向服务的架构，是一个组件模型（即子项目模型）， 它将应用程序的不同功能单元（称为服务）通过这些服务之间定义的良好接口和契约联系起 来。接口是采用中立的方式进行定义的（所谓中立方式是指没有与任何具体实现相绑定的的 定义方式，即只有接口，没有实现的方式）。它应该独立于实现服务的硬件平台、操作系统 （即跨平台）和编程语言（即已被编译为可执行文件）。这使得构建在各种各样的系统中的 服务可以以一种统一和通用的方式进行交互。
面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件（即子项目）进 行分布式部署、组合和使用。服务层是 SOA 的基础，可以直接被应用调用，从而有效控制 系统中与软件代理交互的人为依赖性（即人为参与度更低了）。
SOA 是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义的接口进行通讯， 不涉及底层编程接口和通讯模型。SOA 可以看作是 B/S 模型、XML（ 标准通用标记语言的子 集）/Web Service 技术之后的自然延伸
SOA 将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、 部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较 之以往，以 SOA 架构的系统能够更加从容地面对业务的急剧变化
什么是RPC
RPC,即远程过程调用协议，它是一种通过网络从远程计算机上强求服务，而不需要了解底层网络技术的协议，RPC协议假定某些传输协议的存在，如TCP或UDP,为了通讯之间携带信息数据，在OSI网络通讯模型中，RCP跨越了传输层和应用层，RPC是的开发包括网络分布式程序在内的应用程序更加容易。
RPC采用客户端/服务端模式，请求程序就是一个客户端，而服务端提供程序就是一个服务器，首先，客户端调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息，在服务端，进程保持睡眠状态知道调用信息到达为止，当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后客户端调用进程接受到答复信息，获得进程结果，然后调用执行继续进行。
其实RPC的底层就是socket实现的，只要知道对方的主机和端口号，就可以通过网络连接上，而无需知道底层是怎么实现通讯的。
系统架构设计的关键点
单一应用架构
当网站流量很小时，只需要一个应用，将所有功能都部署在在一起，以减少部署节点和成本，当流量增加的时候，搭建集群增加主机水平扩展，以便提高整个应用的性能，此时，用于简化增删改查工作量的数据访问才是关键。
垂直应用架构
当访问数据量增大，单一应用的水平扩展，其所带来的速度越来越小，此时可能要将应用拆分成独立的几个应用，以提高效率，这是用于加速前端页面开发的web框架是关键。
分布式服务架构
当垂直应用越来越多，应用之间的交互是不可避免的，这时候将核心业务抽离出来，独立一个服务，逐渐形成稳定的服务中心，使前端应用可以更快速响应多变的市场需求，此时，用于提高业务复用以及整合的分布式服务框架是关键
流动计算架构
当服务越来越多，容量的评估(主机所能支撑特定服务的能力成为容量)，小服务资源的浪费等问题逐渐显现，此时需要增加一个调度中心，使其基于访问压力实时管理集群容量，提高集群利用率，此时用于提高机器利用率的资源调度和治理中心是关键。
Dubbbo
Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring 框架无缝集成。
Dubbo 发展过程中的重要时间点
dubbo四大组件
Provider:暴露服务方，即服务提供者
Consumer:调用远程服务方，即服务消费方
Registry:服务注册于发现的中心，提供目录服务，即服务注册中心
Monitor:统计服务的调用次数，调用时间等信息的日志服务，即服务监控中心
（init:仅执行一次，async:异步处理过程，sync:同步处理过程）
0.start:Dubbo服务启动，Spring容器首先会创建服务提供者
- register:服务提供者创建成功之后，马上会把服务注册到register,这个注册过程称为服务暴露，服务暴露的本质就是把服务名称和服务提供者主机写到注册中心的服务映射表中，注册中心充当域名服务器的角色。
- subsribe:服务消费者创建成功后，首先会向服务注册中心订阅服务，当然服务必须是服务提供者暴露在注册中心的服务
- notify:消费者可能订阅的服务还没有提供相应的提供者，当相应的服务提供者注册成功后，就会通知服务消费者，但消费者在订阅了执行服务后，在没有收到注册中心的通知之前是不会被阻塞的，而是可以订阅其他服务，一个消费者可以订阅多个服务，
- invoke:消费者会同步的方式调用提供者的请求，消费者通过远程注册中心的服务列表调用远程服务，dubbo基于负载均衡会选一台提供者处理消费者的请求，而消费者的这个调用是同步的，即提供者在没有像消费者返回处理结果之前，消费者处于阻塞状态，知道返回结果，或者等待超时，随后，dubbo会在提供一个提供者服务为消费者服务。
- count:每个消费者对各个服务的累计调用次数，调用时间，每个提供者被消费调用的累加次数，和时间，消费者和提供者都会定时发送到监控中心，有监控中心记录，这些统计数据可以在dubbo的可视化界面看到。
Dubbo三大领域模型
为了对Dubbo整体机构叙述方便，Dubbo抽象了三大领域模型，注意这里的模型和DDD(领域驱动模型)无关
- Protocal服务域：是INVOKER暴露和引用的主要功能入口，他负责invoker的声明周期管理
- Invoker实体域：是Dubbo的核心模块，其他模型都向他靠拢，或转换成他，他代表一个执行体，可向他发起invoke调用，他可能是一个本地实现，也可能是一个远程实现，也可能是一个集群实现
- Invocation会话域：他持有调用过程的变量，比如方法名，参数等
Dubbo两大原则
- 采用Microkernel Plugin模式，Microkernel只负责组装Plugin,Dubbo功能也是可以由扩展点实现，也就是Dubbo的所有功能点都可被用户自定义扩展所替换。
- 采用URL作为配置信息的统一格式，所有扩展点都通过传递URL携带配置信息
Dubbo整体架构
Dubbo的架构设计公分为10层，最上面service层是Dubbo开发分布式服务开发者实现业务逻辑的接口层.图中左边是消费者使用着的接口，右边是是提供者使用的接口，位于中轴线的为双方都要用到的接口，对于这10层，根据其总体分为三层。
Business层
该层仅包含一个server服务层，该层与实际业务逻辑有关，根据服务消费方和服务提供方的业务设计，实现对应的接口。
RPC层
- config配置层 对外配置接口，以serviceConfig和ReferenceConfig为中心，可以直接new配置类，也可以根据spring解析配置生成配置类。
- proxy服务代理层 服务接口透明代理，生成服务的客户端stub和服务端Skeleton，以serviceProxy为中心，扩展接口为ProxyFactory，proxy层封装了所有接口的透明化代理，而在其他层是以invoker为中心，只有到了暴露给用户时，才用Proxy将invoker装成接口，或把接口转成Invoker也就是去掉proxy层RPC是可以run的，只是不那么透明，不那么看起来像本地调用一样调用远程服务
- registry注册中心层 封装服务地址的注册和发现，以服务URL为中心，扩展接口为RegistryFactory，Register,RegistryService,可能没有服务注册中心，此时服务提供方直接暴露服务
- cluster路由层 封装多个提供者的路由和负载均衡，并桥接注册中心，以invoker为中心，扩展接口为Cluster,Directory,Router和LoadBalance,将多个服务提供方组合成一个服务提供方，实现对服务的透明，只需要与一个服务提供方进行交互 Dubbo官方指出，在dubbo的整体架构中，Cluster只是一个外围概念，Cluster的目的是将多个INVOKER伪装成一个INVOKER,这样用户只需关注Protocal层的invoker接口，加上Cluster或者去掉Cluster对其它层不影响，因为只有一个提供者时，是不需要Cluster的
- monitor监控层 RPC调用时间和次数监控，以statistics为中心，扩展接口MonitorFactory,Monitor和MonitorService
- protocal远程调用层 封装 RPC 调用，以 Invocation 和 Result 为中心，扩展接口为 Protocol、Invoker 和 Exporter。Protocol 是服务域，它是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。Invoker 是实体域，它是 Dubbo 的核心模型，其他模型都是向它靠拢，或转换成它，它代表一个可执行体，可向它发起 Invoker 调用，它有可能是一个本地实现，也有可能是一个远程 实现，也有可能是一个集群实现。 在 RPC 中，Protocol 是核心层，也就是只要有 Protocol Invoker Exporter 就可以完 成非透明的 RPC 调用，然后在 Invoker 的主过程上 Filter 拦截点。
Remoting层
Remoting实现dubbo协议实现，如果我们选择RMI协议，整个Remoting都不会用上，Remoting内部在划为Transport传输层和Exchange信息交互层，Transport层中负责单向消息传输，是对Mina,Netty,Grizzly的抽象，他也可以扩展UDP传输，而Exchange层是在传输层之上封装了request response语义
- exchange信息交互层 封装请求响应模式，同步转异步，以request和responser为中心，扩展接口Exchanger 和 ExchangeChannel,ExchangeClient 和 ExchangeServer。
- tansport网络传输层 抽象和 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel、Transporter、 Client、Server 和 Codec
- serIalize数据序列化层 可复用的一些工具，扩展接口为 Serialization、ObjectInput、ObejctOutput 和 ThreadPool。
