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

 ■ خدمات فرآیند: خدمات فرآیندی درشت ترین خدمات هستند. این نوع خدمات اغلب خدمات یا محصولاتی را به مصرف کنندگان خود ارائه می دهند.  به عنوان مثال، شما می توانید یک سرویس فرآیندی داشته باشید که فروش یک محصول(هر چیزی) را انجام می دهد. در این سناریو سیستم مالیاتی باید به روز شود، سیستم فروشندگی(فروشگاه، انبار و ...) باید به روز شود و سیستم های بسیار بیشتری در این معامله دخیل هستند. یک سرویس فرآیندی دیگر خدمات فرآیند و خدمات تجاری را برای انجام وظیفه خود فراخوانی می کند.  وقتی به ارکستراسیون(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

فصل اول
2- بلاکچین چگونه کار می‌کند؟

بلاکچین را مجموعه‌ای از بلاک‌ها تصور کنید که به صورت زنجیره‌وار به یکدیگر متصل‌اند.

1- ساختار هر بلاک
هر بلاک در زنجیره شامل 3 بخش اصلی است:

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

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

1.3- هش بلاک قبلی (Previous Block Hash): هر بلاک حاوی هش بلاک قبلی است که به آن متصل است. این ویژگی باعث ایجاد زنجیره‌ای از بلاک‌ها می‌شود و امنیت و تغییرناپذیری بلاکچین را تضمین می‌کند.

2- فرایند افزودن بلاک به زنجیره
برای افزودن بلاک جدید به زنجیره، مراحل زیر انجام می‌شود:


2.1- تایید تراکنش‌ها (Transaction Verification): ابتدا تراکنش‌های جدید توسط نودهای شبکه تایید می‌شوند. این تایید شامل بررسی صحت امضاهای دیجیتال و اطمینان از عدم تکراری بودن تراکنش‌ها است.

2.2- حل مسئله ریاضی (Proof of Work): برای اضافه کردن بلاک جدید به زنجیره، نودها باید یک مسئله ریاضی پیچیده را حل کنند که به آن اثبات کار می‌گویند. این فرآیند نیازمند قدرت محاسباتی زیادی است و زمان و انرژی زیادی مصرف می‌کند.

2.3- اضافه شدن به زنجیره (Block Addition): پس از حل مسئله و تایید صحت بلاک جدید توسط سایر نودهای شبکه، بلاک به زنجیره اضافه می‌شود.

شفافیت و قابلیت ردیابی
هر تراکنش در بلاکچین به صورت عمومی قابل مشاهده و ردیابی است. این ویژگی باعث می‌شود تا تمامی تراکنش‌ها شفاف و قابل اعتماد باشند. این شفافیت به ویژه در کاربردهایی مانند رای‌گیری الکترونیکی، مدیریت زنجیره تأمین و سیستم‌های مالی بسیار مهم است.

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

بیشتر بخوانید:
الگوریتم های هشینگ Hashing algorithms
هش بلاک Block Hash
نود Node

#blockchain
@code_crafters

پ ن(تخصصی):
خب سوالی که پیش میاد این که این نود ها چطوری پیوسته و همیشه در حال چک کردن و پردازش هش بلوک ها هستن تا اونارو تایید یا رد بکنن!؟



  ما در نظر میگیریم  که ۵ بلوک داریم
هش بلوک ۲ تغییر کرده ، این باعث میشه که بلوک ۳ ناساگاز بشه و اون با بلوک ۴ و...
این پروسه مثل یک دومینو ادامه پیدا می‌کنه
حالا نود که دائم داره بلوک های جدید رو پردازش و صحت سنجی  میکنه تشخیص میده

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

حالا اگه هش‌ها مطابقت داشته باشن نود به مرحله بعدی می‌ره اگر مطابقت نداشته باشه هم که خب بلوک رد میشه


مثال علمی:

بلوک 1 (هش: ABC)
بلوک 2 (هش: DEF) - شامل هش بلوک 1 (ABC)
بلوک 3 (هش: GHI) - شامل هش بلوک 2 (DEF)
بلوک 4 (هش: JKL) - شامل هش بلوک 3 (GHI)
بلوک 5 (هش: MNO) - شامل هش بلوک 4 (JKL)

‌ ‌ اگر دیتایی در بلوک 2 تغییر کنه هش بلوک 2 تغییر میکنه

مثلاً به XYZ حالا بلوک 3 که شامل هش قبلی (DEF) بود الان باید شامل XYZ باشه، اما هش بلوک 3 با این تغییر سازگار نیست.


نودها این تغییر را تشخیص میده زیرا وقتی اطلاعات بلوک 2 را هش می‌کنند هش جدید (XYZ) با هش اعلام شده (DEF) در بلوک 3 مطابقت نداره

و درواقع عدم تطابق باعث میشه که نودها بلوک 2 و بلوک‌های بعدی رپ کلا نامعتبر بدونه

#blockchain
@code_crafters

فصل اول
3-کاربردهای بلاکچین

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

1- ارزهای دیجیتال

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

2- قراردادهای هوشمند

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

3- زنجیره تأمین

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


4- رأی‌گیری الکترونیکی

استفاده از بلاکچین در سیستم‌های رأی‌گیری الکترونیکی می‌تواند شفافیت و امنیت انتخابات را افزایش دهد.
- مزایا: جلوگیری از تقلب، افزایش شفافیت و امکان رأی‌گیری از راه دور.
- مثال: پیاده‌سازی سیستم‌های رأی‌گیری برای انتخابات ملی و محلی با استفاده از بلاکچین

5- بهداشت و درمان

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

6- مدیریت

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

نتیجه‌گیری

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

#blockchain

@code_craftesr

گپ فنی و خودمونی گروه بابت امشب

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


به زودی میت‌های تخصصیش هم راه میندازیم
@code_crafters

فصل اول
4-اولین و معروف ترین بلاکچین ها

1-اولین بلاکچین ها:

1.1-بیتکوین(Bitcoin):

بیتکوین اولین و معروف ارز دیجیتالی و بلاکچین غیر متمرکزی است که توسط ساتوشی ناکوموتو در سال 2008 معرفی و در سال 2009 عملی شد.

سازنده: ساتوشی ناکاموتو
سال راه اندازی: 2009
کاربرد اصلی: ارز دیجیتال
ویژگی: اولین بلاکچین غیر متمرکز و آغازگر انقلاب ارزهای دیجیتال.

1.2-لایتکوین(litecoin):

زمان راه‌اندازی: 2011
سازنده: چارلی لی
کاربرد اصلی: ارز دیجیتال برای پرداخت‌های سریع‌تر و ارزان‌تر
ویژگی‌ها: تأیید سریع‌تر تراکنش‌ها، الگوریتم Scrypt، کارمزد پایین.

2-معروفترین بلاکچین ها

2.1-اتریوم (Ethereum):

زمان راه‌اندازی: 2015
سازنده: ویتالیک بوترین
کاربرد اصلی: قراردادهای هوشمند و اپلیکیشن‌های غیرمتمرکز (DApps)
ویژگی‌ها: قابلیت اجرای قراردادهای هوشمند و اپلیکیشن‌های متنوع.

2.2-ریپل (Ripple):

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

2.3-هایپرلجر (Hyperledger):

زمان راه‌اندازی: 2015
سازنده: بنیاد لینوکس
کاربرد اصلی: بلاک‌چین‌های خصوصی و کنسرسیومی برای کسب‌وکارها.
ویژگی‌ها: پلتفرم منعطف برای صنایع مختلف

2.4-کاردانو (Cardano):

زمان راه‌اندازی: 2017
سازنده: چارلز هاسکینسون
کاربرد اصلی: قراردادهای هوشمند و اپلیکیشن‌های غیرمتمرکز
ویژگی‌ها: امنیت و مقیاس‌پذیری بالا.

2.5-ایاس (EOS):

زمان راه‌اندازی: 2018
سازنده: بلاک‌وان
کاربرد اصلی: قراردادهای هوشمند و اپلیکیشن‌های غیرمتمرکز
ویژگی‌ها: سرعت و کارایی بالا، کاهش کارمزدها.

نکته هیچ ترتیبی در میزان معروفیت نیست صرفا معروفترین بلاکچین ها ذکر شده.

بیشتر بخوانید:
بیتکوین (Bitcoin)
لایتکوین(litecoin)
اتریوم (Ethereum)
ریپل (Ripple)
هایپرلجر (Hyperledger)
کاردانو (Cardano)
ایاس (EOS)
#blockchain
#web3
@code_crafters

گپ فنی امشب داخل گروه با سعید جان ، در خصوص استوریج فایلهای حجیم در بستر وب


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


@code_crafters

در پیرو گپ دیشب در گروه بابت minio مقاله زیر رو بخونید


https://blog.min.io/selecting-hardware-for-minio-deployment/

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

برخی از مباحث گفته شده:
- چگونگی عملکرد درگاه های پرداخت انلاین
- چگونگی و چالش های طراحی سرویس فروشگاهی، خرید، سبد خرید و انبار داری
- صحبت در باره retry handling و rollback تغییرات و Saga state machine
- بررسی زنده یک اپلیکیشن دارای فروشگاه، تحلیل محصولات و اپلیکیشن های مشابه
- توضیح درباره کیف پول مجازی، روش های پرداخت، پرداخت
- بحث مدیریت همزمانی، اعتبار سنجی خرید ها، کنترل و رزرو موجودی و Checkout
- پرسش و پاسخ سوالات مرتبط دوستان

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


@code_crafters

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


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


تحلیل خودتون رو راجبش در کامنت‌ها بزارید تا حرف بزنیم و نسبت بهش بیشتر شناخت پیدا کنید

@code_crafters

مقاله زیر رو در خصوص رعایت یکسری اصول کدزنی در پایتون بخونید ،سازمانهای بزرگ خروجی همچین چیزی ازتون انتظار دارن


@code_crafters




https://google.github.io/styleguide/pyguide.html

#مقیاس_پذیری و چالش های آن - پارت 1
Horizontal & Vertical #Scaling ⚖️

زمانی که فرآیند تولید نرم افزار به مرحله Production می‌رسد و اپلیکیشن روی سرور می‌رود، چالش‌ها و مخاطرات جدیدی برای صاحبان آن ایجاد می‌شود. ما در عصری هستیم که استفاده از اینترنت به سبک زندگیمان تبدیل شده. بنابراین پس از معرفی اپلیکیشن یا وبسایت، کاربران آن به سرعت افزایش پیدا می‌کند.
زمانی فرا می‌رسد که سیستم دیگر توان هندل کردن حجم بازدیدکنندگان و پردازش درخواست ها را ندارد.
در مواردی هم حجم دیتا به حدی می‌رسد که سیستم نمی‌تواند آن را در پایگاه داده خود ذخیره کند. در این گونه موارد، زمان آن فرا رسیده که محصول Scale یا مقیاس پذیر شود.
معمول ترین راهکار، مقیاس پذیری عمودی یعنی افزایش منابع سخت افزاری مانند RAM, CPU است اما در نرم‌افزار های بزرگتر، مقیاس پذیری عمودی تا حدی کارساز است.
از یک حدی به بعد تک سرور شما قادر به افزایش منابع نخواهد بود و یا صرفه اقتصادی نخواهد داشت. کما اینکه vertical Scaling محدودیت هایی مانند دیسک و شبکه را مقیاس پذیر نمیکند. (به خصوص پهنای باند در سرور های داخل که سرشار از اختلال و از نسل 3G است!)

بنابراین مقیاس پذیری افقی با افزودن سرور های بیشتر (که زین پس به آنها Node خواهیم گفت) و تقسیم بار بین انها ( Load Balanacing) راه حل بهتری خواهد بود. چرا که هم افزایش سرور ها ارزان تر خواهد بود (به نسبت خرید منابع حافظه و پردازنده بیشتر) و هم هر سرور مستقلا میتواند به‌ مقدار نیاز مقیاس پذیری عمودی هم داشته باشد (هر سرور منابع اختصاصی متفاوتی از حافظه ram، پردازنده، iops دیسک و پهنای باند / پورت شبکه داشته باشد)
تا به اینجا اصلی ترین تفاوت های دو مدل مقیاس پذیری را بررسی کردیم. اما همیشه چالش ها،‌ مزایا و معایبی هم وجود دارد که در جایگاه یک مهندس نرم افزار حرفه ای و معمار سیستم، ما باید با علم به این مباحث برای یک کسب و کار تصمیم بگیریم.

یکی از چهار هدف اصلی مقیاس پذیری، توسعه پذیر تر کردن یک نرم افزار است.
در مقیاس پذیری افقی مهمترین و اصلی ترین چالش های پیش رو مباحثی مانند همزمانی در عملیات ها، یکپارچگی داده ها، از بین بردن Single point of failure و کاهش گلوگاه ها است.
همانطور که در بالاتر اشاره شد در مقیاس پذیری افقی ما بجای تکیه بر سخت افزار محدود یک سرور، به طرف توزیع بار و کلاستر سرویس ها بر روی چند سرور (نود) متعدد میرویم.

فرض کنید نرم افزاری دارید که متشکل از ده ها میکروسرویس‌ و ده ها دیتابیس و ابزار مختلف میباشد. هر کدام ازین میکروسرویس ها بر روی سرور های 1 الی 5 در حال اجرا هستند. همچنین ممکن است هر یک ازین سرویس ها نیاز به replication و load balancing پیدا کنند (هدف از مقیاس پذیری افقی).
در اینصورت علاوه بر این که کلاستر سرور های شما میبایستی در یک شبکه داخلی یا خصوصی پایدار و قابل اتکا با هم در ارتباط باشند، بایستی بتوانند بصورت پایدار عملیات های خود را انجام دهند.
برخی از پارامتر های پایداری:
- درخواست های همزمان متعدد نباید منجر به پاسخ های مختلف شوند.
- داده های خروجی باید جدیدترین داده های موجود باشند.

به عنوان مثال، سرویس سفارش یا احراز هویت مان را مقیاس پذیر کردیم و لود بالانسینگ تعیین میکند هر بار درخواست ها به کدام node / سرور ارسال شود.
در صورتی که دو یا چند کاربر بطور همزمان قصد دسترسی به یک ریسورس مشترک (فایل / دیتابیس / etc) داشته باشند مشکلاتی همچون همزمانی یا concurrency و شرایط مسابقه یا race conditions پدیدار خواهد شد.

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

در مطلب بعدی (پارت 2 مقیاس پذیری)، به برخی شیوه های مدیریت این چالش ها و تجربه های شخصی میپردازیم.

بیشتر بخوانید (مقالات / مفاهیم مرتبط):
دسترسی پذیری بالا HA
گلوگاه Bottleneck
خوشه ها Cluster
تئوری CAP
مقیاس پذیری Scalability
سیستم های توزیع شده Distributed Systems

#مهندسی_نرم‌افزار #معماری
#software_engineering #architecture #Scalability #distributed_systems #devops #infrastructure

@csharpfriends @Code_Crafters

Example of Microservices System design template overview

#microservices #Scaling #bestpractice #architecture #distributed_systems #مهندسی_نرم‌افزار

- برخی از شماتیک‌ معماری دیگر پروژه های معروف در کامنت ها

@csharpfriends @Code_Crafters

دورنمای بسیار ساده و خلاصه لودبالانسینگ در معماری و طراحی میکروسرویس ها
در مطالب آینده درباره لودبالانسینگ یا توزیع بار صحبت خواهیم کرد
#microservices #load_balancing #api_gateway #Scaling #architecture #مهندسی_نرم‌افزار

@csharpfriends @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

چهل نکته درباره Linux Server Hardening
۱. رمزنگاری ارتباطات در سرور لینوکس:

تمام داده‌هایی که از شبکه ارسال می‌شوند، قابل شنود هستند. بهتر است همیشه داده‌های ارسالی را با رمزنگاری کردن، محافظت کنیم.

برای انتقال فایل می‌توان از scp, ssh, rsync و sftp استفاده کرد که همگی رمزنگاری دارند. همچنین می‌توان درایو سرور دیگر یا home کاربری خود را با استفاده از sshfs یا fuse محافظت شده مانت کرد.

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

برای رمزنگاری وب‌سرورها نیز می‌توان از الایت‌تی‌پی‌دی، آپاچی و انجین‌اکس با استفاده از SSL استفاده کرد.‌
‌
‌
‌
۲. از استفاده از سرویس‌های FTP، Telnet و Rlogin/Rsh در لینوکس خودداری کنید!!

از استفاده از سرویس‌های FTP، Telnet و Rlogin/Rsh در لینوکس خودداری کنید.
در بسیاری از تنظیمات شبکه، نام کاربری‌ها، رمزهای عبور، دستورات FTP/telnet/rsh و فایل‌های انتقالی توسط هر فردی که در همان شبکه حضور دارد، با استفاده از یک برنامه (Packet Sniffer)، قابل ضبط می‌باشند. راه حل معمول برای این مشکل استفاده از OpenSSH، SFTP یا FTPS (FTP over SSL) است که به FTP رمزنگاری SSL یا TLS را اضافه می‌کنند.

برای حذف سرویس‌های قدیمی و غیرمطمئن مانند NIS، rsh و سایر سرویس‌ها، دستور yum زیر را وارد کنید:

yum erase xinetd ypserv tftp-server telnet-server rsh-server

اگر از سرور مبتنی بر دبیان/اوبونتو استفاده می‌کنید، از دستور apt-get/apt برای حذف سرویس‌های ناامن استفاده کنید.

sudo apt-get --purge remove xinetd nis yp-tools tftpd atftpd tftpd-hpa telnetd rsh-server rsh-redone-server

توضیح:
این بخش از متن به شما هشدار می‌دهد که استفاده از سرویس‌های FTP، Telnet و Rlogin/Rsh در لینوکس باعث بروز ریسک امنیتی می‌شود. در شبکه‌های عمومی، اطلاعات کاربران، رمزهای عبور، دستورات و فایل‌های انتقالی به راحتی توسط افرادی که در همان شبکه حضور دارند قابل ضبط و دسترسی هستند. برای حل این مشکل، توصیه می‌شود از سرویس‌های امن‌تر مانند OpenSSH، SFTP و FTPS استفاده کنید. همچنین، دستورات لازم برای حذف سرویس‌های قدیمی و غیرمطمئن از سیستم‌عامل لینوکس نیز در اینجا آورده شده است.

packet sniffer:
برنامه (Packet Sniffer) یک نوع نرم‌افزار یا دستگاه است که بسته‌های داده‌ای که در یک شبکه عبور می‌کنند را ضبط و تجزیه می‌کند. هدف اصلی این برنامه‌ها، مشاهده و آنالیز ترافیک شبکه است.

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

استفاده از برنامه‌های packet sniffer در شبکه‌های عمومی یا شبکه‌هایی که به آنها دسترسی عمومی دارید، ممکن است برای جاسوسی یا به دست آوردن اطلاعات حساس به کار گرفته شود. با استفاده از این برنامه ها، فرد مورد نظر می‌تواند بسته‌های شبکه را ضبط کند و اطلاعات را بررسی کند، حتی اگر این اطلاعات به طور عادی رمزنگاری شده باشند.

از طرف دیگر، برنامه‌های packet sniffer نیز می‌توانند به عنوان ابزارهای مفیدی برای آنالیز و عیب‌یابی شبکه استفاده شوند. با استفاده از این برنامه‌ها، می‌توانید ترافیک شبکه را بررسی کنید، مشکلات را تشخیص دهید و عملکرد بهتری را برای شبکه خود فراهم کنید.

برنامه‌های packet sniffer معمولاً در قالب نرم‌افزارهای مختلفی مانند Wireshark، tcpdump، WinPcap و Capsa قابل دسترسی هستند و در سیستم‌عامل‌های مختلفی مانند لینوکس و ویندوز قابل استفاده هستند.‌
‌
‌
‌
۳. کاهش نرم افزار های نصب شده به منظور کاهش آسیب پذیری در لینوکس:

آیا واقعا نیاز به همه نوع سرویس هایی که نصب شده اند دارید؟ با حذف نرم افزار های اضافی امنیت و عملکرد سرور خودتون رو بهبود ببخشید.
از مدیر بسته RPM مانند yum یا apt-get و/یا dpkg استفاده کنید تا مجموعه‌ای از نرم‌افزارهای نصب شده روی سیستم را بررسی کنید. تمامی بسته‌های ناخواسته را حذف کنید.

yum list installed
yum list packageName
yum remove packageName
یا
dpkg --list
dpkg --info packageName
apt-get remove packageName‌
‌
‌‌

#linux
#hardning

@code_crafters

اجرا هر سرویس در یک سیستم نمونه مجازی:
اجرای سرویس‌های شبکه مختلف را در سرورها یا نمونه‌های مجازی جداگانه انجام دهید. این محدودیت تعداد سرویس‌های دیگری که ممکن است قربانی شود را محدود می‌کند. به عنوان مثال، اگر یک حمله‌کننده قادر به بهره‌برداری موفق از یک نرم‌افزار مانند Apache شود، او می‌تواند به تمامی سرور شامل سرویس‌های دیگری مانند MySQL/MariaDB/PGSql، سرور ایمیل و غیره دسترسی پیدا کند.

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

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

برای پیاده‌سازی این رویکرد با استفاده از کانتینر داکر، شما می‌توانید به شکل زیر عمل کنید:

1. ایجاد یک تصویر داکر برای هر سرویس شبکه: شما باید یک تصویر داکر برای هر سرویس شبکه مورد نظر ایجاد کنید. این تصویر شامل تنظیمات و پیکربندی‌های مربوط به سرویس شبکه خاص است.

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

3. پیکربندی شبکه: برای ارتباط بین کانتینرها و اجرای سرویس‌های شبکه، شما می‌توانید شبکه‌های داکر را پیکربندی کنید. این شبکه‌ها به کانتینرها امکان می‌دهند تا از طریق شبکه با یکدیگر ارتباط برقرار کنند.

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

۵. نگهداری از هسته لینوکس و بروز بودن نرم افزار ها:

اعمال پچ‌های امنیتی بخش مهمی از نگهداری سرور لینوکس است. لینوکس ابزارهای لازم برای به‌روزرسانی سیستم شما را فراهم می‌کند و همچنین امکان به‌روزرسانی آسان بین نسخه‌ها را فراهم می‌کند. تمامی بروزرسانی‌های امنیتی باید اعمال شوند. از مدیر بسته RPM مانند yum و/یا apt-get و/یا dpkg برای اعمال تمامی بروزرسانی‌های امنیتی استفاده کنید.

# yum update
یا
# apt-get update && apt-get upgrade

شما می‌توانید Red Hat / CentOS / Fedora Linux را به‌گونه‌ای پیکربندی کنید که از طریق ایمیل اطلاعیه‌های بروزرسانی بسته yum را دریافت کند. یک گزینه دیگر نیز استفاده از کرون جاب برای اعمال تمامی بروزرسانی‌های امنیتی است. در Debian / Ubuntu Linux می‌توانید از apticron برای ارسال اطلاعیه‌های امنیتی استفاده کنید. همچنین امکان پیکربندی بروزرسانی‌های بدون نیاز به تداخل برای سرور Debian / Ubuntu Linux با استفاده از دستور apt-get/apt نیز وجود دارد:

$ sudo apt-get install unattended-upgrades apt-listchanges bsd-mailx

نحوه پیکربندی apticron:

برای استفاده از apticron در سرور Debian/Ubuntu Linux و ارسال اطلاعیه‌های امنیتی، می‌توانید مراحل زیر را دنبال کنید:

1. نصب apticron: ابتدا باید برنامه apticron را در سیستم خود نصب کنید. برای این کار، از دستور زیر استفاده کنید:

sudo apt-get install apticron

2. پیکربندی apticron: پس از نصب، باید فایل تنظیمات apticron را پیکربندی کنید. فایل پیکربندی برای apticron در مسیر /etc/apticron/apticron.conf قرار دارد. باز کنید و ویرایش کنید:

sudo nano /etc/apticron/apticron.conf

3. تنظیمات ایمیل: در فایل تنظیمات، بخشی با عنوان EMAIL وجود دارد. در این بخش، آدرس ایمیل خود را به جای [email protected] قرار دهید. برای مثال:

EMAIL="[email protected]"

4. تنظیمات بسته‌های اطلاعیه‌های امنیتی: در فایل تنظیمات، بخشی با عنوان PACKAGE_NAMES وجود دارد. در این بخش، باید نام بسته‌هایی که می‌خواهید اطلاعیه‌های امنیتی آنها را دریافت کنید را مشخص کنید. برای مثال:

PACKAGE_NAMES="apache2 mysql-server php"

5. ذخیره و بستن فایل تنظیمات: پس از اعمال تغییرات، فایل را ذخیره کنید و ببندید

#linux
#hardning

@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