Docker Featured

一条大路(捷径)通罗马：一种利用docker进行微服务架构的可行方案

w.z.

• 14 min read

当我们要做一件的常常发现有诸多的方法和工具可以实现，也就是"条条大路通罗马"， 寻找最优工具和方法的过程也会花费很多精力和时间，有一种“明明知道条条大路通罗马，却不知道接下来怎么走的感觉” 。在微服务架构方案中也何尝不是如此！ 本文隐去了漫漫长途的探索和横向对比，直接给出其中一种可行方案，也是通往罗马的捷径。

本文默认读者朋友至少研究过微服务（可以没有真实使用过），了解微服务架构的基本概念，和单体的不同，以及需要address的issue。 如果没有，可以尝试先读：

Microservice Architecture (Examples and Diagram)

Introduction to microservices architectures

monolith-vs-microservices

7 Things to Consider While Moving to a Microservices Architecture

4 Challenges You Need to Address with Microservices Adoption

Microservices and containers: 6 things to know at start time

When not to use microservices

Setup Microservices Architecture in Python with ZeroMQ & Docker

预览捷径有多快

在everyday work中，需要部署一个或者几十个容器应用到云端，无论是首次部署还是版本升级，无论是部署到1台服务器还是2000多台机器的集群，一般只需要执行下面的1-5行command：


# 首次使用hub.docker.com需要登陆，也可以使用阿里云提供的免费registry
docker login -u=wz -p="<密码隐藏了>"   hub.docker.com
# 最新的master分支build一个新的docker镜像 
docker build -t "wz/ladyluck_web:0.1.1" ./
# 推送到docker hub 或者阿里云提供的免费registry
docker push  wz/lady_luck_web:0.1.1
# 使用stack-test.yml文件部署到测试用的docker集群
docker  --host tcp://<隐藏了的测试环境ip>:<隐藏了的端口> \
        --tlsverify  --tlscacert  "./_cert/ca.pem"  --tlscert "./_cert/cert.pem" \
        --tlskey "./_cert/key.pem" --with-registry-auth \
        stack deploy -c stack-test.yml  ladyluck_web
# 测试通过之后使用stack.yml文件部署到生产环境
docker  --host tcp://<隐藏了的生产环境ip>:<隐藏了的端口> \
        --tlsverify  --tlscacert  "./_cert/ca.pem"  --tlscert "./_cert/cert.pem" \
        --tlskey "./_cert/key.pem" --with-registry-auth \
        stack deploy -c stack.yml  ladyluck_web

而且不用登陆服务器，不用提前备份当前本版应用，不用担心部署失败造成服务中断。

为什么这么容易？ 因为我们有：

  • docker swarm： 管理服务器集群
  • traefik： 负责url despatch，如果微服务应用需要通过http对外服务
  • Seneca： 负责微服务间通讯，如果你的微服务应用是使用node.js开发的
  • Oracle Graal： 如果你的微服务不是使用node.js开发但仍想使用Seneca

如果你还有一下小疑问，例如 “文件如何同步？”，“ sticky cookie/session能保证吗？” 之类的。没关系，继续往下读，连代码中的注释也要认真看哦，会找到答案的！

使用docker swarm管理服务器集群

为什么选择swarm而不是 Kubernetes / Mesos？

But it, with all the ideas described here, is what I would recommend for teams of less than 200 developers, or clusters of less than 1000 machines.
对于成员小于200人的开发团队，或者需要管理的机器少于1000台，我还是推荐swarm。
This includes small / medium size organizations (like when you are not Google or Amazon), startups, one-man projects, and "hobby" projects.
-- by https://dockerswarm.rocks/

而我的直观感觉也是如此，Kubernetes / Mesos的文档多而沉长，不太容易找到想找的内容，特别是Kubernetes面对的使用场景很多，文档超级多。 而swarm是为docker 容器而生，概念少，文档少，学习起来也快。

如果你使用的阿里云的容器服务，那么docker swarm已经默认开启了，你可以在控制台找到连接这个机器的host地址和证书文件。

如果你使用的云服务商没有提供swarm集群服务，可以自行开启。方法是：
step 1: 确保机器已经安装了docker，然后ssh到你要使用swarm集群的机器上执行 docker run --rm swarm create ，并邀请更多机器加入集群，详情请参考 https://hub.docker.com/_/swarm
step 2(optional): 参考 https://github.com/docker/swarm/blob/master/discovery/README.md 开启这个集群的TLS链接。 这个步骤是可选的，但是为了保证本文后面的步骤也和阿里云提供的容器服务保持一致，最好还是去配置一下。

使用traefik做url despatch

traefik是做这么一件事的： 把来自不同的域名和path的请求转发给正确的后端微服务处理。

traefik-architecture-1-

在docker swarm集群中使用traefik很简单。

step 1 : 准备一个stack.yml 文件：


version: '3.6'
services:
  traefik:
    image: traefik:1.4
    # **如何保障sticky-sessions？ 后端服务器健康检查？ 最大连接数限制？ 请查看：**
    # https://docs.traefik.io/basics/#sticky-sessions
    command:  --web  --logLevel=DEBUG  --docker   --docker.swarmmode  --docker.watch --docker.domain=litup.me \
              --defaultEntryPoints='http'  \
              --entryPoints='Name:http Address::80 compress:true'
              # --entryPoints='Name:https Address::443 TLS'
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      # - /dev/null:/traefik.toml
    labels:
      - "traefik.enable=false"
    networks:
      - public
    deploy:
      replicas: 2
      placement:
        constraints: [node.role == manager]       
      restart_policy:
        condition: on-failure
networks:
  public:
    driver: overlay
    ipam:
      driver: default
      config:
      - subnet: 10.1.0.0/24

step 2: 利用上面使用docker swarm管理服务器集群获得的swarm集群管理链接和证书文件部署，只需要在本地机器（需要已经安装并启动了docker）执行以下command


docker  --host tcp://<隐藏了的生产环境ip>:<隐藏了的端口> \
        --tlsverify  --tlscacert  "./_cert/ca.pem"  --tlscert "./_cert/cert.pem" \
        --tlskey "./_cert/key.pem" --with-registry-auth \
        stack deploy -c stack.yml  traefik

step 3: 在其它微服务的stack.yml 文件中通过配置label就可以使用traefik。 你现在正在读的这篇博文就是使用traefik 分发请求的，它的stack.yml文件大概是这样子的（留意label的配置）：

version: '3.6'

services:
  ghost:
    image: ghost:2.20-alpine
    networks:      
      - traefik_public
    volumes:
      # 如何实现多台服务器间的文件同步的答案在这里： 
      # 如果ghost_content是一个阿里云oss volume， 那么/var/lib/ghost/content的文件就会写到oss了
      # 而应用程序本身不用做任何改动，只管往 /var/lib/ghost/content 读写文件
      - ghost_content:/var/lib/ghost/content
    environment:
      url: "http://blog.litup.me"
    deploy:
      replicas: 2
      restart_policy:
        condition: on-failure
      update_config:
        # parallelism: 2
        # delay: 10s
        order: start-first
        failure_action: rollback
      resources:
         limits:
           cpus: "0.6"
           memory: 668M
      labels:
        # https://docs.traefik.io/configuration/backends/docker/
        - "traefik.docker.network=traefik_public"
        # 权重，千万别小看它，可以搞蓝绿发布，灰度发布的
        - "traefik.weight=100"
        - "traefik.port=2368"
        # 了解modifiers、Matchers的概念： https://docs.traefik.io/basics/#modifiers
        - "traefik.frontend.rule=Host:blog.litup.me" #;PathPrefixStrip:/blog"

volumes:
    ghost_content:

networks:
  traefik_public:
    external: true

然后使用上面step2中同样的 docker --host*** stack deploy *** 部署（记得改一下stack应用的名称） 就可以通过上面services.ghost.deploy.labels 配置的blog.litup.me 访问这个ghost blog了。

版本升级/共存

对于api类的server端应用，有时候版本升级带来breaking change，这时iOS/安卓App可能没那么快完成新版的覆盖了，这时同时保留旧版和新版的应用就很有必要了。

stack.yml


version: '3.6'
services:
  api-v2:
    image: <可以是公司名的repository-name>/user-api:v2.5.9
    ###----省略很多行------------
    deploy:
      labels:
        # 这样通过 http://api.mydomain.com/v2/user/*** 还是可以访问到v2版的user服务
        - "traefik.frontend.rule=Host:api.mydomain.com";PathPrefixStrip:/v2/user"
        
        
  api-v3:
    # 更强大的是，这个v3.0.1的user-api可以使用和上面v2.5.9不同的框架版本、语言版本、甚至不同的语言开发，只要它能被打包成docker镜像
    # 这对于需要把老式的JAVA应用无缝迁移到现代化的Java/node.js/python应用时非常有效
    image: <可以是公司名的repository-name>/user-api:v3.0.1
    ###----省略很多行------------
    deploy:
      labels:
        # 通过 http://api.mydomain.com/v3/user/*** 访问到v3版的user服务
        - "traefik.frontend.rule=Host:api.mydomain.com";PathPrefixStrip:/v3/user"
  
  api-v3-my:
    # 你以为上面就演示完吗？ 更强大的是：整个user-api可能是老式的JAVA应用，但是大部分功能（例如注册、登陆等）运行稳定，我们没必要去动它
    # 而现在的业务需求是在个人中心新增功能，因为一些原因，比如之前负责这块的团队不在了，或者原应用确实也太老旧，或者足够庞大复杂了，不想在上面继续新增业务功能了
    # 这时你可以在一个新的微服务，选择适合的语言和框架开发这些功能，只要它能被打包成docker镜像，都可以和旧版的应用共存
    image: <可以是公司名的repository-name>/user-api-my:v3.0.1
    ###----省略很多行------------
    deploy:
      labels:
        # 通过 http://api.mydomain.com/v3/user/my/*** 访问到v3版的个人中心服务
        - "traefik.frontend.rule=Host:api.mydomain.com";PathPrefixStrip:/v3/user/my"
   
   # 你甚至还可以为用户中心的一个细分功能开辟一个微服务，例如资产管理“http://api.mydomain.com/v3/user/my/balance”
   # 这在某一个小功能需要紧急bug fix，而整个/user或者user/my又没有到更新周期的情况特别有用，
   # 你可以先部署这1小块，等/user或者user/my新版出来的时候再把这个小小的微服务合并回去，因为它们是共享codebase的，除了正常的git merge之外没有额外的工作量
   # 这里就不继续举例了。

看，一个docker + 一个traefik就给我们无限的想象。

Seneca负责微服务间的通讯

如果你的各微服务间不需要或者很少需要互相通讯，上面已经足够了。但是服务器间需要密集的通讯，Seneca 可以让你省去亲自和mq / rpc /gRpc /甚至tcp 打交道。

Seneca 是一个能让您快速构建基于消息的微服务系统的工具集，你不需要知道各种服务本身被部署在何处，不需要知道具体有多少服务存在，也不需要知道他们具体做什么，任何你业务逻辑之外的服务（如数据库、缓存或者第三方集成等）都被隐藏在微服务之后。

Seneca ：NodeJS 微服务框架入门指南 这篇文章已经写得足够好了，我就不重新介绍一篇了。

微服务程序不是使用node.js开发的

可以尝试通过GraalVM使用Seneca。<- 我还没有做试验

GraalVM 是一个高性能的通用虚拟机，可以运行使用 JavaScript，Python 3，Ruby，R，基于 JVM 的语言以及基于 LLVM 的语言开发的应用。 GraalVM 消除了编程语言之间的隔离性，并且通过共享运行时增强了他们的互操作性。它可以独立运行，也可以运行在 OpenJDK，Node.js，Oracle，MySQL 等环境中

全栈虚拟机GraalVM初体验

还有很多要考虑的问题呢？

刚才说的 “不用提前备份当前本版应用，不用担心部署失败造成服务中断”， 为什么这么牛B呢？ 请看：

stack-

也许你会问，微服务架构本身还有很多问题要解决啊，例如 “文件如何同步？”，“ sticky cookie/session能保证吗？”， “后端服务器健康检查？” ，“最大连接数限制？” 之类的。 回头再看一下就能找到答案了，代码中的注释也要认真看哦。

是的还有更多

小地方的tips未来会在这里补充，但不包括， 比如 “数据库的分片/读写分离” 之类的，因为本文的主题是快速实现微服务架构，不是 大*** ，高****。

附录1：
docker swarm 的alternative:
http://highscalability.com/blog/2019/4/8/from-bare-metal-to-kubernetes.html
http://highscalability.com/blog/2019/4/8/from-bare-metal-to-kubernetes.html

Kubernetes: The Surprisingly Affordable Platform for Personal Projects

Kubernetes for personal projects? No thanks!

JAVA应用容器化工具： https://jaxenter.com/jib-java-containerization-146647.html

附录2：
关于“只需要一条大路通罗马”

漫画家蔡志忠有一个演讲，题目叫做《努力是没有用的》。读完这份演讲稿，我觉得他说的有道理。
有些人非常勤奋，别人休息和娱乐的时候，都在工作学习。但是努力了一辈子，人生也没有显著的提升，就像报道里经常说的："某某在平凡的岗位上，勤勤恳恳工作了一辈子"。
另一方面，很多成功者似乎也没有特别努力，就取得了许多成就，过上了好日子。蔡志忠以自己为例，他从小就喜欢画画，然后一直画，不知不觉就成了大漫画家，名利双收，从没有觉得过得很辛苦。
老师或父母老是说，努力就会走到巅峰----才怪。如果这样，不是所有人都走上巅峰了吗？没有人开始不努力，为什么后来不努力，因为努力没有效果。"
人生不是走斜坡，你持续走就可以走到巅峰；人生像走阶梯，每一阶有每一阶的难点，学物理有物理的难点，学漫画有漫画的难点，你没有克服难点，再怎么努力都是原地跳。所以当你克服难点，你跳上去就不会下来了。
蔡志忠的核心观点就是黑体的那句话，成功的人生是台阶式向上，而不是一条水平线。努力只是说明你拼命在走，跟你能不能向上走，关系不大。那些努力却没有结果的人，根本原因就在于，他一直走在平面上，没有走到更高的台阶。
也就是说，垂直方向的努力更有意义，水平方向的努力意义不大。你把同一件事情勤奋地做上十遍，还是只会做这一件事；你做完这件事后，再去挑战更难的事情，就有机会学会做两件事。
初学者经常问我，前端开发应该学习哪一个框架？我的回答就是，你觉得哪一个框架比较容易，就用那个。因为它们都是解决同样的问题，你只要知道怎么解决就可以了，没必要深究哪一个解决得更好。对你更重要的是，要去解决更多的问题，而不是如何最好地解决一个问题。
只有通过解决更多的问题，人生才能摆脱水平运动，进入上升运动。当然，这里还有一个天赋和兴趣的问题，如果找到属于你的领域，不用特别努力就能上台阶；如果找不对领域，再努力也只能做水平运动。

Sign up for more like this.

Enter your email
Subscribe