---------------------------------------10.17----------------------------------------

集群和分布式概念

集群：很多"人"做的相同的一件事，即使有一个人挂掉了，也不会对系统造成致命影响

分布式：很多"人"做的不相同的一件事，，合起来却是一件大事情，效率会提升。

集群：一个业务模块，同时部署在多个饿服务器上

分布式：一个大的业务拆分成多个小的业务模块，每一个小的业务模块部署在不同机器上（微服务）

架构演变

单体架构->垂直架构->分布式架构->SOA架构->微服务架构

分布式架构

把公共模块从垂直架构中抽离出来，形成独立的服务，让其他的项目来消费

消费者调用公共模块（远程服务），使用的是rpc

分布式的缺点：在分布式架构中，如果服务的地址变了，那么所有调用该服务的消费者都需要随之变更

SOA架构

在分布式基础上，添加了ESB组件，作为调度中心

微服务架构

在soa架构上的一个升华，将原来的单个业务系统拆分成多个单独的，可以独立开发的，设计，运行的小应用，这些小的应用通过服务来完成交互和集成

---------------------------------------10.18----------------------------------------

高级特性

序列化

生产者将需要传给消费者的对象序列化成流，但是同样的消费者也需要反序列化，导致两边都需要创建对象并实现序列化接口。

所以会将这个公用对象抽取出来放在一个公共模块中。

地址缓存

当注册中心zk挂掉了，仍然可以正常调用服务，因为在第一次从zk调用之后会进行一个地址缓存，每次去调用服务便不需要与zk进行交互，只有当提供者更改了地址zk会通知消费者

超时与重试

---------------------------------------10.17----------------------------------------

超时机制，如果一直连接不上的话太耗费资源，所以设置了超时机制。

建议在@reference（timeout = 3000）

也就是在服务提供者里面设置超时时间

重试机制：

多版本

发布新的版本时，并不是让所有消费者全部更新使用，而是先让部分的消费者使用，测试到版本稳定后再进行全部版本迁移

dubbo中使用version属性来设置和调用同一个接口到不同版本

服务提供者的注解@service(dubbo包下的service)

远程调用服务的注解@reference

负载均衡

在调用时选择负载均衡策略

@reference（loadbalance=""）