2008-11-30 34 views
6

Chúng tôi chạy một trang nội dung có khối lượng tương đối cao. Giống như hầu hết các trang nội dung, phần lớn mỗi trang là tương đối tĩnh. Các bài viết hiếm khi thay đổi, làm cho chúng trở thành ứng cử viên tốt cho một số dạng bộ nhớ đệm tĩnh/cạnh. Tuy nhiên, có hai vấn đề lớn. Các phần tử trang phụ (nav, các danh sách nội dung gần đây, vv) thay đổi khá thường xuyên, nhanh chóng làm mất hiệu lực các trang được lưu trong bộ nhớ cache "đầy đủ". Cũng khá phổ biến khi chúng tôi bao gồm nhiều bit động hơn trong một trang, như thông tin cụ thể của người dùng, v.v.Xử lý bài đăng của các yêu cầu HTTP được ủy quyền ngược? (giống như ESI của Akamai)

Sẽ rất gọn gàng để có bộ cân bằng tải/proxy ngược sau nội dung được xử lý và cho phép chúng tôi xử lý proxy/cạnh. Yêu cầu ban đầu cho chương trình phụ trợ sẽ trả về một mẫu thô, sau đó phần mềm proxy có thể xử lý mẫu đó để hoàn thành nó. Đánh dấu có thể trông giống như sau:

<html> 
<body> 
    <div id="content"> 
    Lorem ipsum whackem smackem. 
    <% 
     dynamic "http://related.content.service/this/story" 
    %> 
    </div> 
    <div id="sidebar"> 
    <% 
     dynamic do |request| 
     url = "http://my.user.service/user-widget.html" 
     if request.cookies.contains?("user_token") 
      url = "http://my.user.service/" + request.cookies["user_token"] + "/user-widget.html" 
     end 

     error_text = "User service not available" 
     { :url => url, :timeout => 500, :error => error_text } 
     end 
    %> 
    </div> 
</body> 
</html> 

Những gì bạn thấy trong ví dụ này là một chút Ruby xác định tệp được bao gồm dựa trên giá trị cookie, sau đó trả về giá trị băm bằng URL để kéo , thời gian chờ và một số văn bản mặc định để hiển thị trong trường hợp có lỗi. Về lý thuyết, tất cả các bao gồm có thể được yêu cầu không đồng bộ là tốt.

Hiểu biết của tôi là Amazon thực hiện điều gì đó như thế này. Các thành phần trang khác nhau được tạo ra bởi các dịch vụ phụ trợ, với giới hạn thời gian chờ nghiêm ngặt để đảm bảo tốc độ trang tổng thể. Tôi đã hy vọng dịch vụ CDN của họ sẽ bao gồm một cái gì đó như thế này, nhưng nó không phải là!

Có thông số W3 cho Edge Side Includes (ESI) gần như là những gì tôi muốn. Có rất ít hỗ trợ cho nó ra khỏi đó, tuy nhiên. Nó có sẵn thông qua Akamai, có một số phần mềm Oracle thực hiện nó, và bộ nhớ cache Varnish nguồn mở có một triển khai rất cơ bản. Nó cũng là một định dạng XML thực sự xấu xí.

Vì vậy, câu hỏi đặt ra là: điều gì sẽ giúp tôi làm những gì tôi muốn? Có ai khác làm việc theo cách này không?

Trả lời

2

đặt Nginx làm giao diện người dùng và sử dụng SSI để chọn các phần động của các trang. nguồn động có thể là máy chủ HTTP, như Apache hoặc máy chủ FastCGI, ví dụ như PHP hoặc Django.

chỉnh sửa:

Nhiều máy chủ web hỗ trợ một số hình thức của SSI (Server Side Includes), tính năng này cho phép bạn thêm một số thẻ vào HTML như một hình thức rất hạn chế về kịch bản, đơn giản hơn nhiều và nhanh hơn (trở lên) so với PHP. Sử dụng điều này, bạn có thể đặt các trang tĩnh với hầu hết nội dung và đối với 'các phần động nhỏ', thẻ SSI tham chiếu một trang động được tạo ở một nơi khác.

Tôi đặc biệt thích nginx làm lối vào cho hầu hết mọi thứ. nó rất nhanh, ánh sáng trên các nguồn tài nguyên và có khả năng mở rộng cực lớn (hãy nghĩ rằng lighthttp với mã sạch hơn và stabler). tác giả mô tả nó không phải là một máy chủ web có mục đích chung; nhưng như một lối vào proxy. Các backend có thể là một máy chủ HTTP (thường là Apache) hoặc các quy trình FastCGI (PHP, Python, Perl, bất kỳ thứ gì), hoặc một trang trại của một trong hai hoặc cả hai.

mô-đun memcached là tuyệt vời, nó sử dụng memcached (đó là nhanh nhất và có khả năng mở rộng đa năng phân phối xung quanh) để liên kết trực tiếp một trang web với một URL, không có quyền truy cập đĩa. kể từ khi memcached có thể truy cập từ 'bên ngoài' chính máy chủ web, nó có thể được sử dụng ngay cả với các trang động (được cung cấp một bản đồ URL/tài nguyên lành mạnh); nhưng tôi không nghĩ rằng nó sẽ giúp ích rất nhiều trong trường hợp của bạn. trong mọi trường hợp, đầu tiên làm cho nó hoạt động với SSI, sau đó bạn có thể (nếu cần thiết) tối ưu hóa phần năng động với memcached.

+0

Bạn có thể mở rộng câu trả lời này không? Nó không có vẻ như nó mang lại cho tôi nhiều những gì tôi muốn, nhưng có thể tôi đang thiếu một cái gì đó. – MrKurt

+0

Ah, điều đó hữu ích hơn một chút. Nó sẽ không thực sự giúp tôi có điều kiện bao gồm những thứ, mặc dù, mà làm cho nó ít hữu ích cho các loại kịch bản tôi quan tâm. – MrKurt

+0

hãy nhớ rằng 'những thứ' mà SSI có thể chèn vào toàn bộ trang có thể được tạo động bởi bất kỳ máy chủ phụ trợ. – Javier

1

Tôi biết một vài người đã viết về cách sử dụng nginx SSI với mô-đun memcache nginx để ghép các mảnh nội dung với nhau. Nó còn hạn chế hơn nhiều so với ESI, nhưng vẫn hữu ích.

2

Vì vậy, nó chỉ ra rằng Varnish có (và đã có) hỗ trợ ESI cơ bản mà gần như tất cả mọi thứ tôi muốn nó. Nếu bất cứ ai cần phải làm một số công cụ ESI, Varnish dường như làm việc khá tốt cho nó. Nó khá cơ bản, nhưng vẫn tuyệt vời.

1

Akamai có giải pháp cho Edge Computing cho phép chạy J2EE ở Edge. Các lựa chọn thay thế khác ngày nay bao gồm bất kỳ dịch vụ Điện toán đám mây nào - Rackspace và Amazon là một vài người chơi trên thị trường này. Lý tưởng nhất là bạn sẽ sử dụng kết hợp CDN và Cloud Computing để có được kết quả mong muốn. Ngoài ra, bạn có thể chọn để có nội dung động được phân phối không đồng bộ thông qua dịch vụ web sau khi tải mẫu trang và sau đó chỉ cần lưu nội dung trang tĩnh bằng mẫu html.

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