失眠网 > 微服务架构-高可用

微服务架构-高可用

时间：2020-04-06 16:02:35

相关推荐

微服务架构-高可用

微服务必须要搞定的问题

前言一、高可用是什么？二、保证高可用的方法论是什么？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水平切分--数据均匀 --缺点扩展性差