Dubbo
分布式系统
大型互联网项目架构目标
传统项目和互联网项目区别：
传统项目是企业员工适用；互联网项目是所有网民适用；
传统项目使用人比较少，互联网项目并发量比较高；
传统项目美化度可忍耐，互联网项目追求用户体验好：美观、功能、速度、稳定性；
衡量网站的性能指标：
响应时间：执行一个请求从开始到最后收到响应数据所花费的总体时间。
并发数：系统同时处理的请求数量
并发连接数：客户端向服务器发起请求，并建立TCP连接，每秒服务器连接的TCP数量。
请求数：QPS每秒多少个请求
并发用户数：单位时间内访问的用户数
吞吐量：单位时间内系统能处理的请求数量
QPS：每秒查询数
TPS：每秒事务数
一个事务是指一个客户机向服务器发送请求后服务器做出响应的过程，客户机在发送请求时开始计时，收到服务器的响应后结束计时，以此来计算使用的时间和完成的事务个数。
一个页面的一次访问，只会形成一个TPS，
一个页面的一次请求，可能会多次对服务器请求，产生多个QPS
QPS >= 并发连接数 >= TPS
高性能：快速的访问体验
高可用：网站服务一直时正常访问
可伸缩：通过硬件的增加/减少，提高/降低处理能力
高可扩展：系统间的耦合度，方便的通过新增/移除方式，增加/减少新的功能模块
安全性：网站安全访问和数据加密、安全存储等
敏捷性：响应快速，随机应变
集群和分布式
集群：很多“人”一起干一样的事—— 一个业务模块部署在多台服务器中
分布式：很多“人”一起，干不一样的事，这些不一样的事合起来就是一件大事—— 一个大的业务系统，拆分成小的业务模块，分别部署在不同的机器上。
架构演进：单体架构——垂直架构——分布式架构——SOA架构——微服务架构
单体架构：
优点：简单、开发部署方便、小型项目
缺点：项目启动慢、可靠性差、可伸缩性差、扩展性和可维护性差、性能低
垂直架构：
将单体架构的多个模块拆分成多个独立的项目，形成多个单体架构。
优点：解决了单体架构的一些缺点
缺点：重复性功能太多、
分布式架构：
在垂直架构基础上，将公共业务抽取出来形成独立的服务，供其他调用者消费，实现服务的共享和重用。
RPC：远程过程调用。HTTP rest风格。
优点：解决了重复功能太多
缺点：服务方一旦变更，所有消费方都需要变更
SOA：
面向服务架构，是一个组件模型，将应用程序的不同功能单元进行拆分，通过这些服务之间定义的良好的接口和锲约联系起来，
微服务架构
在SOA基础上升华，强调的一个重点是：业务需要彻底的组件化和服务化。
原有的单体业务系统会拆分为多个可以独立开发、设计、运行的小应用，应用之间通过服务完成交互和集成。带有SOA服务架构的思想、组件化架构的思想和领域建模思想。
特点：
1、服务实现组件化，开发者可以自由选择 开发技术，不需要协调其他团队；
2、服务之间交互一般使用REST api；
3、去中心化，每个微服务都有自己私有的数据库持久化存储数据
4、自动化部署，把应用拆分为一个个的单独的服务，方便自动化部署、测试和运维
Dubbo是SOA时代的产物，springCloud是微服务时代的产物。
Dubbo概述
高性能、轻量级、JavaRPC框架
远程服务调用方案、SOA服务治理方案
Dubbo快速入门
实现步骤：
1、创建服务提供者Provider模块
2、创建服务消费者Consumer模块
3、在服务提供者编写service服务
4、消费者的controller远程调用service服务
5、分别启动两个服务测试
将web和service分成两个模块，属于分布式吗？
不是，并不能独立的启动，独立的对外提供服务，所以不属于分布式。引入dubbo改造。
Service层的改造：
将service模块项目改成war包，添加tomcat并且修改tomcat的端口号为9000。
之前的@Service注解是将service类的对象创建出来，放到spring容器中处理，现在导入dubbo的@Service注解，作用是将这个类提供的方法或者服务对外发布，将访问的地址、ip、端口或者路径注册到注册中心。
在spring的核心配置文件引入dubbo的核心配置
添加web.xml文件，让服务的提供者一直启动，所以配置在tomcat中。
Web层的改造：
注释对service的依赖，建立service包，写service接口。
在controller类中要用到service，
如何做？使用@Reference注解，远程注入（@Autowried 本地注入）
远程注入的实现过程：从zookeeper注册中心上获取要访问的service的url，进行远程调用RPC，将结果封装为一个代理对象，给变量赋值。
在spring配置文件中配置dubbo
会报错，端口冲突问题，修改spirngmvc.Xml
此时，web模块和service模块中有相同的接口，一模一样，所以将这些接口提出来形成公共接口，创建dubbo-interface模块，web和service要依赖公共的接口：
如何确定生产者已经注册到注册中心中？图形化界面查看
dubbo-admin管理平台：图形化服务管理页面
从注册中心中获取到所有的提供者/消费者进行配置管理。
路由规则、动态配置、服务降级、访问控制、权重调整、负载均衡
dubbo-admin是前后端分离的项目，前端使用vue.js，后端使用springboot，安装就是部署。
何时使用：消费者无法使用时可以查看监测
Duboo高级特性
序列化
两个机器传输数据，如何传输Java对象？
生产者和消费者是两台机器上的执行，需要通过序列化，将对象以流的形式传输。
dubbo内部已经将序列化和反序列化的过程封装，只需要在定义的pojo类实现Serializable接口即可。
地址缓存
注册中心挂了，服务器是否可以正常访问？
可以，因为dubbo服务消费者在第一次调用时，会将服务提供方的地址缓存到本地，以后再调用则不会访问注册中心，从本地访问。当服务提供者地址发送变化时，注册中心会通知到消费者。
超时与重试
超时机制：
服务消费者再调用服务提供者的时候发生阻塞、等待的情况，消费者会一直等待下去，在某个峰值时刻，大量的请求同时请求消费者，造成线程的大量堆积，雪崩问题。Dubbo用超时机制解决此问题，设置一个超时时间，在这个时间段内无法访问服务则会自动断开连接。Timeout属性设置超时时间，默认是1000毫秒
超时时间建议配置在服务的提供方。
重试机制：
设置了超时时间，在时间段内无法完成服务访问，会自动断开连接，如果出现网路抖动，这一次请求就会失败，为了避免此类情况发生，Dubbo使用重试机制，通过retries属性设置重试次数，默认为2次
多版本问题
灰度发布：服务提供者升级为多个访问，让少量的一部分消费者先使用，反馈没问题再将所有用户迁移到新功能。
Dubbo 中使用version属性设置和调用统一接口的不同版本
服务者提供版本
消费者使用对应的版本
负载均衡：在集群环境中
策略
1、Random：按权重设置随机概率，默认值，
2、RoundRobin：按权重轮询
3、LeastActive：最少活跃调用数，相同活跃数随机
4、ConststentHash：一致性hash，相同参数的请求发到同一提供者
集群容错模式：
·Failover Cluster：失败重试，默认值，当出现失败，重试其他服务器，默认重试两次，使用retries设置，一般用于读操作；
·failfast Cluster：快速失败，只发起一次调用，失败就报错，用于写操作；
·failsafe Cluster：失败安全，出现异常时，直接忽略，返回一个空结果；
·Failback Cluster：失败自动恢复，后台记录失败请求，定时重发；
·Forking Cluster：并行调用多个服务器，只要一个成功就返回；
·Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错就报错。
服务降级方式：
·mock=force ： return null表示消费方对该服务的方法调用都直接返回null值，不发起远程调用，用来屏蔽不重要服务不可用时对调用方的影响；
·mock=fail ： return null表示消费方对该服务的方法调用在失败后再返回null值，不抛异常，用来容忍不重要服务不稳定时对调用方的影响。
