Cách bạn cung cấp phản hồi nhanh cho các bảng điều khiển phức tạp mà không phát điên? Bạn ngừng hiển thị chúng trên đường dẫn yêu cầu.
Mục lục
Vấn đề: Phân tán trên mỗi yêu cầu (per-request fan-out)
Một bảng điều khiển (dashboard) là một loại trang web tốn kém một cách khó tin. Nó trông giống một URL, nhưng thực tế là một công cụ tổng hợp khoác trên mình chiếc áo hình trang.
Sắp ra mắt trong Stylo.Bot
Signal Shingle là kiến trúc bảng điều khiển sắp tới. Bảng điều khiển đã triển khai ở trên là bề mặt hiện tại. Hình dạng đa widget của nó là vấn đề mà thiết kế này giải quyết.
Người vận hành thấy một bảng điều khiển; máy chủ thấy các tổng hợp di chuyển chậm, danh sách trực tiếp và các chế độ xem có cửa sổ tốn kém.
Cách triển khai ASP.NET quen thuộc khiến mỗi widget tự lấy dữ liệu của riêng mình, bắt đầu các lệnh gọi này song song, sau đó chờ tất cả chúng trước khi hiển thị trang.
Nó trông nhanh với một người và bộ dữ liệu nhỏ: khoảng mười lệnh gọi độc lập chồng chéo, nên trang mất thời gian gần bằng widget chậm nhất của chúng chứ không phải tổng của chúng. Phép tính thay đổi khi trang trở nên phổ biến.
Trên Stylo.Bot dashboard, một lần tải trang bình thường có nghĩa là khoảng mười lệnh gọi song song qua ranh giới trang web/cổng. Chế độ xem 30 ngày có thể quét hơn một triệu hàng. Một lần tải yên tĩnh đơn lẻ đã là nhiều giánh under lưu lượng đồng thời, p95 vượt quá bảy giây vì mỗi khách truy cập đều chờ và bắt đầu khoảng mười thao tác tốn kém.
Đa luồng có ích. Phân tán trên mỗi yêu cầu mới là vấn đề. Với năm người xem đồng thời, khoảng mười lệnh gọi trở thành khoảng năm mươi lệnh gọi cạnh tranh. Với năm mươi người xem, nó trở thành khoảng năm trăm. Pool kết nối cơ sở dữ liệu chứng kiến một cơn bão đang mở rộng của các công việc tốn kém độc lập. Các yêu cầu chậm lại, giữ kết nối lâu hơn và làm chậm các yêu cầu tiếp theo hơn nữa.
Fan-out song song khiến một yêu cầu duy nhất trông nhanh hơn bằng cách nhân lên áp lực phá hủy hệ thống dưới tải.
Đây là đường cong mở rộng sai cho một bảng điều khiển. Một bảng điều khiển là bề mặt quan sát chung. Nó nên rẻ hơn khi nhiều người nhìn vào cùng một thứ, chứ không phải đắt hơn.
| Bảng điều khiển đa widget bình thường | Bảng điều khiển Signal Shingle |
|---|---|
| Mỗi yêu cầu bắt đầu phân tán dữ liệu của riêng nó | Yêu cầu đọc một phép chiếu đã sẵn sàng |
| Mỗi widget có thể cũ và thất bại độc lập | Các widget bắt nguồn từ một mô hình được đóng dấu thế hệ |
| Nhiều người xem tạo ra nhiều công việc cơ sở dữ liệu | Nhiều người xem chia sẻ các mô hình và shingle đã được làm nóng |
| Tải làm chậm chính phản hồi | Tải kéo giãn tần suất làm mới trong khi phản hồi vẫn nhanh |
Đối với Stylo.Bot, bảng điều khiển có giá trị nhất trong thời kỳ bùng nổ bot hoặc sự cố, chính xác khi đường dẫn dữ liệu bị áp lực. Do đó, kiến trúc tối ưu hóa sự ổn định trước tiên: một bản chụp nhanh, nhất quán với tuổi rõ ràng hữu ích hơn một trang lý thuyết tươi mới nhưng chậm, không hoàn chỉnh hoặc không khả dụng.
Giải pháp: Signal Shingle
Signal Shingle coi mỗi widget bảng điều khiển là một mảnh trang được hiển thị trước, tự chứa. Nhận dạng của nó là dữ liệu mà nó đại diện và cách nó được hiển thị: widget, hàng, cửa sổ, bộ lọc và tham số hiển thị. Tần suất làm mới không phải là một phần của nhận dạng đó.
Dấu vân tay của nó đơn giản là widget + tham số chuẩn hóa + thế hệ bề mặt dữ liệu. Một bản cập nhật quốc gia không nên vô hiệu hóa thẻ khách truy cập trực tiếp; một bộ lọc thay đổi không nên làm lạnh mọi widget khác. Một thế hệ mới chỉ định vị lại các shingle bị ảnh hưởng.
Các mảnh này sống trong bộ nhớ đệm LFU có giới hạn. Các đọc ấm giữ các widget được xem cư trú; các tổ hợp bộ lọc dùng một lần tự nhiên mất đi.
SignalR thông báo rằng bề mặt đã thay đổi; khách hàng yêu cầu batch widget bị ảnh hưởng; HTMX áp dụng các mảnh out-of-band được trả về với Idiomorph. Tín hiệu mang theo một gợi ý bẩn, không bao giờ là bản sao dữ liệu bảng điều khiển.
Trong mẫu này, signal có nghĩa là “cân nhắc làm mới”; shingle là kết quả có thể định địa chỉ độc lập.
Kiến trúc tách biệt hợp đồng phản hồi khỏi công việc làm mới. Phản hồi giống tĩnh: một bản chụp nhanh, nhất quán từ bộ nhớ đệm. Phía động là một quá trình riêng biệt, có ngân sách làm mới và giao các mảnh đã thay đổi. Tải có thể làm chậm làm mới mà không làm chậm phản hồi trang.
Chỉ các shingle phía hiển thị là không đủ. Nếu mỗi lần truy cập miss kích hoạt quét cơ sở dữ liệu mới, công việc tốn kém vẫn tồn tại. Signal Shingle sử dụng bộ nhớ đệm hai cấp với một điểm bàn giao có chủ đích hẹp giữa chúng.
Phép chiếu dữ liệu và bộ nhớ đệm giao hàng
Sự khác biệt nằm giữa một mô hình tổng hợp và các đơn vị giao hàng widget được hiển thị của nó. Không bộ nhớ đệm nào trở thành cơ quan chức năng cho dữ liệu phát hiện.
Phép chiếu dữ liệu: xô tăng dần
Cổng sở hữu dữ liệu. Nó giữ một phép chiếu LFU trong bộ nhớ, có giới hạn, của các xô tăng dần, có cửa sổ với thời gian giữ 30 ngày trượt: một tập làm việc, không phải cơ sở dữ liệu thứ hai.
Sử dụng các xô chi tiết cho biểu đồ sáu giờ và 24 giờ, tổng hợp theo giờ cho các cửa sổ dài. Điểm quan trọng là một cửa sổ được yêu cầu hợp nhất các xô thay vì đọc lại các sự kiện thô.
24 giờ cuối → hợp nhất 288 xô năm phút
30 ngày cuối → hợp nhất 720 xô theo giờ
không phải
30 ngày cuối → quét và tổng hợp lại hơn 1.000.000+ hàng sự kiệnCác quan sát mới cập nhật xô mới nhất. Phần lịch sử không được quét lại vì một trang đã được tải. Cổng vẫn là nhà văn duy nhất và nơi duy nhất quyết định một phát hiện có nghĩa là gì.
Bộ nhớ đệm giao hàng 1: mô hình nội dung đã được hydrate
Ở phía upstream, trang web caching các mô hình dashboard đã hydrate, được đánh key theo tổ hợp widget chuẩn hóa, cửa sổ, bộ lọc và thế hệ. Nó kết nối dữ liệu có thẩm quyền và hiển thị.
Cache một mô hình thay vì HTML đầy đủ giữ các giá trị CSRF, chrome xác thực, cờ tính năng và nonce trên shell được hiển thị theo yêu cầu, nơi chúng thuộc về.
Trên một key lạnh, trả về trạng thái làm nóng rõ ràng thay vì tính toán lại đồng thời. Chỉ trình tạo tick mới kiếm được một kết quả trang mới. Các đọc sau đó phục vụ thế hệ thành công mới nhất, ngay cả khi một thế hệ mới hơn đang được xử lý.
Bộ nhớ đệm giao hàng 2: bộ nhớ đệm hiển thị shingle
Bảng điều khiển được chia có chủ đích: cổng sở hữu dữ liệu; trang web sở hữu Razor và mối quan hệ trình duyệt. Bộ nhớ đệm giao hàng 2 cung cấp các cập nhật nhỏ tại chỗ mà không trở thành một kho dữ liệu cạnh tranh; nó chỉ giữ HTML có phiên bản bắt nguồn từ mô hình trang được hỗ trợ bởi cổng.
Khi mô hình trang tồn tại, một widget có thể được hiển thị dưới dạng một phần tử OOB và giữ trong bộ nhớ đệm LFU shingle có giới hạn với TTL an toàn. Một shingle ấm bỏ qua cả tổng hợp và hiển thị Razor; một miss đọc kết quả trang đã ấm, hiển thị chỉ widget đó, thêm hx-swap-oob="morph" và lưu kết quả theo dấu vân tay của nó.
Đầu cuối batch phân vùng các widget thành các dấu vân tay ấm và các miss, tổng hợp các miss được hỗ trợ một lần, sau đó trả về OOB HTML. Một thay đổi tóm tắt hoặc quốc gia chỉ định vị lại bề mặt đó.
Đây không phải cache trùng lặp. Bộ nhớ đệm giao hàng 1 trả lời “mô hình dashboard nhất quán là gì?” Bộ nhớ đệm giao hàng 2 trả lời “hòn đảo DOM nào trình duyệt này có thể nhận?” Cái đầu tiên làm cho tổng hợp có thể chia sẻ; cái thứ hai làm cho các cập nhật gần như miễn phí.
Ranh giới bộ nhớ đệm: tại sao đây không phải response caching
Response caching đáng được so sánh trực tiếp. Một response cache bình thường lưu một câu trả lời HTTP không rõ ràng; các widget được cache độc lập phát triển các chế độ hết hạn và thất bại độc lập. Trang có thể tải nhanh trong khi không còn mô tả một trạng thái nhất quán duy nhất. Trên một bảng điều khiển vận hành, một bộ đếm mâu thuẫn với các hàng bên dưới khiến người vận hành điều tra các bóng ma.
Các mẫu cache quen thuộc đều hữu ích. Chúng chỉ bảo vệ các ranh giới khác nhau:
| Mẫu | Nó lưu gì? | Phù hợp nhất | Tại sao nó không đủ ở đây |
|---|---|---|---|
| HTTP response cache | Một phản hồi HTTP, thường được đánh key theo URL và quy tắc request-vary | Các điểm cuối GET công khai và nội dung thân thiện CDN | Nó không biết gì về các widget nội bộ của dashboard hay liệu dữ liệu của chúng có đồng ý không. |
| ASP.NET output cache | Đầu ra máy chủ đã tạo, với chính sách vary và eviction rõ ràng | Các trang tốn kém với không gian key yêu cầu nhỏ, ổn định | Nó có thể cache trang nhanh, nhưng đó vẫn là kết quả trang không rõ ràng chứ không phải phép chiếu trực tiếp được phối hợp. |
| Donut-hole / fragment cache | Một shell được cache với các lỗ động, hoặc các mảnh được cache độc lập | Các trang có chrome ổn định và các vùng động nhỏ thực sự độc lập | Nó biến mỗi lỗ thành chu kỳ cache riêng; đó chính xác là cách một dashboard có thể trở nên không nhất quán bên trong. |
| Signal Shingle | Một mô hình trang đã hydrate, đóng dấu thế hệ cộng với các mảnh giao hàng widget có phiên bản | Một dashboard mà các phần phải cập nhật độc lập và tiếp tục mô tả một trạng thái | Ranh giới cache là phép chiếu đã tổng hợp; các shingle bắt nguồn từ nó, không phải các kho cạnh tranh. |
Các shingle cấp-2 là output cache, có chủ đích nhỏ và có hình dạng mảnh. Sự khác biệt là các mảnh không quyết định thực tế dữ liệu một cách độc lập. Mô hình nội dung được tổng hợp trước tiên, dưới một thế hệ duy nhất; mỗi shingle là một hiển thị của lát cắt mô hình đó.
Khi dữ liệu thay đổi, phép chiếu bị ảnh hưởng nhận một thế hệ mới. Trình duyệt có thể thấy tạm thời cái trước trong khi bản cập nhật đang được xử lý, nhưng tuổi đó rõ ràng và có giới hạn. Nó không bao giờ là một bộ sưu tập cache riêng biệt đưa ra các tuyên bố mâu thuẫn về “bây giờ”.
Một cơ quan chức năng, một thế hệ tổng hợp, nhiều mảnh giao hàng có thể tái sử dụng.
SSR trước, progressive enhancement sau
Signal Shingle không phải là JSON API với một dashboard phía client được vẽ lên trên. Bảng điều khiển Stylo.Bot là Razor SSR trước: các bộ đếm, biểu đồ, bảng, liên kết và điều hướng có ý nghĩa trước khi JavaScript chạy. HTMX, SignalR và Alpine sau đó nâng cao trang đó thay vì thay thế nó.
Stack trình duyệt
Razor hiển thị trang trên máy chủ. HTMX yêu cầu và hoán đổi các đảo HTML. SignalR mang các beacon thay đổi nhỏ. Alpine sở hữu trạng thái tương tác cục bộ. Idiomorph cập nhật một đảo trong khi giữ nguyên các nút DOM ổn định như trạng thái focus và hover.
Bỏ bất kỳ cái nào trong số chúng, trang SSR vẫn hữu ích; thêm cả ba, nó có được các cập nhật trực tiếp, ít thay đổi.
Tại sao đây không phải là một dashboard được hiển thị ở phía client
Lý do chính đơn giản: dashboard phải hữu ích cho mọi client mà không yêu cầu JavaScript. Một trình duyệt với script bị tắt, kết nối chậm, client hỗ trợ, công cụ tự động hóa hoặc crawler vẫn nhận được HTML, liên kết, bảng và điều khiển có ý nghĩa. JavaScript cải thiện trải nghiệm; nó không phải là vé vào cửa.
Một dashboard được hiển thị ở phía client phù hợp khi trạng thái ứng dụng cục bộ phong phú là sản phẩm. Nó sẽ khiến dashboard này phụ thuộc vào JavaScript trước khi có thể hiển thị dữ liệu. Nó cũng sẽ hoặc tái tạo logic tổng hợp trong trình duyệt hoặc khiến trình duyệt phối hợp các widget API, biến nó thành một thực thể có trạng thái khác trong tính tươi mới, thử lại, lỗi và nhất quán.
| Dashboard được hiển thị ở phía client | Bảng điều khiển Signal Shingle |
|---|---|
| Trình duyệt lấy JSON và sở hữu trạng thái hiển thị | Máy chủ tổng hợp mô hình và hiển thị HTML; trình duyệt nâng cao nó |
| Client hòa giải các phản hồi độc lập, trạng thái tải và dữ liệu cũ | Máy chủ đóng dấu một thế hệ nhất quán trước khi giao hàng |
| Nội dung hữu ích đầu tiên phụ thuộc vào JavaScript và hoàn thành API | Nội dung hữu ích đầu tiên là SSR HTML; cập nhật trực tiếp đến sau |
| Tốt nhất khi trạng thái ứng dụng cục bộ phong phú là sản phẩm | Tốt nhất khi dashboard là một phép chiếu vận hành được chia sẻ |
Thiết kế giữ cho dashboard phổ quát theo mặc định: dữ liệu cổng và tổng hợp trên máy chủ, hiển thị trang trên trang web, và trạng thái tương tác tùy chọn có tuổi thọ ngắn trong trình duyệt.
Làm mới là một công việc được lên lịch, không phải tác dụng phụ tình cờ của lưu lượng
Làm mới xảy ra ngoài yêu cầu trang. Đây là ranh giới cứng: một đọc lạnh trả về kết quả đang làm nóng, trong khi chỉ trình tạo tick mới tổng hợp. Yêu cầu trang là đọc một phép chiếu nhất quán, không bao giờ là cái cớ để bắt đầu công việc dữ liệu tốn kém.
Bộ điều phối xếp hàng các envelop được ghim và đọc gần đây, sau đó làm nóng chúng trong các wave có giới hạn với ngân sách số trang và thời gian thực. Trong một wave, nó batching các công việc tương thích; một ngân sách chi phí đo lường có thể dừng hoàn toàn các wave sau. Đây không phải Task.WhenAll khoác tên mới.
Giới hạn đa luồng là một phần của tính chính xác: vòng lặp làm mới nhận được ngân sách dung lượng đã biết, không bao giờ là tập hợp kết nối không giới hạn. Một yêu cầu hoàn toàn ấm không thực hiện bất kỳ tổng hợp hoặc hiển thị Razor nào.
Được điều phối, không phải bão. Đó là quy tắc vận hành.
Prewarming là sự phủ sóng, không phải cache ước mơ
Một cache không thể bảo vệ yêu cầu đầu tiên nếu nó chỉ làm nóng sau khi yêu cầu đó đến. Vì vậy, trình tạo có hai công việc. Các giá trị mặc định được ghim giữ các tùy chọn cửa sổ thực 6h, 24h, 7d và 30d ấm. Các envelop theo nhu cầu bao phủ các bộ lọc mọi người thực sự sử dụng, được xếp hạng theo số lượng truy cập và thời gian gần đây. Chỉ một yêu cầu thực sự mới giữ một cái hoạt động.
Prewarming phải phù hợp với bề mặt sản phẩm thực tế. Nếu giao diện cung cấp bốn cửa sổ bình thường và warmer biết một cửa sổ, ba phần tư đường dẫn nhấp chuột đầu tiên dự kiến vẫn lạnh.
LFU không chỉ là eviction: nó là tín hiệu nhu cầu
LFU ở đây nhiều hơn eviction. Truy cập là tín hiệu nhu cầu: nó quyết định những gì vẫn cư trú, công việc đến hạn nào được làm mới trước, và những gì có thể biến mất an toàn. Điều đó làm cho không gian bộ lọc không giới hạn có thể quản lý. Một bộ lọc quốc gia được xem cả ngày vẫn ấm; một bộ lọc thử một lần sẽ cũ đi. Không cần bảng “dashboard phổ biến” riêng biệt.
Ổn định dưới áp lực
Các dashboard trực tiếp truyền thống phản ứng với lưu lượng nhiều hơn bằng cách làm nhiều công việc hơn, sau đó trở nên ít hữu ích nhất tại thời điểm người vận hành cần chúng nhất. Signal Shingle đảo ngược mối quan hệ đó. Bộ điều khiển làm mới đo chi phí làm mới so với ngân sách; các chu kỳ tốn kém kéo dài khoảng thời gian hiệu quả, các chu kỳ rẻ co lại về tần suất được yêu cầu.
chi phí làm mới ≤ ngân sách → duy trì tần suất được yêu cầu
chi phí làm mới > ngân sách → kéo dài tần suất hiệu quả
chi phí ổn định → thận trọng rút ngắn lạiĐây là vòng kín trên tài nguyên được bảo vệ, không phải phỏng đoán từ RPS thô. Dưới tải, hệ thống di chuyển về phía bản chụp tĩnh thay vì tạo ra nhiều công việc cơ sở dữ liệu hơn để duy trì lời hứa về tính trực tiếp không thể thực hiện. Do đó, Stylo.Bot trở nên bình tĩnh hơn khi sự cố ồn ào hơn.
Làm cho dashboard làm ít công việc hơn, không nhiều hơn. Đó là lý do tại sao mẫu này suy giảm thay vì sụp đổ.
“Tĩnh” không phải là thất bại. Đó là phép chiếu nhất quán đã biết cuối cùng, bị giới hạn bởi chính sách tươi mới và được gắn nhãn trung thực.
Tĩnh và động theo thiết kế
Sự phân tách ở trên cung cấp cho dashboard một hợp đồng phản hồi nhanh và một quy trình làm mới có ngân sách riêng. Kiểm tra đến hạn theo lịch trình, tăng tốc SignalR tùy chọn cho các widget trực tiếp và đồng bộ hóa kết nối lại giữ cho phía động cập nhật. Phản hồi vẫn nhanh ngay cả khi bản chụp trở nên cũ hơn, và tuổi vẫn hiển thị.
Vì vậy, hệ thống có thể trượt liên tục giữa hai chế độ hữu ích:
làm mới yên tĩnh / rẻ → dashboard động, tần suất hiệu quả ngắn
làm mới bận rộn / tốn kém → bản chụp giống tĩnh, tần suất được tuyên bố dài hơnĐó là khả năng mở rộng thích ứng được xây dựng trong kiến trúc, không phải công tắc hoảng loạn được thêm vào sau khi pool thất bại.
Freshness thuộc về widget: một bất biến không thể thương lượng
Không phải widget nào cũng xứng đáng với cùng độ tươi mới. Một biểu đồ xu hướng hoặc xếp hạng endpoint có thể chậm vài phút hoặc một giờ; danh sách khách truy cập gần đây hoặc điểm số hiện tại cần tần suất chặt chẽ hơn. Tần suất sống cùng với lớp tươi mới của widget.
| Lớp | Widget điển hình | Tần suất cơ sở | Lý do |
|---|---|---|---|
| Tổng hợp | tóm tắt, xu hướng, quốc gia, endpoint | phút đến giờ | Tín hiệu thay đổi đủ chậm để sự ổn định quý giá hơn sự xáo trộn. |
| Trực tiếp | khách truy cập gần đây, phiên, tên, điểm số, mối đe dọa | khoảng một phút | Người vận hành đang tìm kiếm chuyển động hiện tại. |
Hai widget giống hệt nhau có thể yêu cầu các tần suất khác nhau. Đặt tần suất vào key cache nhân đôi dữ liệu; chấp nhận tần suất đầu tiên có thể khiến người tiêu dùng sau cũ.
Bất biến đơn giản:
Một mục cache được chia sẻ không bao giờ được phục vụ cũ hơn bất kỳ người tiêu dùng hoạt động nào của nó yêu cầu.
Theo hình thức:
tần suất hiệu quả(entry) = MIN(tần suất yêu cầu của mọi người tiêu dùng hoạt động)Tần suất là giá sàn cho mỗi người tiêu dùng, không phải một phần của chữ ký. Nếu một người tiêu dùng yêu cầu 60 giây và một người khác yêu cầu năm phút, một mục được chia sẻ làm mới mỗi 60 giây. Khi người tiêu dùng nhanh rời đi, tính lại minimum; khi không còn người tiêu dùng nào, dừng lên lịch và để LFU thu hồi nó.
Một người tiêu dùng hoạt động là một hợp đồng thuê nhu cầu ngắn hạn, có thể gia hạn được tạo bởi một yêu cầu thực sự. Các đọc liên tục gia hạn nó; hết hạn là sự ra đi. Bộ điều khiển chỉ bao gồm các hợp đồng thuê hoạt động khi nó tính toán tần suất tối thiểu.
Chrome trung thực và các quy tắc nhất quán
Một hệ thống thích ứng nên trung thực về sự thích ứng của nó. Chrome widget hiển thị tần suất hiệu quả hiện tại: “cập nhật mỗi 60s”, “cập nhật mỗi 5 phút”, “dữ liệu tính đến 10:42”.
Có vài quy tắc cần thiết để giữ phép chiếu trung thực:
- Dấu thế hệ. Mỗi mảnh/shingle ghi lại thế hệ dữ liệu mà nó được xây dựng từ đó. Dấu thế hệ beacon và phản hồi được so sánh, để bản cập nhật cũ hơn không thể ghi đè lên chế độ xem mới hơn.
- Tín hiệu được gộp lại. Bộ phát hiện bận có thể tạo ra nhiều sự kiện mỗi giây. Đường dẫn tín hiệu batching chúng thành một beacon bẩn và một quyết định làm mới thay vì firehose trình duyệt hoặc vòng lặp làm mới.
- Đồng bộ hóa lại khi kết nối lại. Một kết nối lại không được coi là bằng chứng rằng không có gì xảy ra. Một kiểm tra đến hạn đóng khoảng cách pulse bỏ lỡ một cách xác định.
- Fallback TTL có giới hạn. Một mảnh được giữ lại không được trở nên bất tử. Khi nó vượt quá giới hạn cũ theo lớp và không thể làm mới, nó trở nên lạnh/làm nóng thay vì im lặng nói dối mãi mãi.
- Không rò rỉ nội dung. Các shingle trực tiếp có thể chứa tên, vân tay hoặc điểm số. Nội dung của chúng ở trong bộ nhớ, không được ghi nhật ký, và bất kỳ chẩn đoán nào đều biên tập lại chúng theo mặc định.
Mục tiêu không phải là nhất quán tức thì. Đó là một phép chiếu mà tuổi và thế hệ bị giới hạn, có thể quan sát và không bao giờ là tình cờ.
Lợi ích và đánh đổi
Các lợi ích mang tính cấu trúc: độ trễ yêu cầu ổn định, một thế hệ trang nhất quán, công việc chung cho các chế độ xem phổ biến, và SSR hữu ích mà không cần JavaScript. Dưới áp lực, hệ thống phục vụ một phép chiếu cũ hơn trung thực thay vì biến mỗi lượt xem trang thành nhiều áp lực cơ sở dữ liệu hơn.
Chi phí là có thật. Kiến trúc này thêm bộ điều phối, key cache, theo dõi thế hệ, hợp đồng thuê nhu cầu và khả năng quan sát mà một controller bình thường không cần. Một chế độ xem bộ lọc lạnh có thể hiển thị trạng thái làm nóng trước khi trở nên trực tiếp. Người vận hành phải chọn giới hạn tươi mới chấp nhận được thay vì giả v rằng mọi bề mặt cần dữ liệu thời gian thực. Mỗi bản sao trang web cũng cần bộ nhớ đệm có giới hạn và tín hiệu làm mới riêng; nội dung cache có chủ đích cục bộ, không phải cơ quan chức năng mới được chia sẻ.
Nó không phù hợp với ứng dụng ghi nhiều, được cá nhân hóa sâu sắc nơi mỗi phản hồi là duy nhất, hoặc với bề mặt thực sự yêu cầu mỗi người dùng thấy mọi thay đổi ngay lập tức. Nó phù hợp mạnh mẽ với các bảng điều khiển vận hành được chia sẻ, đọc nhiều nơi sự quan sát nhanh, nhất quán quan trọng hơn việc giả vờ mọi con số là tức thì.
Signal Shingle tổng hợp các thành phần ASP.NET quen thuộc: LFU, SignalR, tổng hợp batching, Razor, HTMX và bộ điều phối với ngân sách đa luồng thực. Cổng vẫn có thẩm quyền; trang web phục vụ một phép chiếu; trình duyệt nhận các mảnh nhỏ có phiên bản.
Bảng điều khiển vẫn nhanh vì sự quan sát không còn gây ra tính toán.
