微服务架构-高可用

微服务必须要搞定的问题

  • 前言
  • 一、高可用是什么?
  • 二、保证高可用的方法论是什么?
    • 1.集群化
    • 2.高可用第二步--故障自动转移
  • 总结:


前言

随着技术业务体量发展,微服务架构将会面临巨大挑战,以下讲述的是针对于微服务架构的高可用架构将如何实现

一、高可用是什么?

HA:简单归纳就是即便出现异常down机也要能够保持服务可用
常见微服务的分层架构,每一层都要实现高可用 ,才能保证整体的高可用



常见互联网分布式架构如上,分为:

(1)客户端层:典型调用方是浏览器browser或者手机应用APP

(2)反向代理层:系统入口,反向代理

(3)站点应用层:实现核心应用逻辑,返回html或者json

(4)服务层:如果实现了服务化,就有这一层

(5)数据-缓存层:缓存加速访问存储

(6)数据-数据库层:数据库固化数据存储

整个系统的高可用,又是通过每一层的集群化+自动故障转移来综合实现的。

二、保证高可用的方法论是什么?

1.集群化

单点的高可用问题的原罪

*一.必须要做集群化,多机化

1.反向代理层 :
    nginx :
    多台Nginx做,线上服务提供,非中心化
    常见的实践是通过Keeplive 进行不停探活,如果发现down机不可用情况,
    相同virtual ip 继续提供服务
2.站点应用层:
   应用站点进行多机部署
   假设反向代理层是nginx,nginx.conf里能够配置多个web后端,并且nginx能够探测到多个后端是否存活
3.微服务的水平扩展:
    加service节点,并且通过对应**connectPool组件**来控制
4.数据层和缓存层的,是比较难的
   核心是数据多备份
   4.1.服务端到缓存层高可用--通过数据双写缓存来保证
         服务层到缓存集群高可用--通过缓存组件进行数据同步比如Redis的哨兵机制
    说明:很多时候我们并不一定要做缓存高可用,这个时候建议要封装一层对于缓存的操作服务,把服务进行高可用
   4.2.服务到数据库高可用:
       大部分互联网公司已做读写分离和读写分离,所以又可分为读库高可用 写库高可用
      4.2.1.读库高可用:读库进行多级备份,多级节点部署
      4.2.2 写库高可用:也是Keepalive理论虚拟IP,互相同步来保证--rds同理

总结数据库理论要考虑的问题:  
   怎么达到存储容量的无限容量?
   怎么使处理能力--无限读写能力的无限扩展?
基本解决方式:
     水平切分 ,hash切分,
      扩充存储 ,扩充读性能 
读写分离--读性能线性扩展
水平切分:解决写性能的扩展

2.高可用第二步–故障自动转移

代码如下(示例):

核心诉求不需要人为介入--自动转移
1.nginx:
 当nginx挂了的时候,keepalived能够探测到,会自动的进行故障转移,将流量自动迁移到shadow-nginx,由于使用的是相同的virtual IP,这个切换过程对调用方是透明的。
 2.反向代理到站点
   当web-server挂了的时候,nginx能够探测到,会自动的进行故障转移,将流量  自动迁移到其他的web-server,整个过程由nginx自动完成,对调用方是透明的。
3.站点到服务
   当service挂了的时候,service-connection-pool能够探测到,会自动的进行故障转移,将流量自动迁移到其他的service,整个过程由连接池自动完成,对调用方是透明的(所以说RPC-client中的服务连接池是很重要的基础组件)
4.redis:
  当redis主挂了的时候,sentinel能够探测到,会通知调用方访问新的redis,整  个过程由sentinel和redis集群配合完成,对调用方是透明的。
5.数据库读库
  当读库挂了的时候,db-connection-pool能够探测到,会自动的进行故障转移,将流量自动迁移到其他的读库,整个过程由连接池自动完成,对调用方是透明的(所以说DAO中的数据库连接池是很重要的基础组件)
6.数据库写库:
当写库挂了的时候,keepalived能够探测到,会自动的进行故障转移,将流量自动迁移到shadow-db-master,由于使用的是相同的virtual IP,这个切换过程对调用方是透明的。

三 .负载均衡:loadBalance(均匀)

核心不同处理方式:
同构资源--负载均匀
异构资源--要有处理能力相匹配

nginx--dns 轮询 已经实现负载均衡 
nginx--tomcat   一致性hash 权重 等
数据层负载:
进行水平切分--切分方式多样如 
水平切分
hash切分
1.范围水平切分--归档数据是冷数据访问低-扩展容易
2.hash水平切分--数据均匀  --缺点扩展性差

总结:

架构体系
1.端到反向代理
2.反向代理到站点应用
3.应用到微服务
4.微服务到缓存,
基本没有高可用的需求
5.微服务到数据库写
6.微服务到写库

高可用三大关键点:
集群化
故障自动转移
负载均衡

你可能感兴趣的:(架构,微服务,缓存)