ما در آیتی هلو از شهریور ۱۴۰۲ کارمون رو با عشق به کتاب و یادگیری شروع کردیم. تخصص ما چاپ کتابهای تخصصی به زبان اصلیه و با استفاده از تکنولوژیهای روز و مواد اولیه باکیفیت، مطمئن میشیم که هر کتاب از نظر ظاهر و محتوا در بهترین سطح قرار بگیره.
هدفمون اینه که دسترسی به منابع علمی و آموزشی معتبر رو برای همه سادهتر کنیم و در این مسیر، همراه و همکار خوبی برای شما باشیم.
A Practical Guide to Large-Scale System Design: From Monolith to Al-Native, Beyond Scaling Servers
بیشتر کتابهای مربوط به مقیاس پذیری نرم افزار شبیه کتابهای مرجع نوشته شدهاند؛ یک فصل درباره کش، یک فصل درباره پایگاه داده، یک فصل درباره پایش و هر فصل به صورت مستقل یک موضوع را بررسی میکند. اما در دنیای واقعی، مهندسی مقیاس پذیری این شکلی نیست.
در یک پروژه واقعی، شما معمولاً یک سامانه موجود را تحویل میگیرید. سامانه در ابتدا به خوبی کار میکند، سپس تعداد کاربران و درخواستها افزایش پیدا میکند، بخشی از سیستم تحت فشار قرار میگیرد، خطاها بیشتر میشوند و تیم باید در شرایط واقعی و تحت فشار تصمیم معماری بگیرد.
یک راه حل انتخاب میشود، با برخی هزینهها و مصالحهها کنار میآیید، تغییر را با کمترین ریسک منتشر میکنید و کسب و کار همچنان باید به کار خود ادامه دهد. اما همین تغییر ممکن است مشکل جدیدی ایجاد کند و دوباره باید تصمیم بعدی را بگیرید.
این کتاب مقیاس پذیری را دقیقاً به همین شکل آموزش میدهد: به عنوان یک مسیر تکاملی و پیوسته، نه مجموعهای از فناوریهای جدا از هم.
در طول کتاب، یک سامانه فرضی به نام ShopFlow همراه خواننده رشد میکند؛ سامانهای که از یک برنامه تک سروره با حدود صد سفارش در روز آغاز میشود و در نهایت به یک سکوی جهانی، توزیع شده، امن، تاب آور، تحت حاکمیت و مجهز به قابلیتهای هوش مصنوعی تبدیل میشود.
یکی از ایدههای محوری کتاب این است که مقیاس پذیری بیشتر از آنکه مسئله اضافه کردن باشد، مسئله حذف کردن است.
واکنش طبیعی در زمان افزایش بار این است که موارد بیشتری اضافه کنیم:
سرورهای بیشتر
سرویسهای بیشتر
کشهای بیشتر
نیروی انسانی بیشتر
ابزارهای بیشتر
اما رسیدن به مقیاس بعدی همیشه با اضافه کردن منابع بیشتر اتفاق نمیافتد.
گاهی باید:
وابستگیها را حذف کرد.
نقاط شکست منفرد را حذف کرد.
وابستگی به یک انسان خاص را حذف کرد.
گلوگاههای معماری را حذف کرد.
پیچیدگیهای غیرضروری را حذف کرد.
در یک سامانه مقیاس پذیر، نباید یک نفر قهرمان عملیات باشد؛ چون قهرمان در واقع یک نقطه شکست منفرد با ضربان قلب است.
تمام کتاب حول یک سامانه واحد پیش میرود.
ShopFlow ابتدا یک مونولیت ساده روی یک سرور است که روزانه حدود صد سفارش را مدیریت میکند.
در این مرحله، معماری پیچیده ضرورت ندارد.
مهندس اصلی سیستم، شخصیتی به نام Dave، برای زنده نگه داشتن سیستم حتی ممکن است ساعت سه صبح سرور را دوباره راه اندازی کند.
اما با رشد سامانه، چنین رویکردی دیگر قابل قبول نیست.
کتاب نشان میدهد چگونه معماری به تدریج تغییر میکند تا نیاز به این قهرمانیهای انسانی کاهش پیدا کند.
سامانه از یک مونولیت ساده به سمت:
معماری توزیع شده
سرویسهای مستقل
کلمات کلیدی:پردازش رویدادمحور
زیرساخت مقاوم
استقرار جهانی
حاکمیت خودکار
قابلیتهای هوش مصنوعی
حرکت میکند.
در ابتدای کتاب، نقشه تکامل سامانه ShopFlow ارائه میشود که چهار مرحله اصلی رشد سیستم را نشان میدهد؛ از مونولیت تا سامانه خودگردان.
این نقشه مانند یک چارچوب ذهنی در سراسر کتاب مورد استفاده قرار میگیرد.
خواننده قرار نیست صرفاً مجموعهای از قابلیتها را جمع آوری کند.
هدف، یادگیری نحوه هدایت تکامل یک سامانه است.
هر فصل کتاب با یک تصویر واقعی از وضعیت سامانه شروع میشود.
شاخصهایی مانند:
تأخیر
دسترس پذیری
هزینه
نرخ خطا
در ابتدا وضعیت مطلوبی ندارند.
وظیفه فصل این است که این شاخصها را به وضعیت مناسب برساند.
اما نکته مهم اینجاست که حل یک مشکل معمولاً مشکل بعدی را آشکار میکند.
بنابراین فرایند مقیاس پذیری پایان مشخصی ندارد.
وقتی یک گلوگاه را حذف میکنید، معمولاً گلوگاه بعدی خودش را نشان میدهد.
سه موضوع در تمام فصلها حضور دارند و به فصلهای پایانی موکول نشدهاند.
هر تغییر معماری باید بتواند با ریسک کنترل شده منتشر شود.
برای این منظور کتاب از مفاهیمی مانند:
پرچمهای قابلیت
انتشار قناری
بازگشت خودکار
استفاده میکند.
هدف این است که تغییر معماری به جای تبدیل شدن به یک رویداد پرخطر، به بخشی عادی از فرایند توسعه تبدیل شود.
کتاب با رویکردی واقع گرایانه به هوش مصنوعی نگاه میکند.
هوش مصنوعی نباید فقط به این دلیل وارد معماری شود که مد روز است.
در هر مورد باید بررسی شود که آیا هوش مصنوعی واقعاً ارزش هزینه، پیچیدگی و ریسک اضافه شده را دارد یا خیر.
امنیت و الزامات انطباق نباید بعد از وقوع اولین مشکل به سیستم اضافه شوند.
کتاب این موضوعات را از نخستین تصمیمهای معماری وارد فرایند میکند.
در نتیجه، امنیت بخشی از معماری است، نه یک وصله روی سیستم موجود.
اولین فصل کتاب دیدگاه خواننده نسبت به مقیاس پذیری را تغییر میدهد.
قرار نیست هر محصولی از روز اول با معماری پیچیده و توزیع شده ساخته شود.
در مراحل ابتدایی، سرعت رسیدن محصول به بازار ممکن است از مقیاس پذیری مهمتر باشد.
به همین دلیل، اولین تصمیم ShopFlow عمداً بسیار ساده است:
یک سرور بزرگتر بخرید.
این تصمیم شاید در نگاه اول با اصول مقیاس پذیری مدرن در تضاد باشد، اما کتاب توضیح میدهد چرا در مرحله اول میتواند تصمیم درستی باشد.
هدف این است که خواننده یاد بگیرد چه زمانی نباید زودتر از موعد مقیاس پذیری را وارد معماری کند.
در فصل دوم، ShopFlow از یک ماشین تحت فشار به مجموعهای از منابع توزیع شده تبدیل میشود.
موضوعات مهم این فصل شامل موارد زیر است:
تجزیه تدریجی
بدون حالت بودن سرویسها
انتقال افقی
بی طرفی نسبت به بستر
مشاهده پذیری
کتاب از بازنویسی کامل و ناگهانی سیستم اجتناب میکند و به جای آن تجزیه مرحلهای را پیشنهاد میدهد.
این رویکرد احتمال شکست پروژه را کاهش میدهد و اجازه میدهد سیستم همچنان در حال سرویس دهی باشد.
وقتی تعداد سرورها و اجزای سیستم افزایش پیدا میکند، تعداد نقاط ورود احتمالی نیز بیشتر میشود.
هر گره جدید میتواند یک در جدید برای حمله باشد.
در این مرحله، معماری از مدل اعتماد پیش فرض فاصله میگیرد و به سمت اعتماد صفر حرکت میکند.
موضوعات این فصل شامل:
اعتماد صفر
انتقال امنیت به مراحل ابتدایی توسعه
امنیت در خط لوله توسعه
سیاست به عنوان کد
خودکارسازی انطباق
است.
امنیتی که با رشد سیستم رشد نکند، دیر یا زود به گلوگاه تبدیل خواهد شد.
در این مرحله، بخشی از پردازش از مرکز داده به سمت کاربر منتقل میشود.
موضوعاتی مانند:
پردازش لبه
شبکههای توزیع محتوا
HTTP/3
QUIC
اعتبارسنجی و به روزرسانی کش در نقاط مختلف جهان
محافظت از مبدأ
پیش واکشی پیش بینی کننده
بررسی میشوند.
هدف این است که درخواست کاربر تا حد امکان از نزدیکترین نقطه پاسخ داده شود.
در این فصل، بخش رابط کاربری نیز تکامل پیدا میکند.
برنامه از یک برنامه تک صفحهای بزرگ به سمت ریزبرنامههای مستقل و قابل انتشار حرکت میکند.
موضوعات این فصل شامل:
ریزبرنامهها
مدیریت وضعیت در مقیاس بالا
رندر سمت سرور
تولید ایستا
تولید ایستا به صورت افزایشی
بودجه عملکرد
دستگاههای ضعیف
کاهش تدریجی قابلیتها هنگام فشار
است.
یک رابط کاربری مقیاس پذیر نباید با خراب شدن یک بخش، کل تجربه را از کار بیندازد.
در این مرحله، مرزهای سرویسهای سمت سرور مشخص میشوند.
کتاب از طراحی مبتنی بر دامنه برای پیدا کردن مرزهای واقعی سیستم استفاده میکند.
همچنین موارد زیر بررسی میشوند:
طراحی رابطهای برنامه نویسی
مقایسه REST و gRPC
پایگاه داده مستقل برای هر سرویس
مهاجرت تدریجی از مونولیت
الگوی Strangler Fig
یکی از اهداف اصلی این فصل جلوگیری از یک بازنویسی عظیم و پرخطر است.
مونولیت را نباید با یک ضربه از بین برد؛ باید آن را مرحله به مرحله کوچک کرد.
پس از تجزیه سیستم، مسئله جدیدی ایجاد میشود: چگونه این سرویسهای متعدد را پایدار نگه داریم؟
فصل هفتم به مواردی مانند:
کشف سرویس
مش سرویس
مدیریت تلاش مجدد
مدارشکن
جداسازی منابع
مهلت زمانی
کانتینرها
پردازش بدون سرور
سرورهای اختصاصی
میپردازد.
هدف این است که یک سرویس کند یا خراب نتواند زنجیرهای از شکستها را در کل سیستم ایجاد کند.
در معماریهای کاملاً همزمان، یک سرویس ممکن است مجبور باشد برای سرویس دیگری منتظر بماند.
با افزایش مقیاس، این وابستگی زمانی میتواند به گلوگاه تبدیل شود.
معماری رویدادمحور این ارتباط را کاهش میدهد.
کتاب مفاهیمی مانند:
پیام رسانی
کارگزارهای پیام
جریانهای داده
پردازش غیرهمزمان
جلوگیری از پردازش تکراری
همگام سازی
الگوی خروجی تراکنشی
ثبت تغییرات داده
را بررسی میکند.
یکی از اهداف مهم این بخش، جلوگیری از مشکلاتی مانند پرداخت دوباره یا اجرای چندباره یک عملیات حساس است.
پیام رسانی و معماری توزیع شده میتواند فشار خواندن دادهها را افزایش دهد.
در اینجا کش نقش مهمی پیدا میکند.
کتاب سلسله مراتب کش را از:
مرورگر
برنامه
شبکه توزیع محتوا
کش توزیع شده
پایگاه داده
بررسی میکند.
همچنین موضوع دشوار بی اعتبارسازی کش مورد توجه قرار میگیرد.
مواردی مانند گرم شدن کش، هجوم همزمان درخواستها و دادههای نامعتبر نیز بررسی میشوند.
کش کردن آسان است؛ درست باطل کردن کش دشوار است.
در این فصل نوبت به لایه داده میرسد.
کتاب تفاوتها و مصالحههای واقعی میان SQL و NoSQL را بررسی میکند.
موضوعات دیگر عبارتاند از:
افراز داده
تقسیم بندی
تکثیر
شاردینگ
نمایه گذاری
بهینه سازی پرس و جو
لایه دسترسی به داده
هدف این است که پیچیدگیهای لایه داده تا حد امکان از سرویسهای بالاتر پنهان شود.
«سرور روشن است» به معنای «کاربر موفق شده است» نیست.
این فصل به تفاوت میان پایش و مشاهده پذیری میپردازد.
موضوعات مهم شامل:
شناسه همبستگی
ردیابی توزیع شده
سیگنالهای طلایی
ارتباط شاخصهای فنی با اثر کسب و کاری
تبدیل دادههای تله متری به اقدام خودکار
هستند.
هدف نهایی مشاهده پذیری این است که تیم فقط متوجه وقوع مشکل نشود، بلکه بتواند بفهمد مشکل چرا اتفاق افتاده و چه اثری بر کاربر دارد.
در یک سیستم بزرگ، شکست یک استثنا نیست؛ بخشی از واقعیت است.
این فصل سیستم را برای شکست طراحی میکند.
موضوعات آن شامل:
دسته بندی اهمیت قابلیتها
کاهش تدریجی قابلیتها
مدارشکن
جداسازی منابع
حذف بار
مهندسی آشوب
است.
یک مثال کلیدی این است که اگر سیستم پیشنهاد محصولات خراب شد، نباید دکمه خرید نیز از کار بیفتد.
قابلیتهای حیاتی باید بتوانند حتی هنگام شکست بخشهای غیرحیاتی به کار خود ادامه دهند.
در این فصل، کتاب به یک سؤال مهم مدیریتی میرسد:
آیا برای تاب آوری واقعی هزینه میکنیم یا فقط از ترس مشکل، بیش از نیاز منابع خریداری کردهایم؟
کتاب بررسی میکند:
چه زمانی نباید بهینه سازی کرد
چگونه رقابت بر سر منابع را پیدا کنیم
اولویت بندی عملکرد
برنامه ریزی ظرفیت
پیش بینی رشد
ایجاد ظرفیت ذخیره بدون بیش از حد تأمین کردن منابع
را چگونه انجام دهیم.
در معماری ابری، هزینه نیز باید مانند عملکرد و دسترس پذیری یک شاخص مهندسی باشد.
این فصل بررسی میکند که:
هزینه واقعی هر سرویس چیست؟
چه زمانی سرویس مدیریت شده بهتر از سرویس اختصاصی است؟
نقطه سربه سر کجاست؟
هزینه چگونه به اقتصاد واحد محصول مرتبط میشود؟
هزینه استفاده از هوش مصنوعی چگونه مدیریت میشود؟
یکی از موضوعات جدید این بخش، هزینه به ازای تعداد توکنهای مصرف شده توسط هوش مصنوعی است.
این فصل سؤال مهمی مطرح میکند:
آیا این قابلیت واقعاً باید با هوش مصنوعی ساخته شود؟
هر مسئلهای نیازمند هوش مصنوعی نیست.
گاهی یک راه حل قطعی و ساده بهتر، ارزانتر و قابل اعتمادتر است.
کتاب تفاوت میان یک عامل هوشمند که فقط در یک نمایش آزمایشی خوب عمل میکند و یک سامانه هوش مصنوعی که میتواند در محیط تولید دوام بیاورد را بررسی میکند.
موضوعات این فصل شامل:
انتخاب میان هوش مصنوعی و منطق قطعی
اجرای هوش مصنوعی در مقیاس بالا
حاکمیت زمان اجرا
مدیریت عاملهای هوشمند
کنترل هزینه
کنترل ایمنی
کلید توقف اضطراری سامانه هوش مصنوعی
است.
یک سامانه هوش مصنوعی تولیدی باید همیشه یک راه امن برای متوقف شدن داشته باشد.
آخرین مشکل زمانی ایجاد میشود که سامانه آن قدر موفق و پیچیده شده که تیم از تغییر دادن آن میترسد.
در این مرحله، خود معماری باید امکان آزمایش را فراهم کند.
کتاب موضوعاتی مانند:
آزمایش مستمر
پرچمهای قابلیت
آزمایش معماری
مدیریت چرخه عمر پرچمها
حذف بدهیهای ناشی از پرچمهای قدیمی
را بررسی میکند.
هدف نهایی ساخت سیستمی نیست که هرگز تغییر نکند.
سامانه واقعاً آینده نگر سامانهای است که بتواند با اطمینان تغییر کند.
کتاب عمداً وابسته به یک ابزار یا محصول خاص نیست.
فناوریها صرفاً وسیلهای برای نمایش الگوهای معماری هستند و هدف اصلی، یادگیری تصمیم مهندسی است.
برخی فناوریها و مفاهیم مورد استفاده عبارتاند از:
Redis
Kafka
RabbitMQ
پیام رسانی ابری
Kubernetes
مش سرویس
Istio
Linkerd
OpenTelemetry
ردیابی توزیع شده
AWS
Azure
Google Cloud
کانتینرها
پردازش بدون سرور
قرار نیست خواننده یک محصول خاص را حفظ کند؛ قرار است یاد بگیرد چه زمانی و چرا باید یک راهکار را انتخاب کند.
اگر مسئول تصمیمهای معماری در یک تیم یا محصول هستید، کتاب به شما کمک میکند تصمیمهای مربوط به رشد سیستم را ساختاریافتهتر بگیرید.
کتاب روی همان مدلهای ذهنی تمرکز دارد که برای حرکت به سمت نقشهای معماری و مهندسی ارشدتر ضروری هستند.
برای افرادی که مسئول هدایت فنی یک تیم هستند، کتاب زبان مشترکی برای بحث درباره مصالحه میان سرعت توسعه، پایداری، هزینه و مقیاس پذیری ایجاد میکند.
معماران میتوانند از مسیر تکاملی ShopFlow برای درک ارتباط میان تصمیمهای مختلف معماری استفاده کنند.
کتاب برای مدیرانی که باید میان سرعت ارائه قابلیتهای جدید و پایداری سیستم تعادل برقرار کنند نیز مفید است.
اگر در توسعه نرم افزار تجربه دارید و میخواهید ذهنیت لازم برای حرکت به سمت نقشهای Staff یا Principal را ایجاد کنید، این کتاب مدلهای ذهنی مناسبی ارائه میدهد.
برای استفاده کامل از مطالب کتاب، بهتر است با موارد زیر آشنا باشید:
توسعه نرم افزار تمام پشته
خدمات ابری مدرن
پایگاه دادههای رابطهای
پایگاه دادههای غیررابطهای
معماری نرم افزار
نیازی نیست تجربه کار با سامانههای عظیم در مقیاس جهانی داشته باشید. این کتاب قرار است همین مسیر را به شما آموزش دهد.
بهتر است کتاب، دست کم در اولین مطالعه، به ترتیب فصلها خوانده شود.
دلیل این موضوع ساختار داستانی و تکاملی کتاب است.
ShopFlow در هر فصل وضعیت جدیدی پیدا میکند و فصل بعدی بر اساس تصمیمهای قبلی ساخته میشود.
در نتیجه، خواندن فصلها به ترتیب باعث میشود خواننده رابطه علت و معلولی میان تصمیمهای معماری را بهتر درک کند.
مقیاس پذیری فقط به معنای اضافه کردن سرورهای بیشتر نیست.
مقیاس پذیری واقعی یعنی بتوانیم یک سیستم را به گونهای تکامل دهیم که با افزایش کاربران، داده، بار، پیچیدگی و نیازهای کسب و کار، همچنان پایدار، سریع، امن، قابل مشاهده و از نظر هزینه منطقی باقی بماند.
این کتاب با داستان تکامل ShopFlow، این مسیر را از یک مونولیت ساده آغاز میکند و مرحله به مرحله به سمت معماری توزیع شده، سرویسهای مستقل، پیام رسانی، کش، پایگاه دادههای مقیاس پذیر، مشاهده پذیری، تاب آوری، بهینه سازی هزینه و معماری هوش مصنوعی حرکت میدهد.
یکی از ارزشمندترین ایدههای کتاب این است که معماری خوب الزاماً معماری پیچیده نیست؛ معماری خوب معماریای است که در زمان مناسب، مشکل درست را حل کند.
در مراحل ابتدایی ممکن است خرید یک سرور قدرتمندتر بهترین تصمیم باشد. بعدها شاید تجزیه سرویسها ضروری شود. سپس پیام رسانی، کش، شاردینگ، ردیابی توزیع شده یا پردازش لبهای اهمیت پیدا کنند. هیچکدام نباید صرفاً به دلیل محبوبیت یک فناوری وارد سیستم شوند.
هدف کتاب آموزش همین قضاوت مهندسی است.
برای مهندسان نرم افزار ارشد، لیدهای فنی، معماران، مدیران مهندسی و توسعه دهندگانی که میخواهند از سطح ساخت قابلیتهای منفرد به سطح هدایت تکامل یک سامانه بزرگ و مقیاس پذیر برسند، این کتاب منبعی کاربردی و مبتنی بر تصمیمهای واقعی معماری است.
نمونه چاپ کتاب موجود نیست.
نظرات کاربران (0)