【Free Style】基于华为CCE微服务改造的技术实践(三)

举报
tony_sniper 发表于 2017/11/14 14:55:55 2017/11/14
【摘要】 上一篇博文中,我们将单一应用”拆解“成多个微小服务,并采用docker container方式部署到本地VM中。此种方法虽然提高了web app的可靠性,高并发以及开发效率,但是离现实商用的web app部署还有一段距离,原因如下:1. 单一的服务器宕机的可能较大,这样从api gateway,到所有internal rest service都会停止服务;2. express gateway将成为

上一篇博文中,我们将单一应用”拆解“成多个微小服务,并采用docker container方式部署到本地VM中。此种方法虽然提高了web app的可靠性,高并发以及开发效率,但是离现实商用的web app部署还有一段距离,原因如下:1. 单一的服务器宕机的可能较大,这样从api gateway,到所有internal rest service都会停止服务;2. express gateway将成为一个新的性能瓶颈,因为请求压力较多落在express gateway节点上;3. db services和redis这些公共资源,可能会引发不同services的”争夺“;4. 数据本地持久化。需要建立长久的备份恢复、容器重启自动挂在新的数据源,以及灾难备份都需要涉及。


一个成熟的web app,需要能解决上述4个问题,才能提供High Availability。下面我们需要继续引入新的解决方案——cluster mode,来应对上述4个棘手的问题。目前业界有三种cluster mode:docker swarm,google kubernates,以及apache mesos。三种架构方式有所不同,swarm是一堆manager和worker节点组成,manager节点推荐不要超过7个,所以相对来说比较轻量级;kubernates和mesos都是中大型网站部署采用的解决方案,具体三者之间的区别请参考rancher.com/comparing-rancher-orchestration-engine-options/。针对我们的应用,现有app复杂度较低,而且没有庞大并发流量的需求,所以选择较为轻量级的docker swarm


在此解释几个概念,docker swarm的cluster是为了便于进行不同节点之间的images、service以及container管理,但是不同节点的微服务之间web服务,仍需要express gateway手动配置或者采用dockerode来进行配置。swarm cluster可以监控个节点中服务的状态,资源使用率。没有swarm组件,web app依然可以运行。


下面我要开始docker swarm cluster mode搭建。首先,我们准备4台VM server,Ubuntu prefer。4台机器上分别安装docker-ce,然后选中其中2台机器为master01和master02,其他两台机器为slaver01和slaver02。然后ssh master01,执行docker swarm init --advertise-addr <manager-ip>来初始化创建swarm,然后在master02, slaver01, slaver02上join manager。具体docker swarm command如下:

    #master01

    docker swarm init --advertise-addr 192.168.100.1 #manager ip address


    #slaver01,slaver02,master02

    docker swarm join --token SWMTKN-1-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2e7c 192.168.100.1:2377


然后根据每一个web app rest api 创建docker services,可以参考如下命令。注意--replicas后面的参数可以比2大,例如可以写3。这样有一个节点上就有2个服务。

docker service create --replicas 2 --name userService -p 3001:3000 <images for services>

docker service create --replicas 2 --name trialService -p 3002:3000 <images for services>

docker service create --replicas 2 --name publicService -p 3003:3000 <images for services>

docker service create --replicas 2 --name courseService -p 3004:3000 <images for services>

docker service create --replicas 2 --name adminService -p 3005:3000 <images for services>

docker service create --replicas 2 --name redis -p 6379:6379 <images for services>


在master01 node上使用docker service ls查看所有服务状态(参考如下命令),我们可以看到2个redis服务已经分别在两个节点上运行了。

docker service ls redis

services-0.PNG

services-2.PNG


重复docker service create命令,在每一台机器上创建API,mysql,redis,以及express-gateway服务。使用redis-cluster中create-cluster脚本完成redis cluster的配置,同时需要将mysql也配置为cluster模式。服务具体分布图如下:


microservice-2-522222.jpg

Master01和Slaver01互为主备,Master02和Slaver02互为主备。Master01和Master02构成负载均衡来提升性能。对外暴露80端口,映射到Master主备的虚拟IP。

Redis:1, Redis:2, Redis 1:1, 以及Redis 2:1是一个Redis cluster,节点之间数据共享。每个节点只用本机的redis服务,减少了远程访问延迟的问题。

Mysql cluste也类似。


Keepalived和nginx安装与配置过程中,首先完成双机热备的配置,具体过程如下

microservice-2-6.jpg

1. 下载keepalived进行初始化配置: apt-get install keepalived nginx

2. Keepalived conf配置: 请参考如下配置。virtual_router_id主备节点必须保持一致,参数state有两种MASTER或者BACKUP,interface需要制定有效的以太网接口,priority主节点设为100,备节点设为99.auth_pass保持一致。

keepalived-conf.PNG

3. nginx conf配置:请参考如下配置    

nginx-conf.PNG

4. 测试keepalived启停: service keepalived start && service keepalived stop 

5. 测试nginx启停: service nginx start && service nginx stop


nginx配置完成后,需要使用nginx pass_proxy将请求IP重定向到express gateway上,这样就可以把express gateway的api暴露出来。

下面我讲解一下具体数据访问流程图,以便更好的理解

microservice-2-7.jpg

1)      Browser访问http://<virtual_host_ip>:80/

2)      Master01和slaver01的keepalived判定master01为MASTER node

3)      Master01 上的nginx接受 / 访问请求,通过proxy pass 随机指定master01或者master02上的express gateway微服务接受 / 请求

4)      若master02 express gateway 接受 / 访问请求,通过service ending point映射关系,确定http://courseServic.com:3000影响接受 / 请求

5)      通过master02 上的nginx 上courseService.com地址重新随机指定master01或者master02上的course微服务来接受 / 请求

6)      若 master01 上的course接受请求,直接处理 / 所对应的页面以及业务数据


总结:

       整个web app 从single 模式到微服务模式,再到cluster mode,解决了web实际运行过程中的主要故障因素如下:

        1. 单机宕机

        2. 网络通信故障

        3. web app内部异常

        4. 数据库连接异常

        5. redis连接异常

        6. 云端数据服务连接异常

       根据这6种异常的种类,归类发现1和2属于外部因素,或者硬件因素;3、4、5、6属于内部因素,或者软件因素。利用Keepalived和nginx组合的HA方案,可以解决外部故障因素,而且该方案被业内广泛采用;对于内部故障因素,我们采用拆分主应用为微服务,降低整体web影响异常的可能性。而且独立功能解耦,降低并发阻塞概率,同时配合nginx和express gateway负载能力进一步提高。


博主心得:

       微服务作为一种尚未有精确规则的概念模型,目前还是仍处与业务探索阶段。虽然microservice.io提供了较多的reference,但是根据不同业务需求,业务运行场景,最后拆分,部署的微服务解决方案不可能相同的,需要感兴趣的人或者有业务诉求的人继续探索。个人观点:

1. 那些在web app中故障率较高,以及未来可能与其他系统集成的部件,需要独立出来进行微服务化。

2. 想多个team并行引用高效的CI和CD,仍然建议进行微服务化。

3. 想提高单机节点的资源利用率,建议微服务化。

4. 想提高节点高可用性,微服务化起不了太大作用。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200