معماری Shell و SSO متمرکز

ایران فاوا گسترش · گروه صنعتی ایران‌خودرو

نقش
معمار فرانت‌اند
دوره
۱۴۰۲ - اکنون
نوع
سازمانی
  • React
  • TypeScript
  • Shell Architecture
  • SSO
  • Token-based Auth
  • Zustand

چند سرویس کسب‌وکار - فروش خودرو، قراردادهای دیجیتال، امضا، مدیریت حساب - باید برای کاربر مثل یک محصول واحد به نظر می‌رسیدند و برای تیم‌هایی که آن‌ها را می‌سازند محصولاتی جدا می‌ماندند. Shell لایه‌ای است که این را ممکن می‌کند: نشست، اجزای ناوبری و مسیریابی را در اختیار دارد و به هر سرویس یک توکن محدود می‌دهد، نه اطلاعات ورود.

چالش

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

وقتی چند تیم «یک» اپلیکیشن می‌سازند، نتیجه‌ی پیش‌فرض یا یک مونولیت است که هیچ‌کس بدون هماهنگی نمی‌تواند دیپلویش کند، یا مجموعه‌ای از اپلیکیشن‌های جدا که هر کدام دوباره از کاربر می‌خواهند وارد شود. وقتی مسیر کاربر وسط خرید از یک سرویس به سرویس دیگر می‌رود، هیچ‌کدام قابل قبول نیست. بخش واقعاً سخت مدیریت توکن است: هر سرویس به دسترسی احرازشده نیاز دارد، هیچ سرویسی نباید بتواند اطلاعات ورود را نشت دهد، و تازه‌سازی توکن در یک سرویس نباید کاربر را از سرویس دیگر بیرون بیندازد.

کاری که کردم

  • نشست را در Shell متمرکز کردم. سرویس‌های کسب‌وکار هرگز اطلاعات ورود را نمی‌بینند - یک توکن محدود و کوتاه‌عمر می‌گیرند و هر وقت توکن تازه لازم داشتند از Shell می‌خواهند.
  • تازه‌سازی توکن را در سطح Shell به یک عملیات تک‌پرواز تبدیل کردم، تا منقضی شدن هم‌زمان توکن در چند سرویس فقط یک درخواست تازه‌سازی بسازد، نه هجومی از درخواست‌ها.
  • به هر سرویس فضای نام route و دیپلوی مستقل خودش را دادم و Shell تشخیص می‌دهد هر URL متعلق به کدام سرویس است.
  • اجزای مشترک - هدر، ناوبری، وضعیت نشست و error boundaryها - را در Shell نگه داشتم تا سرویس‌ها نه از نظر ظاهری از هم فاصله بگیرند و نه خطاهای احراز هویت را ناهمسان مدیریت کنند.
  • قرارداد میان Shell و سرویس‌ها را صریح تعریف کردم، تا یک سرویس جدید با یک رابط مستند یکپارچه شود، نه با خواندن کد سرویس دیگر.

ویژگی‌های کلیدی

  • یک نشست واحد در همه‌ی سرویس‌های کسب‌وکار گروه.
  • دیپلوی مستقل برای هر سرویس - بدون قطار انتشار هماهنگ.
  • تازه‌سازی تک‌پرواز توکن، مشترک میان سرویس‌ها.
  • یک قرارداد یکپارچه‌سازی مستند برای اضافه کردن سرویس‌های جدید.

نتیجه

تیم‌ها با زمان‌بندی خودشان منتشر می‌کنند، در حالی که کاربر یک محصول واحد با یک بار ورود تجربه می‌کند. اضافه کردن یک سرویس کسب‌وکار جدید یکپارچه‌سازی با یک قرارداد شناخته‌شده است، نه ادغام در یک مونولیت.

پروژه‌های دیگر