مدل هرم معکوس

«مدل هرم معکوس» در معماری چیست ؟

مدل هرم معکوس یک راه طراحی سیستم ها و پروتکل هایی است که در آن مهم ترین و کم اهمیت ترین اطلاعات/قابلیت ها برای اولین بار و تضمین شده منتقل می شود و جزئیات کمتر بحرانی به تدریج و به صورت اختیاری اضافه می شود. این اصطلاح ایده ای را از روزنامه نگاری قرض می گیرد (نکته اصلی در ابتدا است)، اما با وظایف مهندسی سازگار است: مسیر بحرانی تحت هر شرایطی کار می کند، هر چیز دیگری «لایه های غنی سازی» است.

تصویر بصری: بالا باریک در بالا «حداقل قرارداد گارانتی» (MGC) است، در زیر پسوند، بهینه سازی و ویژگی های غنی است که سیستم اعمال می شود اگر منابع/سازگاری وجود دارد.

که در آن اعمال می شود

پروتکل های شبکه و API ها: REST/gRPC/GraphQL، وب سایت ها، کارگزاران رویداد.
کانال های جریان: WebSocket، SSE، Kafka/NATS، RTC.
معماری خدمات: مسیر بحرانی در مقابل عوارض جانبی (ممیزی، تجزیه و تحلیل، گرم شدن حافظه پنهان).
مشتریان موبایل/وب: اول «اسکلت» UI و داده های کلیدی، سپس بارگذاری تنبل رسانه ها و توصیه ها.
زنجیره های پرداخت و ریسک: مجوز/رزرو - در اولویت ؛ ضد تقلب/تجزیه و تحلیل - ناهمزمان، با مهلت.
قابلیت مشاهده: همیشه وارد شوید/حداقل سطح متریک ؛ ردیابی/پروفایل - با نمونه برداری.

اصول مدل سازی

1. حداقل قرارداد گارانتی (MGC)

مجموعه ای از زمینه ها و عملیات که بدون آن اسکریپت معنی ندارد. این پایدار، سازگار با عقب است و برای اولین بار عبور می کند.

2. غنی سازی پیشرفته

زمینه های اضافی/توابع به عنوان پسوند اختیاری (قابلیت ها/پرچم های ویژگی/مذاکره) تحویل داده می شود.

3. تخریب بدون شکست

هنگامی که بیش از حد و یا تا حدی در دسترس نیست، سیستم لایه های اختیاری را از بین می برد و MGC را عملیاتی می کند.

4. اولویت بندی صریح و SLA ها

هر لایه SLO (تاخیر، در دسترس بودن)، صف ها و کلاس های خدمات (QoS) خود را دارد.

5. تکامل افزودنی مدارات

زمینه های جدید به عنوان nullable/اختیاری اضافه می شوند، مشتریان را شکستن نیست ؛ تغییرات سخت - تنها از طریق نسخه جدید.

6. قابلیت مشاهده توسط لایه

معیارها و سیاهههای مربوط با انتقاد مشخص شده اند: "هسته. "، نه. '،' دسته ای. برای دیدن آنچه که سیستم تحت بار قربانی می کند.

مقایسه با هرم لایه «کلاسیک»

معماری کلاسیک (پایین - پایه، بالا - UI) بر وابستگی ها تأکید دارد.
هرم معکوس بر اهمیت و ترتیب تحویل تاکید می کند: اول «هسته»، سپس «خوب به داشتن».

مدل طراحی پروتکل

1) استراحت/HTTP

MGC: حداقل منابع/نقطه پایانی و زمینه های مورد نیاز.

• نفی محتوا («پذیرفتن»، «ترجیح دادن»)،
• پارامتر ها ؟ شامل = '/' ؟ فیلدها = 'برای دانه بندی انتخابی،
• پیوستهای «سنگین» (URL های از قبل امضا شده) به جای درون خطی.
• تخریب: هنگام اتمام، MGC بدون مجموعه های تو در تو ؛ 206 محتوای جزئی برای اجسام بزرگ
• نسخه بندی: زمینه های افزودنی بدون تغییر قراردادهای قدیمی ؛ نسخه اصلی فقط برای شکستن تغییرات.

2) gRPC

proto: زمینه های «اختیاری» جدید با شماره برچسب امن ؛ برچسب های حذف شده را دوباره استفاده نکنید.
مهلت سرور و هر روش QoS (RPC های بحرانی بیش از اولویت).
جریان: پیام های اول - هدر/کل، و سپس جزئیات توسط تکه.

3) اتوبوس رویداد (کافکا/NATS)

Event-core: 'event _ type', 'id', 'incident _ at', minimal business fields.
غنی سازی: ما را در outbox/CDC و موضوعات فردی «غنی».
ابتدا جزئیات را جمع بندی کنید: مصرف کنندگان می توانند فرآیند کسب و کار را با هسته کامل کنند و جزئیات به صورت ناهمگام بارگیری می شوند.

الگوهایی که به خوبی با هرم معکوس سازگار هستند

مسیر بحرانی اول: جدا همزمان «اجباری» از عوارض جانبی آسنکرون.
Write-ahead/Outbox: ثبت واقعیت رویداد، بقیه تحویل پس زمینه است.
واکشی تنبل و افزایشی: صفحه بندی، نمایشگرها، 'If-Modified-Since '/ETag.
کشف قابلیت ها - سرور/مشتری به صراحت ارتباط برقرار می کند که کدام پسوند پشتیبانی می کند.
فشار پشتی و بودجه: مهلت، محدودیت CPU/IO در هر لایه ؛ لغو وظایف ثانویه تحت بار.
ذخیره سازی SLO-Scoped: ما «هسته» را به شدت، غنی سازی - کوتاه تر/نازک تر می کنیم.

الگوریتم پیاده سازی

1. نقشه برداری سناریو: سفر کاربر را بنویسید و «لحظه ارزش» را برجسته کنید.
2. MGC را تعریف کنید: حداقل زمینه ها/عملیات برای دستیابی به ارزش.
3. تقسیم به لایه ها: «هسته»، «گسترش یافته»، «تجزیه و تحلیل/دسته ای».
4. SLO/SLA و QoS را برای هر لایه تنظیم کنید.

5. تخریب طراحی: چه چیزی را در رشد N٪ شکست/p95 از بین می بریم ؟

6. تکامل طرح: سیاست نسخه، افزودنی اول.
7. قابلیت مشاهده: برچسب های لایه در متریک/سیاهههای مربوط/آهنگ، هشدار در «هسته».
8. تست: مهندسی هرج و مرج و تزریق خطا توسط لایه.
9. راه اندازی و بازخورد: بر روی پسوند در ficheflags روشن و رول بر روی قناری.

معیارها و SLO توسط لایه

هسته: تاخیر p95/p99، درصد عملیات بحرانی موفق، تحمل خطا در هنگام تخریب.
تمدید شده: درصد پاسخ های غنی شده، متوسط زمان بارگیری.
دسته/تجزیه و تحلیل: تاخیر از زمان واقعی، نسبت رویدادهای پردازش شده در هر پنجره.
معیارهای کسب و کار: تبدیل به «نقطه ارزش» در مقابل اضافه بار طبیعی است.

ضد الگوهای

«همه چیز هسته ای است»: گسترش اجباری می شود، تخریب غیر ممکن می شود.
شکستن تغییرات MGC بدون نسخه اصلی جدید.
شکنندگی پنهان: مسیر بحرانی متکی به وابستگی های خارجی «ثانویه» است (به عنوان مثال، تماس ضد تقلب همزمان).
پسوندهای ضمنی: مشتریان نمی دانند چه چیزی را می توان فعال/غیرفعال کرد.
فقدان قابلیت مشاهده: سیستم «سکوت» کاهش می یابد، و شما نمی بینید کجا.

نمونه ها

A. مشخصات کاربر (REST)

MGC: «id»، «display _ name»، «avatar _ url»، «tier».
Extensions: "مدالها []"، "social _ links []"، "recent _ activity []" توسط "؟ شامل = '.
تخریب: هنگام اتمام، MGC و پیوندها را به منابع مشترک (HATEOAS/URL ها) بدهید.

B. مجوز پرداخت

MGC: نتیجه مجوز (تایید/کاهش یافته)، «transaction _ id»، «مقدار»، «ارز».
برنامه های افزودنی: تله متری 3DS، میزان خطر، جغرافیایی، انتساب شریک - ناهمزمان با پرداخت رویداد. مجاز است ".
تنزل: اگر تجزیه و تحلیل نتواند، پرداخت می رود، و حسابرسی/نمره گرفتن.

B. نقل قول جریان

MGC: آخرین قیمت «عکس فوری».
برنامه های افزودنی: عمق شیشه، شاخص های جمع شده - جریان پس از عکس فوری.
تخریب: تحت بار، فرکانس به روز رسانی پسوند قطره، اما عکس فوری پایدار است.

نسخه و تکامل

اضافی اول: زمینه های جدید «اختیاری/nullable»، آنهایی که قدیمی باقی می ماند.
نسخه های معنایی: 'v1' برای هسته ؛ 'v1. x '- پسوندها;' v2 - هنگامی که MGC تغییر می کند.
قراردادهای کد: JSON Schema/Protobuf + اعتبار سنجی CI از پراکندگی های «غیر شکستن».

ایمنی و انطباق

MGC signed/authenticated: حداقل مجموعه فیلدها دارای یکپارچگی رمزنگاری است.
حداقل امتیاز: دسترسی به غنی سازی توسط حوزه های فردی.
PII/داده های مالی: را در پسوند، جدایی کلید و TTL.

قابلیت مشاهده و اشکال زدایی

پیشوندهای متریک: "هسته. درخواست کنید. مدت زمان، نه. پیوست کنید. load_time'، دسته تاخیر داشته باشد.
نمونه برداری: 100٪ سیاهههای مربوط به خطاهای اصلی ؛ پسوند نمونه.
ویژگی پرچم تله متری: شما می توانید ببینید که کدام پسوند برای مشتریان فعال است.

چک لیست پیاده سازی (کوتاه)

• MGC تعریف شده و مستند شده است.
• برنامه های افزودنی از طریق قابلیت ها/پرچم ها اعلام می شوند.
• پیکربندی SLO/QoS/صف توسط لایه.
• تخریب تست شده توسط آزمون هرج و مرج.
• تکامل طرح ها تنها افزودنی بدون «شکستن» است.
• معیارها/مسیرها/سیاهههای مربوط لایه بندی می شوند.
• مستندات برای مشتریان برای فعال کردن پسوند.

سوالات متداول

آیا هرم معکوس جایگزین معماری لایه ای می شود ؟

نه، اينطور نيست این یک اصل متعامد است: چگونگی ارائه و اولویت بندی عملکرد در لایه های آشنا.

چه زمانی درخواست نکنیم ؟

در بسته های آفلاین، جایی که تحویل جزئی بی معنی است (پروتکل های رمزنگاری با اتمی)، یا زمانی که همه زمینه ها به همان اندازه مهم هستند.

چه چیزی متفاوت از تخریب ظریف است ؟

هرم معکوس در ابتدا حداقل قرارداد کافی و اولویت های آن را طراحی می کند و سعی نمی کند سیستم در حال حاضر بیش از حد را «پس از واقعیت» ذخیره کند.

نتیجه گیری

مدل هرم معکوس کمک می کند تا معماری و پروتکل های تحت هر بار مفید باقی می ماند: نکته اصلی این است برای اولین بار و برای مطمئن ؛ بقیه در صورت امکان این امر دسترسی به مسیر بحرانی را افزایش می دهد، نمایش ویژگی ها را سرعت می بخشد و تکامل را بدون خرابی ساده می کند.