---------------------------------------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=""）
