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

上一篇博文中，我们将单一应用”拆解“成多个微小服务，并采用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

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

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安装与配置过程中，首先完成双机热备的配置，具体过程如下

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

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

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

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暴露出来。

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

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. 想提高节点高可用性，微服务化起不了太大作用。