☰

Meteor JS 故障转移问题（重新连接延迟）

tag-icon • tag-icon nginx node.js javascript meteor
Meteor JS 故障转移问题（重新连接延迟）

我们的 Metrace 部署包含两个 Metrace 节点，位于网络负载均衡器（Google Cloud NLB，它只是将请求传递给 2 个 Ubuntu 14.04 Metrace 实例的目标池）后面。

每个节点都安装了 Nginx，终止 SSL 和代理将请求传递到端口 3000 上的应用程序。

Nginx 配置：

server_tokens off; # for security-by-obscurity: stop displaying nginx version

# this section is needed to proxy web-socket connections
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;

# HTTPS server
server {
    listen 443 ssl spdy; # we enable SPDY here
    server_name meteor.cg-platform.com; # this domain must match Common Name (CN) in the SSL certificate

    root html; # irrelevant
    index index.html; # irrelevant

    ssl_certificate /etc/nginx/ssl/server.crt; # full path to SSL certificate and CA certificate concatenated together
    ssl_certificate_key /etc/nginx/ssl/server.key; # full path to SSL key

    # performance enhancement for SSL
    ssl_stapling on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 5m;

    # safety enhancement to SSL: make sure we actually use a safe cipher
    ssl_prefer_server_ciphers on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES$

    # config to enable HSTS(HTTP Strict Transport Security) https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security
    # to avoid ssl stripping https://en.wikipedia.org/wiki/SSL_stripping#SSL_stripping
    # add_header Strict-Transport-Security "max-age=31536000;";

    # If your application is not compatible with IE <= 10, this will redirect visitors to a page advising a browser update
    # This works because IE 11 does not present itself as MSIE anymore
    if ($http_user_agent ~ "MSIE" ) {
        return 303 https://browser-update.org/update.html;
    }

    # pass all requests to Meteor
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade; # allow websockets
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header X-Forwarded-For $remote_addr; # preserve client IP

        # this setting allows the browser to cache the application in a way compatible with Meteor
        # on every applicaiton update the name of CSS and JS file is different, so they can be cache infinitely (here: 30           days)
        # the root path (/) MUST NOT be cached
        if ($uri != '/') {
            expires 30d;
        }
    }
}

我们已经从 Meteor 示例存储库用户 mup 部署了 simple-todos 应用程序。

我们正在测试一个节点到另一个节点的故障转移，方法是关闭一个节点上的应用程序，看看浏览器是否重新建立与另一个节点的连接。这实际上是可行的，但延迟可能相当大 - 介于 1 秒到 20 秒之间（！）。

在浏览器控制台上，我们会收到一些502-BAD_GATEWAY错误，直到 websocket 重新建立与其他工作节点的连接。

  1. 我们如何才能将延迟降至最低？
  2. 有没有什么好的做法可以实现这种高可用性功能？

相关内容