软件架构的演变
单一的应用架构 --> 垂直的应用架构 --> 分布式服务架构 --> 流动计算机构
a、单一的应用架构
小型网站、小型管理系统、所有功能部署到一个服务器里，简单易用，并发少
缺点：性能扩展比较难、协同开发问题、不利于升级维护
b、垂直的应用架构（纵向的分割）
按功能模块划分 分层 MVC等 服务器（Tomcat）集群 模块独立部署，降低了维护部署的难度，团队各司其职更易管理，性能扩展方便
缺点：公共模块无法重复利用、开发性的浪费
c、分布式服务架构
集群内部相同的模块集群、不同集群之间不同内容。
RPC 分布式服务框架
d、流动计算架构
服务越来越多 小服务资源的浪费问题逐渐显现 分的功能更细致 微服务 提高集群利用率 提高机器利用率的
资源调度和治理中心（SOA）【Service Oriented Architecture】是关键 建立在集群加分布式基础之上
分布式：：集群之间有调用关系 单向 双向 集群很多 调用关系很复杂
增加 服务治理 服务协调中心
而微服务 是去中心化 没有中心
两个设计思想
SOA：（Service-Oriented Architecture）面向服务的架构；
RPC：（Remote Procedure Call）远程过程调用
高性能、轻量级、开源 Java RPC 框架（SOA、RPC 实现）
三大核心能力：面向接口的远程方法调用、智能容错和负载均衡，以及服务的自动注册和发现。
Dubbox 是一个分布式服务框架，前身是阿里巴巴开源项目Dubbo，阿里不维护了（后交给 Apache），当当在Dubbo的基础上进行优化，继续维护，为了与Dubbo区分，命名Dubbox
Dubbox 致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。远程服务调用分布式框架。
五个组成角色
Dubbo 使用 Zookeeper 作为注册中心
启动 Zookeeper Registry
./zkService start
安装监控中心 dubbo-admin
https://github.com/apache/dubbo-admin 下载源码
先配置 注册中心地址 application.properties 中 地址
DubboAdminApplication 主程序启动
provider 和 consumer 自己写的
provider 提供方 提供 web 和 service等 spring 容器
consumer 消费方 提供 web 和 controller springmvc等
使用Reference 注解 远程过程调用 返回接口实现类
都需要注册
配置文件
炳汉的独白
<!-- 扫描包-->
<context:component-scan base-package="com.bh"></context:component-scan>
<!-- 给服务提供者命名-->
<dubbo:application name="provider"></dubbo:application>
<!-- 注册中心地址-->
<dubbo:registry address="zookeeper://192.168.159.128:2181"></dubbo:registry>
<!-- 服务注册-->
<dubbo:annotation package="com.bh.service"></dubbo:annotation>
远程调用 RPC
容器 是服务提供者 使用的 dubbo 的 Service 注解
Tomcat 容器 （加载 Spring 配置文件） -- Spring 容器 （加载 service） -- 套一个 Dubbo 容器
Dubbo 是同步方案 同步框架对象提前得有，响应回复需要等待 ，返回成功才能运行 后台的数据传输
异步框架 不需要等待 什么时候有了再用 不需要等待
负载均衡
服务降级
当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。
可以通过服务降级功能临时屏蔽某个出错的非关键服务，并定义降级后的返回策略。
服务方忙碌集中处理重要的请求，不重要的服务，先返回一个提示信息，等待处理。
服务方出问题了，宕机了，给一些提示信息，等待或者先处理之后的。
服务容错
集群调用失败时，Dubbo 提供了多种容错方案
Failover Cluster
失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
Failfast Cluster
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错 [2]。通常用于通知所有提供者更新缓存或日志等本地资源信息。