微服务架构扩展FreeStyle

最新推荐文章于 2024-01-12 18:50:05 发布

刘春强

最新推荐文章于 2024-01-12 18:50:05 发布

阅读量464

点赞数

分类专栏：系统架构

系统架构专栏收录该内容

11 篇文章 0 订阅

订阅专栏

随着越来越多的互联网技术团队开始采用微服务实施系统架构，伴随着业务的扩大，系统扩容的问题就会摆上议程，那么微服务架构该如何扩容呢？今天本文就尝试将从上到下扩容方案梳理一下，供大家做为一个参考。

一个常见的微服务架构如下：

微服务基于Dubbo + Zookeeper的组合，缓存和数据库采用Redis + Mysql的经典组合。

利用DNS服务器做前端入口层扩展

在上图描述的架构中，Nginx作为整个系统的唯一入口，如果系统吞吐量增加，nginx的性能变为成为一个瓶颈，另外单台nginx也容易引起单点故障，所以，我们就需要将nginx进行水平扩展，在这里我们考虑使用dns-server来实现。

例如nginx的地址为192.168.0.1，新加一台nginx的地址为192.168.0.2

通过在DNS服务器配置记录：

nginx.yw.com INTOP 192.168.0.1，

nginx.yw.com INTOP 192.168.0.2，

DNS服务器会根据负载算法计算得到其中一个记录返回。利用DNS服务器来承担负载均衡，无需单独管理负载均衡服务器，轮询返回不同的ip，从而实现nginx的水平扩展。

利用Nginx反向代理实现网关层的扩展

Nginx具备反向代理服务器的功能，可以用于实现负载均衡。反向代理位于网关服务器之前，可以缓存网关请求，提高访问速度，通过其负载功能，管理网关服务器。

upstream apigw{
    server 192.168.1.1:8080 weight=1;
    server 192.168.1.2:8080 weight=1;            
}

location / { index index.jsp; proxy_pass http://apigw; #在这里设置一个代理，和upstream的名字一样

采用Nginx，反向代理功能与负载功能集成在同一台服务器上，实现简单。

提前准备好镜像服务器和脚本

由于采用Dubbo, 服务节点的水平扩展已经是现成的，唯一要注意的，可以提前准备各类服务的镜像，需要扩展的时候，直接生成一台虚机，启动对应服务器。如果有自动化脚本更好，生成机器后，可以做到一键到位。

按服务拆分Redis，并利用redis-sentinel保证高可用

为每一个微服务建立独立的Redis缓存服务实例，数据量和访问量比较大的服务更是如此，避免相互影响。

Redis-Sentinel在这里多说两句，RS是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换，选举出master的多个slave中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。

这里使用三台服务器，每台服务器上开启一个redis-server和redis-sentinel服务，redis-server端口为6000，redis-sentinel的端口为6600.

redis-server

192.168.3.1:6000 主

192.168.3.2:6000 从

192.168.56.3:6000 从

redis-sentinel

192.168.3.1:6600

192.168.3.2:6600

192.168.3.3:6600

很多朋友或许会问，为什么不直接考虑采用Redis Cluster，Twemproxy或者Codis这样的方案。从本人过去的经验看，如果你的业务量没有到一定程度或团队没有精力去给他们打Patch二次开发，那就先用好Redis单机的主从方案，可用性反而更高。

Mysql 垂直分库+水平分库

关于垂直分库的方案，之前已经写过一篇文章阐述了，大家可以点击这里参考一下。

今天，我们在这里多阐述一下水平分库的方案。水平分库这件事，可以很粗糙，也可以很细致。比方说，我们对于订单库，按照2016年之前的数据的数据导入到另外一个库，较新的数据继续保留在原库，毕竟1年前的订单查询是少数，然后，将数据库的选择放到业务代码中取控制，每次查询，业务代码通过查询时间来进行表选择和数据整合。

但如果想把这件事，做得更细更合理，上面的粗糙的做法远远不够用，那么我们还是需要找到更加细致的方案的。所幸的是，国内外的各家已经为我们造了很多轮子了，不需要我们再花力气去造。在这里，我也将我个人过去做过的一个调研方案和大家分享一下：

简单来说，水平分库分表的开源方案可以分为两种类型，基于Library 包和 Proxy 服务。Library目前发展比较好的还是Mysql官方的Fabric项目，一直都在优化和更新中。不过由于是非开源项目，所以很多具体的细节尚不清楚，主要基于官方文档处理。

对于Proxy方式的多个开源项目中，目前个人比较看好的还是MyCAT，主要原因是基于Cobar，起点就比较高，而且社区一直很活跃。

(插图来源于MyCAT)

总结

通过将微服务架构从前到后各层中间件扩展方案的梳理，可以发现目前社区已经有了很多成熟的方案，大家可以根据各自业务的实际情况，进行分步实施，让你的架构轻松扩展便可FreeStyle。:)