发展背景
1、单一应用架构:一个应用将所有功能部署在一起,减少部署结点和成本
2、垂直应用架构:访问量逐渐增大,单一应用的加速度越来越小,将应用拆分成互不相干的几个应用,提升效率
3、分布式服务架构:垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心
什么是分布式系统
分布式系统是若干个独立计算机的集合,这些计算机对于用户来说就像是单个相关系统。
从进程角度看,两个进程分别运行在两台主机上,他们相互协作最终完成一个功能,那么理论上这两个程序组成的系统,可以称作是“分布式系统”
分布式和微服务的区别:
微服务架构偏向于业务,比如可以将系统按照子业务、数据库、接口不同的维度划分成不同的微服务
分布式系统偏向于机器,目前可以说微服务架构是分布式架构,因为大部分公司把每个服务部署在不同的机器上
分布式会遇到的问题
1、分布式session
解决方案:
1、session粘滞:当用户访问集群中某一台机器后,强制指定后续所有请求均落到此机器上
使用场景:机器数适中、对稳定性要求不是非常苛刻
优点:实现简单、配置方便、没用额外的网络开销
缺点:网络中有机器down掉时,用户session会丢失,容易造成单点故障
方案:nginx中的ip_hash负载均衡方法
2、session复制:将一台机器上的session复制广播到集群中其他机器上
使用场景:机器较少、网络流量较少
优点:实现简单、配置较少、当网络中有机器down时不影响用户访问
缺点:广播式复制到其他机器有一定的延时,带来一定的网络开销
方案:开源方案tomcat-redis-session-manager 暂不支持tomcat8
3、缓存集中式管理:将session存入分布式缓存集群中的某台机器上,当用户访问不同结点时先从缓存中拿session信息
使用场景:集群中机器多、网络环境复杂
优点:可靠性好
缺点:实现复杂、稳定性依赖于缓存的稳定性、session信息放入缓存时要有合理的策略写入
方案:开源方案spring session,也可以自己实现,重点重写HttpServletRequestWrapper中的getSession方法
2、分布式配置中心
在分布式系统中,一次构建、发布、上线是一个非常重要的过程,它不像单机时代重启一台机器就行,在分布式系统中,它涉及到将软件包发布到超过几千台的机器,然后将几千台机器一个一个重启。所以从这个角度看,我们认为每一个大型分布式系统都应该有一个配置中心
常见的分布式配置变更:
- 线程池、连接池大小
- 开关限流配置
- 数据源主备容灾切换
- 路由规则
开源解决方案:
- disconf 百度开源
- diamond 阿里开源
- zookeeper 成熟的分布式配置解决方案
- 等等
3、分布式事务
分布式事务解决的最本质的诉求是数据一致性
比如零售行业,库存与出货的数据一致
比如金融行业,转账账户数据一致
几个典型的解决方案:
- XA事务方案
- 柔性事务
- 基于消息的最终一致
- 业务补偿与人工定正
4、分布式锁
分布式的CAP理论告诉我们,任何一个分布式系统都无法同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)
CAP最多同时满足两项
常见的解决方案:
- mysql
- 内存数据库(redis、memcached等)
- zookeeper
zookeeper介绍
1、下载与安装
下载地址:https://zookeeper.apache.org/
1.1 解压
1.2 配置
进入conf文件夹,找到zoo_sample.cfg文件,并复制为zoo.cfg
1.3 配置文件解释
tickTime:zookeeper服务器之间或客户端与服务器之间维持心跳的时间间隔,也就是每个tickTime时间会发送一个心跳
initLimit:Follower在启动过程中,会从Leader同步所有最新数据,然后确定自己能够对外服务的起始状态。Leader允许Follower在initLimit时间内完成这个工作。
syncLimit:在运行过程中,Leader负责与集群中其他机器进行通讯,如果Leader发出心跳包syncLimit时间后,没有收到Follower的响应,就认为Follower不存在了。
dataDir:存储快照文件目录
2、集群中的角色
领导者:负责 进行投票的发起和决议,最终更新状态
跟随着:用于接收客户请求并返回客户结果
观察者:可以接收客户端连接,将写请求转发给领导者结点,但观察者不参与投票,只同步领导者的状态