معماری خوب یعنی تغییر ارزان. هدف این متن کمک به تیمهاست تا تصمیمهای معماری را کوچک، مستند و قابل بازنگری نگه دارند.
معماری چه چیزهایی را تعیین میکند؟
- شکل تغییرات: اضافه کردن فیچر بدون دست زدن به پنج ماژول دیگر.
- کیفیتهای اجرایی: تأخیر، دسترسپذیری، ظرفیت و هزینه.
- مرزهای تیمی: مالکیت ماژولها و شاخصهای سطح خدمت (SLO/SLI).
- قراردادهای فنی: طرح داده، امنیت و ممیزی.
چهار اصل کلیدی
- انسجام بالاتر از اندازه: ماژول کوچک ولی پراکنده هم دردسر است.
- وابستگی جهتدار: وابستگیها باید به سمت سیاست پایدار (دامین) بروند، نه به سمت جزئیات متغیر (فریمورک، فروشنده).
- مشاهدهپذیری پیشفرض: لاگ ساختیافته، متریک و تریس بخشی از معماریاند.
- واسطهای صریح: قراردادهای تایپی/اسکیما جای حدس و گپزدن را میگیرند.
انتخاب سبک ساختاری
- لایهای/ششضلعی: پیشفرض خوب برای بیشتر محصولات؛ تستپذیر و قابل فهم.
- مونو لیت ماژولار: یک دیپلوی با مرزهای سخت؛ مناسب مراحل اولیه.
- سرویسمحور: وقتی نیازمندیهای مقیاس یا cadence انتشار متفاوت میشود. مرزها را بر اساس باوندریکانتکست بکشید نه چارت سازمان.
- رویدادمحور: برای جداسازی جریانها و ممیزی؛ ولی مالکیت و اسکیما را برای هر استریم مشخص کنید.
جریان تصمیم (ADR سبک)
- یک ADR یکصفحهای بنویسید: زمینه، تصمیم، جایگزینها، پیامدها.
- قبل از انتخاب فناوری، SLI/SLO را تعریف کنید.
- اول دامین را مدل کنید (اسمها، قیود، ایونتها).
- برای هر use case اصلی یک sequence diagram کوتاه بکشید.
- قواعد مرزبندی را کد کنید: قانون import، مالکیت پوشهها، lint.
مالکیت داده و قراردادها
- هر داده یک نویسنده اصلی و یک قرارداد عمومی (اسکیما + قوانین تکامل) دارد.
- لاگ الحاقی برای ممیزی عالی است؛ نماهای خواندنی را از آن بسازید.
- API باید نسخهبندی و سازگاری عقبرو را تعریف کند؛ با تست قرارداد enforce کنید.
- درباره سازگاری شفاف باشید: قوی برای پول و ماشین حالت؛ در نهایت برای فید و شمارنده.
الگوهای قابلیت اطمینان
- Bulkhead: جداسازی منابع برای tenant یا فیچر پر سروصدا.
- Timeout + retry با jitter: هیچ کال خارجی بدون این دو نباشد.
- کلید idempotency برای نوشتنهای تکراری.
- Circuit breaker برای fail-fast.
- Dead-letter queue با هشدار، نه drop بیصدا.
امنیت در طراحی
- احراز هویت/مجوز را متمرکز نگه دارید؛ منطق نقش را تکرار نکنید.
- اصل حداقل دسترسی برای هر سرویس.
- طبقهبندی داده تعیین میکند چه چیزی رمزنگاری و ماسک میشود.
- پیشفرض عدماجازه برای ترافیک ورودی؛ allowlist بجای blocklist.
بازرسی ماهانه معماری
- آیا برای هر ماژول مالک و SLO تعریف شده؟
- آیا قوانین وابستگی به صورت خودکار enforce میشود؟
- آیا رخدادهای عملیاتی به فقدان قیود یا قراردادها برمیگردند؟
- آیا مهاجرتهای داده قابل بازگشتاند و در استیجینگ تمرین میشوند؟
- آیا داشبوردها به خروجیهای تجاری وصلاند، نه فقط CPU؟
چکلیست شروع یک سیستم جدید
- مدل دامین نوشته و با محصول/عملیات مرور شده.
- ADR برای انتخاب ذخیرهسازی (تراکنش، تأخیر، ظرفیت، نگهداری).
- مرزهای ماژول با ابزار enforce میشود.
- قلابهای مشاهدهپذیری و استراتژی نمونهگیری تعریف شده.
- رانبوک برای سه سناریوی شکست اصلی (DB down، cache سرد، سرویس وابسته flaky).
معماری یک گفتوگوی مداوم است. تصمیمهای کوچک و مستند باعث میشود سیستم بعد از اولین انتشار هم قابل تغییر بماند.
ادامه مطالعه