2011-08-31 17 views
46

Tôi đã đăng bài này lên ServerFault, nhưng cộng đồng Node.js có vẻ nhỏ bé ở đó, vì vậy tôi hy vọng điều này sẽ mang lại nhiều hơn Phơi bày.Cách triển khai Node.js trên đám mây để có tính sẵn sàng cao bằng cách sử dụng đa lõi, đảo ngược proxy và SSL

Tôi có ứng dụng Node.js (0.4.9) và đang nghiên cứu cách triển khai và duy trì tốt nhất. Tôi muốn chạy nó trong đám mây (EC2 hoặc RackSpace) với tính sẵn sàng cao. Ứng dụng sẽ chạy trên HTTPS. Tôi sẽ lo lắng về sự chuyển đổi dự phòng hoàn toàn của East/West/EU sau này.

Tôi đã thực hiện rất nhiều việc đọc về các tiện ích đa sức sống (Upstart, Forever), đa lõi (Fugue, multi-node, Cluster) và proxy/load balancers (node-http-proxy, nginx, Varnish) , và Pound). Tuy nhiên, tôi không chắc chắn làm thế nào để kết hợp các tiện ích khác nhau có sẵn cho tôi.

Tôi có ý tưởng thiết lập này và cần đưa ra một số câu hỏi và nhận phản hồi.

  1. Cụm là tiện ích đa lõi tích cực nhất được phát triển và dường như phổ biến cho Node.js, vì vậy sử dụng để chạy 1 nút "cluster" mỗi máy chủ ứng dụng trên cổng không có đặc quyền (nói 3000). Q1: Nên Mãi mãi được sử dụng để giữ cho cụm tồn tại hoặc chỉ là dư thừa?
  2. Sử dụng 1 nginx mỗi máy chủ ứng dụng đang chạy trên cổng 80, chỉ cần đảo ngược proxy đến nút trên cổng 3000. Q2: Would nút-http-proxy thể phù hợp hơn cho nhiệm vụ này mặc dù nó không gzip hoặc các tập tin tĩnh máy chủ một cách nhanh chóng?
  3. Có tối thiểu 2x máy chủ như được mô tả ở trên, với một máy chủ độc lập hoạt động như bộ cân bằng tải trên các hộp này. Sử dụng số Pound nghe 443 để chấm dứt HTTPS và chuyển HTTP sang Varnish sẽ làm tròn số dư tải trên toàn bộ các máy chủ ở trên. Q3: Nên nginx được sử dụng để thực hiện cả hai thay vào đó? Q4: nên AWS hoặc Rackspace cân bằng tải được coi là thay vì (sau này không chấm dứt HTTPS)

Câu hỏi chung:

  1. Bạn có thấy một nhu cầu (2) ở trên tại tất cả các?
  2. Đâu là nơi tốt nhất để chấm dứt HTTPS?
  3. Nếu WebSockets là cần thiết trong tương lai, bạn sẽ thực hiện những thay thế nginx nào?

Tôi thực sự muốn biết cách mọi người đang thiết lập môi trường sản xuất hiện tại và sự kết hợp các công cụ mà họ thích. Nhiều đánh giá cao.

+4

Lưu ý rằng Cụm v.v. không cung cấp đa luồng, chúng chỉ đơn giản cung cấp việc sử dụng nhiều lõi thông qua nhiều quy trình. Điều này hoàn toàn khác. Cũng lưu ý rằng Cluster sẽ không cung cấp tính khả dụng cao nếu master của bạn bị hỏng. Đứa trẻ sẽ tự tử và thầy sẽ không hồi sinh. Có lẽ bạn có thể sử dụng một cái gì đó như Forever để khởi động lại tổng thể. Ngoài ra, lưu ý rằng Nginx không có khả năng định tuyến các kết nối websocket. Cuối cùng, "một máy chủ độc lập hoạt động như một bộ cân bằng tải trên các hộp này": nếu máy chủ này bị hỏng? – Tom

+0

@Tom, tất cả các điểm tuyệt vời. Tôi sẽ cập nhật các câu hỏi để lưu ý sử dụng đa lõi, không phải đa luồng, nhưng trước đây là những gì tôi có ý nghĩa. Tôi muốn sử dụng Monit trên mỗi máy chủ để xem PID của Cluster và khởi động lại nó nếu cần thiết. Tôi hiểu giới hạn WS/WSS hiện tại của nginx nhưng không cần điều đó. Tôi cũng sử dụng Monit trên bộ cân bằng tải, nhưng vẫn chưa có giải pháp tốt cho điểm lỗi duy nhất đó, thiếu nhiều vùng sẵn có (bản sao của toàn bộ thiết lập này). –

+0

@ChrisF nói chuyện với các nodejitsu guys trong #nodejitsu trên freenode. Nếu bạn muốn biết về kiến ​​trúc nút đó là nơi để được. – Raynos

Trả lời

20

Đã vài tháng kể từ khi tôi hỏi câu hỏi này và không có nhiều dòng câu trả lời. Cả Samyak Bhuta và nponeccop đều có những gợi ý tốt, nhưng tôi muốn thảo luận về những câu trả lời mà tôi đã tìm thấy cho câu hỏi của mình.

Đây là những gì tôi đã giải quyết vào thời điểm này cho một hệ thống sản xuất, nhưng các cải tiến khác luôn được thực hiện. Tôi hy vọng nó sẽ giúp bất cứ ai trong một kịch bản tương tự.

  1. Sử dụng Cụm để sinh ra nhiều quy trình con như bạn muốn xử lý các yêu cầu đến trên máy ảo hoặc máy đa lõi. Điều này liên kết với một cổng duy nhất và làm cho bảo trì dễ dàng hơn. Quy tắc chung của tôi là n - 1 Công nhân cụm. Bạn không cần Forever về điều này, vì Cluster đáp ứng các quy trình của nhân viên chết. Để có khả năng phục hồi ngay cả ở cấp cha mẹ Cluster, hãy đảm bảo rằng bạn sử dụng kịch bản Upstart (hoặc tương đương) để daemonize ứng dụng Node.js và sử dụng Monit (hoặc tương đương) để xem PID của Cluster cha và respawn nó nếu nó chết . Bạn có thể thử sử dụng tính năng hồi sinh của Upstart, nhưng tôi thích có Monit đang theo dõi mọi thứ, hơn là chia trách nhiệm, tôi thấy tốt nhất là để Monit xử lý sự hồi sinh.

  2. Sử dụng 1 nginx trên mỗi máy chủ ứng dụng chạy trên cổng 80, chỉ cần đảo ngược proxy vào cụm của bạn trên bất kỳ cổng nào bạn đã ràng buộc trong (1). nút-http-proxy có thể được sử dụng, nhưng nginx là trưởng thành hơn, nhiều tính năng hơn và nhanh hơn trong việc phân phối các tệp tĩnh. Chạy nginx lean (không đăng nhập, không gzip các tập tin nhỏ) để giảm thiểu chi phí của nó. Có 2 máy chủ tối thiểu như được mô tả ở trên trong tối thiểu 2 vùng sẵn có, và nếu trong AWS, sử dụng ELB kết thúc HTTPS/SSL trên cổng 443 và giao tiếp trên cổng HTTP 80 với máy chủ ứng dụng node.js. ELB rất đơn giản và nếu bạn muốn, làm cho nó dễ dàng hơn để tự động mở rộng quy mô. Bạn có thể chạy nhiều nginx hoặc chia sẻ một IP hoặc round-robin cân bằng bản thân bởi nhà cung cấp DNS của bạn, nhưng tôi thấy điều này quá mức cần thiết cho bây giờ. Tại thời điểm đó, bạn sẽ xóa phiên bản nginx trên mỗi máy chủ ứng dụng.

Tôi không cần WebSockets để nginx tiếp tục phù hợp và tôi sẽ truy cập lại vấn đề này khi WebSockets được đưa vào ảnh.

Phản hồi được hoan nghênh.

+4

tại sao bạn sử dụng nginx? để phục vụ nội dung tĩnh hoặc làm bộ định tuyến cho các máy chủ ứng dụng khác nhau? Nếu chỉ để phục vụ nội dung tĩnh thì tại sao không s3? – GJain

+0

Tôi thực sự tò mò muốn biết liệu bạn có cân nhắc sử dụng công cụ PM2 và các vòng mạnh 'sở hữu' các bộ công cụ 'slc' chủ yếu là 'triển khai scl' và 'scl pm' –

2

Bạn không nên bận tâm phân phát tệp tĩnh một cách nhanh chóng. Nếu tải của bạn là nhỏ - nút máy chủ tệp tĩnh sẽ làm. Nếu tải của bạn lớn - tốt hơn là sử dụng CDN (Akamai, Limelight, CoralCDN).

Thay vì mãi mãi, bạn có thể sử dụng đơn vị.

Thay vì nginx bạn có thể sử dụng HAProxy. Nó được biết là làm việc tốt với websockets.Cũng nên xem xét các ổ cắm flash proxy vì chúng là một giải pháp tốt cho đến khi hỗ trợ websocket có mặt khắp mọi nơi (xem socket.io).

HAProxy có một số hỗ trợ để cân bằng tải HTTPS, nhưng không chấm dứt. Bạn có thể thử sử dụng stunnel để chấm dứt HTTPS, nhưng tôi nghĩ nó quá chậm.

Cân bằng tải vòng (hoặc thống kê khác) hoạt động khá tốt trong thực tế, do đó không cần phải biết về tải của các máy chủ khác trong hầu hết các trường hợp.

Cân nhắc việc sử dụng ZeroMQ hoặc RabbitMQ để liên lạc giữa các nút.

+1

Tò mò, Zero/RabbitMQ có lợi thế gì khi sử dụng ổ cắm nodeJS nguyên gốc cho giao tiếp giữa các nút? –

+1

@XHR: Sử dụng MQ có thể cung cấp giao tiếp phức tạp hơn giữa nhiều nút, bao gồm tin nhắn và tin nhắn phát sóng vào hàng đợi công việc có thể được phục vụ chính xác bằng một trong các nút sẵn có tiếp theo. Hãy nghĩ về MQ là ổ cắm tự tổ chức và tự chữa bệnh. –

0

Tôi đã thấy cân bằng tải AWS để tải cân bằng và chấm dứt + http-node-proxy cho proxy ngược, nếu bạn muốn chạy nhiều dịch vụ cho mỗi hộp + cluster.js để hỗ trợ mulicore và quá trình chuyển đổi dự phòng hoạt động rất tốt.

forever.js trên cluster.js có thể là lựa chọn tốt cho việc chăm sóc cực độ mà bạn muốn thực hiện về chuyển đổi dự phòng nhưng điều đó hầu như không cần thiết.

2

Đây là một chuỗi tuyệt vời! Nhờ tất cả mọi người đã đóng góp thông tin hữu ích.

Tôi đã xử lý các vấn đề tương tự trong vài tháng qua để thiết lập cơ sở hạ tầng cho việc khởi động của chúng tôi.

Khi mọi người đề cập trước đây, chúng tôi muốn có một môi trường Node với đa lõi socket hỗ trợ + web + vhosts

Chúng tôi đã kết thúc việc tạo ra một hỗn hợp giữa các module cụm bản địa và http-proxy và gọi nó là Drone - tất nhiên nó mở nguồn:

https://github.com/makesites/drone

Chúng tôi cũng phát hành nó như một AMI với Monit và Nginx

https://aws.amazon.com/amis/drone-server

Tôi tìm thấy chủ đề này nghiên cứu cách thêm hỗ trợ SSL cho Drone - tnx để giới thiệu ELB nhưng tôi sẽ không dựa vào giải pháp độc quyền cho một điều rất quan trọng.

Thay vào đó, tôi mở rộng proxy mặc định để xử lý tất cả các yêu cầu SSL. Cấu hình tối thiểu trong khi yêu cầu SSL được chuyển thành http đơn giản - nhưng tôi đoán đó là thích hợp hơn khi bạn đang chuyển lưu lượng truy cập giữa các cổng ...

Hãy nhìn vào nó và cho tôi biết nếu nó phù hợp với nhu cầu của bạn. Tất cả phản hồi đều được hoan nghênh.

Các vấn đề liên quan