在上次發布失敗后，很多朋友建議我們改用 k8s ，但我們還是想再試試 docker swarm ，實在不行再改用 k8s 。
在改進了 docker swarm 集群的部署后，我們准備今天 17:30 左右進行一次發布嘗試。
docker swarm 集群是我們使用阿里雲服務器自己搭建的，這次進行了3方面的改進。
1. 升級了 worker 節點服務器的配置
worker 節點由6台4核8G服務器換成了3台8核16G服務器，基於3點考慮：
1）提高單台服務器的處理能力；
2）提高服務器的網絡處理能力，阿里雲的服務器配置越高，網絡處理能力越強；
3）減少服務器數量可以減少 docker swarm 節點之間的通信開銷。
2. 升級了 docker engine，由 18.09.4 升級至 19.03.1
wget -c https://download.docker.com/linux/centos/7/x86_64/stable/Packages/containerd.io-1.2.6-3.3.el7.x86_64.rpm && \ wget -c https://download.docker.com/linux/centos/7/x86_64/stable/Packages/docker-ce-19.03.1-3.el7.x86_64.rpm && \ wget -c https://download.docker.com/linux/centos/7/x86_64/stable/Packages/docker-ce-cli-19.03.1-3.el7.x86_64.rpm && \ yum install -y containerd.io-1.2.6-3.3.el7.x86_64.rpm && \ yum install -y docker-ce-19.03.1-3.el7.x86_64.rpm && \ yum install -y docker-ce-cli-19.03.1-3.el7.x86_64.rpm
3. nginx 改用 host 網絡模式部署
ports: - target: 80 published: 80 protocol: tcp mode: host
另外，改進了博客系統緩存部分的代碼，解決了新舊版切換時的緩存沖突問題。
這次發布如果遇到問題，我們可以快速回退到舊版。
如果在發布過程中出現問題影響您的正常訪問，請您諒解。
------------------------------------------
發布過程記錄
17:40 使用 nginx 轉發，切換了1/5不到的流量就出現了1秒延遲的問題。
18:20 改為 kestrel 以端口映射的方式直接監聽 80 端口，切換了1/3左右的流量，未出現延遲1秒的問題。
18:33 所有流量都已切換，未出現延遲1秒的問題。
以下是發布過程中服務器同時連接數監控，使用 nginx 轉發時，當同時連接數超過 40K ，所有請求都出現1秒延遲的問題。當改為 kestrel 直接監聽80端口后，即使同時連接數超過 100K ，也沒出現1秒延遲的問題。沒想到1秒延遲竟然是 nginx 的問題（或者是 nginx 對 docker swarm 的支持問題），不是 docker swarm 網絡本身的問題。
21:00 今天發布后一直在線上，如果明天上午的訪問高峰能撐住，那就說明發布成功了。
8月8日
9:15 左右，服務器同時連接數超過 130K ，3台服務器撐不住，加了1台服務器。
9:26 左右，memcached 客戶端 socketPool 滿了，將 maxPoolSize 由 500 修改為 800 。
2019-08-08 09:24:30.781 [Error] Pool is full, timeouting. 10.0.78.124:11211
10:15 左右，docker swarm 集群有增加了1台8核16G的服務器，目前一共5台 worker 節點。
11:05 更新：每台服務器上博客應用容器的的 CPU 消耗在 5-6 核，內存消耗在 1G 與 1.5G 之間。
11:05 左右，負載沒有下降，我們什么也沒動，響應速度卻出奇地穩定，並且與訪問低峰時一樣飛快。
13:30 更新：今天上午訪問高峰時單台服務器同時連接數最高達到21萬（監控數據來自阿里雲雲監控）。
17:10 更新：今天下午訪問高峰期間，訪問速度很不穩定。我們正在考慮下一步的對策。
17:30 左右，當訪問量回落到一定程度后， 訪問速度恢復正常。