وب سایت کانال https://codecrafters.ir

لیست هشتک‌ها در کانال رو در زیر براتون خواهم گذاشت و آپدیت خواهد شد


#design_patterns الگوهای طراحی

#postgresql پستگرس

#k8s کوبرنتیز

#agile اجایل
#scrum

#algorithm الگوریتم

#video

#meeting متینگ‌

#principles اصول کدنویسی

#project_managment_system مدیریت تیم

#free خارج از مبحث کامپیوتر


#app برنامه‌های کاربردی

#Git #actions مباحث مربوط به گیت و گیتلب

#conda #env کار با

#Docker مباحث مربوط به داکر

#AI #ML مباحث هوش مصنوعی

#book معرفی کتاب

#monitoring بررسی وضعیت سیستم و کد

#concurrency همزمانی کتاب grokking concurrency


#blovkchain #web3

#DDD #domain_driven_design

#BDD #behavior_driven_development

#soa #sso #microservice


@Code_Crafters

Git Hub:
https://github.com/CodeCrafters-ir/

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

در این پست پست‌های با تگ soa# راجب این موضوع حرف میزنیم و مثالهایی برای اون خواهیم گفت تا دیدگاهمون نسبت بهش بازتر بشه و شناخت دقیقتری ازش داشته باشیم

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

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

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

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


1-سیاست‌های پایه

1-1 سیاست پایه زمان طراحی (design-time policies):

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

۲-استانداردسازی فناوری:
این سیاست چیزی شبیه به این است که: "همه خدمات ارائه شده به عموم مردم، به عنوان مثال، از طریق اینترنت، باید از الگوی REST پیروی کنند.خدماتی که منحصراً برای اهداف B2B ارائه می شوند باید از معماری WS-* استفاده کنند." این یک سیاست اساسی است، اما سیاستی است که مانع از آن می‌شود که طراحان پروژه‌ها آنچه را که فکر می‌کنند بهترین است بدون نگاه کردن به شمای بزرگ‌تر انجام دهند.


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

1-2 سیاست‌های پایه زمان اجرا (runtime policies):

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

۲-صداکردن (تماس) سرویس‌ها باید در یک کانال امن صورت گیرد:
یکی دیگر از سیاست‌های اساسی برای شروع میتواند این مورد باشد، اگر قرار است ارتباط سرویس‌ها در یک بستر امن صورت گیرد این میتواند یک مورد مناسب باشد، برای مثال جهت اجرای این سیاست ارتباطات میتوانند توسط Apache اجرا کنید

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

ما سیاست‌های پایه خودمون رو مشخص کردیم حال به سراغ سیاست‌های دسته‌بندی میریم و اونهارو بررسی میکنیم


#microservoce
#soa

@code_crafters

2-سیاست‌های دسته بندی شده

2-1سیاست های طراحی و مستندسازی

۱- مستندسازی سرویس‌های خود را ایجاد کنید:
تمام سرویس‌ها باید مستندسازی شوند.  شما باید بتوانید بدون نیاز به بررسی دفترچه راهنما از یک سرویس استفاده کنید

۲-استفاده مجدد از استانداردهای تبادل داده (پیام)  موجود:
اگر یک مدل استاندارد یا واقعی وجود دارد که در سازمان یا دامنه تجاری شما استفاده می شود، باید از آن مدل در سرویس خود استفاده کنید.(برای مثال استفاده از REST برای کاربران نهایی و WS-* برای تجارت بین سازمانی، شماتیک json مشخص در خروجی)

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

۴-پشتیبانی از چندین نسخه از سرویس:
 پشتیبانی از چندین نسخه از یک سرویس در کنار یکدیگر باید امکان پذیر باشد.تغییرات در نسخه ها باید تا حد امکان بر مصرف کننده تأثیر بگذارد.

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

۱-رمزنگاری کانال ارتباطی برای داده‌های حساس:
تمامی ارتباطات با سرویس شما باید در یک کانال امن صورت بگیرد

۲- تایید یکپارچگی و عدم انکار پیام:
 باید مطمئن شوید که می‌توانید یکپارچگی و منشأ داده‌های پیام را تضمین کنید.(برای مثال ارسال مشخص امضا شده دو طرفه، استفاده از گواهینامه‌های اعتبارسنجی، در برخی از پروتکل‌ها مانند ws-secureconversion این امکان بصورت فیچر وجود دارد)

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

۴-استفاده از یک سیستم هویت متمرکز برای مجوزها:
 مجوز مورد استفاده همه سرویس‌ها می باشد.برای جلوگیری از اجرای این مورد برای هر سرویس به طور جداگانه، باید از یک سیستم هویت و مجوز متمرکز استفاده کنید.

2-3موارد تست و کارایی

۱-پردازش پیام در ۱۰ ثانیه:
یک سرویس همیشه باید در کمترین زمان ممکن پاسخ دهد

۲-مانیتور سرویس بموقع(real time):
اگر می خواهید خدمات خود را به طور موثر نظارت کنید، باید بتوانید عملکرد را در زمان واقعی اندازه گیری کنید.

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

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

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

در سازمان خود اگر برای بخش‌هایی از سیاست‌ها ابزار خاصی مدنظر دارید در داخل سند ارائه شده مطرح کنید برای مثال:

در بخش مانیتورینگ از graphana telegraf یا Prometheus یا BAM استفاده میشود

در بخش کیفیت سنجی و تحلیل کد از sonarqube با sage استفاده میگردد

در بخش تست کدها از end2end یا integration استفاده میگردد

برای بررسی لاگ‌ها ELK استفاده میگردد

برای container orchestrations از k8s استفاده میگردد

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

#microservice
#soa

@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