GH GambleHub

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

پروتکل اول چیست ؟

پروتکل اول رویکردی است که در آن یک قرارداد تعامل بین اجزاء (خدمات، مشتریان، شرکای خارجی) قبل از پیاده سازی طراحی و ثابت می شود. کد، ذخیره سازی، زیرساخت ها و اسناد مربوط به قرارداد است و به طور خودکار از آن تولید می شود و نه برعکس.

بر خلاف کد اول، که در آن API تنها یک محصول جانبی از کد است، پروتکل اول باعث می شود پروتکل یک مصنوع اولیه: آن را صاحب مفاهیم دامنه، مدل داده ها، وضعیت، خطاها، معناشناسی idempotency، SLO/SLI، و حتی سیاست نسخه.

چرا به آن نیاز دارید ؟

سازگاری و قابل پیش بینی بودن رابط ها در سراسر سازمان.
نصب سریع (SDK/stable/client autogeneration، خطاها و کدهای یکنواخت).
تکامل قابل اعتماد (سازگاری طرح ها، قراردادهای تست، سیاست نسخه روشن).
تمرکز محصول: بحث در مورد رفتار، SLA و ادغام UX قبل از نوشتن کد.
اتوماسیون: CI/CD مصنوعات (مشتریان، خرده سرور، اعتبار سنج) را از یک منبع واحد حقیقت جمع آوری می کند.
امنیت و انطباق: حقوق، پوشش PII، سیاست های نگهداری در قرارداد ذکر شده است.

رویکرد اصلی

1. تنها منبع حقیقت (SSOT) - مشخصات ماشین قابل خواندن:

REST: OpenAPI/JSON Schema.
رویدادها و جریان: AsyncAPI، Avro/JSON Schema.
RPC: Protobuf (gRPC)، Thrift، Smithy.
GraphQL: دستورات/سیاست های SDL +.
2. ترتیبات قبل از اجرای: واژه نامه دامنه، کدهای خطا، معانی idemotency، مهلت، retrays، deduplication.
3. Autogeneration: مشتری/سرور خرد، انواع، SDK ها، قراردادهای تست، moks، مجموعه Postman، Terraform/OpenAPI Gateway config.
4. حکومت: linters/سیاست (نامگذاری, صفحه بندی, فیلتر, خطاها), بررسی از طریق انجمن API, تغییر مشاوره برای نسخه های اصلی.
5. سازگاری: تایید دقیق از «افزودنی فقط» منتشر, نسخه معنایی, canary/آزمون مصرف کننده محور.
6. قابلیت مشاهده در سطح قرارداد: شناسه های همبستگی، مدل های خطا، بودجه های تاخیر در پروتکل بیان شده است.

روند به نظر می رسد (اسکلت)

1. شروع: مختصر محصول → سفرهای کاربر → API/پروتکل PRD (منابع/روش ها/رویدادها، SLA/SLO، خطاها، محدودیت ها).
2. مدل سازی: مشخصات پیش نویس (OpenAPI/AsyncAPI/Proto) + طرح داده ها، فرهنگ لغت اصطلاحات.
3. قراردادها و یکپارچگی UX: نمونه های بارگیری، قراردادهای خطا، نقشه های وضعیت، قوانین نسخه بندی.
4. بررسی و حاکمیت: خطوط/استانداردها، بحث در مورد متغیرهای دامنه، قفل در MGC (حداقل قرارداد گارانتی).
5. تولید خودکار مصنوعات: SDK ها، stabs، رفع تست، خرده های زیرساختی (دروازه ها، دامنه های IAM).
6. پیاده سازی و تست قرارداد: تامین کننده و مصرف کنندگان تحت بررسی سازگاری در CI قرار می گیرند.
7. قابلیت مشاهده و SLO: ردیابی همبستگی-شناسه، کاتالوگ خطا، بودجه بازپرداخت/اتمام وقت.
8. انتشار و تکامل: اولین افزودنی، سیاست رد، قناری، پرچم قابلیت A/B.

پروتکل های تعامل و سبک

استراحت/HTTP

استانداردها: مدل منبع، 'GET/POST/PATCH/DELETE'، صفحه بندی (مکان نما)، فیلترها، مرتب سازی.
زمینه ها و طرح ها: طرح JSON، فرمت ('تاریخ-زمان'، 'uuid')، ناوردا (regex/enum/min-max).
خطاها: فرمت واحد («نوع»، «کد»، «عنوان»، «جزئیات»، «ردیابی _ id»)، نقشه برداری به پشته HTTP.
کنترل تغییر: ETag/If-Match، کلید های idempotent برای POST، معانی صریح 409/422.

gRPC/RPC

Protobuf: شماره گذاری برچسب پایدار، «اختیاری»، عدم استفاده مجدد از فیلدهای حذف شده.
مهلت ها و اولویت ها در قرارداد ؛ وضعیت پایدار (OK، INVALID_ARGUMENT، FAILED_PRECONDITION، و غیره).
جریان: مشخصات سفارش پیام، فشار پشتی، تریلر نهایی.

رویداد محور (Kafka/NATS/SNS/SQS)

AsyncAPI: تم ها/کانال ها، کلید های پارتیشن بندی، کنوانسیون های کلیدی deduplication، retentions، دقیقا یک بار معنایی "در مقابل" حداقل یک بار "

رویداد اصلی و غنی سازی: حداقل بار و پسوند جداگانه ؛ version 'event _ type '/' schema _ version'.
Idempotency: 'event _ id'، 'producer _ id'، سیاست در retrays و deduplication.

GraphQL

SDL به عنوان یک قرارداد، دستورالعمل برای استهلاک، محدودیت در عمق و پیچیدگی، کد خطا/پسوند قرارداد.

ادغام با اصول معماری

هرم معکوس/مسیر بحرانی اول: در مشخصات، برجسته MGC (حداقل اجباری)، پسوند - از طریق ؟ شامل = "/توانایی ها.
جاده های هموار: مجموعه ای از قالب های مشخصات آماده (پرداخت، KYC، حسابرسی، جستجو، فایل ها) + خطوط.
API Gateways & Service Mesh: سیاست های مبتنی بر قرارداد (محدودیت نرخ، محدوده auth، تکرار، قطع کننده مدار).

نسخه و تکامل

نسخهبندی معنایی:
  • جزئی = فیلدها/کانال های افزودنی تنها.
  • عمده = تغییرات شکستن (حذف، تغییر نام، تغییر معانی).
  • سیاست رد: پنجره های پشتیبانی، هدر های «غروب آفتاب»، رویدادهای اطلاع رسانی.
  • قراردادهای مبتنی بر مصرف کننده (CDC): تأیید اینکه API فعلی مصرف کنندگان خاص را برآورده می کند.
  • دایرکتوری طرح: رجیستری طرح/Artifact رجیستری با تاریخ و قوانین سازگاری (BACKWARD/FORWARD/FULL).

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

احراز هویت/مجوز به عنوان بخشی از قرارداد (حوزه های OAuth2/OIDC، mTLS، ادعاهای JWT).
PII/PCI: پوشش، فرمت های نشانه گذاری، زمینه های با حالت های ذخیره سازی ویژه/TTL.
سیاست های حسابرسی: ویژگی های مورد نیاز («بازیگر»، «موضوع»، «عمل»، «رخ داده است _ در»، «ردیابی _ id»).
محدودیت ها: هدر محدودیت نرخ، سهمیه، اندازه پیام، مهلت.

قابلیت مشاهده قرارداد

همبستگی/درخواست-ID: مورد نیاز در مشخصات.
کاتالوگ خطا - لیست ثابت از کدها و SLA ها برای حل و فصل.
SLI/SLO: تاخیر p50/p95، نسبت پاسخ های موفق، نسبت رویدادهای سازگار، نسبت تکرارهای idempotent.

تست و کیفیت

تست های قرارداد (ارائه دهنده ↔ مصرف کننده)، schema diff در CI، نسل سرورهای ساختگی.
نمونه های طلایی: نمونه های مرجع درخواست/پاسخ، وسایل برای e2e.
هرج و مرج/تزریق تاخیر: چک کردن زمان/بازپرداخت، تخریب پسوند هنگام صرفه جویی در MGC.

نمونه قالب های دامنه

پرداخت (REST + رویدادها)

'POST/payments' → '201 Created' with 'payment _ id', 'status = authorized'.
پرداخت مراسم. مجاز است. v1 '(ядро):' {payment_id، مقدار، ارز، روش، occurred_at} '.
پرداخت تمدیدی غنی شده v1 ': میزان خطر، جغرافیایی، اثر انگشت دستگاه.
خطاها: «422» (اعتبار سنجی)، «402» (پرداخت مورد نیاز)، «409» (تکراری).
SLA: مجوز ≤ 800ms p95 ؛ رویداد هسته ≤ 2c تاخیر p95.

KYC (gRPC + صف)

RPC 'StartVerification (user_id)' → 'operation _ id'.
رویدادهای پیشرفت در موضوع "kyc. وضعیت. v1 '(' در انتظار '→' تایید/رد ').
این قرارداد زمینه های PII، عمر مفید، پوشش، کدهای شکست علت را تعیین می کند.

حسابرسی (فقط رویداد)

بله، بله. ضبط شده v1 '(ядро):' actor ',' subject ',' action ',' رخ داد _ at ',' trace _ id '.
غنی سازی: IP، دستگاه، جغرافیایی - یک رویداد/موضوع جداگانه، هسته را مسدود نمی کند.

ابزار و اتوماسیون (پشته تقریبی)

Спеки: OpenAPI/AsyncAPI/Protobuf/Avro/GraphQL SDL.
Линтеры: طیف، OpenAPI Diff، Buf (protobuf)، بررسی سازگاری SR Confluent.
Генерация: OpenAPI Generator, Buf/I, GraphQL Codegen, AsyncAPI Generator.
دروازه: Kong/Apigee/Azure/GCP GW، نماینده.
Тесты: Pact/CDC، Dredd، Schemathesis، Hoverfly، MockServer.
Register: فهرست راهنمای برنامهها + Schema Registry/Artifact Registry.
مستندات: Redocly/Stoplight/Swagger-UI/GraphiQL/Explorer.

ضد الگوهای

کد اول به طور تصادفی: «MVP اول در کنترل»، مشخصات پس از واقعی، اختلاف بین اسناد و رفتار.
Swagger-wash: یک OpenAPI رسمی بدون قوانین واقعی (خطاها، محدودیت ها، SLA ها، نسخه ها).

شکستن سازگاری: حذف فیلد/تغییر نوع بدون نسخه اصلی ؛ استفاده مجدد از تگ های protobuf

پاسخ «ضخیم» بدون صفحه بندی/فیلتر ؛ عدم توانمندی.
امنیت خارج از قرارداد: auth/scopes در ویکی شرح داده شده است، اما نه در مشخصات.

ارتباط با فرآیند سازمان

API Guild: استانداردهای متولی، تغییر بررسی، آموزش.
اسناد طراحی: برای هر API - PRD، ADR (راه حل ها)، SLA، ماتریس ریسک.
مدیریت تغییر: فرآیند RFC، یادداشت های انتشار، راهنماهای مهاجرت، انحراف جدول زمانی.
جاده آسفالت و قالب: ژنراتور چارچوب خدمات از مشخصات (اسکلت گرداننده، اعتبار سنجی، ورود به سیستم).

چک لیست

قبل از شروع

  • یک PRD و یک واژه نامه دامنه وجود دارد.
  • سبک انتخاب شده (REST/gRPC/Event/GraphQL) و فرمت طرح.
  • MGC ها، خطاها، SLA/SLO ها، قوانین idempotency تعریف شده است.

در حال توسعه

  • مشخصات عبور linters و بررسی.
  • SDK/پایدار/ثابت تولید خودکار پیکربندی شده است.
  • تست قرارداد (CDC) در CI شامل; schema-diff تغییرات ناسازگار را مسدود می کند.

قبل از انتشار

  • مستندات یکپارچه با مثال ها و کدهای خطا.
  • قرارداد قابل مشاهده: همبستگی ID، کاتالوگ خطا، داشبورد SLI.
  • سیاست نسخه و کاهش ارزش اعلام شده است.

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

پروتکل اول چه تفاوتی با API اول دارد ؟

اغلب اصطلاحات به جای یکدیگر استفاده می شوند. در این مقاله تحت پروتکل اول، ما بر دقت قرارداد و پوشش تمام سبک ها (REST/RPC/Events/GraphQL)، از جمله SLA، ایمنی و قابلیت مشاهده تاکید می کنیم.

آیا این پیشرفت را کند می کند ؟

شروع ممکن است کمی طولانی تر باشد، اما پس از آن ما در ادغام، ثبات و سرعت توسعه موازی (تولید خودکار، SDK های پایدار) برنده می شویم.

با آزمایشهای سریع چه کنیم ؟

از نسخه های «پیش نویس» طرح ها (پیش نویس)، پرچم های ویژگی و sandboxes استفاده کنید، اما از خطوط و قوانین سازگاری اساسی استفاده نکنید.

مجموع

طراحی پروتکل اول باعث می شود که قرارداد مرکز معماری باشد: ما رفتار را هماهنگ می کنیم، طرح ها را ثابت می کنیم، تولید و آزمایش های خودکار را انجام می دهیم، به صورت افزایشی تکامل می یابیم. در نتیجه، ما یکپارچگی قابل پیش بینی، سرعت بالای توسعه و مقاومت سیستم ها در برابر تغییرات در مقیاس و فرمان را دریافت می کنیم.

Contact

با ما در تماس باشید

برای هرگونه سؤال یا نیاز به پشتیبانی با ما ارتباط بگیرید.ما همیشه آماده کمک هستیم!

Telegram
@Gamble_GC
شروع یکپارچه‌سازی

ایمیل — اجباری است. تلگرام یا واتساپ — اختیاری.

نام شما اختیاری
ایمیل اختیاری
موضوع اختیاری
پیام اختیاری
Telegram اختیاری
@
اگر تلگرام را وارد کنید — علاوه بر ایمیل، در تلگرام هم پاسخ می‌دهیم.
WhatsApp اختیاری
فرمت: کد کشور و شماره (برای مثال، +98XXXXXXXXXX).

با فشردن این دکمه، با پردازش داده‌های خود موافقت می‌کنید.