https://virgool.io/feed/@mmdaz مهندس پایداری سایت در یکتانت fa 2026-06-27 08:43:31 https://files.virgool.io/upload/users/54035/avatar/09Qg8K.png?height=120&width=120 https://virgool.io/@mmdaz https://virgool.io/@mmdaz/%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1%DB%8C%D9%86%DA%AF-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-kyrezebkxknm به نام خدادر این نوشته به بررسی فصل Monitoring Distributed Systems می‌پردازیم.کلا این فصل درمورد تعاریف و best practiceهای مانیتورینگ بحث می‌کنه و کمک میکنه که رصد بهتری از سیستم‌مون داشته باشیم و نهایتا باعث بشه که سرویس‌مون قابل اعتماد بشود.اول از همه یک سری تعاریف مطرح میشود:مانیتورینگ: به طور کلی به جمع‌آوری، پردازش و دسته‌بندی اطالاعات یک سیستم مثل تعداد کوئری‌ها و درخواست‌ها و مدت‌زمان طول کشیدن اون‌ها و ... مانیتورینگ می‌گوییم.مانیتورینگ white-box: این قسمت شامل اطلاعاتی کلی از داخل سیستم میشود. مانند: لاگ‌ها و مصرف منابع (cpu, ram, ...) و مسائلی که برای کاربر نهایی قابل لمس نیستند.مانیتورینگ black-box: این قسمت شامل داده‌های مربوط به رفتار خارجی سرویس که توسط کاربر نهایی قابل لمس است، می‌شود. مانند: ارورها، لیتنسی درخواست‌ها و...داشبورد: یک وب اپلیکیشن که اطلاعات مانتیورینگ ما در آن به صورتی که می‌خواهیم، قابل مشاهده است. و داده‌های روزهای قبل نیز دردسترس است. مثلا grafana یک مثالی از این داشبورد‌ها است.پ-ن: قبلا در نوشته‌ای این که چگونه یک داشبورد گرافانا برای خودمان راه بندازیم را توضیح داده‌ام.آلرت (Alert): یک اعلانی است که از قبل تعیین شده است و حتما توسط یک فرد خاص مورد توجه قرار می‌گیرد.دلیل ریشه‌ای (Root cause): یک عیبی در سیستم است که اگر درست شود، سیستم دیگر از آن‌جا خراب نمی‌شود.حالا یک سوال اساسی مطرح می‌شود.چرا باید مانیتورینگ داشته باشیم؟ دلایل بسیاری بر ضرورت وجود مانیتورینگ وجود دارد که به برخی اشاره می‌کنیم:تحلیل و مقایسه روندهای بلندمدت: یعنی این که بدانیم در طی یک زمان خاص مثلا چقدر رشد کاربر داشته‌ایم؟ سرعت پاسخ‌دادن به درخواست‌هایمان چگونه بوده است؟ آیا بهبود داشته‌ایم یا بدتر شده‌ایم؟ و سوالاتی از این قبیل با داشتن یک مانیتورینگ خوب، قابل پاسخ‌دادن است.سیستم هشدار (Alerting): واضح است که با وجود مانیتورینگ ما می‌توانیم از اتفاقات بد سیستم در لحظه باخبر شویم و اقدامات لازم را انجام دهیم.دیباگ‌کردن سیستم: وقتی مشکلی پیش می‌آید، مانیتورینگ معمولا جزو اولین جاهایی است که به آن رجوع می‌شود. مثلا تاخیر در ریکوئست‌ها زیاده شده است. آیا مصرف رم بالا رفته است؟ cpu چطور؟ ارور داریم یا نه؟ و سوالاتی از این قبیل که از مانیتورینگ به دست‌ می‌آیند، باعث پیدا شدن دلیل ریشه‌ای می‌شوند.انتظارات معقولی از مانیتورینگ داشته باشیم. :دینباید انتظار داشته باشیم که یک سیستم مانیتورینگ تمام مشکلات ما را حل خواهد کرد.هر چه قدر که می‌توانیم، مانیتورینگ را باید ساده نگه داریم. از ابزارهای پیچیده و به قول کتاب، جادویی، استفاده نکنیم و سعی کنیم مفاهیم پایه‌ای که برای سیستم تعریف شده است را پوشش دهیم.همچنین در قانون‌های هشدار (این که چه زمانی برای‌مان هشدار ارسال شود.) باز هم نباید پیچیده باشند و دقیقا مسائلی که با آن‌ها می‌شود فهمید که حال سیستم بد است و کاربر دچار مشکل شده است، کافی می‌باشد.تعداد این هشدارها هم نباید زیاد باشد، چرا که دیگر آن اثربخشی خود را از دست می‌دهند و حالت عادی شدن به خودشان می‌گیرند.علامت‌ها درمقابل دلیل‌هایک سیستم مانیتورینگ باید به دو سوال جوابی داشته باشد: چه چیزی خراب شده است و چرا؟جواب این که چه چیزی خراب شده است به علامت مربوط شده و جواب چرا به دلیل مربوط است.در زیر چند نمونه از علامت‌ها و دلیل‌ها برای یک خرابی داریم:علامت: تعداد درخواست‌های با جواب‌های 500 یا 404 زیاد شده است.دلیل: دیتابیس درخواست‌ها را رد می‌کند.علامت: پاسخ‌ها کند شده‌اند.دلیل: لود cpu بالا رفته است.- تفاوت دلیل و علامت در نوشتن یک سیستم مانیتورینگ خوب خیلی ماثر است.مانیتورینگ Black-Box در مقابل White-Box:تفاوت عمده این دو مورد، در علامت‌گرا بودن black-box و در حالی که white-box هم می‌تواند علامت‌گرا و هم علت‌گرا باشد. از این جهت که در یک سیستم چندلایه، علامت مشکل یک سرویس ممکن است دلیل مشکل یک سرویس وابسته به آن باشد. نهایتا white-box وابسته به قدرت پایش اطلاعات داخل سیستم، مثلا لاگ‌ها و ... است. و باعث فهمیدن مشکلات قریب‌الوقوع و حتی مشکلاتی که با ریترای کردن پنهان شده‌اند، می‌شود.میزان مراجعه white-box بیشتر است. و این جواب را معمولا به ما می‌دهد که چرا مشکل داریم و از این سمت black-box جواب چه چیزی خراب است را به ما می‌دهد.چهار سیگنال طلایی مانیتورینگ:این چهار سیگنال، اصلی‌ترین سیگنال‌های مانیتورینگ هستند و یک مانیتورینگ خوب همه این چهار مورد را پوشش می‌دهد.Latency: مدت زمانی که طول می‌کشد که سرویس یک درخواست را پردازش کرده و به آن جواب بدهد. یک نکته مهم در این جا وجود دارد و آن جدا کردن latency درخواست‌ها موفق و ناموفق است. چرا؟ چون که درخواست‌های ناموفق مانند 404 طولی نمی‌کشند و سریع هستند و باعث تاثیر در سایر داده‌ها شده و منجر به برداشت اشتباه از این قسمت می‌شوند.Traffic:این که در لحظه چقدر درخواست برای یک سرویس وجود دارد و مقدار هر کدام از درخواست‌ها در صورت وجود، چقدر است؟ برای سرویس‌های استریمینگ این تعداد ممکن است حجم داده‌ منتقل شده در لحظه باشد.Errors: سرعت درخواست‌هایی که با خطا مواجه می‌شوند. توجه داشته باشید که این خطاها لزوما شامل مثلا خطاهای 500 نمی‌شوند و بلکه یک پاسخ 200 هم ممکن است خطا تلقی شود. وقتی که دارای محتوای اشتباهی باشد و وقتی مثلا یک قانونی (این که باید یک ثانیه طول بکشد و یک و نیم ثانیه طول کشیده است.) را بشکند.حتی در مواقعی که کدهای کلی‌تر مانند 500 برای توضیح شرایط پیش‌آمده آن‌چنان کافی نیستند، لازم است کدهای خروجی داخلی یک سرویس نیز پوشش داده شوند.حالا مانیتور کردن همه این موارد شاید یکسان نباشد. مثلا فهمیدن پاسخ‌های 500 می‌تواند در مثلا load balancer به راحتی انجام شود. اما فهمیدن درخواست‌های با محتوای اشتباه به این سادگی نیست و در تست‌های end-to-end به دست‌ می‌آیند.Saturation:این که سرویس شما چقدر پر است و تا چقدر می‌تواند دوام بیاورد؟ مثلا ما بدانیم که اگر همین‌ الان مصرف رم دوبرابر شود، سرویس دچار مشکل می‌شود. و دقیقا بدانیم که سرویس ما توانایی پاسخ‌دادن به چند ریکوئست در ثانیه را دارد؟ و چقدر از آن الان پر است؟و ...واقعا لازم نیست کار عجیب‌ و غریبی انجام دهیم! اگر سرویس ما همه این چهار سیگنال را پوشش می‌دهد و در صورت وقوع اتفاقی درآن‌ها هشدار می‌دهد، ما یک مانیتورینگ خوب داریم.*** یک نکته مهم ***:وقتی می‌خواهیم یک سیگنالی مانند latency را اندازه‌ بگیریم، احتمالا اولین سوال این باشد که چه مقداری از آن برای ما مهم باشد؟ و شاید اولین جواب میانگین آن باشد.فرض کنید ما یک وب‌سرویسی داشته باشیم که در هر ثانیه ۱۰۰۰ درخواست را جواب می‌دهد و میانگین latency برابر ۱۰۰ میلی‌ثانیه است. ظاهرا همه چیز خوب است ولی اگر کمی دقت کنیم متوجه می‌شویم که در همین سناریو ممکن است ۱ درصد درخواست‌هایمان بالای ۵ ثانیه طول کشیده باشند!!!مواردی از قبیل مصرف CPU، میزان مشغول بودن Database و ... مقدار مصرف‌شان به صورت نرمال توزیع نشده است و کاملا ممکن است غیرمتعادل باشند.برای این که اینگونه به اشتباه نیوفتیم، می‌توانیم برای مثال همین latency را بر اساس مقدارهای مناسب تقسیم بندی کنیم. مثلا این‌گونه اندازه‌گیری کنیم که چه مقدار از درخواست‌های ما زیر ۱۰ میلی‌ثانیه و چه مقدار بین ۱۰ تا ۳۰ و چقدر بین ۳۰ تا ۱۰۰ و نهایتا چقدر بالای صد داریم. در این حالت نمود واقعی‌تری را از وضعیت سیستم موجود می‌بینیم.وضوح اندازه‌گیری مهم است:این که ما متریک‌های مختلف را با چه وضوح و دقتی اندازه‌گیری کنیم، مهم است.در مشاهده بار پردازنده در بازه زمانی یک دقیقه، احتمالا spikeهایی که باعث افزایش latency می‌شوند برایمان نمایان نشوند. و برعکس برای سیستمی که SLO آن ۹۹٫۹ درصد دردسترس بودن در یک سال است، چک کردن میزان پر بودن هارد هر یک دقیقه یک بار، فرکانسی نیست که لازم باشد.اگر بخواهیم بار پردازنده را در هر ثانیه مشاهده کنیم، ممکن است هزینه این کار زیاد باشد. در این موارد برای کاهش این هزینه‌ها اگر سیستم ما نیازمند مشاهده لحظه‌ای نباشد، می‌توانیم داده‌ها را داخل سیستم جمع‌آوری کنیم و یک سرویس خارجی آن‌ها را جمع آوری کرده و نشان دهد.این قسمت تا اینجا کافی است و در ادامه به بررسی سیستم هشدار و استانداردهای آن می‌پردازیم.اگر نظری هم دارید مانند همیشه مشتاق به شنیدنش هستم. :دی محمد اژدری محمد اژدری Tue, 07 Sep 2021 19:00:56 +0430 https://virgool.io/baleacademy/%D8%AC%D9%84%D8%B3%D9%87-%D9%BE%D8%B3%D8%AA%D9%85%D8%B1%D8%AA%D9%85-%DA%86%DB%8C%D8%B3%D8%AA-xivfqbzorimc در ادامه قسمت قبل، در این نوشته، فصل Postmortem Culture: Learning from Failure را خلاصه و بررسی می‌کنیم.هزینۀ خطا/شکست، یادگیری است!در شرکت‌ها یا سازمان‌ها ممکن است به دلایل مختلف، خطاها و شکست‌هایی رخ بدهد.اما نکتۀ مهم، چگونگی مواجه شدن با این خطاهاست. اینکه آن‌ها را درست کنیم و رهایشان کنیم یا اینکه هر چه می‌توانیم از آن‌ها یاد بگیریم تا جلوی دوباره رخ دادنشان یا حتی رخ دادن خطاهای دیگر را بگیریم.جناب گوگل از این خطاها به‌عنوان incident یاد می‌کند و می‌گوید وقتی حادثه‌ای رخ می‌دهد، ابتدا افراد مربوط به سرویس یا سیستم، آن را به حالت قبلی بدون خطا برمی‌گردانند و سپس، جلسه‌ای با عنوان «پست‌مرتم» تشکیل می‌شود که افراد ذی‌نفع آن سرویس در آن حضور دارند تا دلایل اصلی حادثه،‌ کارهایی که انجام شده تا درست شود و... مشخص و مکتوب شود.با انگشت نشان دادن ممنوع!نکتۀ مهم این است که این جلسه‌ها به‌عنوان یک فرهنگ در گوگل به blame-free postmortem culture معروف است. یعنی کسی حق ندارد دیگران را سرزنش کند یا فرد خاصی را به‌عنوان مسبب خطا نشان دهد؛ بلکه همه به‌دنبال روال غلطی هستند که باعث این اتفاق شده است تا آن را درست کرده، از تکرار مجدد آن جلوگیری کنند.اینجا دو جمله از یک فرد دخیل با سیستم را می‌نویسم و با هم مقایسه می‌کنم:این سیستم بک‌اند واقعاً افتضاح است! در چند هفتۀ گذشته بارها پایین آمده است و اگر اوضاع این‌‌گونه پیش برود، خودم آن را از اول می‌نویسم...در چند هفتۀ اخیر، چند بار سیستم بک‌اند پایین آمده است. شاید بازنویسی این سیستم کمک کند که از این اتفاق‌ها جلوگیری شود. اگر این کار را بکنیم، on-callهای بعدی نیز خوش‌حال خواهند بود. :)تفاوت دو جملۀ بالا کاملاً ملموس است. مشخص است که هرکدام چه جو منفی و مثبتی را ایجاد می‌کند. اصلاً اینکه این جلسات blame-free باشند، خودش چالش است و به تمرین بسیار نیاز دارد.ابتدا کمی جزئی‌تر می‌گوییم که چه زمانی incident رخ داده است؟از اتفاق‌های زیر به‌عنوان incident یاد می‌شود:هر اتفاقی که کاربر احساسش کند!‌ چه پایین آمدن سیستم و چه تجاوز کردن یک متریک مانند latency از یک مقدار معین؛اگر داده‌ای از دست برود؛اگر کسی که on-call است، مجبور شود مداخله کند؛یک زمان خاص که برخی آستانه‌ها رد شده باشند؛کشف حادثۀ دستی (یعنی خطای مانیتورینگ).این موارد کاملاً کلی هستند و شاید حتی برای یک سازمان یکی از این‌ها مهم نباشد و به‌جای آن مورد دیگری مطرح شود. نکته در ماهیت این موارد نیست؛‌ بلکه در وجود آن‌هاست. یعنی حتماً باید از قبل برای یک سرویس مشخص باشد که اگر چه اتفاقی بیفتد، یک incident تلقی می‌شود و باید برایش جلسۀ پست‌مرتم برگزار شود.خود گوگل فرهنگ‌های جذابی برای این جلسات پست‌مرتم دارد:انتخاب پست‌مرتم ماه و تقدیر از آن؛گروه‌های پست‌مرتم‌خوانی که بحث‌های مربوط به این جلسات در آنجا رخ می‌دهد.در ادامه، به ساختار و مناسک جلسه‌های پست‌مرتم می‌پردازیم:یک Template از داکیومنت را با هم بررسی می‌کنیم:ـ تاریخ وقوع؛ـ نویسندگان؛ـ وضعیت فعلی: وضعیتی که سرویس در حال حاضر در آن قرار دارد؛ـ خلاصۀ حادثه؛ـ تأثیر حادثۀ مزبور: مثلاً n کاربر نتوانستند از ما سرویس بگیرند؛ـ دلایل ریشه‌ای: چه چیزهایی باعث این حادثه شد. نکتۀ مهم این است که این دلایل باید قابلیت ایجاد مجدد را داشته باشند؛ـ چگونگی اطلاع: مثلا سرویس Alerting بالا رفتن Latency را هشدار داد و مهندس on-call وارد عمل شد؛ـ ابعاد حادثه: اینکه حادثه در چه حدی بزرگ یا کوچک بوده است؛ـ کارهایی که باید انجام شود: برای اینکه این حادثه یا حوادث مشابه آن دیگر تکرار نشود، چه کسی چه کاری را انجام دهد (کارهای مختلف به افراد مختلف اساین می‌شوند).ـ درس‌هایی که آموختیم:در این قسمت باید به این سؤالات جواب داده شود:ـ نقاط قوتمان کجا بود؟ـ کجا ضعف داشتیم؟ـ کجا خوش‌شانس بودیم؟و در نهایت، یک تایم‌لاین با تاریخ و ساعت از کل اتفاق شرح داده می‌شود.شاید این جلسات در بسیاری از سازمان‌ها نه به‌عنوان پست‌مرتم، بلکه با عنوان‌های دیگر برگزار شوند.ـ حالا سؤال این است که آیا همۀ این مناسک باید انجام شوند؟به قول یکی از دوستان، بودن همین کارهای مشخص، باعث نظم و پیگیری بیشتر این جلسه‌ها می‌شود و در نهایت هم، تأثیر آن‌ها را بیشتر می‌کند.برای تجربه بیشتر، می‌توان نمونه جلسات پروژ‌ه‌های متن‌باز دنیا را بررسی کرد. مانند این مثال از پروژه گیت‌لب:https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/4113خب، این بخش هم تمام شد و در بخش بعدی به سراغ فصل Monitoring Distributed Systems می‌رویم ان‌شاءالله. محمد اژدری محمد اژدری Tue, 08 Dec 2020 12:03:45 +0330 https://virgool.io/baleacademy/site-reliability-engineering-b2tkyudupjb5 ما در تیم سعدی، از تیم‌های قسمت پیام‌رسانی «بله»، جلسات همخوانی کتاب Site Reliability Engineering را برگزار می‌کنیم. اینجا خلاصۀ مطالبی را که می‌خوانیم و یاد می‌گیریم، به‌مرور می‌نویسم.این کتاب را گوگل منتشر کرده است و می‌توان آن را به‌صورت رایگان در لینک بالا مطالعه کرد.(برای اختصار، SRE را هم به‌جای Site Reliability Engineering و هم Site Reliability Engineer به کار می‌بریم. اینکه کجا کدام است، به نظر واضح خواهد بود.)کتاب به‌صورت کلی دربارۀ SRE حرف می‌زند؛ ولی لزوماً به شرح یک عنوان شغلی نمی‌پردازد و شامل توضیح فرهنگ‌های سازمانی و کاری است که نهایتاً هدفش رسیدن به یک سیستم پایدار و مطمئن است.در این قسمت، به خلاصه بخش Introduction کتاب می‌پردازیم.متن را با این سؤال آغاز می‌کنیم: SRE کیست؟در یک جمله، فردی است که از صفر (تولد) تا صد (انتشار و نگهداری) یک نرم‌افزار حضور و نقش دارد. اسم این شغل زیاد واضح نیست و ممکن است افرادی که در این قسمت کار می‌کنند، واقعاً ندانند که کار و رسالتشان دقیقاً چیست.اما حالا کمی جزئی‌تر به بررسی کلمات این موقعیت شغلی می‌پردازیم:اول Engineer:‌ این اشخاص مهندس هستند و طبعاً مهارت‌های یک Computer Engineer و Computer scientist را دارند. یعنی توسعه و طراحی سرویس‌ها جزو کارهایشان است، یا توسعۀ ابزارهایی کمکی برای سایر مهندسان، ازجمله: لودبالانسینگ، بک‌آپ‌گیری و ... .دوم Reliability: مهم‌ترین ویژگی هر محصول، این است که بتوان به آن اعتماد کرد و اگر این ویژگی را نداشته باشد، عملاً به درد نمی‌خورد و موفق هم نمی‌شود. بنابراین، SREها بر این موضوع تمرکز ویژه‌ای دارند و به نوعی اصلی‌ترین و اولویت‌دارترین وظیفۀ خودشان را حفظ reliability سرویس می‌دانند و اگر به این هدف مهم رسیدند، سراغ کارهای دیگر می‌روند.سوم Site: منظور از این کلمه در واقع Service است و دلیل انتخاب این اسم برایش، این است که در اوایل هدف فقط سایت سرچ google.com بوده است؛ به همین دلیل، این اسم مانده است و تغییرش هم نداده‌اند! :) نهایتاً منظور از سرویس همان نرم‌افزارهایی است که در یک سازمان در حال اجرا هستند، مثلاً در گوگل، یوتیوب، م‍پ و... .حالا این سؤال پیش می‌آید که آیا همیشه و در همۀ شرکت‌ها این موقعیت شغلی وجود دارد و باید وجود داشته باشد؟ جواب خیر است. زیرا با توجه به حجم کار و عمر شرکت، ممکن است اصلاً چنین پوزیشنی (position) به‌طور خاص وجود نداشته باشد؛ اما همیشه افرادی هستند که این کارها را انجام می‌دهند و اگر برای آن‌ها اسم بگذاریم و کمی منظمشان کنیم، می‌شوند SRE.از رسالت‌های اصلی این افراد، حذف کردن پروسه‌های انسانی از کارهاست. آن‌ها تا جایی که می‌توانند، همه‌چیز را خودکار می‌کنند و به دست برنامه‌های کامپیوتری می‌سپارند. دلیلش هم مشخص است. یک انسان هرچقدر هم حرفه‌ای باشد، اشتباه می‌کند و ممکن است همین اشتباهش پیامدهای بدی را به همراه داشته باشد.داستان مارگارتدر زمینۀ خودکار‌ کردن، کتاب یک داستان واقعی را از ناسا تعریف می‌کند.فردی به نام مارگارت در ناسا مهندس بوده و کار می‌کرده است. یک روز بچۀ خردسالش را با خودش به سر کار می‌برد. آن زمان در سفینه‌های ارسال فضانوردان به فضا، دکمه‌ای وجود داشت که همۀ اطلاعات برگشت را پاک می‌کرد و برگرداندن آن‌ها به مدارک بخصوصی نیاز داشت.این بچه به‌صورت اتفاقی آن دکمه را در سفینه‌ای که در حال ساخت بوده، می‌زند و این اطلاعات پاک می‌شود. همان‌جا زنگ خطری برای مارگارت به صدا درمی‌آید که مبادا در یک سفر واقعی، این اتفاق بیفتد و فضانوردی که سوار سفینه است، اشتباهی آن دکمه را بزند! بعد این ایده را مطرح می‌کند که این دکمه از دید و دسترس فضانوردان خارج شود تا آن‌ها مرتکب این خطا نشوند؛اما با این ایدۀ مارگارت مخالفت می‌شود. به این دلیل که می‌گویند: «فضانوردان ما آن‌قدر حرفه‌ای هستند که بدانند نباید این دکمه را بزنند!» نهایتاً با اصرارهای وی، یک داکیومنت (document) اضافه می‌شود مبنی بر اینکه اگر به هر دلیلی این دکمه فشار داده شد، برای برگرداندن اطلاعات چه اقداماتی لازم است.نهایتاً در اولین سفری که با این سفینه انجام می‌شود، یکی از همین فضانوردان حرفه‌ای (!)‌ این دکمه را به‌اشتباه فشار می‌دهد و اطلاعات برگشت پاک می‌شود. آن‌ها با مراجعه به همان داکیومنت می‌توانند این خطر را دفع کنند و به زمین برگردند.نتیجۀ داستان واضح است!انسان هرچقدر هم که حرفه‌ای باشد، جایزالخطاست و کسی هم حق ندارد سرزنشش کند. چیزی که برای جلوگیری از این خطا لازم است، از بین بردن نقش انسان در برخی کارهای تکراری است که به هیچ خلاقیت خاصی نیاز ندارند.روش SysAdmin در مدیریت نرم‌افزاراول باید به این سؤال جواب بدهیم که sysAdmin کیست؟ کسانی که کامپوننت‌های مختلف نرم‌افزار را به هم ملحق می‌کنند و نهایتاً سیستم را اجرا می‌کنند.کارهای این افراد بیشتر در زمینۀ راه‌اندازی سیستم است و پاسخ‌ دادن به آپدیت‌هایی که از تیم‌های توسعه می‌آید و خطاهایی که رخ می‌دهد.هرچقدر که لود و استفاده از نرم‌افزار زیاد شود، باید sysAdminهای بیشتری استخدام شوند؛ چراکه لزوماً توسعه‌دهندگان نرم‌افزار، توانایی انجام و دسترسی به تسک‌های این افراد را ندارند و این جایگاه، نیازمند برخی مهارت‌های خاص است.این شیوه همانند همه‌چیز در دنیا، مزایا و معایبی دارد:مزیت‌هامزیتی که این شیوه دارد، جاافتاده شدن آن است. یعنی در دنیای متن‌باز امروزی، برای اکثر کارهای این جایگاه، ابزار خیلی مفیدی توسعه داده شده است و احتمالاً همه‌چیز را می‌توان خیلی سرراست کنار هم چید و به راه انداخت.معایبمعایب این روش را می‌توان در دو روش مستقیم و غیرمستقیم تقسیم‌بندی کرد:مستقیم: همان‌طور که اشاره شد، با اضافه شدن لود و استفاده از سیستم، لازم است افراد بیشتری برای سازمان در این جایگاه استخدام شوند که خب، هزینه ایجاد می‌شود.غیر مسقیم: این مشکل که شاید خیلی ظریف و اتفاقاً خیلی مهم‌تر از مشکل مستقیم است، تعارض منافع تیم توسعه و دوآپس است.تیم عملیات همیشه می‌خواهد یک سیستم پایدار و مطمئن داشته باشد؛ ولی تیم توسعه از طرف دیگر، در تلاش برای توسعه و انتشار نسخه‌های پی‌درپی در محیط عملیاتی است. انتشار و به‌روزرسانی ذاتاً پایداری سیستم را کمتر می‌کند.این عین جملۀ کتاب دربارۀ این تعارض منافع است:We want to launch anything, any time, without hindrance "versus" We won’t want to ever change anything in the system once it works.بنابراین تیم عملیات در برابر این تغییرات مقاومت می‌کنند. مثلاً شرایطی را وضع می‌کنند که قبل از هر انتشار باید انجام شود و... .اما رویکرد SRE این موضوع را تا حد زیادی حل می‌کند. چگونه؟همان‌طور که گفتیم، یک SRE در واقع کسی است که هم مهارت‌های Dev-Opsی و هم مهارت‌های مهندسی دارد و هم در توسعه و هم در نگهداری نرم‌افزار نقش دارد؛ اما گوگل می‌گوید این دو به‌طور مساوی انجام می‌شود. یعنی یک SRE، پنجاه درصد وقت خود را برای کارهای عملیاتی و بقیه را برای توسعۀ نرم‌افزار می‌گذارد.یعنی اگر کارهای عملیاتی به‌قدری زیاد شد که این پنجاه درصد را رد کرد، آن کارها به توسعه‌دهنده‌ها اساین (assign) می‌شود و همین باعث می‌شود که آن‌ها هم با این‌جور کارها درگیر شوند و همین تعارض در ذهنشان کم‌رنگ‌تر بشود.یک مزیت این روش تولید یک سرویس پایدار است، چون کسی که تفکر و مهارت عملیاتی دارد، در توسعۀ آن نقش داشته است.برخی استانداردها را این‌گونه بیان می‌کند که وقتی یک SRE، هشت تا دوازده ساعت on-call است، حداکثر دو و حداقل یک ایونت برایش اساین شود.حالا ایونت (event) چیست؟ منظور خطایی است که رخ می‌دهد یا اتفاقی غیرعادی است که می‌افتد و باید با در نظر گرفتن اولویت‌ها درست شود. مثلاً یک سرویس داون (down) می‌شود یا لیتنسی (latency) یک سرویس افزایش پیدا می‌کند و... .حالا بعد از دریافت این ایونت (event)، آن شخص موظف است پس از رفع آن، جلسۀ پست‌مرتمی (postmortem) برایش تشکیل دهد و مکتوبش کند.در چه شرایطی جلسه پست‌مرتم برگزار می‌شود؟وقتی اتقاق بدی می‌افتد! حالا چه این اتفاق را سیستم آلرت، هشدار داده باشد چه انسانی فهمیده باشد. اتفاقاً این دومی خیلی مهم‌تر است؛ زیرا این اتفاق گپی در سیستم نظارت و هشدار شما را نشان می‌دهد که آن هم باید پیدا شود.فرهنگ خوبی در گوگل وجود دارد که وقتی اتفاقی می‌افتد، کسی دنبال مقصر آن نیست؛ بلکه جلسه‌ای تشکیل می‌شود که افراد ذی‌نفع آن محصول یا سرویس در آن حضور دارند و دلیل ریشه‌ای آن پیدا و مطرح می‌شود و کارهایی به افراد مربوط اساین می‌شود که دیگر این اتفاق نیفتد.اصطلاح قشنگی که گوگل برای این فرهنگ به کار می‌برد، blame-free postmortem culture است.یعنی قرار نیست کسی سرزنش شود و اصلاً کسی هم حق ندارد یکی را با انگشت نشان دهد که فلانی مسبب این اتفاق شد؛ بلکه باید دنبال درست کردن ساختاری باشد که از تکرارش جلوگیری شود.یک فصل از کتاب به پست‌مرتم اشاره می‌کند که ان‌شاءالله در نوشتۀ‌ بعدی به آن خواهم پرداخت.حالا آن‌قدر گفتیم، ولی خود گوگل اعتراف می‌کند که چون تفکر SRE تفکر جدیدی است، هنوز قابلیت توسعۀ فرهنگی و فنی دارد و اتفاقاً این کار در حال انجام شدن است! اینکه این افراد چه مهارت‌هایی داشته باشند، چگونه جذب بشوند و چگونه با سایر افراد شرکت رابطه داشته باشند، چالش‌هایی است که یک سازمان دارای این فرهنگ با آن روبه‌روست.در همین فرهنگ رابطۀ تیم عملیات و توسعه، گوگل در این تفکر یک فرهنگ قشنگ دیگر هم دارد و آن بودجۀ ارور است. یعنی اگر در دسترس بودن یک متریک برای سرویس تعریف شود، لزوماً هدف آن را ۱۰۰ نمی‌گذارند و مقداری از آن‌را، مثلاً ۰.۰۱ به‌عنوان بودجه‌ای در نظر می‌گیرند که تیم توسعه حق دارد در سیستم خطا ایجاد کند و این در دسترس بودن را پایین بیاورد.اما حالا چرا هدف ۱۰۰ نیست؟ خود گوگل که سرویس‌های همیشه پایداری دارد، می‌گوید که وقتی اینترنت و شبکه و همه راه‌هایی که کاربر شما باید طی کند تا به سرویس شما برسد، ۱۰۰ نیست بلکه خیلی کمتر است، ۱۰۰ بودن شما را کسی متوجه نمی‌شود!این بودجه در یک محصول با مشورت مدیر محصول و بر اساس لاجیک و بیزینس آن و اینکه کاربر در چه حالتی خوش‌حال است، تعریف می‌شود.این خلاصه اینجا پایان می‌یابد و امیدوارم برایتان مفید باشد.امیدوارم در نوشتۀ بعدی سراغ جلسۀ پست‌مرتم بروم و این فصل از کتاب را برایتان خلاصه کنم. محمد اژدری محمد اژدری Sat, 21 Nov 2020 18:48:51 +0330 https://virgool.io/@mmdaz/%D8%A7%D8%B1%D8%AA%D8%A8%D8%A7%D8%B7-%D8%A8%DB%8C%D9%86-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3%D9%87%D8%A7-wbf5glxq3xmg قسمت دوماگر قسمت اول را خوانده‌ باشید، درمورد تعریف و معرفی معماری میکروسرویس‌ها حرف‌ زده‌ام.در این قسمت به نحوه ارتباط بین میکروسرویس‌ها می‌پردازیم.این موضوع که سرویس‌هایی که در یک سیستم کار می‌کنند باید باهم در ارتباط باشند، امری بدیهی است. اما به طور کلی این ارتباط انواع و الگوهای خودش را دارد و لزوما هیچ‌کدام بر دیگری برتری نداشته و هر کدام بدی‌ها و خوبی‌های خود را دارند. نهایتا با تشخیص معمار نرم‌افزار که برحسب نیاز سیستم است، انتخاب و پیاده سازی می‌شوند.به طور کلی ارتباط بین میکروسرویس‌ها از دو جنبه مختلف تقسیم‌بندی می‌شوند:تقسیم‌بندی اول:ارتباط‌های همگام (Synchronous)در حالت همگام، نحوه ارتباط به صورت request/response می‌باشد. سرویس‌ها براساس پروتکل‌هایی که توسعه داده شده‌اند، با هم ارتباط میگیرند. مثلا REST, Grpc, Graphql, ...بدین صورت که یک سرویس در نقش کلاینت و سرویس دیگر در نقش سرور عمل می‌کنند. نکته مهم در این حالت این است که کلاینت منتظر جواب درخواستی که به سرور زده است می‌ماند و دیتایی که در جواب است، برایش مهم است. بنابراین در هنگام درخواست بلاک می‌شود.ارتباط‌های ناهمگام (Asynchronous)در این حالت نحوه ارتباط دو گونه است:به صورت request/response: که در این صورت کلاینت بازهم به همان روش‌های گفته شده در حالت قبل درخواست خود را به سرور ارسال می‌کند، ولیکن منتظر پاسخ نمی‌ماند و ادامه روندش را دارد. مثال‌های ضمنی این حالت اجرای یک دستور یا نوتیفیکیش در سرویس مقصد است که موفقیت یا عدم آن برای کلاینت اهمیتی ندارد.به صورت Publish/subscribe: در این حالت یک Message Broker بین کلاینت و سرور قرار می‌گیرد و کلاینت پیام‌ها یا ایونت‌های خود را در آن publish کرده و سرور که روی آن subscribe کرده است، آن‌ها را خوانده و پردازش موردنظر خود را روی‌شان انجام می‌دهد. در این حالت نیز کلاینت بلاک نشده و پیام خود را انتشار داده و به کار خود ادامه می‌دهد.تقسیم‌بندی دوم:ارتباط‌های یک به یک (one-to-one)در این حالت یک سرویس با یک سرویس ارتباط می‌گیرد و می‌تواند هم همگام و به صورت request/response باشد و هم ناهمگام که باز هم یا request/response یا به صورت Publish/subscribe باشد.ارتباط یک به یک در حالت ناهمگامارتباط‌های یک به چند (one-to-many)در این نوع از ارتباط، دیگر مرسوم نیست که از حالت همگام و request/response استفاده شود. چرا که یک سرویس می‌خواهد با چند سرویس همزمان ارتباط برقرار کند. در این حالت، روش Publish/subscribe مناسب می‌باشد. به این صورت که سرویس مبدا، پیام خود را در Message Broker انتشار می‌دهد و سرویس‌های مقصد، هر کدام برحسب نیازشان پیام‌ها را خوانده و استفاده می‌کنند. توجه داشته باشید که این ارتباط هم می‌تواند به با یک Message Broker و هم میتواند با چند Message Channel صورت بگیرد. که هر کدام مزایا و معایب خودشان را دارند.دو نوع ارتباط یک به چندحالا برخی (نه همه) مزایا و معایب انواع ارتباطات گفته شده به صورت نکته‌وار می‌پردازیم.به صورت کلی برای دردسترس بودن (availability) بیشتر سیستم توصیه به استفاده از حالت ناهمگام در نحوه ارتباط‌ها توصیه ‌می‌شود. چرا که در حالت همگام اگر یک سرویس از دسترس خارج شود، عملا کار سرویس کلاینت که منتظر جواب درخواستش است مختل شده و از دسترس خارج می‌شود. ولی در حالت ناهمگام این اتفاق نیوفتد و یک سرویس در درسترس نباشد و سرویس دیگر کار خودش را انجام دهد.یکی از معایب ارتباط یک به چند در حالتی که از Message Broker استفاده می‌شود، این است که ممکن است این MB به یک گلوگاه تبدیل بشود و از دسترس خارج شدن آن باعث مختل شدن کار همه سرویس‌هایی که به آن وابسته هستند بشود.در حالتی که شما از Message Broker استفاده می‌کنید، پیام‌هایی که در آن انتشار داده می‌شوند، تا زمانی که خوانده نشوند. (این قوانین در MBهای مختلف متفاوت است.) حفظ می‌شود و عملا اگر سرویس استفاده کننده پیام‌ها از دسترس خارج شود و دوباره برگردد دیتایی را از دست نداده است. ولیکن اگر همین اتفاق برای حالت همگام اتفاق بیوفتد، یعنی درخواست از کلاینت ارسال شود و با ارور مواجه شود، یا سرور اصلا در درسترس نباشد، دیگر دیتا از بین رفته و قابلیت برگشت وجود ندارد. مگر اینکه در کلاینت نگه‌داری شود که اصلا توصیه به این کار نمی‌شود.در حالت Messaging شما از انعطاف‌پذیری خوبی برخوردار هستید. چون پیام‌ها ساختارهای متنوعی می‌توانند داشته باشند و حتی یک پیام می‌تواند توسط چند سرویس خوانده شده و استفاده شود.یکی از چالش‌های اصلی مطرح شده در حالت Messaging و ناهمگام وجود دارد، مدیریت خطاها و تراکنش‌هایی هست که اتفاق می‌افتد. مثلا رایت‌های دیتابیس و تغییراتی که ممکن است در یک سرویس اتفاق بیوفتد ولی در سرویس بعدی ادامه این کار انجام نشود و این سرویس متوجه آن نمی‌شود. برای این قضیه پترن‌هایی مانند Saga طراحی و مطرح شده است که انشالله در یک پست مجزا بررسی می‌شود.امیدوارم برایتان کاملا مفید بوده باشد. و این نکته که این مقاله‌ها کاملا جنبه معرفی اجمالی دارند و اگر دوست دارید بیشتر عمیق شوید حتما کتاب‌هایی من جمله Microservices Patterns که نوشته‌های من هم اقتباس شخصی‌ام از این است را مطالعه نمایید. محمد اژدری محمد اژدری Wed, 09 Sep 2020 17:19:45 +0430 https://virgool.io/@mmdaz/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3%D9%87%D8%A7-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-tobr25bsyblg این نوشته برداشت‌های شخصی من از کتاب Microservices Patterns است.خیلی وقت هست که دوست داشتم این متن رو منتشر کنم و متاسفانه فرصتی پیدا نمی‌کردم.اما بالاخره امروز تصمیم گرفتم شروعش کنم.میکروسرویس، واژه‌ای که این روزها شاید در اکثر شرکت‌های تکلونوژی دنیا اسمش شنیده می‌شود.در این نوشته به تعریف این معماری از منظر خودم و مزایا و معایب آن می‌پردازم و در نوشته‌های بعدی جزئیاتی را هم در این باره منتشر می‌کنم.من به موجودیتی سرویس می‌گویم که به تنهایی قابل توسعه، دیپلوی، تست و scale باشد.برخلاف اسمش که میکرو در آن وجود دارد، هیچ‌وقت این تصور را نداشته باشید که یک سرویس هر چه قدر کوچک‌تر باشد بهتر است.خب حالا سوالات اساسی:چرا میکروسرویس؟فرق معماری میکروسرویس‌ها با معماری مونولوتیک چیست؟خب بدیهی‌ترین فرق این است که در معماری مونولوتیک، یک سیستم از یک سرویس تشکیل شده است ولی در معماری میکروسرویس‌ها از چند سرویس.حالا برخی مزایای مهم معماری میکروسرویس‌ها را بیان می‌کنم:ابتدا از تعریفی که ارائه دادم شروع میکنم و کمی توضیحش میدهم:هر سرویس به تنهایی قابل توسعه دادن است! شاید بگویید مگر در بقیه حالت‌ها قابل توسعه نیست؟ در جواب باید بگویم که بله در برخی حالت‌ها اگر در زمان مناسبش اقدام درستی انجام نشود سرویس توانایی توسعه‌اش را از دست می‌دهد. حالا چگونه؟فرض کنید که سیستم خیلی بزرگ دارید و چند تیم روی‌ آن کار می‌کنند. حالا زیاد هم نگوییم مثلا سه تیم پنج نفره. هر چقدر هم کد یک پروژه تمیز باشد و وابستگی در آن کم باشد، یک برنامه‌نویس چون یک آدم است، می‌تواند اشتباه کند و اگر جایی اشتباه کند همین اشتباه او باعث کرش در سیستم شده و کل مجموعه را از کار می‌اندازد. و از جنبه دیگر، وقتی با یک سرویس سر و کار دارید و یک برنامه‌نویسی باشید که تازه به آن مجموعه اضافه شده‌اید شاید سال‌ها طول بکشد که از همه‌ جای آن سر در بیاورید و عملا نمی‌توانید توسعه خاصی روی آن انجام دهید. ولی اگر این سیستم به چند سرویس شکسته شده باشد شما در یک تیم مجزا به توسعه سرویس خودتان می‌پردازید. و با بقیه کاری ندارید. :)هر سرویس به تنهایی قابل دیپلوی کردن است.همین سرویس بزرگ قبلی را تصور کنید، شما یک کامیت روی برنچ مستر انجام می‌دهید. در بهترین حالت احتمالا دو روز طول بکشد که کدی که شما زده‌اید بر روی نسخه پروداکشن اجرا شود. به نظرتان زمان خوبی است؟ اگر کدی که شما زده‌اید فقط یک خط باشد چه؟ واقعا فاجعه‌ است! اما در میکروسرویس فاصله مرج تا دیپلوی می‌تواند حتی کمتر از یک دقیقه باشد. این یعنی چابکی به معنای واقعی کلمه. :)هر سرویس یه تنهایی قابل تست کردن است.شما یک کدی میزنید و انتظار دارید کارایی که می‌خواهید را داشته باشد و حتی برایش تست هم نوشته‌اید. اما از کجا می‌دانید که کد شما قسمت‌های مختلفی که سایر تیم‌ها روی آن‌ها کار می‌کنند تاثیر نمی‌گذارد آن‌ها را خراب نمی‌کند و برعکس. اما در میکروسرویس شما توسعه را در سرویسی که برای خودتان است پیش می‌برید و تست‌های خودتان که پاس شد روی نسخه عملیاتی اجرایش میکنید. و حتی اگر خراب هم شود فقط روی این سرویس تاثیر می‌گذارد و کل سیستم مختل نمی‌شود.هر سرویس به تنهایی scale کردن است.در حالت مونولوتیک اگر بار روی سرویس‌تان زیاد شود و بخواهید آن را حالا با هر روشی scale کنید، مجبور هستید برای همه سیستم این کار را انجام دهید. و این در حالی است که احتمال زیاد همه قسمت‌های آن مثلا همه apiها، بار زیادی ندارند و فی‌الواقع نیازی نیست که scale شوند.ولی در معماری میکروسرویس‌ها شما می‌توانید هر سرویس را به طور جداگانه و در حد نیازش scale کرده و خروجی خوبی را به کاربران خود بدهید.کلا معماری میکروسرویس‌ها نکته‌های خوب زیاد دارد که در این حجم از کلام نمی‌گنجد و همین کتابی که اول نوشته معرفی کردم یکی از منابع خوب برای شناختن هر چه بهتر آن است.اما در میان مزایا، این معماری مانند هر چیز دیگری معایبی را دارد. که به نظر من مهم‌ترین آن‌ها پیچیدگی است که به مجموعه اضافه می‌کند. از این جهت که اگر یک کسب و کار نوپا در همان اول کار دنبال میکروسرویس بودن باشد احتمال زیاد هم وقت زیادی صرف می‌کند و هم خطاها و شکست‌هایی در پی خواهد داشت. مهم‌ترین نکته در بین مرز معماری میکروسریس‌ها و مونولوتیک، شناختن و درک عمیق زمان درست مهاجرت از مونولوتیک به میکروسرویس‌ها است که اگر این زمان درست انتخاب شود، اتفاقات خوبی‌ را برای یک کسب و کار نوپا از نظر فنی رقم می‌زند.خب این نوشته را اینجا تمام می‌کنم با این نکته که چیزی که خواندید: اقتباسی از کتاب اشاره شده که آکنده از نظرات و تجربه‌ها و برداشت‌های شخصی من بود. و مثل همیشه مشتاق شنیدن نظرات و پیشنهادات هستم.انشالله در نوشته‌های آینده در این معماری ریز می‌شوم و درباره نحوه ارتباط بین سرویس‌ها و نقش دیتابیس و نحوه‌ جداسازی و مهاجرت و ... حرف می‌زنم. محمد اژدری محمد اژدری Sun, 23 Aug 2020 17:57:12 +0430 https://virgool.io/@mmdaz/%D8%B3%D9%87-%D8%A8%D8%A7%D9%84-scalability-ywzrsnvh7xr1 به نام خدادر کتاب Microservices Patterns With Example وقتی میخواهد معماری میکروسرویس را تعریف کند به نقل از کتاب The Art of Scalability میگوید:تعریف میکروسریس از three-dimensional scalability model (مدل سه بعدی مقیاس پذیری) الهام گرفته شده است.در اینجا به توضیح سه محور این مکعب میپردازیم:محور xها: معمول ترین روش scale کردن یک نرم‌افزار را بیان میکند. به نحوی که چند نمونه (instance) از app بالا می‌آید و یک لودبالانسر سر راه درخواست ها قرار میگیرد تا آن‌ها را بین instance های مختلف پخش کند.محور z‌ها: در این روش هم مانند روش قبل چند instance بالا می‌آید و یک لودبالانسر وجود دارد. فرقش این است که پخش شدن درخواست ها بر اساس نوعشان است. برای مثال سه سرویس بالا آماده و درخواست ها براساس حرف اول نام کاربری افراد یا عدد یکان ID آنها در دیتابیس و یا چیزهای دیگر بین آنها تقسیم میشوند.دو روش بالا برای ظرفیت و دردسترس بودن برنامه را بهبود میدهند. اما هیچ یک از این رویکردها مشکل افزایش توسعه و پیچیدگی کاربردها را حل نمی کند. بنابراین سراغ محور y می‌رویم که functional decomposition نام دارد و براساس برنامه را براساس عملکرد قسمت های مختلف scale میکند.در این نمودار کاملا چگونگی کار مشاهده میشود:نویسنده می‌گوید تعریف معماری میکروسرویس‌ها چیزی شبیه این قسمت از scale هست. یعنی شکستن یک برنامه بزرگ به برنامه‌های کوچک براساس عملکردهایی که دارند و در ادامه به صورت اجمالی به ویژگی‌های معماری میکروسرویس‌ها میپردازد و در هر فصل آنها را بررسی میکند. من هم اگر فرصت شد سعی میکنم خلاصه هر فصل را در یک نوشته جداگانه انتشار دهم. امیدوارم که مفید بوده باشد و مثل همیشه از کامنت‌ها و انتقادها و پیشنهادها استقبال میشود. محمد اژدری محمد اژدری Tue, 26 May 2020 20:52:08 +0430 https://virgool.io/@mmdaz/%D9%84%D8%A7%DA%AF-%D8%A7%D9%86%D8%AF%D8%A7%D8%AE%D8%AA%D9%86-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-%D8%AF%DB%8C-xbmc44baolzp اول از همه میخوام درمورد خود لاگ حرف بزنم. ما ها هر برنامه ای که مینویسیم اینجوریه که باید همیشه یک سری اطلاعات از اون رو بدیم بیرون که بفهمیم الان داره چه اتفاقی میافته ؟ اصلا برنامه کار میکنه ؟ ارور خورده یا نه ؟ اگه ارور خورده چه اروری خورده ؟و کجا این اتفاق افتاده ؟اینجوری بگم که حجم کد که از یه حدی بزرگتر بشه، اگه اشکالی به‌ وجود بیاد عملا بدون دیدن لاگ ها نمیشه کاریش کرد و فهمید اشکال کار کجاست :(پس در واقع لاگ انداختن یکی از شیوه های دیگه‌ی مانیتورینگه ک قبلا یه دونش رو گفتیم.خب لاگ رو کی تولید میکنه ؟ معلومه ما (برنامه نویس) باید وقت هایی که احساس میکنه اینجا باید یک چیزی لاگ بشه باید اونجا این کار رو انجام بده.دیگه نمیخوام زیاد وارد جزئیات بشم ولی لازم میدونم چند تا نکته رو همینجا بگم - شاید اصلا بعدا یک نوشته خصوصا برای چجوری لاگ خوب بندازیم رو بنویسم - :سطح های لاگ ها:لاگ ها سطح بندی دارن و اینجوریه که توی هر موقعیت باید لاگ مربوط به اون رو بندازیم. و میتونیم به سیستم لاگینگ‌مون بگیم که کدوم سطح از لاگ ها رو میخوایم ببینیم. این سطح ها عموما به ترتیب debug و info و error و critical هستن. (البته سطح های warning , exception هم هستن که من کم دیدم استفاده بشن.) این سطح هایی که گفتم از راست به چپ به ترتیب با اهمیت تر میشن. (چون عموما حجمشون خییلیه) سطح debug: معمولا همه مراحله های یک برنامه رو روی سطح debug میندازیم و این سطح رو معمولا توی مرحله توسعه و دیباگ و اینجور مواقع به کار میبرن و توی مرحله production این رو غیرفعال میکنن.سطح info : مرحله بعدی info هستش که اطلاعات مهم تری رو شامل میشه و برنامه نویس لازم میدونه که توی این سطح لاگ بشن و هی بتونه ببینه اون ها رو. سطح error: توی این مرحله همونجوری که از اسمش پیداست، خطاهای برنامه لاگ میشن و باید مشخص بشه که چی بوده و از کجا و حتی از کدوم خط از کد بوده.سطح critical : این سطح دیگه خطرناک ترین اتفاق های ممکن رو لاگ میکنه، مثلا میدونیم که اگه فلان اتفاق بیافته کل سیستم به فنا میره و از کار می‌افته، اونجا یه دونه از این ها میندازیم و روی این ها خیلی حساسیم که اگه دیدیمشون سریع باید یه کاری بکنیم.خب تا الان احتمالا به اهمیت لاگ پی برده ایم و قانع شدیم که باید باشن.کلا اگه بخوام یک تصور راحت بهتون بدم اینه که دیدید وقتی یک کدی رو داریم میزنیم و یه ایرادی داره اولین راهی که به ذهنمون میرسه میریم و چند تا پرینت توی قسمت های مختلف از برنامه میذاریم که ببینیم چه اتفاقی داره میافته و ایراد رو پیدا کنیم. لاگ کردن میشه حالت پیشرفته این کار که صرفا به قصد دیباگ کردن و فهمیدن خطا نیست و حتی بعدا میشه تحلیل های بیزینسی و آماری جالبی روی لاگ های برنامه کرد و چیز های جالبی از اون ها فهمید.به جرئت میتونم بگم که همه زبون های برنامه نویسی logger دارن برای خودشون و با یک سرچ ساده که مثلا توی پایتون چجوری لاگ بندازیم ؟ میتونیم ببینیم چجوری دارن کار میکنن. (بازم اگر شد میام و درمورد لاگ انداختن توی زبون های معروف حرف میزنم.)نکته بعدی اینه که لاگ ها معمولا یک سری فرمت هایی هم دارن که کاملا بستگی مستقیم به برنامه نویس اون سیستم داره. مثلا اینکه تاریخ و ساعت و کجا باشه و این ها،‌ این یک مثال ساده از لاگ لایبرری echo توی زبون Go هستش:{&quotlevel&quot:&quotinfo&quot,&quotmsg&quot:&quot⇨ http server started on [::]:8000&quot,&quottime&quot:&quot2018-12-28T09:39:31Z&quot}حالا یک مسئله ای پیش میاد و اونم اینه که الان برنامه من داره کار میکنه یک مشت لاگ رو داره میده بیرون و خیلی هم زیاد هستن و فی الواقع باید گفت یا ابلفضل : دیخب این ها رو یه جوری باید مدیریت کرد و برای این روش های مختلفی وجود داره، ابتدایی ترین اون ها اینه که به کدمون بگیم روی همون کنسولی که روش اجرا شده یا یه مرحله بریم جلو تر رو یک سری فایل ذخیرشون کنیم و بعد دییتابیس و این داستانها. اما همه این ها (که بعضی هاشون لازمن و باید باشن بعضا) مشکلاتی دارن. مثلا یک مشت لاگ داریم که توی یک مشت فایله، سرچ توی اون ها و کلا مدیریتش هزینه (زمان) بره. یک سری ابزار ها هستن که اینکار رو برای ما راحت تر میکنن و گری‌لاگ یکی از اون ها هستش. که برای طولانی نشدن مطلب توی نوشته بعدی بهش میپردازم. محمد اژدری محمد اژدری Sun, 15 Dec 2019 14:50:03 +0330 https://virgool.io/baleacademy/%DA%86%DA%AF%D9%88%D9%86%D9%87-%DA%AF%D8%B1%D8%A7%D9%81%D8%A7%D9%86%D8%A7-%D8%A8%D8%A7%D9%84%D8%A7-%D8%A8%DB%8C%D8%A7%D8%B1%DB%8C%D9%85-cqrwpw3z61da قبل از اینکه این نوشته را بخوانید، اکیداً توصیه می‌کنم که متن قبلی‌ام را دربارۀ کلیات مانیتورینگ و پرمتئوس مطالعه کنید. :)خب، رسیدیم به گرافانا!گرافانا چیست؟گرافانا ابزار متن بازی است که متریک‌ها را می‌خواند و آن‌ها را خیلی ساده و روشن در قالب نمودارهایی کارآمد و جذاب نمایش می‌دهد. برای آشنایی با نحوۀ به‌کارگیری و راه‌اندازی آن اینجا را بخوانید.نمونه‌ای از گرافانا خیلی ساده بخواهم بگویم، ابزار متن بازی (گیت هاب) است برای نمایش هرچه بهتر‌‌ متریک‌ها.گرافانا متریک‌ها را از برخی منابع (مثلاً پرومتئوس که در نوشتۀ قبلی توضیح دادم) که خودمان به آن می‌دهیم، می‌خواند و می‌توان در آن نمودارهای خیلی متنوع و درعین‌حال خوشگلی :) کشید.ازآنجاکه گرافانا ابزار متن باز است، پس یک docker image از آن در داکر هاب پیدا می‌شود.حالا تنها کاری که لازم است بکنیم، این است که کانفیگ‌هایش را برای این ایمیج سِت کنیم و در سرورمان یا هر جای دیگری دلمان خواست، آن را بالا بیاوریم.نحوۀ بالاآوردن گرافانا با داکرـ مرحلۀ اول:باز هم مثل قبل یک فایل docker-compose.yaml داریم که باید آن را بالا بیاوریم. محتوای این فایل این است:version: '3.1' services: grafana: image: grafana/grafana:6.4.4 container_name: grafana environment: - GF_SERVER_ROOT_URL=YOUR_SERVER_IP - GF_SECURITY_ADMIN_PASSWORD=asadasad - TZ=Asia/Tehran volumes: - ./volumes/dynamic/data:/var/lib/grafana - ./volumes/static:/etc/grafana - /var/log/docker/grafana-babr:/var/log/grafana ports: - 3000:3000 user: &quot0&quotخب مشخص است که اول می‌گوید: «برو ایمیج گرافانا رو بگیر و بیار و این environment_variable ها رو بهش بده.». بعد برخی چیزهایی را که لازم است، volume می‌کند.ـ همین جا توضیح می‌دهم که volume چیست؟ در هر کانتینر داکر که در حال اجرا شدن باشد‌، دیتاهایی وجود دارد که اگر کانتینر را پایین بیاوریم، آن‌ها پاک می‌شوند. برای اینکه جلوی این اتفاق گرفته شود، آن‌ها را اصطلاحاً volume می‌کنند. مثلاً می‌گویند فلان فایل‌ها توی فلان مسیر از سیستم ذخیره بشود که بعداً که کانتینر ریست شد، برود و دوباره آن‌ها را از آنجا بخواند.خب بعدش هم می‌گوید که روی چه پورتی بالا بیاید و آن را bind می‌کند به پورت سرور و تمام!ـ مرحلۀ دوم:فایلی هم به اسم grafana.ini هست که برای کانفیگ‌های بیشتر گرافانا استفاده می‌شود که چون خیلی حجیم است و قرار هم نیست برای کاربردهای ساده بخشی از آن را تغییر دهیم، از اینجا می‌توانید به آن دسترسی بیابید.حالا که آن فایل را هم داریم، دستورات زیر را اجرا کنید:sudo mkdir -p ./volumes/static/ sudo cp grafana.ini ./volumes/static/ docker-compose up -dخب این‌ها هم که دیگر خودتان می‌دانید چی هستند! فایل‌هایی که باید در جای خودشان باشند.باز هم تأکید می‌کنم که الان ما توی مسیری هستیم که فایل docker-compose.yaml وجود دارد.خب الان گرافانای شما باید بالا آمده باشد. بروید توی localhost:3000 ببینیدش.کاری که باید بکنید، این است که لاگین کنید (توی فایل docker-compose.yaml تعیین کردیم که یوزر و پسورد چیست!) و به بخش تنظیمات و قسمت اضافه‌کردن داشبورد جدید بروید و آنجا سورسش را پرومتئوسی بدهید که قبلاً اینجا بالا آوردیم.اینکه چطور نمودار بسازید و... در این نوشته مدنظر نبوده است. خودتان کمی با آن ور بروید، یادش می‌گیرید. سخت نیست. :)خب ممنون که خواندید. سؤالی پیشنهادی بود، حتماً کامنت بگذارید. :)در نوشتۀ بعدی می‌روم سراغ graylog ان‌شاءالله... محمد اژدری محمد اژدری Thu, 21 Nov 2019 14:50:33 +0330 https://virgool.io/baleacademy/%D8%B3%D8%A7%D8%AE%D8%AA%D9%86-%DB%8C%DA%A9-%D8%AF%D8%A7%D8%B4%D8%A8%D9%88%D8%B1%D8%AF-%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1%DB%8C%D9%86%DA%AF-%D8%A8%D8%B1%D8%A7%DB%8C-%DB%8C%DA%A9-%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D8%A8-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-xt46n68evloe به نام خدامانیتورینگ یعنی چی؟خیلی ساده بخواهم بگویم: همةۀ ما می‌دانیم که وقتی سرویسی را توسعه می‌دهیم، قطعاً باید وضعیت آن سرویس همیشه جلوی چشممان باشد و اتفاق‌هایی را که برایش می‌افتد، رصد کنیم.برای مثال، اگر یک وب سرویس داریم، باید بدانیم که در این لحظه میزان (rate) خطاهایش چقدر است یا اصلاً سرویس بالا هست یا نه!شکی نیست که مانیتورینگ برای همةۀ سرویس‌ها ضروری است. حالا پرسش اینجاست که چطور سرویس خودمان را مانیتور کنیم؟باید بگویم که خیلی ساده است؛ چراکه تاکنون شرکت‌های مختلف ابزارهای خیــلی متنوعی را برای این کار توسعه داده‌اند.یکی از این ابزارها که متن باز و رایگان است، prometheus نام دارد.این ابزار به زبان Go توسعه داده شده و لینک سایت و گیت‌هابش اینجاست:https://prometheus.io/https://github.com/prometheusکار اصلی این ابزار و احتمالاً خیلی از ابزارهای دیگر این است که برخی متریک‌هایی (metric) را که در روند توسعه‌ کد سرویس تغییر داده‌ایم، بر روی نمودار نشان می‌دهند و تغییرات آن‌ها را نیز به نمایش می‌گذارند.متریک چیست؟معنی لغوی این واژه تعریف خوبی برای این اصطلاح است که تقریباً معادل است با معیار اندازه‌گیری؛مثلاً ممکن است تعداد کاربرهای سایت شما، ممکن است از متریک‌های مانیتورینگ سایتتان باشد. نمونه دیگر،تعداد خطاها یا میزان مصرف رم یا latency درخواست‌هایی است که به سرور فرستاده می‌شود.برای اینکه بدانید هر متریک چیست و به چه دردی می‌خورد، این لینک را مطالعه کنید. من هم سعی می‌کنم در آینده مقاله‌ای درباره متریک‌ها منتشر کنم.https://prometheus.io/docs/concepts/metric_types/چطور prometheus را بالا بیاوریم؟برای این کار لازم است دانش اولیه‌ای درباره‌ی «داکر» داشته باشید؛ چون‌که می‌خواهم چگونگی بالا آوردن با داکرش را توضیح بدهم.خب، برای این کار اول از همه باید فایلی docker-compose.yaml مثل فایل زیر ایجاد کنیم:version: &quot3&quot services: prometheus: image: prom/prometheus:v2.12.0 hostname: &quot&quot container_name: prometheus volumes: - ./volumes/static/entrypoint.sh:/bin/prometheus-entrypoint.sh - ./volumes/static/prometheus.yml:/etc/prometheus/prometheus.yml - ./volumes/dynamic/prometheus/:/var/lib/prometheus/data user: root entrypoint: - /bin/sh - /bin/prometheus-entrypoint.sh - --config.file=/etc/prometheus/prometheus.yml - --storage.tsdb.path=/var/lib/prometheus/data - --storage.tsdb.min-block-duration=1h - --storage.tsdb.max-block-duration=6h - --storage.tsdb.retention=7d - --web.console.libraries=/usr/share/prometheus/console_libraries - --web.console.templates=/usr/share/prometheus/consoles ports: - 9090:9090اگر این را با کامند docker-compose up بالا بیاوریم، وب سرویس پرومتئوس توی پورت 9090 سرور بالا می‌آید. ولی الان مسئله این است که متریک‌ها را از کجا باید خواند؟ پس برای این هم باید کانفیگ‌هایی سِت شود:بدین‌ ترتیب‌ که اول باید فایلی به اسم prometheus.yml ایجاد کنید با محتویات زیر:global: scrape_interval: 30s scrape_configs - job_name: 'your_job static_configs: - targets: ['targer_host:target_port']ـ منظور از scrape_interval این است که پرومتئوسی که این‌طرف بالا آمده، چند ثانیه‌ای یک بار، برود و آن تارگت‌هایی (target) را که بهش می‌دهیم، بررسی کند.ـ منظور از job_name اسمی است که برای آن کار انتخاب می‌کنید و دلخواه شماست.ـ اما این هدف‌هایی (target) که برای کار خودتان تعریف می‌کنید، چی هستند؟ باید همان سروری را که متریک‌ها تویش ریخته شده‌اند، به آن بدهید.اینجا پرانتزی باز می‌کنم و نکته‌ای را توضیح می‌دهم: دقت کنید که پرومتئوس اکسپورترهایی دارد که برایش توسعه داده شده‌‌اند و اینجا می‌توانید آن‌ها را ببینید. کاری که اکسپورترها انجام می‌دهند، این است که متریک‌های مدنظر خودشان را توی سروری می‌ریزند و می‌شود اینجا توی targetهای پرومتئوسی که می‌سازیم، آدرس آن سرورها را بهش بدهیم و آن‌ها را توی داشبوردمان نگه داریم.بعد یک فایل entrypoint.sh با محتویات زیر ایجاد کنید:چیز خاصی نیست؛ اسکریپتی برای چطوری اجرا شدن داکر است. :)#!/bin/sh # # Entrypoint that adds `host.docker.internal` for Linux # https://github.com/docker/for-linux/issues/264 HOST_DOMAIN=&quothost.docker.internal&quot ping -q -c1 $HOST_DOMAIN > /dev/null 2>&1 if [ $? -ne 0 ]; then HOST_IP=$(ip route | awk 'NR==1 {print $3}') echo -e &quot$HOST_IP\t$HOST_DOMAIN&quot >> /etc/hosts fi exec /bin/prometheus &quot$@&quotبعد از آنکه این دو تا فایل را ایجاد کردید، دستورهای زیر را اجرا کنید: (دقت کنید که فرض بر این است که الان توی مسیری هستیم که فایل docker-compose.yaml بالا را گذاشتیم.)sudo mkdir -p ./volumes/dynamic/ sudo mkdir -p ./volumes/static/ sudo cp prometheus.yml ./volumes/static/ sudo cp entrypoint.sh ./volumes/static/این‌ها هم چیز خاصی نیستند و همان‌طور که می‌بینید، برای کپی‌کردن آن فایل‌ها داخل volume داکر است. :)بعد از این کار با دستور زیر داکرتان را اجرا کنید و بروید روی پورت 9090 (اگر توی داکر عوضش نکرده‌اید.) سرورتان را ببینید که بالا آمده است. :دیdocker-compose up -dبعد از این کار با دستور زیر داکرتان را اجرا کنید و بروید روی پورت 9090 (اگر توی داکر عوضش نکرده‌اید.) سرورتان را ببینید که بالا آمده است. :دیخب با همین کانفیگ، کار به‌کلی تمام است و می‌توانید داکر را اجرا کنید.اگر سؤال یا ابهامی هست، حتماً کامنت بگذارید که توضیحات را بهتر کنم یا جواب بدهم.توی نوشته‌های بعدی می‌روم سراغ گرافانا و گری‌لاگ و نهایتاً پروژه‌ای آزمایشی با این‌ها بالا می‌آورم و توضیح می‌دهم که چگونه است.ضمناً اینجا می‌توانید فایل‌هایی را که گفتم، ببینید. :)https://github.com/mmdaz/useful_dockers/tree/master/prometheus محمد اژدری محمد اژدری Thu, 14 Nov 2019 14:11:14 +0330 https://virgool.io/apieco/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D8%B3%D8%A7%D8%AF%D9%87-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-mvc-wxlhxgnvgrrf خب میخوام به صورت خیلی ساده درمورد چیزی که این روز ها خیلی درموردش شنیده میشه حرف بزنم معماری MVC :این معماری یا اینجوری بگم طرز فکر، اکثرا توی بک اند وب اپلیکیشن ها مورد استفاده قرار میگیره و چون که ساده و سرراست هستش خیلی فراگیر شده و حتی فریمورک هایی مثل , spring, django که امروزه استفاده خیلی زیادی ازشون میشه برمبنای همین معماری نوشته شدن کار میکنن.اول بگیم مخفف چیه ؟‌Model, View, Controllerیک شکل کلیخب این معماری داره یک وب سرور رو به سه تا قسمت تقسیم میکنه که بریم ببینیم هر قسمت منظورش چیه ؟مدل (Model) : تقریبا از اسمش مشخصه. ما داریم مسئلمون رو مدل میکنیم به آبجکت و کلاس توی کدمون.اگه با مفاهیم آبجکت ارینتد آشنا نسیتید سمت این معماری نیاید و همین الان برید درموردش بخونید و یادبگیرید و بعد بیاید ادامه این رو بخونید :)حالا چه چیز هایی رو مدل میکنیم ؟ معمولا جدول (table) های دیتابیس اینجا به صورت کلاس ظاهر میشن.در واقع اکثر فریمورک هایی ک mvc هستن orm هم هستن.حالا orm چیه ؟ خلاصه بگم میشه Object-relational mapping ینی اینکه روابط دیتابیس رو به صورت کلاس بیاری تو کد و آبجت اورینتدی برخورد کنی با مسئله.پس مثلا اگه یدونه جدول User داشته باشیم توی دیتابیس یدونه هم کلاس User توی مدل داریم که همون مشخصات چیزی رو ک توی دیتابیس هست رو داره.حالا لزوما دیتابیس رو مدل نمیکنیم. کلا هر چیزی که نیاز داریم که کلاس باشه توی این قسمت ایمپلیمنت میکنیم و میریم جلو.کنترلر (Controller) : اینجا جاییه که مشخص میکنیم کی کجا بره :)توی یک وب سرور ریکوئست های مختلفی سمتمون میاد و همشون هم جواب میخوان !اینجا مشخص میکنیم که مثلا یه چیزی از یه اندپوینت (end point) خاصی اومد کجا بره و چه توابعی کال بشه تا جوابش رو بدیم.ویو (View) : یادتونه دیگه تو خط قبلی گفتم کنترلر میگه چ توابعی به ازای ریکوئست های مختلف صدا زده بشن ؟این توابع توی ویو هستن و کارشون جواب دادن به یک سری ریکوئست خاص هستش.حالا چجوری ؟ این توابع از خودشون که چیزی ندارن ؟ پس با چی جواب میدن ؟درست حدس زدید :) مدل ها دیتاهای مورد نیازشون رو از مدل هامون ک همون دیتابیسمون هستن تقریبا میگیرن (حالا یا یه چیزی رو از اون ها پیدا میکنن و بهمون میدن مثلا اطلاعات یه یوزر خاص رو و یا اینکه یه چیزی رو به اون ها اضافه میکنن بازم مثلا اینکه یک یوزر رو توی دیتابیس اد کنن )این جواب دادن میتونه برگردوندن یک جبیسون به عنوان ریسپانس باشه یا رندر کردن و نمایش دادن یه صفحه html.در هر صورت یک یه ورودی میگیرن و یه خروجی برمیگردونن :)خب تموم شد ! همین قد ساده و راحت مهم اینه که بفهمید واقعا مفهوم کار چیه ابزار زیاد مهم نیست اما توصیه میکنم برای یادگیری بهتر جنگو رو امتحان کنید برای mvc چون که راحت تر میتونید باهاش ارتباط برقرار کنید اگه تازه کار هستید :) آخرش هم ک مثل همیشه خوشحال میشم بگید اینجای حرفت غلطه :) و کمکم کنید بهترش کنم نوشته هامو با کامنت هاتون محمد اژدری محمد اژدری Mon, 30 Sep 2019 00:16:27 +0330 https://virgool.io/baleacademy/%DA%86%D9%87%D8%A7-%D8%AA%D8%A7-%D9%86%DA%A9%D8%AA%D9%87-%D8%B3%D8%A7%D8%AF%D9%87-%D9%88-%D8%AC%D8%A7%D9%84%D8%A8-%D8%AA%D9%88%DB%8C-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-f79wcmrtwyvo داشتم کتاب clean code in python را می‌خواندم. برخی نکته‌هایش به نظرم بسیار جالب‌توجه بود. البته، کل این کتاب جالب و خواندنی است.چهار تا نکته یا اصل توصیه می‌شود و با اینکه شاید نکته‌ها خیلی ساده به نظر بیایند، اما واقعاً درخور توجه هستند؛ خصوصاً که خیلی از ما رعایتشان نمی‌کنیم.من نکته‌ها را نوشته‌ام و چسبانده‌ام روی میز کارم تا همیشه جلوی چشمم باشند.اصل اول:DRY/OAOO : Don't Repeat Yourself (DRY) / Once and Only Once (OAOO)خب، حالا این به چه معناست؟این نکته واقعاً مهم است که نگذاریم هیچ‌چیز در برنامه‌مان تکرار شود. این جمله پیامی فراتر را مدنظر دارد یا لااقل من این‌طور برداشت می‌کنم. آنگاه که می‌گوید: «خودتان را تکرار نکنید»، یعنی اینکه حتی تکراری فکر هم نکنید.دیزاین‌های گوناگونی از پترن‌ها و قاعده‌ها و ابزارها هستند که می‌توان از آن‌ها استفاده کرد تا کدمان تکراری نشود.هر وقت بخشی از کدی را که می‌نویسم، کپی‌پیست می‌کنم، احساس شرم می‌نمایم و فکر می‌کنم جایی از کارم می‌لنگد که الان ناچارم چنین کاری بکنم.در این کتاب، با دلیل به اهمیت این موضوع اشاره می‌شود:نویسنده معتقد است لاجیکی که شما تکرارش می‌کنید، احتمال اِرور یا خطای زیادی دارد و البته، درست‌کردنش هم به این راحتی‌ها نیست. فرض کنید من لاجیکی را در سه بخش استفاده می‌کنم و به‌جای اینکه یک اینترفیس برایش داشته باشم، همه‌جا از اول می‌نویسم. بعد یکی خطا می‌دهد و همان یکی را درست می‌کنم. شک نکنید که یادم می‌رود دو تای دیگر را درست کنم و تعداد خطا‌هایم همین‌طور بیشتر می‌شود.از دیگر ضررهای این کار این است که هزینه‌ها را بیشتر می‌کند؛ چنان‌که پیش‌تر نیز اشاره کردم، بسیار سخت است در کدی که این قاعده را رعایت نکرده، تغییری ایجاد کرد.و نهایتاً نمی‌شود به این کد اعتماد کرد.اما دومین اصل:YAGNI: You Ain't Gonna Need Itگاهی‌وقت‌ها پیش می‌آید که برنامه‌ای را می‌نویسیم که قرار است کار معیّنی را انجام دهد. اما داریم علاوه بر آن کار معیّن، به هزار تا فرضیة دیگر نیز فکر می‌کنیم؛ مثلاً با خودمان می‌گوییم: «خب پس‌فردا اگر این‌جوری شد، چی؟ بگذار این فیچر را هم اضافه کنم.» بعد به خودمان می‌آییم و می‌بینیم که در زمان مشخصی که انتظار داشتیم این کار تمام شود، به همة آن فرضیه‌ها که نپرداخته‌ایم هیچ، آن کار اصلی را هم انجام نداده‌ایم.اینکه به آینده فکر کنیم، لزوماً بد نیست‌؛ اما ضروری است که جنبه‌های مختلف را در نظر بگیریم،جنبه‌هایی که در چارچوب کار اصلی‌مان باشند و ما را از هدف اصلی دور نکنند.اصل سوم:KIS : Keep It Simpleآقا، خانم، بردار، خواهر این‌طور فکر نکنید که هرقدر کد شما پیچیده‌تر باشد، برنامه‌نویس بهتری هستید.اتفاقاً کاملاً برعکس است. برنامه‌نویسی خوب است که مسئله را به ساده‌ترین وجه ممکن حل کند و کدش کاملاً خوانا باشد؛ به‌طوری‌که هرکس بیرون از پروژه (حتی اگر برنامه‌نویسی هم بلد نباشد) قضیه را کاملاً بفهمد.عمیقاً آرزو می‌کنم روزی چنین برنامه‌نویسی بشوم و کدهایم را همة آدم‌های روی کرة زمین بفهمند. :)اصل چهارم:EAFP/LBYL: EAFP (stands for Easier to Ask Forgiveness than Permission), while LBYL (stands for Look Before You Leap)در این عبارت، دو تا اصل را یکجا گفته است.به کلمة while بین دو تا اصل دقت کنید؛ چراکه این دو با همدیگر کاملاً متناقض هستند و نویسنده گفته سعی کنید جفتشان را رعایت کنید. :)بخش اول چی می‌گوید؟ EAFP می‌گوید وقتی داری به مسئله‌ای فکر می‌کنی که حلش کنی، راه‌حل‌هایی به ذهنت می‌رسد. برو کدش را بزن و بعدش باگ‌هایش پدیدار می‌شوند.یعنی لازم نیست مدام فکر کنی که نتیجة این و آن، چه خواهد شد. نتیجه در نوشتن و آزمایش‌کردن نمایان می‌شود.دومی (LBYL) کاملاً برعکس این است. ترجمه‌اش می‌شود: «قبل از اینکه بپری، نگاه کن.»یعنی سعی کنید به همة حالت‌ها و باگ‌ها و خطاهایی که ممکن است رخ دهد و کدتان با آن‌ها مواجه شود، فکر کنید.نویسنده معتقد است که باید سعی کنید هر دو این‌ها را رعایت کنید و میانه‌رو باشید.بعد در نکته‌ای ظریف می‌گوید:(:امیدوارم آنچه نوشتم، مفید بوده باشد.اشکالی داشت، حتماً بگویید. خوش‌حال می‌شوم. محمد اژدری محمد اژدری Sat, 14 Sep 2019 17:30:03 +0430 https://virgool.io/apieco/%D9%81%D8%B1%D9%82-graphql-%D9%88-rest-nlikcxjbphgi الان تقریبا سه ماهی هست که دارم بک اند یک وب اپلیکیشنی رو با graphql توسعه میدمتو این چند مدت تجربه های جالبی داشتم که میخوام به اشتراک بذارم:اول درمورد خود graphql حرف بزنم و اینکه از کجا پیداش شده !؟جریان اینه که تو سال 2015 توسط فیسبوک توسعه داده شده و از اون موقع توی اپلیکیشن های معروفی همچون خود فیسبوک و اینستاگرام و توئیتر و سایر اپلیکیشن ها استفاده شده.من تو ایران جایی رو ندیدم که ازش استفاده کرده باشن.تو این مقاله میخوام درمورد فرق هاش با rest یه کم حرف بزنم چون که حس میکنم اینجوری گفتن و فهمش آسون تر باشه.همونجوری که احتمالا همه میدونن rest یک معماری طراحی api عه که برای گرفتن اطلاعات و دستکاری کردن روی اطلاعات یک دیتابیس که پشت یک وب اپلیکیشن هست استفاده میشه.معمولا اگه HTTP استفاده کنیم معماری rest چند تا متود معروف داره : GET, POST, PUT, DELETE.برای گرفتن و query زدن از GET استفاده میشه و معمولا برای ساختن و مودیفای کردن یا همون دست کاری کردن از POST و برای بقیه کاربرد ها که دیگه نمیخوام زیاد واردش بشم.اینکه rest یک معماری عالیه توش شکی نیست اما خب بعضی از ایراد هایی بهش وارده:اولین موردش رو میخوام با یک مثال بگم :فرض کنید دو تا مودل post و user رو توی اپلیکیشنمون داریم بعد میخوایم محتوای یک پست و همزمان با اون نویسنده اون پست که میشه یک یوزر رو هم از سرور بگیریم، کاری که توی rest مجبوریم بکنیم اینه که دو تا ریکوئست به سرور بزنیم با این عنوان ها :mydomain.com/posts/:idmydomain.com/users/:idمورد دوم رو هم میخوام با همین مثال میخوام بگم اونم اینجوری که فرض کنید مودل پست ما چهار تا قسمت داره (title, id, user, body) ما توی کلاینت تو یه قسمت فقط قسمت title رو از پست میخوایم و اگه از همون ریکوئستی تو همین مثال قبل بزنیم کل پستی که میخوایم رو به ما برمیگردونه که خب علی الحساب لازمش نداریم و دیتای اضافی هستش.اما بریم سراغ graphql :این دوستمون هم یک نوع معماری برای نوشتن API هستش که بعضا ازش به عنوان یک زبون هم یاد میشه.کانسپت اصلی این معماری اینه که همه چیز مثل راس های یک گراف هستن که با هم در ارتباطن.ویژگی مهمی که graphql داره اینه که منعطفه. حالا چجوری ؟اینجوری که شما میتونید مثلا یک اطلاعاتی رو از سرور بگیرید و دقیقا مشخص کنید که چی میخواید برای مثال کوئری زیر رو ببینید :{ post(id: 1) { title user { name email courses { title } } } }الان با این کوئری که زدیم ما title و user پستی که آی دی اون 1 هست رو گرفتیم و از یوزرش فقط name و email و courses و از courses فقط قسمت title همونجوری که میبینید به طرز خیلی قشنگی همه این ها با یک کوئری و ریکوئست به سرور هندل شده :دیو دیگه لازم نیست برای هر کدوم این ها یک ریکوئست جداگانه به سرور بزنیم.کلا خیلی چیز های دیگه درمورد این معماری graphql هست که دیگه نمیخوام طولانی کنم این نوشته رو توی نوشته های بعدی ادامه میدم انشالله.مثل همیشه مشتاق نظرات شما هستم.منابع :https://medium.com/codingthesmartway-com-blog/rest-vs-graphql-418eac2e3083#targetText=Both%2C%20REST%20and%20GraphQL%2C%20are,to%20deal%20with%20single%20resources.https://graphql.org/ محمد اژدری محمد اژدری Mon, 19 Aug 2019 21:50:48 +0430 https://virgool.io/@mmdaz/%D9%88%D8%A8-%D8%A7%D9%BE%D9%84%DB%8C%DA%A9%DB%8C%D8%B4%D9%86-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-pnjirkjux3ch این اولین نوشته من توی ویرگوله و یک برنامه نویسی هستم که تجربه اونقدری ندارم که بگم حرفام وحی منزله :) و همیشه خوشحال میشم که کامنتی با موضوعیت اصلاح حرف هام دریافت کنم.اول میخوام درمورد یک موضوع تحت عنوان وب اپلیکیشن ها حرف بزنم.موضوع اینه که امروزه با گسترش اینترنت و کلا فضای آنلاین، همه کارهامون رو به این سمت قدم برمیدارن و از شکل سنتیش فاصله میگیرن. از فرستادن پول و گرفتن تاکسی گرفته تا خریدن نون و حتی دادن فرش به خشک شویی :)اما خب همه این کارها و هر کدوم توی یک سایتی یا یک اپلیکیشینی توی گوشی ما هستند که به این ها میگیم وب اپلیکیشن.همین الان اگه اپ هایی که توی گوشیتون رو یه نگاه بندازید میبینید که اگه اینترنت نداشته باشد اکثرشون عملا کاربردی ندارن.خب من میخوام چیزهایی که فهمیدم رو از پایه و ساده بگم اونم اینه که:خب الان این وب اپلیکیشن ها چجوری ساخته میشن ؟اکثر این ها از دو بخش عمده تشکلیل میشن:کلاینت و سرورکلاینت : اون چیزی که توی گوشی شماس یا حتی خود شما :) یک نوع کلاینت محسوب میشید و خب این خودش سطح های مختلفی داره و اگه بخوام ساده بگم کسی که درخواستی داره کلاینت محسوب میشه.مثلا شما الان درخواست دارید که برای دوستتون پول بفرستید میاید یک اپلیکیشن مالی رو باز میکنید و براش کارت به کارت میکنید. تو این مثال شما درخواست کننده یا همون کلاینت به این اپلیکیشن هستید. و در نهایت یک جوابی با موضوعیت اینکه این کار انجام شد یا نه دریافت میکنید.سرور : اگه بازم بخوام با زبون آدمیزاد حرف بزنم :) اون بخشی که درخواست ها رو از کلاینت میگیره و با یک سری پردازش و حساب کتاب یک جوابی رو برمیگردونه و به کلاینت میده رو بهش میگیم سرور.خب الان فهمیدیم که کلاینت و سرور با هم در ارتباطن و چیزی که مشخصه این ها باید با یک سری قراردادی که خودشون میدونن باید حرف همدیگه رو بفهمن. توی اکثر اپلیکیشن ها این کار از طریق API انجام میشه.خب حالا API چیه ؟ اینجوریه که سرور یک سری قواعد و آدرس هایی تعریف میکنه و به کلاینت میگه اگه میخوای فلان کار رو برات انجام بدم اینجوری بهم بگو و منم اینجوری بهت جواب میدم. مثلا اگه گفتم "اوکی" ینی انجام دادم و اگه گفتم "مشکل" ینی نتونستم و یه جای کار ایراد داره.خب معمولا اینجوریه که هر کسی که وب اپلیکیشن توسعه میده برای خودش قواعد خودشو داره.ولی خب یک سری قواعد و قرارداد های عمومی هستند که بقیه تقریبا زیر این ها برای خودشون قانون وضع مکنن.ینی اینجوری بگم این API هایی که گفتم انواعی دارن. یکی از معروف ترین هاش rest api عه که به وفور توی جاهای مختلف ازش استفاده شده ولی هدف من توی این نوشته معرفی یک میشه گفت زبونِ API نویسی ینی Graphql عه.که برای اینکه متن طولانی نشه توی پست بعدی این رو ادامه میدم. محمد اژدری محمد اژدری Tue, 13 Aug 2019 19:51:41 +0430