در ادامه مبحث میکروسرویس رسیدیم به sso و اکنون با یک پلتفرم جامع بابتش آشنا خواهیم شد


در پست قبل گفتیم تمامی سرویس‌ها و برنامه‌های ما نیاز به احراز هویت دارن و با استفاده از sso تمام صفحات ورود رو در یک صفحه جا میدیم، برای اینکار یک پلتفرم رایگان و پر استفاده وجود دارد از شرکت readhat با نام keycloak


در واقع keycloak یک ابزار رایگان شناسایی هویت و مدیریت دسترسی میباشد(IAM) identity and access management ، فرآیند احراز هویت رو برای سرویس‌های IT ساده میکند

هدف از ابزار IAM اطمینان حاصل کردن از این مورد است که مردم به منابع درستی دسترسی دارن، که معمولاً اجرای SSO, فدراسیون هویت (identity federation) و احراز هویت قوی (authentication strong) رو امکان پذیر می کند

همه شما استفاده از مدیریت هویت و دسترسی (IAM) را می دانید.کاربرد اصلی راه حل IAM این است که به عنوان یک Identity Provider (IdP) عمل می کند، به این معنی که هویت های دیجیتالی کاربر و همچنین فاکتورهای احراز هویت آنها را ایجاد، نگهداری و مدیریت می کند

اما این سوالات پیش میاد

خود keycloak چیست؟؟
ویژگی و سودمندی آن چیست؟؟
چگونه تاثیر گذاره؟؟  

ما به این سوالات پاسخ میدیم

نخست keycloak چیست؟؟
یک ابزار برای IAM هستش که مجوز Apache رو داره و توسط شرکت redhat برای sso طراحی شده است

با keycloak شما میتونید در تایم کوتاهی سرویس خودتون رو امن و احرازهویت رو به برنامه خود اضافه کنید

با استفاده از کنسول ادمین keycloak ،کمپانی‌ها میتونن با شبکه‌های اجتماعی سریعا وارد بشن، اینجا کد یا برنامه‌ای تغییر نمیکنه، تمامی این موارد نیازمند انتخاب شبکه اجتماعی میباشد، ادمین‌ها میتونن تمام جنبه‌های keycloak رو به سادگی مدیریت کنند، برای مثال فعال و غیرفعال کردن ویژگی‌های آن


ویژگی‌های keycloak
در واقع keycloak از سه نوع پروتکل oidc, oauth2, saml پشتیبانی میکند

این ابزار بصورت کامل از SSO که مخفف single-sign on و single-sign out میباشد پشتیبانی میکند

کنسول ادمین
یک رابط کاربری گرافیکی مبتنی بر وب توسط Keycloak ارائه شده است، که در آن می‌توانید تمام تنظیمات مورد نیاز خود را با «کلیک کنید» آنطور که می‌خواهید کار کند تنظیم کنید


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

میتواند نقش یک پروکسی رو بین کاربران و ارائه دهندگان هویت سنجی خارجی رو ایفا کنه
مهمترین ویژگی آن اجازه دادن به ارائه دهندگان احراز هویت خارجی می باشد و شما میتوانید موارد رو در کنسول ادمین آن کنترل کنید

مزایای keycloak

۱-سریع و منعطف:
جامعه ان نشان داده که بسیار سریع با تغییرات  دنیای مهندسی خودش رو وفق میده و در کل طراحی keycloak خودش رو برای رویکرد agile آماده و مناسب کرده

۲-نرم افزار منبع باز:
شما میتوانید به تمامی کدهای برنامه بصورت رایگان دسترسی داشته باشید و از آن استفاده نمایید

۳-پشتیبانی و ثابت شده:
جامعه عظیم و پشتیبانی بزرگی از آن حمایت میکند که سریع میتوانند به شما بازخورد دهند

۴-احراز هویت و مجوز دسترسی:
با حداقل ترین تلاش و سریع احراز هویت و افزایش امنیت را به سازمان و برنامه‌های خود میتوانید اضافه کنید

۵-مدیریت سیستم:
حساب های کاربران را به طور یکپارچه مدیریت و داده ها و همچنین جلسات را حفظ می کند

۶-ماژول و مستقل:
می توان از آن به عنوان یک عنصر زیرساخت IT یا به عنوان یک راه حل مستقل استفاده کرد

#microservice
#sso #keycloak


@code_crafters

در ادامه مباحث میکروسرویس رسیدیم به sso و پلتفرم keycloak

با محیط خود keycloak بیشتر آشنا بشیم


ابتدا با دستور زیر پلتفرم رو در داکر بالا میاریم

docker run -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin -e KEYCLOAK_LOGL_EVEL=debug quay.io/keycloak/keycloak:24.0.3 start-dev

پلتفرم رو بر روی پورت 8080 بالا میاریم و با نام کاربری و پسورد admin وارد کنسول ادمین ان میشویم (در بروزر خود نام هاست خود یا ip رو همراه با پورت وارد کرده (localhost:8080) و به صفحه لاگین وارد میشویم)

بعد ورود به کنسول در سمت چپ نوباری میبینیم که هرکدوم رو بصورت جداگانه بررسی میکنیم

در قسمت بالایی آن یک لیست کشویی میبینیم که مربوط به realm می‌باشد، realm بعنوان یک یک فضای جداگانه برای مدیریت مجموعه‌ای از کاربران و نقش‌ها و برنامه‌ها و تنظیمات امنیتی تعریف میشود، هر realm بطور جداگانه و مستقل از بقیه عمل میکند و میتواند تنظیمات امنیتی و مدیریتی مخصوص به خود را دارد با کلیک کردن بر روی create realm.و دادن یک نام یکتا به آن میتوان یک realm ساخت (ما با نام test14 یک realm میسازیم) و با رجوع به آدرس (localhost:8080/admin/test14/console) میتوان به محیط کنسول یوزر خود وارد شد و با دادن نام‌کاربری و پسورد داخل شد(چون تا کنون یوزری نساخته‌ایم نمیتوان به ان ورود کرد)


پس بریم سراغ قسمت User و با زدن add user شروع به ساخت کنیم، فرم ان کامل مشخص است فیلد username رو وارد میکنیم و create رو میزنیم و بعد ریدایرکت میشیم به داخل محیط تنظمیات این یوزر که ساختیم در قسمت credentials برای این یوزر پسورد میگذاریم و در قسمت assign role به این یوزر نقش‌هایی رو‌ میدیم و با استفاده از filter و جستجو این قسمت میتوانیم دنبال role مد نظر خود بگردیم در قسمت میتونیم دسترسی یوزر رو محدود کنیم

برای دسترسی پیدا کردن به کنسول ادمین در لینک بالا که گفتیم حتما باید رول role_admin رو از زیر مجموعه realm_management رو اضافه کنیم

بعد از اتمام با یوزرنیم و پسورد این کاربر میتوانیم به لینک بالا که مربوط به کنسول realm با نام test14 میباشد دسترسی پیدا کرد(در قسمت رولهای یوزر میتوان دسترسی یوزر رو با realm آن مرتبط و محدود کرد) در قسمت یوزر هم میتوان تمام یوزرهارو دید و هنگام اتصال به پروژه یوزرهامون رو در این قسمت ایجاد میکنیم

اکنون نیاز به یک کلاینت داریم
کلاینت به یک برنامه یا سرویس اشاره دارد که برای احراز هویت و مجوز دسترسی (authentication, authorization) به منابع محافظت شده با keycloak ارتباط برقرار میکند، کلاینت‌ها میتوانند انواع مختلفی از برنامه‌ها باشند، مانند برنامه‌های وب، موبایل و سرویس‌ها بک‌اند باشند

در قسمت client بر روی create client کلیک‌کنید یک نام یکتا به ان دهید نوع بر روی oidc بماند، تیک client authentication رو فعال کنید و گزینه service accounts roles رو اضافه کنید برای کارکرد بهتر مقدار redirects uris رو یک ستاره بزارید و کلاینت رو ذخیره کنید

وارد کلاینتی که ساختید بشی
در تنظمیات کلاینت تمامی موارد رو میبینید و در تب credentials مقدار سکرت رو میبینید و در تب service accounts roles بر روی assign role کلیک کنید و رول‌های مدنظر خودتون رو بهش اضافه کنید دو رول views , manage users دو رول حیاتی هستند که بعدا در کتابخانه‌هامون جهت کار با keycloak لازم داریم

خبر اینکه این پلتفرم اندپوینت داره و با طراحی rest api می‌باشد که داکیومنتش رو در لینک زیر میتونید بخونید(دوستانی که سابقه کاری بالایی دارند اهمیت این موضوع رو بهتر میدونن)
https://www.keycloak.org/docs-api/22.0.1/rest-api/index.html


برای تست و کار کردن با اندپوینت‌ها پنل رو بالا بیارید و موارد ذکر شده در بالا رو پیش ببرید(در قسمت رول‌ها با توجه به اینکه میخواهیم اندپوینت‌هارو تست کنیم تمامی رول‌هارو اعمال کنید)

یک پست من بالا بیارید و یک درخواست با متد post به لینک
reelms/test14/protocol/openid_connect/token
با مقادیر زیر در body ارسال کنید

client_id test14
client_secret در پنل و از کلاینتتون بردارید
grant_type client_credentials

تا توکن دسترسی بهتون برگردونه و با استفاده از این توکن در قسمت authorization که از نوع bearer token هستش به اندپوینت‌ها دسترسی پیدا میکنید


پنل رو بالا بیارید با محیط ان آشنا بشید تا بتونیم اندکی بیشتر به سمت پیاده سازی sso خودمون پیش بریم


#microservice
#sso #kecloak

@code_crafters

در ادامه مبحث sso و کار با ابزار keycloak و آشنایی با محیط آن میرسیم به این موضوع که چگونه با پایتون با این ابزار کار کنیم


یکی از بهترین کتابخانه‌های اون رو در زیر براتون میزارم

https://pypi.org/project/python-keycloak/

دلیل استفاده از این پکیج جهت کار کردن روی سطح پایینتری از کی‌کلاک جهت ترکیب ان با drf و پیاده سازی کردن اندپوینت‌هایی جهت ساخت ui مخصوص خود و جدا شدن از محیط ui خود کی‌کلاک ،در پست قبلی یاد گرفتیم که چگونه realm, client, user بسازیم که دسترسی داشته باشیم از این داده درون این پکیج هم استفاده کنید جهت کار کردن و اعتبار سنجی

اگر به ارور نوع grant برخوردید ابتدا با کنسول لاگین خود کی‌کلاک ورود کرده و مرحله تغییر پسورد رو پشت سر بگذارید، اگر میخواهید به این قسمت برنخورید هنگام ساخت یوزر زمانیکه به تب credentials میروید و برای یوزرتون پسورد ست میکنید گزینه Temporary رو غیر فعال کنید

لازم بذکر میباشد که پکیج جامع django all auth نیز از کی‌کلاک پشتیبانی میکند، دلیل استفاده من از کتابخانه بالاتر انتخاب شخصی و مناسب با درخواست شرکت می‌باشد و نیاز به کد زدن در سطح پایینتری داشتم با امکان کنترل بیشتر بر روی flow موجود در طراحی سیستم


سعی میکنم یک نمونه پروژه کوچیک بسازم و بالا بیارم تا بتونیم درک سریعی از ترکیب موارد بالا رو باهم داشته باشیم و در گیتهاب پابلیک کنم


#microservice
#sso #keycloak


@code_crafters

یکی از سیاست‌های حکمرانی soa این است که سرویس ‌های ما قابل اجرا بر روی فضاهای ابری (cloud) باشد،این یک الزام است، فضاهای ابری زیاد و متنوعی وجود دارد که شما میتوانید از آنها استفاده کنید اما این بسته به نیاز شما و سرویس‌های شما دارد

در این پست مسائلی مطرح میکنیم که با استفاده از آن تشخیص دهید کدام فضای ابری مناسب سرویس شماست

ابتدا بیایید مختصر در خصوص انواع فضای ابری صحبت کنیم:

ارایه دهنده software as a service (Saas):
هنگامی که از یک محیط SaaS استفاده می کنید،به یک برنامه یا سرویس کامل که در جایی آنلاین میزبانی شده است دسترسی خواهید داشت.  شما برنامه‌ها یا خدمات خود را در این ابر مستقر نمی‌کنید،بلکه از آنچه ارائه‌دهنده SaaS ارائه می‌کند استفاده می‌کنید.Google Docs، Salesforce و Office 365 همگی نمونه‌هایی از SaaS هستند

ارائه دهنده platform as a service (PaaS):
-اگر می خواهید برنامه های خود را مستقر کنید، ممکن است از PaaS استفاده کنید.با یک PaaS یک پلت فرم محاسباتی کامل یا پشته نرم افزاری به شما پیشنهاد می شود که می توانید از آن برای ایجاد برنامه ها و خدمات خود استفاده کنید.Google Apps، AWS آمازون،Windows Azure مایکروسافت و بسیاری دیگر این سرویس را ارائه می دهند

ارائه دهنده infrastructure as a service (IaaS):
ارائه دهنده IaaS زیرساخت های محاسباتی مانند منابع CPU، ذخیره سازی داده ها و IO شبکه را فراهم می کند.اغلب PaaS از خدمات ارائه شده توسط IaaS استفاده می کند.ارائه دهندگان IaaS زیادی وجود دارد:Cloud.com، Rackspace، Amazon، و HP به جز چند مورد

با توجه به سیاست‌های soa بهتر است بر روی PaaS تمرکز کنید و با استفاده از پارامترهای زیر و خدماتی که provider به ما می‌دهند انتخاب کنیم:

عملکرد همه ارائه دهندگان ابر عملکرد یکسانی را ارائه نمی دهند.برخی ممکن است فقط منابع محاسباتی را ارائه دهند،در حالی که برخی دیگر یک پشته نرم افزار کامل را ارائه می دهند
وقتی به یک ارائه دهنده ابر احتمالی نگاه می کنید، باید عملکرد مورد نیاز خود را تعیین کنید.آیا به یک پایگاه داده آنلاین،قابلیت ایمیل یا شاید یک سیستم پیام رسانی نیاز دارید؟ سعی کنید ارائه دهنده ای پیدا کنید که تمام این الزامات را پوشش دهد.اگر نتوانستید یکی را پیدا کنید،سعی کنید تعدادی را پیدا کنید که به خوبی با یکدیگر ادغام شوند

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

قابل حمل بودن داده ها وقتی خدمات خود را در فضای ابری اجرا می کنید،از گزینه های ذخیره سازی ارائه شده توسط ابر استفاده کنید و مطمئن شوید که این ارائه دهنده به شما اجازه می دهد تا داده های خود را به راحتی صادر کنید.اگر اینطور نیست، می توانید به سرعت در یک ارائه دهنده ابر خاص قفل شوید

مقیاس پذیری یکی از مزیت های مهم استفاده از ارائه دهنده ابر این است که وقتی برنامه شما رشد می کند،لازم نیست نگران اضافه کردن منابع اضافی باشید.هنگامی که به دنبال ارائه دهنده ابری هستید، به دنبال ارائه دهنده ای باشید که قابلیت مقیاس پذیری شفاف را ارائه می دهد.اگر منابع مورد نیاز شما افزایش یابد،ارائه‌دهنده ابر باید به طور خودکار بتواند مقیاس را افزایش دهد.اگر منابع مورد نیاز شما کاهش یابد،ارائه دهنده ابر باید مقیاس را کاهش دهد

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

خط‌مشی پشتیبان‌گیری اگر از پلتفرم ابری برای ذخیره‌سازی استفاده می‌کنید،تعیین خط‌مشی‌های پشتیبان‌گیری ارائه‌دهنده ابر مهم است.آیا آنها به طور منظم از داده ها نسخه پشتیبان تهیه می کنند،آیا پایگاه داده ها تکرار می شوند یا اینکه شما کنترل بازیابی نسخه های پشتیبان را خودتان دارید؟

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

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

#microservice
#soa

@code_crafters

در ادامه مباحث میکروسرویس و حکمرانی soa و سیاست‌های آن ما نیازمند یه چارت سازمانی هستیم تا با دیدن آن بتوان به موجودیت soa پی برد وظایف و خواستگاه هر نقش مشخص باشد

در این تصویر یک نمونه از چارت سازمانی رو میبنیم

در ادامه به تعریف هر یک از نقش‌های سازمانی و حکمرانی soa میپردازیم

#microservice
#soa

@code_crafters

بخش product development: تمام توسعه محصول در بخش توسعه محصول متمرکز است که دارای سه بخش فرعی است. هر یک از این بخش ها بر روی یک منطقه خاص تمرکز می کنند

بخش analytics: بخش تجزیه و تحلیل نحوه استفاده از خدمات و محصولات را تجزیه و تحلیل می کند.روندها را رصد می کند و به مشتریان کمک می کند تا نحوه استفاده از خدمات و محصولات ارائه شده را بهینه کنند.

بخش sales: نقش بخش فروش یافتن مشتریان جدید و بهبود تعداد نهادهای نیازمند به محضول هستند

بخش product support:بخش پشتیبانی محصول در این زمینه ها پشتیبانی می کند:پشتیبانی مشتری، پشتیبانی فنی و پشتیبانی پیاده سازی

بخش Core Services : یک بخش فرعی توسعه محصول است. این بخش بر توسعه و گسترش خدمات اصلی ارائه شده توسط محصول تمرکز دارد. این خدمات شامل ارائه آمار، بازگرداندن اطلاعات ساکنان، و ارائه اطلاعات در مورد خود نهادهای مصرف کننده محصول است

بخش domain service: توسعه محصولات و خدمات خاص را مدیریت می کند. به عنوان مثال، سیستم کاهش ترافیک، توسعه یافته و توسط این بخش نگهداری می شود

بخش Mobile Services: توسعه همه برنامه های تلفن همراه را انجام می دهد

بخش customer product: پشتیبانی مشتری به سوالات مربوط به استفاده از محصولات و خدمات رسیدگی می کند

بخش technical support: پشتیبانی فنی با مسائل اتصال، ادغام فنی و مسائل مربوط به امنیت سر و کار دارد

بخش implementation support: پشتیبانی پیاده سازی، به مشتریان محصول کمک می کند تا متصل شوند


بخش مدیران و ذینفعان و سهامداران سازمان، در نهایت ذینفعان سازمان سیاست‌های سازمانی رو تعریف میکنند اندکی راجب نگرش انها بدانیم

مدیر عامل CEO: "من می خواهم این شرکت رشد کند. ما در حال حاضر عده‌ای به عنوان مشتری داریم. من می خواهم در دو سال آینده مشتریان افزایش پیدا کند.ما باید هزینه های IT را در یک راستا نگه داریم، زیرا آنها در چند سال گذشته به طور پیوسته در حال افزایش بوده اند

مدیر فروش sales manager: «مشتریان ما گزینه های مختلف استقرار را می خواهند. برخی در حال حاضر ابر خصوصی خود را دارند و نمی خواهند در ابر ما اجرا شوند.علاوه بر این، آنها خواهان دسترسی آسان‌تر به داده‌ها هستند تا بتوانند آن‌ها را در برنامه‌های کاربردی خود بگنجانند»


مدیر توسعه development manager: «ما باید توسعه خدمات را ادغام کنیم. سرویس ها از انواع مختلفی از مدل ها استفاده می کنند. ما همچنین متوجه شده‌ایم که برخی از سرویس‌ها تقریباً عملکرد مشابهی را ارائه می‌کنند، و می‌خواهیم تعدادی از خدمات را برای حذف این تکرار اصلاح کنیم.»


مدیر پشتیبانی محصول product support manager: «ما نسخه‌های بسیار زیادی در حال تولید داریم که پشتیبانی از آن‌ها سخت است و نظارت خوبی نداریم. ما یک نسخه واحد می خواهیم که همه مشتریان از آن استفاده کنند. ما همچنین سوالات زیادی در مورد نحوه استفاده از خدمات دریافت می کنیم که باید در جایی مستند شود.

تحلیلگر اصلی lead analyst: «ما باید بتوانیم گزارش‌های سفارشی ایجاد کنیم تا به مشتریان خود کمک کنیم. می‌خواهم ببینم فرآیند درخواست مجوز چه زمانی و توسط چه کسی و چه مدت اجرا می‌شود، از کدام سرویس‌ها استفاده می‌شود.»

این نقش‌های تعریف شده در یک سازمان کوچک است که هر دپارتمان اهداف خاص خود را دنبال میکند

#microservice
#soa

@code_crafters

در ادامه مباحث میکروسرویس و حاکمیت soa میرسیم به سیاست‌های ادغام سازی


منشا موضوع از جایی هستش که سازمان ما در حال توسعه یک برنامه هستش و ما تنها سازمان موجودی نیستیم که سعی در نوشتن این پروژه رو داره یا حداقل بخش‌هایی از سیستم ما قبلا موجود هستش یا قوانین جامع و یکپارچه‌ و شناخته شده‌ای برای اون بخش وجود داره

بیایید با یک مثال اندکی بیشتر راجبش صحبت کنیم، فرض کنید که ما یک پروژه داریم که قراره از خدمات بانکی استفاده کنه یا به بانک‌ها خدمات ارائه بده، سیستم بانکی در سرتاسر کشور یکسان هستش و قوانین مشخص شده‌ای داره که کا باید از این قوانین پیروی کنیم در صورت عدم پیروی از این قوانین پروژه ما با شکست مواجه میشه، از طرفی دیگه هم پروژه ما باید توانایی ادغام با سیستم بانکی رو هم داشته باشه و مشابه کاری که ما میخوایم انجام بدیم هم توسط سازمان‌های دیگه صورت گرفته، اینجاست که یکسری سیاست‌های حاکمیتی soa به شکل زیر به میان میاد:

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

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

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


سیاست‌های استفاده مجدد از طراحی:
سازمان ما بصورت مداوم در حال توسعه برنامه و سرویس‌ها هستش، ذینفعان و مالکان پروژه نیازمندی‌های خود رو بیان میکنن و سیستم روز به روز بزرگتر میشود، تصور کنید چند سرویس وجود دارد که یک کار را انجام میدهند چه اتفاقی میافتد، رهگیری کاربران بشدت پیچیده خواهد شد و صرف هزینه زیاد میگردد(درخواست مدیر توسعه)
بیانیه: تمام خدمات با توضیحات آنها باید به صورت مرکزی ثبت شود. قبل از اینکه یک سرویس جدید ایجاد شود، این رجیستری باید بررسی شود تا ببیند آیا قبلاً سرویسی وجود دارد که این عملکرد را ارائه می دهد یا اینکه آیا این قابلیت باید به جای معرفی یک سرویس جدید به یک سرویس موجود اضافه شود.

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

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


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

#microservice
#soa

@code_crafters

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

سیاست implication: ما باید مطمئن شویم که فضاهای نام استفاده شده منعکس کننده نسخه صحیح یک سرویس یا پیام هستند. سرویس های REST نیز باید نسخه شوند. این بدان معنی است که در توصیف نوع محتوای آنها باید شماره نسخه وجود داشته باشد. چرخه عمر سرویس باید وجود داشته باشد که به مصرف کننده وضعیتی که سرویس در آن است اطلاع دهد. مخزن باید بتواند چندین نسخه از یک سرویس را پشتیبانی کند و کاربران مخزن باید بتوانند به راحتی نسخه سرویس مورد نظر خود را تشخیص دهند.

سیاست‌های امنیتی:
برخی از سرویس‌ها شامل داده‌های حساسی هستند و ممکن است قوانین جامعی برای انها منتشر شود

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

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

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


سیاست‌های ثبت تغییرات و جعل داده:
سیستم ما در حال بزرگ شدن هستش و تغییرات در ان یک مسئله مرسوم هستش، بالاخص زمانیکه واحد پشتیبانی بزرگی داشته باشیم که دسترسی نسبتا جامعی داشته باشند (یا یک کاربر بخواهد غیرمجاز رفتار کند) ما نیازمند سیستم ثبت وقایع هستیم تا در صورت لزوم متخلف شناسایی گردد(درخواست تحلیلگر اصلی)

بیانیه: ما باید مطمئن باشیم که همه پیام‌هایی که اطلاعاتی را در سیستم‌های ما ایجاد یا به‌روزرسانی می‌کنند، می‌توانند از نظر یکپارچگی و عدم انکار پیام بررسی شوند.

منطق بیانیه: اگر مشتریان بتوانند داده های جعلی ارسال کنند، محاسبات نادرست خواهد بود و سازمان ضرر خواهد کرد.

پیامدهای بیانیه: ما باید راهی را تعریف کنیم که پیام ما می تواند امضا شود.این باید به ما امکان دهد تشخیص دهیم که آیا پیام دستکاری شده است یا خیر. مشتریان ما باید به هر پیامی که می فرستند یک امضا اضافه کنند. باید سرویس‌های خود را تغییر دهیم تا هر پیام قبل از پردازش تأیید شود.

بیانیه(دوم): همه برنامه ها و سرویس ها از یک سیستم مرکزی استفاده می کنند که نقش ها و حقوق کاربران سیستم ها و برنامه های ما را تعیین می کند.

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

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


سیاست‌های تست و افزایش کارایی:
مشتریان سازمان ما متفاوت هستند، گاها یک مستری نسبت به خدمات ما تقاضای شخصی خود را نیز دارد، که منجر به نوشتن یک قرارداد سطح خدمات (SLA) میشود مشتری از ما اطمینان پاسخ دهی سریع سرویس را میخواهد(درخواست مدیر فروش)

بیانیه: میانگین زمان پردازش پیام ها باید کمتر از 10 میلی ثانیه باشد

پیامدهای منطقی: برای اینکه بتواند با بار فزاینده کنار بیاید، سرویسی که با داده های سروکار دارد باید بتواند پیام ها را در عرض 10 میلی ثانیه پردازش کند.

پیامدهای بیانیه: برای مشاهده میانگین زمان پردازش باید محیط را زیر نظر داشته باشیم. ما باید تست های استرس را اجرا کنیم تا ببینیم سیستم تحت افزایش بار چگونه عمل می کند.


#microservice
#soa

@code_crafters

سیاست‌های نظارت بر عملکرد:
واحد پشتیبانی باید در لحظه بتواند سرویس را نظارت کند و قبل از وقوع اتفاق این امکان نظارت را داشته باشد، معمولا واحد پشتیبانی بعد از رخ داد برای سرویس متوجه ان میشود(درخواست مدیر پشتیبانی)

بیانیه: همه خدمات باید در زمان واقعی نظارت شوند.

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

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


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

بیانیه: خدمات باید یک نمای قابل تنظیم از رویدادهای خاص ارائه دهد.

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

پیامدهای بیانیه: داشبوردهایی را تنظیم کنید که عملکرد خاص خدمات ما را نظارت کنند. اجازه پردازش پیچیده رویدادها را برای ایجاد نمای مورد نیاز تحلیلگران تجاری.


سیاست مقیاس کردن پروژه:
در طی سالیان انتظار رشد زیاد پروژه رو دارند ازین بابت نیازمند رویکردی کم هزینه هستیم (درخواست مدیر عامل و مدیر فروش)

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

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

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


سیاست بررسی و نظارت بر توسعه سیستم:
هر سیستم بخش‌هایی از آن به دلایلی ممکن است دچار خطا شوند این زمانی معضل میشه که تعداد آنها بسیار بالا باشد و بخش پشتیبانی رو با حجم زیادی از درخواست روبرو کند، از این رو نظارت بر توسعه سیستم بوجود میاد(درخواست مدیر توسعه)

بیانیه: همه خدمات ما باید قبل از ارسال آزمایش شوند. این سرویس ها باید روی تمام لایه های مختلف تست شوند. علاوه بر این تست ها، باید از بررسی خودکار برای تعیین کیفیت کد و پوشش تست برای یک سرویس خاص استفاده شود.

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

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


#microservice
#soa

@code_crafters

در ادامه مباحث در خصوص میکروسرویس و حاکمیت soa و سیاست‌های آن میرسیم به سیاست‌های مستند سازی


سیستم ما مدام در حال ارائه خدمات به مشتریان است و در کنار این روند در حال بهبود خود و توسعه بخش‌های جدید نیز می‌باشد، سرویس‌های ما نیاز به اسنادی منظم و قابل درک برای مشتریان ما هستند تا از این طریق به مشتریان خود دیدگاهی واحد و یکسان ارائه دهیم تا در طی توسعه و بهبود سیستم از مشکلات احتمالی برای مشتریان خود جلوگیری نماییم لذا در این بخش به سیاست‌ها مربوط به مستند سازی صحبت میکنیم


طراحی سرویس و سیاست داکیومنت سازی

۱-خدمات مستندسازی خود را ایجاد کنید:
برای مشتریان شما مهم است که اسناد خوبی برای خدماتی که می خواهند استفاده کنند داشته باشند.اغلب این مستندات در یک سند جداگانه است که باید قبل از اینکه با رابط سرویس ارتباط برقرار و معنادار شود، مطالعه کنند.
(با این خط‌مشی به شما نشان می‌دهم که بیشتر قابلیت‌هایی که یک سرویس ارائه می‌دهد را می‌توان توسط خود سرویس توصیف کرد، بدون نیاز به اسناد خارجی گسترده)


۲-استفاده مجدد از استانداردهای موجود:
یک ضد الگویی (anti pattern) که اغلب دیده می شود، الگوی "اختراع نشده" است.به جای استفاده از استانداردها (استانداردهای واقعی)، سازمان ها، به ویژه گروه های فناوری اطلاعات، تمایل به اختراع مجدد چرخ دارند. در اجرای این خط مشی، خواهید دید که استفاده مجدد از استانداردهای موجود در محیط های معماری های معروف چقدر آسان است


۳-طراحی برای قابلیت استفاده مجدد:
هنگامی که شما یک سرویس را طراحی می کنید، خوب است که این سرویس توسط سایر خدمات و مصرف کنندگان مجددا استفاده شود.در بخش مربوط به این خط‌مشی، من مجموعه‌ای از دستورالعمل‌ها و روش‌های رایج را ارائه می‌دهم که می‌تواند به شما در ایجاد سرویسی کمک کند که به راحتی قابل استفاده مجدد باشد

۴-پشتیبانی از چندین نسخه از خدمات:
خط مشی نهایی با نسخه سازی سروکار دارد. یک سرویس ثابت نیست در طول عمر آن، اشکالات برطرف می شود و عملکرد اضافه یا حذف می شود. قرارداد یک سرویس تغییر خواهد کرد.
داشتن یک استراتژی نسخه‌سازی خوب به شما کمک می‌کند تأثیر این تغییرات را بر مصرف‌کنندگان خود به حداقل برسانید

رویکرد ما رویکرد سرویس محور می‌باشد و از دیدگاه و تفکر قدیمی نسبت به سیستم‌ها فاصله گرفته‌ایم، در رویکرد قدیمی مشتریان ما یک سند بزرگ رو مطالعه میکردن تا به درکی ابتدایی برای استفاده از سیستم دست پیدا کنن، در شیوه جدید هر سرویس خدمات خاص خود را دارد که مشتریان با مطالعه سرویس مورد نیاز خود به درکی جامع میرسند، در معماری‌های مدرن مانند REST نقاط انتهایی ما باید بگونه‌ای باشد که مشتریان با مشاهده ورودی و خروجی api سریعا درک کنند که چه چیزی نیاز دارند و چگونه از سرویس مدنظر خود استفاده کنن

در ادامه و تکمیل موارد ذکر شده در بالا مطرح کردن این موضوع که استاندارد HTTP میتواند سریعا به مصرف کنندگان سرویس‌های ما سندی توضیحی ارایه دهد بسیار قابل توجه هستش، استفاده از متدهای POST, DELETE, GET, PUT به مشتریان سریعا میرساند که چه چیزی بدست میگیرند رعایت موارد دیگر نیز میتواند درک صریحی رو ارائه دهند برای مثال ذکر json در ریپورت استاندارد HTML این رو میرسونن که در انتظار چه نوع خروجی باشد و همچنین کاربر با دیدن <report-ID> به این مسئله پی خواهد برد که با گذاشتن مقدار عددی بجای ID میتواند اطلاعات مربوط به ان را بگیرد

ذکر این مسائل به ما میگوید که در داکیومنت سازی لازم نیست هرچیزی را مطرح کنید، ذکر موارد زیر در داکیومنت سازی کافیست

■ ذکر URL های مورد استفاده برای دسترسی یا جستجوی یک گزارش
■ روابط پیوندهایی که نحوه پیوند منابع مختلف را با هم توضیح می دهد 
■ انواع رسانه ای که توسط این سرویس استفاده می شود

ریپوزیتوری پروژه بهترین جای ممکن برای ذخیره و نگهداشت و ارائه اون به مشتریان هستش


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


#microservice
#soa

@code_crafters

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

 ■ خدمات فرآیند: خدمات فرآیندی درشت ترین خدمات هستند. این نوع خدمات اغلب خدمات یا محصولاتی را به مصرف کنندگان خود ارائه می دهند.  به عنوان مثال، شما می توانید یک سرویس فرآیندی داشته باشید که فروش یک محصول(هر چیزی) را انجام می دهد. در این سناریو سیستم مالیاتی باید به روز شود، سیستم فروشندگی(فروشگاه، انبار و ...) باید به روز شود و سیستم های بسیار بیشتری در این معامله دخیل هستند. یک سرویس فرآیندی دیگر خدمات فرآیند و خدمات تجاری را برای انجام وظیفه خود فراخوانی می کند.  وقتی به ارکستراسیون(orchestrations) فکر می کنید، احتمالاً در مورد یک سرویس فرآیند صحبت می کنید.

■ خدمات تجاری: یک سرویس تجاری یک عملکرد تجاری واحد و خاص را برای یک سیستم فراهم می کند. در مثال قبلی، یک سرویس تجاری سرویسی است که می توانید برای به روز رسانی اطلاعات در یک سیستم مالیاتی استفاده کنید.

■ خدمات فنی: بهترین خدمات، خدمات فنی هستند. یک سرویس فنی بخش کوچکی از عملکرد را برای سایر خدمات فراهم می کند.  یک مثال از این می‌تواند سرویسی باشد که به شما امکان می‌دهد یک شخصیت شخصی را در پایگاه داده به‌ روزرسانی کنید، یک ایمیل ارسال کنید.

جدا سازی لایه انتقال transformer layer (سریالایزر) از لایه منطق تجاری business logic، این امکان رو براتون بوجود میاره که سرویس خود رو منتقل کنید، این امر باعث میشه که لایه منطق شما قابل استفاده و در صورت نیاز رابط‌های راه دوری ساخت که از منطق تحاری شما مجدد استفاده کنند


سیستم ما در حال توسعه است و دستخوش تغییراتی که ممکن است ورژن جدیدی رو خلق کنه، این تغییرات به دو دسته عملیات شکسته نشدن و عملیات شکسته شدن منجر گردد، که عواقب آن شامل سازگاری با نسخه قبلی و عدم سازگاری با نسخه قبلی گردد

سیاست‌های موجود در این خصوص

سازگاری با نسخه قبلی و شکسته نشدن:
(افزودن api جدید به سرویس‌های خاص و افزودن منابع غیر اجباری-مشتریان میتونن نادیده بگیرند)
۱-افزودن عملیات جدید- با افزودن عملیات جدید به سرویس‌های خود شکسته شدن رخ نمیدهد و سازگاری با نسخه قبلی همچنان پا بر جاست
۲-با افزودن عملیات جدید، طرحواره xml نیز بوجود می‌آید (schema)، تا زمانیکه طرحواره‌های بوجود اومده برای عملیات‌های جدید منجر به تغییر در طرحواره‌های قبلی و موجود فعلی نگردد سازگاری پا برجاست


عدم سازگاری با نسخه قبلی و شکسته شدن:
(حذف ویژگی از یک منبع، تغییر دادن یک ویژگی-حذف یک ارتباط و یا تغییر دادن ارتباط منابع)
۱-حذف یک عملیات از سرویس که منجر به شکسته شدن و عدم سازگاری با نسخه قبلی بوجود می‌آید

۲-تغییر نام یک عملیات موجود، این مسئله چیزی نیست جز حذف عملیات قبلی و خلق عملیات جدید که منجر به عدم سازگاری با نسخه قبلی میگردد

۳-تغییر پارامترهای موجود، این عمل منجر میشود که ورودی و خروجی عملیات شما دچار دگرگونی شود

۴-افزودن طرحواره xml، این موضوع بسنگی دارد به تغییرات بوجود اومده و بررسی سرویس توسط مشتریان است، اگه حالت توسعه مانند صورت گیرد به این معنا که چیزی مازاد به طرحواره قبلی اضافه گردد همچنان سازگاری پا برجاست ،اما اگر تغییرات بر روی نسخه قبلی صورت گیرد منجر به عدم سازگاری میشود

نسخه گذاری و ورژنینگ بر اساس شکسته شدن یا عدم شکسته شدن روی میدهد برای مثال ورژن فعلی ما 1.1 میباشد، اگر عملیات بدون شکسته شدن باشد ورژن ما 1.2 و اگر همراه با شکسته شدن باشد ورژن ما 2.1 خواهد شد، که به آن افزایش جزئی و افزایش تعداد نسخه میگوییم


اضافه بر مباحث کتاب:

ما لایه‌های مختلف زیادی داریم و این ممکن است برای شما گیج کننده باشد، رویکرد شما بصورت کلی در یک سرویس به این شکل خواهد بود(این نکات مفید برای سرویس‌های بزرگ میباشد)

لایه ذخیره ساز شما دیتابیس میباشد

لایه دیتای شما مدل‌های شما میباشد

لایه کوئری شما در مدلهای شما می‌باشد(object manager) که عملیات جستجو در ان قرار میگیرد

لایه دسترسی دیتای شما شامل تمامی عملیات‌های crud می باشد

لایه منطق تجاری شما شامل تمام عملیات‌های اعتبار سنجی و پردازش می‌باشد(لایه کوئری و لایه دسترسی داده شما در اینجا فراخوانی میشود)-ویو در این لایه قرار دارد اما اکسپرت این است که در کنار view ما فایل service هم داشته باشیم که رابطی بین viewی ما با لایه کوئری و دسترسی داده باشد و قرار بگیرد

لایه انتقال داده شما سریالایزرهای شما می‌باشد

لایه نمایش شما شامل هر چیزی میشود که کاربر میبیند(html, css, js, swagger)

رعایت کردن این لایه‌ها در سرویس‌های ما منجر به انعطاف پذیری و قابلیت استفاده مجدد میگردد

#microservice
#soa

@code_crafters

میکروسرویس و حکمرانی soa، در ادامه مباحث مربوط به سیاست‌های سازمانی soa در ادامه میریم به سراغ سیاست‌های امنیتی

امنیت بخش جدا ناپذیر دنیای امروزی هست و مشتریان ما خواهان امن بودن اطلاعات حساس خود در سامانه شما هستند برای مثال اطلاعات شخصی و موارد مالی افراد، مشتریان انتظار دارن که شما امنیت اطلاعات رو محفوظ تضمین کنید


سیاست‌های امنیتی

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

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

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

از یک سیستم هویت متمرکز برای مجوز استفاده کنید: قوانین مشابهی برای مجوز اعمال می شود. این اغلب چیزی است که در گذشته به برنامه ها اضافه می شود و نگهداری از آن اغلب دشوار است. با متمرکز کردن مجوز می توانید مطمئن شوید که همه سرویس ها از دستورالعمل های مجوز یکسانی که در سازمان تعریف شده است پیروی می کنند.


وب سرویس‌ خود را بشناسید و یکپارچگی پیام را در آن رعایت و پیاده سازی کنید (SOAP, REST, ...) برای مثال در REST این مسئله با https فراهم گشته اما اگر جایی این پروتکل نبود میتوانید از HMAC استفاده کنید، کمپانی های بزرگی مانند azure, aws, ... از این موضوع برای سرویس REST خود استفاده میکنند و عموما یک رویکرد مشابه دارن، یک سرویس تولید HMAC بالا بیاورید کاربر قبل از ارسال پیام به شما یک کلید گرفته و همراه پیام برای شما ارسال میکند شما پیام را گرفته و بر اساس پارامترهای خود از سرویس HMAC کلید رو میگیرید حالا دو کلید HMAC رو باهم مقایسه کرده و یکپارچگی و یا عدم یکپارچگی رو تایید کنید، اما سوال پارامترهای ورودی ما چه چیزهایی باشد، AWS به شکل زیر عمل میکند

روش HTTP:
با REST نوعی از روش HTTP که اجرا می کنید رفتار سمت سرور را مشخص می کند.  DELETE به یک URL خاص به طور متفاوتی با GET به آن URL مدیریت می شود

هدر Content-MD5:
این هدر HTTP یک هدر استاندارد HTTP است.این یک هش MD5 از بدنه درخواست است.اگر این هدر را در تولید کد HMAC قرار دهید، یک مقدار HMAC دریافت می کنید که با تغییر بدنه درخواست تغییر می کند

هدر Content-Type: 
هدر Content-Type یک هدر مهم هنگام برقراری تماس های REST است. بسته به نوع رسانه، سرور می تواند به یک درخواست پاسخ متفاوتی بدهد.بنابراین باید در HMAC گنجانده شود.

 هدر تاریخ:
شما همچنین تاریخ ایجاد درخواست برای محاسبه HMAC را درج می کنید. در سمت سرور می توانید مطمئن شوید که تاریخ در حین انتقال تغییر نکرده است.  علاوه بر این می توانید قابلیت انقضای پیام را در سرور اضافه کنید.

 مسیر روش HTTP:
بخشی از مسیر URL که فراخوانی شده است نیز در محاسبه HMAC استفاده می شود، زیرا یک URI منبعی را در REST شناسایی می کند.

یک سیستم احرازهویت مرکزی و مجوزدهی (authentication, authorization) راه اندازی کنید SSO (دقت کنید ممکن سیستم مجوز هی شما متفاوت از هویت سنجی باشد این بستگی به سیستم شما دارد) (در کتاب که بر اساس جاوا نوشته شده، پلتفرم openam را معرفی و پیش برده، در پست‌های قبلی کانال راجب keycloak صحبت شد)


#microservice
#soa

@code_crafters

در ادامه حکمرانی soa میرسیم به سراغ تست نویسی ،اما چرا این بخش وجود دارد، سوا از اینکه تست نویسی در قلمرو soa نمیگنجد، اما این یک الزام همیشگی می‌باشد که باید در تمام نقاط و کدهای خود انجام دهید تا از درستی و سلامت کار کرد کدهای خود آگاه شوید و سرویس‌های خود را از راه دور فرا بخوانید تا مطمئن شوید به درستی کار میکنن

سیاست‌های تست نویسی:

لایه ادغام: 
تست کنید تا ببینید آیا تمام اجزای مختلف همانطور که انتظار می رود با هم کار می کنند یا خیر.  این ممکن است شامل تماس هایی با استفاده از چندین سرویس باشد. 

 لایه سرویس از راه دور:
تست کنید تا ببینید آیا می توانید با لایه راه دور سرویس تماس بگیرید و آیا این لایه به درستی تبدیل داده ها از فرمت راه دور به فرمت داخلی را انجام می دهد یا خیر.  برای این کار باید یک الگو از لایه سرویس خود بسازید، اما بعداً در مورد آن بیشتر توضیح دهید.

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

 لایه داده:
در لایه داده شما آزمایش می کنید که آیا اطلاعات به درستی باقی می مانند یا خیر.

در بخش مربوط به لایه منطقی و لایه داده اگر شما unittest نوشته باشید حجت رو تموم کرده‌اید، اما میتوانید و بهتر است با mock نیز تست کنید

در تست لایه ارتباطی خود(لایه راه دور) دو موضوع اهمیت دارد، یک تست پروتکل ارتباطی بین سرور و مشتری، دو تست تبدیل داده‌های بین سرور و مستری و جاساز آن به درستی(در این تست شما به ذخیره سازی داده اهمیت نمیدهید)

تست ادغام(integration): سرویس های شما با هم در ارتباط هستند و این نیازمند تست می باشد تا مطمئن شوید جریان شما صحیح و به درستی کار میکند


در ادامه مبحث این تست‌های شما نیست که تنها اهمیت دارد بلکه کیفیت کدها نیز اهمیت بالای دارد، که کدام بخش از کد شما در سطح بهتری کار میکند(در کتاب از ابزار sonar برای بررسی کیفیت کد اسم برده) معیارهای خروجی این برنامه میتواند نقطه شروع سیاست گذاری ما باشد:

بیانیه:
 ما می خواهیم خدمات ما حداقل سطح کیفی قابل اندازه گیری داشته باشد.  سرویس ها باید به خوبی تست شده و استانداردهای کدگذاری را که ما تعریف کرده ایم تایید کنند.  ما سطوح زیر را از انطباق تعریف می کنیم:
 پوشش کد: حداقل 80% .موفقیت در تست: 100% .مسائل امنیتی: 0 .رعایت قوانین: 90% 

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

 پیامدها:
کد باید به طور گسترده آزمایش شود تا مطابق با خواسته های کیفیت خاص باشد. یک ساخت با کیفیت باید برای بررسی خودکار کیفیت کد تنظیم شود.

مورد بعدی توسعه برای cloud می باشد که در پست‌های قبلی در خصوص صفات و ویژگی‌های آن کامل توضیح داده شده است

لینک تکمیلی پست

#microservice
#soa

@code_crafters

در ادامه مباحث حاکمیت soa میرسیم به سیاست‌های زمان اجرا، بعد از اتمام و اجرا کردن سرویس وقت آن فرا رسیده که نظارت جامعی بر روی انها و بررسی مطابقت آن با سیاست‌های تعریف شده برسیم و چرخه عمر سرویس مشخص گردد، جهت نظارت بر زمان اجرا شما اینکار رو با ابزارهای مختلفی انجام میدهید و گزارشات آنرا بررسی میکنید(در کتاب در این فصل به پلتفرم BAMOS پرداخته و راجب آن صحبت میکند) و از سرویس‌های مانیتورینگ استفاده نموده و رویدادهای خاصی رو تعریف کرده تا سیستم برای شما طبق آن گزارش تهیه کند


چرخه عمر سرویس به دلایل زیر قابل اهمیت می‌باشد:

 ■ به شناسایی خدماتی که نیاز به ایجاد یا به‌روزرسانی دارند کمک می‌کند، زیرا یک نمای کلی از تمام سرویس‌هایی که در حال حاضر در حال تولید هستند را ارائه می‌دهد

 ■ کمک می کند تا مطمئن شوید که تمام اقدامات لازم قبل از تولید یا منسوخ شدن یک سرویس انجام شده است

 ■ تعیین خط مشی هایی که در هر مرحله باید رعایت شود استفاده کرد.

چرخه عمر سرویس معمولاً در چهار فاز متمایز شناسایی می‌شوند: مدل‌سازی، مونتاژ، استقرار و مدیریت

فاز مدل:
در این فاز شما دو مرحله دارید، یک به الزامات تجاری که باید برآورده شود نگاه کنید(بررسی درخواست مشتریان و آنچه که انها نیاز دارند) دو شناسایی خدمات مورد نیاز برای ارائه این قابلیت تجاری(آیا این قابلیت از قبل در سیستم ما و سرویس‌های ما وجود دارد؟؟؟آیا نیاز به توسعه یک سرویس جدید داریم؟؟؟آیا میشه یکی رو تمدید کرد؟؟)

فاز مونتاژ:
در این مرحله شما الزامات خدمات تجاری در فاز قبل رو دریافت کرده و آنرا به یک سرویس تبدیل میکنید و منتشر میسازید

فاز استقرار:
پس از ایجاد سرویس آن را در یک ظرف گذاشته و مستقر میکنید تا شروع به تبادل با سیستم نموده و یکپارچه گردد

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


سیاست‌های چرخه عمر سرویس:

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

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

 قرارداد را تعریف کنید در این مرحله شما خدماتی که باید ایجاد کنید را می شناسید.  در این مرحله شما قرارداد را تعریف خواهید کرد (یک WSDL در مورد WS-* و مجموعه ای از اسناد در مورد REST)

 ثبت قرارداد:
بعد از اینکه قرارداد را تعریف کردید، می توانید آن را در مخزن WSO2 ثبت کنید

 تحقق سرویس:
 با قرارداد موجود در مخزن، می توانید اجرای سرویس را آغاز کنید.  در این مرحله ممکن است تغییرات کوچکی در قراردادی که قبلاً در مخزن ذخیره شده است ایجاد کنید

سرویس را آزمایش کنید:
قبل از اینکه سرویس را اجرا کنید تا مصرف کنندگان سرویس شما بتوانند از آن استفاده کنند، ابتدا باید سرویس را آزمایش کنید. 

 استقرار سرویس:
 پس از آزمایش، در نهایت می توانید سرویس را در یک کانتینر مستقر کنید و به مصرف کنندگان سرویس اطلاع دهید که می توانند از آن استفاده کنند

 سرویس در دسترس:
پس از استقرار، سرویس در دسترس است.  در این مرحله سرویس نظارت خواهد شد تا ببینیم آیا با سیاست های زمان اجرا مطابقت دارد یا خیر

 سرویس منسوخ شده:
هنگامی که سرویس دیگر استفاده نمی شود یا نسخه جدیدی مستقر می شود، این سرویس می تواند به عنوان منسوخ شده علامت گذاری شود.  در این صورت، مصرف کنندگان خدمات همچنان می توانند از این سرویس استفاده کنند اما باید به سرویس دیگری منتقل شوند، زیرا این سرویس به زودی بازنشسته خواهد شد

 سرویس بازنشسته شد:
پس از اینکه یک سرویس منسوخ شد و باید حذف شود، سرویس را بازنشسته می‌کنید.  اگر سرویسی بازنشسته شود، مصرف کنندگان خدمات دیگر نمی توانند به آن دسترسی داشته باشند.

#microservice
#soa

@code_crafters

سوالات مربوط به سیاست‌های بالا:

اولیه: 
آیا قراردادی تعریف شده است؟
آیا مستندات نوشته شده است؟

 ثبت شده: 
آیا سرویس ایجاد شده است؟
آیا کیفیت کد و پوشش آزمایشی با خط مشی مطابقت دارد؟

 در تست:
آیا تست ادغام با سایر اجزا به پایان رسیده است؟
آیا تست ادغام با مصرف کننده خدمات به پایان رسیده است؟
آیا سرویس در محیط تولید مستقر شده است؟
آیا پیکربندی سرویس به روز شده است؟

موجود:
آیا مصرف کنندگان در مورد استهلاک مطلع شده اند؟
آیا پیکربندی سرویس به روز شده است؟

 منسوخ شده:
آیا مصرف کنندگان در مورد بازنشستگی خدمات مطلع شده اند؟

 بازنشستگی:
چرخه عمر پایان سرویس

علاوه بر سرویس‌های ما که دارای چرخه عمر هستند، برخی از سیاست‌های ما نیز دارای یک عمر هستند و این ممکن است به دلایل مختلی از قبیل اعمال سیاست جدید، ایجاد خط مشی صنعتی جدید، تغییر خواسته‌های مشتریان و عدم سنجیده شدن سیاست ابلاغ شده و ... صورت گیرد

یک مخزن قابل جستجو و مشاهده سیاست‌های خود بالا بیاورید و همچنین برای خدمات خود و توضیح مختصر آن تا بتوانید سریعا به اطلاعاتی در مورد آنها دست پیدا کنید




به انتهای کتاب حکمرانی soa رسیدیم ، سیاست‌های آنرا مطالعه و جامعیت عملکردی آن را فهمیدیم، اکنون با دانش به این مسائل و موضوعات درک بهتر و پایه مقدماتی رو برای معماری‌های جدیدی از قبیل microservice, DDD و .... و همچنین آمادگی اولیه برای زبان مدلسازی BPM را داریم

#microservice
#soa

@code_crafters

در این سری پست میخوایم بررسی کنیم api gateway در معماری میکروسرویس چکاری میکند


یک api gateway در واقع یک ابزار مدیریت api هستش که بین یک کلاینت و یک مجموعه از سرویس‌هایی بکند قرار میگیره

در این حالت یک کلاینت یک‌ برنامه است که روی دیوایس‌های کاربران میشنه و سرویس‌های بکند در سرورهای قرار دارند

یک api gateway جزو یک برنامه تحویل است (ترکیبی از سرویس‌هایی که یک برنامه کاربردی در اختیار کاربران قرار میده) و شبیه یک پروکسی معکوس (revers proxy) عمل میکنه که همه درخواست‌ها api رو‌ می‌پذیره و پاسخ میده، تجمیعی از خدمات مختلف مورد نیاز برای برای انجام دادن و بازگشت نتایج مناسب

در یک شکل ساده تر api gateway یک بخش از نرم افزار است که رهگیری میکنه تماس apiهارو از یک کاربر و مسیردهی میکنه این رو به سرویس مناسب


چرا از api gateway استفاده میکنیم؟
بیشتر apiهای سازمانی از طریق api gateway مستقر میشوند. معمولا api gateway هندل میکنه وظایف که استفاده میشوند در سرتاسر یک سیستم از سرویس‌های api، مانند احراز هویت کاربران، محدودیت نرخ و آمار گیری

در حالت ابتدایی یک api سرویس میپذیره یک درخواست بیرونی و برمیگردون یک پاسخ رو، اما حیات اون انقدر ساده نیست، نگرانی‌ در یک مقیاس بزرگ رو‌در نظر بگیرید:

شما میخواهید از apiهای خود در برابر سواستفاده و استفاده زیاد محافظت کنید

شما میخواهید بدونید که مردم چقدر از api شما استفاده میکنن و ابزارهای مانتیورینگ و تحلیل اضافه کنید

اگر یک api تجاری دارید شما میخواهید به یک سیستم صورتحساب متصل شوید

ممکنه شما یک معماری میکروسرویس اتخاذ کرده باشید در این صورت یک درخواست میتواند به تماس ده‌ها برنامه مجزا نیاز داشته باشد

با گذشت زمان شما سرویس‌های جدیدی بالا میاورید و سرویس‌هایی رو بازنشسته میکنید (در مبحث soa اشاره کردیم قبلا) اما مشتریان میخواهند تمامی سرویس‌های شما را در یکجا داشته باشند

چالش ما ارائه یک تجربه ساده و قابل اعتماد در مقابل این همه پیچیدگی به مشتریان است. یک api gateway راهی برای جدا کردن رابط مشتری از apiهای پیاده سازی شده است. هنگامیکه یک‌کلاینت درخواستی میده api gateway اون رو به چندین درخواست تقسیم میکنه، و مسیردهی میکنه به مکان‌های مناسب، یک پاسخ رو تولید میکنه و همه چیز رو پیگیری میکنه


نقش api gateway در مدیریت api:
یک api gateway یک بخش از سیستم مدیریتی است، این api gateway رهگیری میکنه تمامی درخواستهای ورودی رو و از طریق سیستم مدیریت ارسال میکنه، و تمامی توابع مختلف ضروری رو انجام میده

کاری که یک api gateway انجام می‌دهد از یک پیاده سازی تا انجام دیگری متفاوت است. برخی از توابع رایج شامل احرازهویت، مسیردهی، نرخ محدودیت، صورتحساب، مانیتورینگ، تحلیل، سیاست گذاری، هشدارها و امنیت است. api gateway فراهم میکنه این منافع رو:

کاهش تاخیر:

با توزیع درخواست‌های دریافتی و بارگذاری وظایف رایج مانند خاتمه SSL و ذخیره سازی، api gateway با بهینه کردن مسیریابی ترافیک و توزیع در سرتاسر سرویس‌های بکند به اطمینان از عملکرد بهینه و مصرف منابع. با اینکار، api gateway بار سرور و استفاده از پهنای باند را به حداقل می‌رسانند و نیاز به ظرفیت سرور و پهنای اضافی شبکه را کاهش و تحربه کاربری را بهبود می‌دهد

مدیریت ترافیک:

 ترافیک را از طریق مکانیسم‌های مختلفی که برای کنترل نرخ و حجم درخواست‌های دریافتی طراحی شده‌اند و عملکر بهینه و استفاده از منابع را تضمین، کنترل و مدیریت می‌کنند

۱-سیاست‌های محدود کننده نرخ در یک بازه زمانی را مشخص میکند، برای هر کلاینت یا کلید، در برابر بار اضافی محافظت میکنند

۲-قواعد مهار درخواست،قوانین و محدودیت‌هایی را برای تنظیم ترافیک درخواست تعریف می‌کنند مانند: حداکثر نرخ‌های درخواست، مجوزهای انفجاری و سهمیه‌ها

۳-قواعد کنترل همزمانی بالاخص سقف تعداد درخواست‌های از ارتباط همزمان یا درخواست‌های که میتونن بصورت همزمان سرویس‌های بکند هندل کنند

۴-قواعد قطع مدار سلامت مانیتورینگ و پاسخگویی از سرورهای بکند و بلاک موقت یا تغییر مسیر ترافیک موقت، تا از خرابی عادی و ابشاری یا کندی سرویس‌ها جلوگیری کنید

۵-توزیع بار پویا از api gateway، بطور مداوم سلامت سرور را نظارت می‌کند و مسیریابی ترافیک را در زمان واقعی تنظیم می‌کند تا بتوانند افزایش تقاضا رو مدیریت کند، زمان پاسخ را حداقل و توان عملیاتی را به حداکثر برساند

استفاده از زیرساخت‌ها شبکه جهانی:

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

#api_gateway
#microservice



@code_crafters

هزینه اثربخشی:

با ارائه یک پلتفرم متمرکز برای مدیریت ترافیک API، اجرای سیاست‌های امنیتی، اجرای قوانین مدیریت ترافیک و تسهیل یکپارچه‌سازی با سرویس‌های بکند، در مدیریت اثربخشی هزینه تحویل برنامه و یکپارچه‌سازی API نقش دارند. همچنین امکان مصرف سطحی خدمات را برای حفظ اثربخشی هزینه فراهم می‌کنند. انواع مختلف API ها می توانند از طرق مختلفی بر اثربخشی هزینه یک برنامه تاثیر بگذارند

۱-انعطاف پذیری:  apiهای http که عمومی‌ترند، می‌توانند از هر روش http استفاده کنند. که سادگی و انعطاف پذیری را در توسعه ارائه می‌دهند و کاهش هزینه می‌دهند rest api که به قواعد خاصی تمرکز و پایبند دارند ممکن است به تلاش و تخصص بیشتری نیاز داشته باشند جهت پیاده سازی و هزینه رو افزایش دهند

۲-زیرساخت: به دلیل انعطاف apiهای http ممکن است هزینه زیرساخت کمتری داشته باشند برای res api ها جهت پشتیبانی از از ویژگی‌ها نیاز به اجزای اضافی در زیرساخت یا خدمات اضافی باشد که به‌طور بالقوه باعث افزایش هزینه‌های زیرساخت شود

مقیاس پذیری: API های HTTP، که می توانند با افزودن سرورها یا نمونه های بیشتر به صورت افقی مقیاس شوند، ممکن است گزینه های مقیاس پذیری مقرون به صرفه تری را ارائه دهند، به ویژه در محیط های ابری با قابلیت های مقیاس خودکار. APIهای REST ممکن است به دلیل شرایط بدون حالت، حافظه پنهان، و ملاحظات معماری توزیع شده نیاز به مقیاس بندی پیچیده تری داشته باشند و ممکن است برای دستیابی به مقیاس پذیری افقی به منابع زیرساخت یا خدمات اضافی نیاز داشته باشند که به طور بالقوه هزینه ها را افزایش می دهد

#api_gateway
#microservice


@code_crafters

2-الگوی مش سرویس
تصور کنید تو یه شهر شلوغ هستید که پر از ماشین‌ها (میکروسرویس‌ها) است که می‌خوان با هم ارتباط برقرار کنن. اگه هر ماشین بخواد خودش مسیرش رو پیدا کنه، ترافیک قفل می‌شه، تصادف پیش میاد و هیچ‌کس به موقع به مقصد نمی‌رسه. حالا مش سرویس مثل یه سیستم هوشمند مدیریت ترافیک عمل می‌کنه. این سیستم یه شبکه‌ی اختصاصی از «پروکسی‌ها» (مثل چراغ‌های راهنمایی یا پلیس‌های ترافیک) داره که تمام ارتباطات بین ماشین‌ها رو هدایت، کنترل و بهینه می‌کنه.


تصویر سوم
این لایه‌ی واسطه (که معمولاً با ابزارهایی مثل Istio یا Linkerd پیاده‌سازی می‌شه) مسئولیت کارهای زیر رو به عهده می‌گیره:

هدایت ترافیک: تصمیم می‌گیره درخواست‌ها از کدوم مسیر برن. مثلاً اگه یه سرویس شلوغ باشه، درخواست‌ها رو به یه نمونه‌ی دیگه از همون سرویس می‌فرسته.
تعادل بار (Load Balancing): بار کاری رو بین نسخه‌های مختلف یه سرویس تقسیم می‌کنه تا هیچ سرویسی بیش از حد تحت فشار نباشه.
امنیت: ارتباط‌ها رو رمزنگاری می‌کنه (مثلاً با TLS) و مطمئن می‌شه فقط سرویس‌های مجاز بتونن با هم حرف بزنن.
نظارت و رصد: اطلاعاتی مثل زمان پاسخ‌گویی، تعداد درخواست‌ها یا خطاها رو جمع‌آوری می‌کنه تا تیم توسعه بتونه عملکرد سیستم رو تحلیل کنه.
مدیریت خطا: اگه یه سرویس از کار بیفته، مش سرویس می‌تونه درخواست‌ها رو به‌طور خودکار به یه سرویس سالم هدایت کنه یا یه پیام خطای مناسب برگردونه.

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

مزیت بزرگ: مش سرویس کد سرویس‌ها رو ساده‌تر می‌کنه، چون منطق شبکه‌ای (مثل retry، timeout یا رمزنگاری) از سرویس‌ها جدا می‌شه و به لایه‌ی مش منتقل می‌شه. اما یه نکته هم داره: راه‌اندازی و مدیریت مش سرویس ممکنه خودش پیچیدگی‌هایی به سیستم اضافه کنه، مخصوصاً تو محیط‌های کوچک‌تر.
#microservice #design_patterns

@code_crafters

4-الگوی Event Sourcing
حالا تصور کنید یدیه دفترچه خاطرات دارید که هر چیزی تو زندگیت توناتفاق می‌افته رو توش می‌نویسیید: امروز چی خریدید، کجا رفتید، چی گفتی. اگه بخوادی یه روز خاص رو یادتون بیاد، فقط کافیه دفترچه رو باز کنید و اون صفحه رو بخونید. الگوی Event Sourcing به همون منبع یابی رویداد تو میکروسرویس‌ها هم یه همچین چیزیه تقریبا. جای اینکه فقط حالت فعلی سیستم (مثل موجودی حساب بانکی) رو ذخیره کنید، هر اتفاقی که تو سیستم می‌افته رو به‌عنوان یه ایونت ثبت می‌کنید. بعد هر وقت بخوایذ، می‌تونیذ این رویدادها رو بخونیذ و حالت سیستم رو بازسازی کنی.

اجزای اصلی این الگو:

ا(Event): مثل یه خط تو دفترچه‌ست. مثلاً «کاربر X صد تومن واریز کرد». هر ایونت یه تغییر تو سیستم رو نشون می‌ده.
ا(Event Store): همون دفترچه خاطراته! همه رویدادها رو به ترتیب و بدون امکان تغییر ذخیره می‌کنه.
ا(Event Handler): مثل یه کتابدار که می‌ره تو دفترچه، ایونت رو می‌خونه و سیستم رو به‌روزرسانی می‌کنه.
ا(Aggregate): یه گروه از ایونت هایی مرتبط که با هم یه داستان کامل (مثل لاگ یه حساب بانکی) رو تعریف می‌کنن.
ا(Event Stream): تاریخچه ایونت هایی یه چیز خاص (مثلاً همه تراکنش‌های یه حساب).
ا(Event Publisher): مثل یه پستچی که خبر رو به بقیه می‌رسونه، ایونت رو به سرویس‌های دیگه می‌فرسته.
ا(Event Subscriber): سرویس‌هایی که منتظرن خبر جدید برسه و باهاش کار کنن.
ا(Command): درخواست‌هایی که کاربر می‌فرسته (مثل «پول واریز کن») و باعث می‌شن یه ایونت جدید ساخته بشه.

مثال:

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

رویداد 1: «100 تومن واریز شد»
رویداد 2: «50 تومن برداشت شد» اگه بخواید موجودی حساب رو ببینی،د سیستم همه رویدادهای اون حساب رو می‌خونه و محاسبه می‌کنه: 100 - 50 = 50 تومن. این روش نه‌تنها تاریخچه کامل رو نگه می‌داره، بلکه اگه بخواهید حسابرسی کنید یا خطایی رو پیدا کنید، خیلی راحت می‌تونید همه‌چیز رو بررسی کنید.
همچنین مقیاس پذیری ,حسابرسی و انعظاف پذیری از ویژگی های Event Sourcing به حساب میان.

کلام آخر این که تو این بخش، دو تا الگوی خفن دیگه رو بررسی کردیم:Circuit Breaker که مثل یه نگهبان جلوی خرابی‌های بزرگ رو می‌گیره(مثل بتمن🥸)، و Event Sourcing که مثل یه دفترچه خاطرات همه‌چیز رو ثبت می‌کنه.
#microservice #design_patterns

@code_crafters

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


حالا تو بخش سوم، قراره با دو تا الگوی مهم دیگه آشنا بشیم: الگوی SAGA و الگوی API Gateway. این دو الگو بهمون کمک می‌کنن تا هماهنگی داده‌ها و دسترسی به سرویس‌ها رو تو سیستم‌های پخش‌شده بهتر مدیریت کنیم.

5. الگوی SAGA (SAGA Pattern)
الگوی SAGA یه روش کارآمد برای مدیریت هماهنگی داده‌ها تو تراکنش‌های پخش‌شده بین میکروسرویس‌هاست.
تو سیستم‌های سنتی، تراکنش‌ها با مدل ACID مدیریت می‌شن که تضمین می‌کنه همه‌چیز یا کامل انجام بشه یا اصلاً انجام نشه.
اما تو معماری میکروسرویس، که هر سرویس دیتابیس خودش رو داره، پیاده‌سازی این مدل خیلی سخته.
اینجاست که الگوی SAGA یه راه‌حل هوشمندانه ارائه می‌ده.

چطور کار می‌کنه SAGA؟

تو این الگو، یه تراکنش بزرگ به چند قدم کوچیک‌تر تقسیم می‌شه که هر کدومش رو یه سرویس انجام می‌ده.
هر قدم یه پیام یا رویداد منتشر می‌کنه که باعث فعال شدن قدم بعدی می‌شه.
اگه یه قدم به مشکل بخوره، یه سری عملیات جبرانی (Compensating Transactions) اجرا می‌شن تا وضعیت به حالت اولیه برگرده.

دو نوع هماهنگی در SAGA:
🔹 کروئوگرافی (Choreography):
هیچ هماهنگ‌کننده‌ی مرکزی نداریم. هر سرویس یه رویداد منتشر می‌کنه و بقیه سرویس‌ها خودشون به اون گوش می‌دن.
مثلاً سرویس سفارش یه رویداد «سفارش ثبت شد» می‌فرسته، سرویس انبار اینو می‌شنوه و موجودی رو کم می‌کنه.
این روش تو سیستم‌های ساده خوبه، ولی تو سیستم‌های بزرگ مدیریت سخت می‌شه.

🔹 ارکستراسیون (Orchestration):
اینجا یه سرویس مرکزی (Orchestrator) همه‌چیز رو مدیریت می‌کنه. مثلاً اول به سرویس سفارش می‌گه سفارش رو ثبت کن، بعد به سرویس پرداخت دستور می‌ده پول رو بگیره.
مدیریتش متمرکزه و برای سیستم‌های پیچیده بهتره، ولی نقطه‌ی شکست هم می‌تونه باشه.

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

چرا SAGA مهمه؟
تضمین هماهنگی داده‌ها تو سیستم‌های پخش‌شده
مدیریت درست خطاها با عملیات جبرانی
مناسب برای معماری‌های مدرن که نمی‌تونن از تراکنش‌های سنتی استفاده کنن

6. الگوی API Gateway (API Gateway Pattern)
الگوی API Gateway یه راه‌حل برای ساده‌سازی و مدیریت دسترسی به میکروسرویس‌هاست.

تو سیستم‌های پخش‌شده، معمولاً سرویس‌های زیادی وجود دارن که هر کدوم وظیفه خاصی دارن.
اگه کلاینت‌ها (مثلاً اپ موبایل یا وب) بخوان مستقیماً با هر سرویس ارتباط برقرار کنن، کار خیلی پیچیده می‌شه.
اینجاست که API Gateway وارد می‌شه و همه‌چیز رو ساده‌تر می‌کنه.

چطور کار می‌کنهAPI Gateway ؟
مثل یه دربان هوشمند جلوی سیستم می‌ایسته.
هر درخواستی که از سمت کاربر میاد، اول وارد API Gateway می‌شه، بعد اون تصمیم می‌گیره این درخواست باید به کدوم سرویس بره.

وظایف کلیدی API Gateway:
هدایت و تعادل بار (Routing and Load Balancing): درخواست‌ها رو بر اساس قوانین به سرویس درست می‌فرسته و با پخش بار بین نسخه‌های مختلف، سیستم رو پایدار نگه می‌داره.
ترجمه پروتکل (Protocol Translation): می‌تونه درخواست‌های HTTP رو به فرمت‌های دیگه (مثل gRPC) تبدیل کنه تا با سرویس‌های بک‌اند سازگار بشه.
تغییر درخواست (Request Transformation): درخواست‌ها و پاسخ‌ها رو بر اساس نیاز سرویس‌ها تغییر می‌ده، مثلاً پارامترها یا هدرها رو تنظیم می‌کنه.
کش کردن (Caching): با ذخیره داده‌ها، سرعت رو بالا می‌بره و بار رو از روی سرویس‌ها کم می‌کنه.
هدایت و تعادل بار (Load Balancing) بین چند سرور

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

چرا API Gateway مهمه؟
دسترسی به سرویس‌ها رو متمرکز و ساده می‌کنه
امنیت و نظارت رو از یه نقطه انجام می‌ده
به مقیاس‌پذیری، پایداری و مانیتورینگ سیستم کمک می‌کنه

#microservice #design_patterns

@code_crafters