Lời tựa
Cập nhật vào năm 2016. Mọi thứ đang phát triển, tất cả các máy chủ đang trở nên tốt hơn, tất cả đều hỗ trợ SSL và web tuyệt vời hơn bao giờ hết.
Trừ khi được nêu, những điều sau đây được nhắm đến các chuyên gia trong kinh doanh và khởi nghiệp, hỗ trợ hàng ngàn đến hàng triệu người dùng.
Những công cụ và kiến trúc này đòi hỏi rất nhiều người dùng / phần cứng / tiền. Bạn có thể thử điều này tại phòng thí nghiệm tại nhà hoặc để chạy blog nhưng điều đó không có ý nghĩa nhiều.
Theo nguyên tắc chung, hãy nhớ rằng bạn muốn giữ cho nó đơn giản . Mỗi phần mềm trung gian được thêm vào là một phần quan trọng khác của phần mềm trung gian để duy trì. Sự hoàn hảo không đạt được khi không còn gì để thêm nhưng khi không còn gì để xóa.
Một số triển khai phổ biến và thú vị
HAProxy (cân bằng) + nginx (ứng dụng php + bộ nhớ đệm)
Máy chủ web là nginx chạy php. Khi nginx đã ở đó, nó cũng có thể xử lý bộ nhớ đệm và chuyển hướng.
HAProxy ---> nginx-php
A ---> nginx-php
P ---> nginx-php
r ---> nginx-php
o ---> nginx-php
x ---> nginx-php
y ---> nginx-php
HAProxy (cân bằng) + Varnish (bộ nhớ đệm) + Tomcat (ứng dụng Java)
HAProxy có thể chuyển hướng đến Varnish dựa trên URI yêu cầu (* .jpg * .css * .js).
HAProxy ---> tomcat
A ---> tomcat
---> tomcat
P ---> tomcat <----+
r ---> tomcat <---+|
o ||
x ---> varnish <--+|
y ---> varnish <---+
HAProxy (cân bằng) + nginx (SSL đến máy chủ và lưu trữ) + Máy chủ web (ứng dụng)
Các máy chủ web không nói SSL mặc dù MỌI NGƯỜI PHẢI NÓI SSL ( đặc biệt là liên kết HAProxy-WebServer này với thông tin người dùng cá nhân đi qua EC2 ). Thêm một nginx cục bộ cho phép đưa SSL lên máy chủ. Khi nginx ở đó, nó cũng có thể thực hiện một số bộ nhớ đệm và ghi lại URL.
Lưu ý : Chuyển hướng cổng 443: 8080 đang diễn ra nhưng không phải là một phần của tính năng. Không có điểm nào trong việc chuyển hướng cổng. Bộ cân bằng tải có thể nói chuyện trực tiếp với máy chủ web: 8080.
(nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A ---> nginx:443 -> webserver:8080
P ---> nginx:443 -> webserver:8080
r ---> nginx:443 -> webserver:8080
o ---> nginx:443 -> webserver:8080
x ---> nginx:443 -> webserver:8080
y ---> nginx:443 -> webserver:8080
Middleware
HAProxy: Cân bằng tải
Các tính năng chính :
- Cân bằng tải (TCP, HTTP, HTTPS)
- Nhiều thuật toán (vòng tròn, ip nguồn, tiêu đề)
- Kiên trì phiên
- Chấm dứt SSL
Các lựa chọn thay thế tương tự : nginx (máy chủ web đa năng có thể định cấu hình như một bộ cân bằng tải)
Các lựa chọn khác nhau : Cloud (Amazon ELB, Google load balancer), Phần cứng (F5, fortinet, citrix Netscaler), Other & Worldwide (DNS, anycast, CloudFlare)
HAProxy làm gì và khi nào bạn phải sử dụng nó?
Bất cứ khi nào bạn cần cân bằng tải. HAProxy là giải pháp.
Ngoại trừ khi bạn muốn rất rẻ HOẶC nhanh & bẩn HOẶC bạn không có sẵn các kỹ năng, thì bạn có thể sử dụng ELB: D
Ngoại trừ khi bạn ở ngân hàng / chính phủ / tương tự yêu cầu sử dụng trung tâm dữ liệu của riêng bạn với các yêu cầu khó khăn (cơ sở hạ tầng chuyên dụng, chuyển đổi dự phòng đáng tin cậy, 2 lớp tường lửa, công cụ kiểm toán, SLA để trả x% mỗi phút thời gian chết, tất cả trong một) bạn có thể đặt 2 F5 lên trên giá chứa 30 máy chủ ứng dụng của bạn.
Ngoại trừ khi bạn muốn vượt qua 100 nghìn HTTP (S) [và nhiều trang web], thì bạn PHẢI có nhiều HAProxy với một lớp cân bằng tải [toàn cầu] ở phía trước chúng (cloudflare, DNS, anycast). Về mặt lý thuyết, bộ cân bằng toàn cầu có thể nói chuyện trực tiếp với các máy chủ web cho phép bỏ HAProxy. Tuy nhiên, thông thường, bạn NÊN giữ HAProxy (s) làm điểm vào công khai cho trung tâm dữ liệu của mình và điều chỉnh các tùy chọn nâng cao để cân bằng công bằng giữa các máy chủ và giảm thiểu phương sai.
Ý kiến cá nhân : Một dự án nhỏ, chứa, nguồn mở, hoàn toàn dành riêng cho MỘT MỤC ĐÍCH THỰC SỰ. Trong số các cấu hình dễ nhất (MỘT tệp), phần mềm nguồn mở hữu ích và đáng tin cậy nhất mà tôi đã gặp trong đời.
Nginx: Apache không hút
Các tính năng chính :
- Máy chủ web HTTP hoặc HTTPS
- Chạy các ứng dụng trong CGI / PHP / một số khác
- Chuyển hướng / viết lại URL
- Kiểm soát truy cập
- Thao tác tiêu đề HTTP
- Bộ nhớ đệm
- Proxy ngược
Các lựa chọn thay thế tương tự : Apache, Lighttpd, Tomcat, Gunicorn ...
Apache là máy chủ web thực tế, còn được gọi là một cụm khổng lồ gồm hàng chục mô-đun và hàng ngàn dòng httpd.conftrên cấu trúc xử lý yêu cầu bị hỏng. nginx làm lại tất cả điều đó, với ít mô-đun, cấu hình đơn giản hơn (một chút) và kiến trúc lõi tốt hơn.
Nginx làm gì và khi nào bạn phải sử dụng nó?
Một máy chủ web được dự định để chạy các ứng dụng. Khi ứng dụng của bạn được phát triển để chạy trên nginx, bạn đã có nginx và bạn cũng có thể sử dụng tất cả các tính năng của nó.
Ngoại trừ khi ứng dụng của bạn không có ý định chạy trên nginx và nginx không tìm thấy ở đâu trong ngăn xếp của bạn (cửa hàng Java có ai không?) Thì có rất ít điểm trong nginx. Các tính năng của máy chủ web có khả năng tồn tại trong máy chủ web hiện tại của bạn và các tác vụ khác được xử lý tốt hơn bằng công cụ chuyên dụng thích hợp (HAProxy / Varnish / CDN).
Ngoại trừ khi máy chủ web / ứng dụng của bạn thiếu tính năng, khó định cấu hình và / hoặc bạn thà chết công việc hơn là nhìn vào nó (Gunicorn có ai không?), Thì bạn có thể đặt nginx ở phía trước (tức là cục bộ trên mỗi nút) để thực hiện URL viết lại, gửi chuyển hướng 301, thực thi kiểm soát truy cập, cung cấp mã hóa SSL và chỉnh sửa các tiêu đề HTTP một cách nhanh chóng. [Đây là những tính năng được mong đợi từ máy chủ web]
Varnish: Máy chủ lưu trữ
Các tính năng chính :
- Bộ nhớ đệm
- Bộ nhớ đệm nâng cao
- Bộ nhớ đệm hạt mịn
- Bộ nhớ đệm
Các lựa chọn thay thế tương tự : nginx (máy chủ web đa năng có thể định cấu hình như một máy chủ bộ đệm)
Các lựa chọn thay thế khác nhau : CDN (Akamai, Amazon CloudFront, CloudFlare), Phần cứng (F5, Fortinet, Citrix Netscaler)
Varnish làm gì và khi nào bạn phải sử dụng nó?
Nó không lưu trữ, chỉ lưu trữ. Nó thường không đáng để nỗ lực và nó lãng phí thời gian. Hãy thử CDN thay thế. Hãy lưu ý rằng bộ nhớ đệm là điều cuối cùng bạn nên quan tâm khi chạy một trang web.
Ngoại trừ khi bạn đang điều hành một trang web độc quyền về hình ảnh hoặc video thì bạn nên xem xét kỹ CDN và suy nghĩ nghiêm túc về bộ nhớ đệm.
Ngoại trừ khi bạn buộc phải sử dụng phần cứng của riêng mình trong trung tâm dữ liệu của riêng bạn (CDN không phải là một tùy chọn) và máy chủ web của bạn rất tệ trong việc cung cấp các tệp tĩnh (thêm nhiều máy chủ web không giúp đỡ) thì Varnish là giải pháp cuối cùng.
Ngoại trừ khi bạn có một trang web có nội dung chủ yếu là tĩnh-nhưng-phức tạp-được tạo động (xem các đoạn sau) thì Varnish có thể tiết kiệm rất nhiều sức mạnh xử lý trên máy chủ web của bạn.
Bộ nhớ đệm tĩnh được đánh giá cao trong năm 2016
Bộ nhớ đệm gần như là cấu hình miễn phí, không có tiền và thời gian miễn phí. Chỉ cần đăng ký CloudFlare hoặc CloudFront hoặc Akamai hoặc MaxCDN. Thời gian tôi viết dòng này dài hơn thời gian để thiết lập bộ nhớ đệm VÀ bia tôi đang cầm trên tay đắt hơn đăng ký CloudFlare trung bình.
Tất cả các dịch vụ này đều hoạt động tốt đối với tĩnh * .css * .js * .png và hơn thế nữa. Trên thực tế, họ chủ yếu tôn trọng Cache-Controlchỉ thị trong tiêu đề HTTP. Bước đầu tiên của bộ nhớ đệm là cấu hình máy chủ web của bạn để gửi các chỉ thị bộ đệm phù hợp. Không quan trọng CDN là gì, Varnish là gì, trình duyệt nào ở giữa.
Cân nhắc hiệu suất
Varnish được tạo ra vào thời điểm các máy chủ web trung bình đang nghẹt thở để phục vụ hình ảnh con mèo trên blog. Ngày nay, một ví dụ duy nhất của máy chủ web điều khiển từ thông dụng không đồng bộ đa luồng hiện đại trung bình có thể cung cấp mèo con một cách đáng tin cậy cho cả một quốc gia. Lịch sự của sendfile().
Tôi đã làm một số thử nghiệm hiệu suất nhanh chóng cho dự án cuối cùng mà tôi đã làm việc. Một phiên bản tomcat duy nhất có thể phục vụ 21 000 đến 33 000 tệp tĩnh mỗi giây qua HTTP (các tệp thử nghiệm từ 20B đến 12kB với số lượng kết nối HTTP / máy khách khác nhau). Lưu lượng ra bên ngoài được duy trì vượt quá 2,4 Gb / s. Sản xuất sẽ chỉ có giao diện 1 Gb / s. Không thể làm tốt hơn phần cứng, thậm chí không cần cố gắng Varnish.
Bộ nhớ đệm thay đổi nội dung động
CDN và máy chủ lưu trữ thường bỏ qua URL với các tham số như ?article=1843, họ bỏ qua mọi yêu cầu với cookie phiên hoặc người dùng được xác thực và họ bỏ qua hầu hết các loại MIME bao gồm application/jsontừ /api/article/1843/info. Có các tùy chọn cấu hình có sẵn nhưng thường không phải là hạt mịn, thay vì "tất cả hoặc không có gì".
Varnish có thể có các quy tắc phức tạp tùy chỉnh (xem VCL) để xác định cái gì là bộ nhớ cache và cái gì không. Các quy tắc này có thể lưu trữ nội dung cụ thể theo URI, tiêu đề và cookie phiên người dùng hiện tại và loại MIME và nội dung TẤT CẢ ĐẾN. Điều đó có thể tiết kiệm rất nhiều sức mạnh xử lý trên máy chủ web cho một số mẫu tải rất cụ thể. Đó là khi Varnish tiện dụng và TUYỆT VỜI.
Phần kết luận
Tôi phải mất một thời gian để hiểu tất cả những mảnh ghép này, khi nào nên sử dụng chúng và làm thế nào chúng khớp với nhau. Hy vọng điều này có thể giúp bạn.
Điều đó hóa ra khá dài (6 giờ để viết. OMG !: O). Có lẽ tôi nên bắt đầu một blog hoặc một cuốn sách về điều đó. Sự thật thú vị: Dường như không có giới hạn về độ dài câu trả lời.