https://virgool.io/feed/@alifalahati . fa 2026-06-27 22:05:23 https://files.virgool.io/upload/users/10745/avatar/QQ54qJ.png?height=120&width=120 https://virgool.io/@alifalahati https://virgool.io/@alifalahati/%DB%8C%DA%A9-%D9%88%DB%8C%DA%98%DA%AF%DB%8C-%D8%AC%D8%AF%DB%8C%D8%AF-%D9%88-%D8%AC%D8%B0%D8%A7%D8%A8-%DA%AF%D9%88%DA%AF%D9%84-%DA%A9%D8%B1%D9%88%D9%85-ehrsdm8t3gx9 گوگل کروم در بروزرسانی اخیر خود یعنی در نسخه  ۷۶٫۰ به بعد یک ویژگی اضافه کرده است که بسیار به درد بخور و جذاب است. شما وقتی با حساب کاربری گوگل خود به وسایل مختلف خود لاگین کرده اید میتوانید ازین قابلیت استفاده کنید. فرض کنید شما در حال مطالعه یک مطلب بر روی کامپیوتر شخصی خودتان هستید و خب قصد دارید آن مطلب را به تلگرام برای یکی از دوستان خودتان ارسال کنید. حال و حوصله اینکه وی پی ان را وصل کنید و برنامه تلگرام رو هم باز کنید ندارید ?خب هرکجا روی صفحه خواستید راست کلیک کرده و گزینه Send to your devices را بزنید. لیست دیوایس هایی که با حساب جاری جیمیل به آنها وصل هستید را برایتان می آورد و میتوانید به راحتی آن را ارسال کنید. در سمت گیرنده نیز به راحتی پس از چند ثانیه میتوانید مطلب مورد نظر را دریافت کنید. به همین راحتیSourcehttps://blog.phpadmin.ir/ ali ali Fri, 15 Nov 2019 12:58:58 +0330 https://virgool.io/phpadmin/%D9%87%D8%AF%D9%81-%D9%88-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF%D9%87%D8%A7%DB%8C-%D9%87%D9%88%D8%B4-%D9%85%D8%B5%D9%86%D9%88%D8%B9%DB%8C-%DA%A9%D8%AF%D8%A7%D9%85%D9%86%D8%AF-abi6jvk7tolu هدف و کاربرد‌های هوش مصنوعیهدف هوش مصنوعی، نزدیک نمودن رفتار و پاسخ یک سیستم کامپیوتری به الگوهایی است که انسان بر اساس آن‌ها رفتار می‌کند و پاسخ می‌دهد. گاه سیستم‌هایی طراحی می‌شوند که قدرت تجزیه و تحلیل آن‌ها از انسان بیشتر است، ولی باز از الگوهای ما استفاده می‌کنند. از اهداف متخصصین این رشته، تولید ماشین‌هایی است که دارای احساسات بوده و دست کم نسبت به وجود خود و احساسات خود آگاه باشند. این ماشین باید توانایی تعمیم تجربیات قدیمی خود در شرایط مشابه جدید را داشته و به این ترتیب اقدام به گسترش دامنه دانش و تجربیاتش کند. بیشتر افراد با شنیدن عبارت هوش مصنوعی، به یاد ربات‏های فیلم ‏های علمی تخیلی و بازی‏های کامپیوتری و به خصوص شطرنج می‌افتند. در حالی که هوش مصنوعی در مدت زمان کوتاهی از عمر خود، توانسته است از حد توسعه بازی‏ها به سوی دنیایی از مسائل شگفت‏ آوری همچون سیستم‏های خبره، بینایی ماشین و… گام بردارد. امروزه ردپایی از هوش مصنوعی را می‌‏توان در علوم مختلفی اعم از پزشکی، علوم هوا فضا، اکتشافات، تسلیحات نظامی، پیش بینی وضع هوا، نقشه برداری و شناسایی عوارض، تشخیص صدا، تشخیص گفتار و دست خط و همچنین بازی‌ها و نرم افزارهای رایانه‌ای مشاهده کرد. از این رو، متخصصان هوش مصنوعی، با توجه به کاربردهای گوناگون این علم، آن را در شاخه ‏های متنوعی دنبال نموده ‏اند، که به نمونه‌هایی از آن‌ها اشاره می‌کنیم:۱/ دید دستگاهعلمی برای دیدن کامپیوترها است. این فناوری با استفاده از دوربین، تبدیل آنالوگ به دیجیتال و پردازش سیگنال دیجیتال، اطلاعات تصویری را ضبط و تجزیه و تحلیل می‌کند. این تکنولوژی غالبا با دید انسان مقایسه می‌شود، اما دید این دستگاه به زیست شناسی محدود نمی‌شود. این فناوری در طیف وسیعی از برنامه‌ها از شناسایی امضا گرفته تا تجزیه و تحلیل تصاویر پزشکی استفاده می‌شود.۲/ پردازش زبان طبیعی(NLP) : به پردازش زبان انسانی توسط یک برنامه رایانه‌ای اطلاق می‌گردد. پردازش زبان طبیعی، به ماشین‌های هوشمند این قابلیت را می‌دهد که زبان انسان‌ها را بخوانند و آن‌ها را متوجه شوند. رویکردهای فعلی NLP مبتنی بر یادگیری ماشین است. وظایف NLP شامل ترجمه متن، تحلیل احساسات و تشخیص گفتار است.۳ / رباتیکیک رشته مهندسی با تمرکز بر طراحی و ساخت ربات‌ها است. اغلب از ربات‌ها برای انجام کارهایی استفاده می‌شوند که انجام یا اجرای مداوم آن‌ها برای انسان دشوار است. آن‌ها در خطوط مونتاژ برای تولید خودرو یا توسط ناسا برای جابجایی اشیاء بزرگ در فضا استفاده می‌شوند. محققان همچنین از ماشین یادگیری، برای ساخت ربات‌هایی استفاده می‌کنند که می‌توانند در تعاملات اجتماعی شرکت داشته باشند.۴/ اتومبیل‌های هوشمندیک خودروی هوشمند نه تنها با استفاده از مفهوم اینترنت اشیا قادر است با خودروهای دیگر و تابلوهای کنار جاده ارتباط برقرار کند، بلکه قادر است تا با یادگیری، عادت‌های کاربر یا راننده را نیز بشناسد. این عادات شامل دمای داخلی خودرو، تنظیمات سیستم صوتی و وضعیت صندلی است. خودرو قادر است با تکیه بر قابلیت‌های هوشمند، تنظیمات را تغییر داده و در صورت بروز مشکل، خود مساله را حل کند. همچنین باید به ارائه‌ی پیشنهاد در مورد مسیر رسیدن به مقصد براساس داده‌های ترافیکی و وضعیت جاده نیز اشاره کرد.۵/ مراقبت‌های بهداشتیبیشترین تمرکز این رشته در بهبود بیماران و کاهش هزینه‌ها است. شرکت‌ها در حال ساخت ماشینی هستند تا تشخیصی بهتر و سریعتر از انسان انجام دهد. یکی از مشهورترین فناوری‌های مراقبت‌های بهداشتی IBM Watson است. این ماشین، زبان طبیعی را درک می‌کند و قادر به پاسخگویی به سؤالات پرسیده شده از آن است. در این شاخه، کامپیوترها برای تصمیم ‏گیری در شرایط واقعی زندگی برنامه ‏ریزی می‌شوند. نمونه ‏ای از سیستم‏های خبره، سیستم‏های تشخیص بیماری هستند. در این سیستم‏ها، اطلاعات یک یا چند متخصص به همراه اطلاعات دریافتی از مراجعان به کامپیوتر داده می‌شود؛ سپس کامپیوتر با پرسش سؤالاتی از مراجعه‏ کننده و تطبیق آن با بانک اطلاعاتی خود، بیماری شخص را تشخیص خواهد داد.۶ / آموزش و پرورشهوش مصنوعی می‌تواند رتبه بندی دانش آموزان را به صورت خودکار انجام داده و این امر به معلمان زمان بیشتری می‌دهد. هوش مصنوعی می‌تواند دانش آموزان را ارزیابی کرده، با نیازهای آن‌ها سازگار شود و در یادگیری دروس به آن‌ها کمک کند. حتی ممکن است به زودی جایگزین برخی از معلمان شود.۷ / صنعتاز هوش مصنوعی می‌توان در کلیه سیستم‌های خودکار جهت برش قطعات مختلف، سرهم کردن و فیکس کردن قطعات داخل هم و اتصال آن‌ها به یکدیگر استفاده کرد. همچنین می‌توان از سیستم کنترل کوره ها، ربات‌های مختلفی که در برشکاری ورق، اتصال و جوشکاری استفاده می‌شوند و همین طور سیستم‌های هوشمند بینایی که در کنترل کیفیت انواع محصولات بکار می‌روند نام برد.بیشتر بخوانید : چهار زیر شاخه اصلی هوش مصنوعیsource: blog.phpadmin.ir ali ali Tue, 29 Oct 2019 14:44:37 +0330 https://virgool.io/phpadmin/%D9%88%D8%A8-%D8%B3%D8%B1%D9%88%D8%B1-nginx-%DA%86%DB%8C%D8%B3%D8%AA-%D9%88-%DA%86%DA%AF%D9%88%D9%86%D9%87-%DA%A9%D8%A7%D8%B1-%D9%85%DB%8C%DA%A9%D9%86%D8%AF-nav1aiucpckb NGINXوب سرور NGINX یک سرور وب قدرتمندتصور کنید که شما یک برنامه وب ایجاد کرده اید و اکنون در جستجوی سرور وب مناسب برای میزبانی از آن هستید. برنامه شما ممکن است شامل چندین فایل استاتیک،HTML ، CSS و JavaScript، یک سرویس API با پس زمینه یا حتی چندین سرویس وب باشد. ممکن است استفاده از Nginx همان چیزی باشد که به دنبال آن هستید و دلایل زیادی برای آن وجود دارد. NGINX یک سرور وب قدرتمند است و از معماری بدون موضوع و رویداد محور استفاده می کند که در صورت پیکربندی صحیح، آن را قادر می سازد تا از حداکثر توان خود استفاده کند. همچنین می تواند کارهای مهم دیگری مانند توازن بار و ذخیره سازی HTTP را انجام دهد یا به عنوان یک پروکسی معکوس مورد استفاده قرار گیرد. دو روش برای نصب NGINX وجود دارد، می‌توانید با استفاده از یک باینری از پیش ساخته شده، یا ساخت از منبع، آن را نصب کنید. روش اول بسیار ساده و سریعتر است، اما ساختن آن از منبع، امکان گنجاندن ماژول های شخص ثالث مختلف را فراهم می آورد که NGINX را بسیار قدرتمندتر می کند. همچنین این امکان را به ما می دهد تا متناسب با نیاز برنامه، آن را سفارشی کنیم.پیکربندی NGINX چگونه است؟با توجه به نیازها، شما می توانید چیزهای مختلفی را در این پرونده مرتب سازی کنید، اما NGINX آنچنان ساده است که می توانید حتی با تنظیمات پیش فرض هم پیش بروید. برخی از مهمترین قطعات فایل پیکربندی NGINX عبارتند از:۱٫ Working_processes: این تنظیم تعداد فرآیندهای کارگر را که NGINX از آنها استفاده خواهد کرد، تعریف می کند. از آنجا که NGINX تک رشته ای است، معمولا این تعداد باید برابر با تعداد هسته های CPU باشد.۲٫ Working_connention: این مورد تعداد حداکثر اتصالات همزمان برای هر فرآیند کارگر است و به کارگر ما می گوید که چگونه می توان به بسیاری از افراد به صورت همزمان توسط NGINX خدمات ارائه داد. هرچه این متغیر بزرگتر باشد، کاربران NGINX همزمان می توانند خدمات بیشتری داشته باشند.۳٫ Access_log & error_log: این پرونده هایی هستند که NGINX برای ثبت هرگونه خطا و تلاش برای دسترسی از آنها استفاده خواهد کرد. این لیست های مربوط، به طور کلی برای اشکال زدایی و عیب یابی بررسی می شوند.۴٫ Gzip: این تنظیمات مربوط به فشرده سازی GZIP از پاسخ های NGINX است. فعال کردن این مورد به همراه زیر مجموعه های مختلفی که دارد، باعث ارتقاء عملکرد بسیار بزرگی خواهد شد. از زیر تنظیمات GZIP باید به gzip_comp_level که سطح فشرده سازی نامی‌ده می‌شود و از ۱ تا ۱۰ متغیر است دقت کنید. به طور کلی، این مقدار نباید بالاتر از ۶ باشد. هر چه این عدد بزرگتر باشد به همان نسبت، به استفاده CPU بیشتری احتیاج دارد.وب سرور NGINX چگونه کار می‌کند؟با نصب NGINX شما می توانید خیلی بیشتر از یک وب سایت واحد را پشتیبانی کنید. پرونده هایی که سایت های سرور شما را تعریف می کنند در فهرست سایتهای موجود زندگی می کنند. با این حال، پرونده های این دایرکتوری زنده (Live) نیستند. شما می توانید همانطور که می خواهید، تعداد فایلهای تعریف سایت را در اینجا داشته باشید، اما NGINX در واقع هیچ کاری با آنها انجام نخواهد داد مگر اینکه در فهرست فعال شده سایتها قرار داشته باشند. همچنین می توانید آنها را در آنجا کپی کنید، اما همگام سازی اطمینان می دهد که فقط یک نسخه از هر پرونده برای پیگیری وجود دارد. این روش به شما امکان می دهد تا وب سایت‌ها را، به سرعت آنلاین کنید و آنها را به صورت آفلاین و بدون نیاز به حذف پرونده‌ها قرار دهید. هنگامی که یک سایت برای آنلاین شدن آماده است، آن را به صورت فعال در سایت‌ها همگام سازی کرده و NGINX را مجددا راه اندازی کنید.متن سرور، یک سرور مجازی خاص را برای رسیدگی به درخواست های مشتری شما تعریف می کند. می توانید چندین بلوک سرور داشته باشید و NGINX بر اساس بخشنامه listen و server_name بین آنها انتخاب خواهد کرد. در داخل بلوک سرور، چندین زمینه موقعیت مکانی را تعریف می کنیم که برای تصمیم گیری در مورد نحوه رسیدگی به درخواست های مشتری تعریف می شوند. هرگاه درخواستی وارد شود، NGINX سعی خواهد کرد URI خود را با یکی از آن تعاریف موقعیت مکانی مطابقت دهد و مطابق با آن رفتار کند. بسیاری از دستورالعمل های مهم وجود دارد که می تواند در متن موقعیت مکانی مورد استفاده قرار گیرد، مانند:۱٫ try_files: سعی خواهد کرد که یک پرونده استاتیک موجود در زیر پوشه را که به راهنمای root اشاره دارد، ارائه دهد.۲٫ proxy_pass: درخواست را به سرور پروکسی مشخصی ارسال می کند.۳٫ Rewrite: در واقع URI ورودی را بر اساس یک عبارت معمولی بازنویسی می کند تا یک بلوک موقعیت مکانی دیگر بتواند آن را اداره کند.مقالات جدید در وب سایت ali ali Fri, 11 Oct 2019 16:41:16 +0330 https://virgool.io/phpadmin/%D9%88%D8%A8-%D8%B3%D8%B1%D9%88%D8%B1-apache-%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%AF%D8%B1%D8%AE%D9%88%D8%A7%D8%B3%D8%AA-%D9%87%D8%A7-%D8%B1%D8%A7-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%85%DB%8C%DA%A9%D9%86%D8%AF-rrcmogwsdveq وب سرور آپاچیآپاچی محبوب ترین وب سرور برای وب سرورهای لینوکسی است. بسیاری از مدیران سیستم (سیس ادمینیستریتور) های لینوکسی مراحل یادگیریشان را با استفاده از این وب سرور(httpd) شروع کرده اند. در مراحل اولیه همه آنها با این وب سرور کار کرده اند. خیلی از آنها از تنظیمات پیشفرض استفاده کرده اند ولی نمیدانند که آپاچی چگونه کار میکند و چگونه اتصالات ورودی و یا درخواست ها و همچنین پردازش های چندگانه را مدیریت میکند.آپاچی از یکی از متدهای زیر که به MPM ها (Multi Process Module)  یا ماژول چندپردازش معروف هستند برای مدیریت کردن درخواست های ورودی و پردازش های آنها استفاده میکند. هر دوی این اعمال (مدیریت درخواست ها و  پردازش آنها) روش خود را  دارد. بیایید نگاهی کوتاه به این روش ها بیندازیم:متد یک - Prefork MPM:این روش که به آن Process model نیز میگویند چندین پردازش فرزند ایجاد و اجرا میکند. با استفاده از این MPM  پردازش فرزند (‌child process) یک کانکشن را در یک زمان مدیریت میکند. چندنخی در این روش معنی ای ندارد و یک Thread وجود دارد که یک پردازش را مدیریت میکند و به همین دلیل این روش مصرف مموری بیشتری نسبت به MPMهای دیگر که در زیر معرفی میشوند دارد. روش پیشفرضی که توسط نسخه های Apache 2 انجام میشود این روش است. اگر هیچ MPMای انتخاب نشود این روش انتخاب و اجرا خواهد شد. این روش در صورتی که قرار باشد آپاچی از کتابخانه های ایمن بدون Thread مثل mod_php استفاده کند روش مناسبی است و همینطور اگر قرار باشد پردازش ها ایزوله شوند گزینه مناسبی است.این روش حداقل چندتا پروسس تعریف شده را به عنوان پروسه یدکی یا جایگزین اجرا میکند و بنابراین درخواست های جدید نیازی ندارند برای شروع پردازششان صبر کنند.متد دو - Worker MPMاین متد چندین پردازش فرزند مشابه با روش بالا ایجاد میکند. هر پردازش فرزند چند Thread را اجرا میکند. هر Thread یک کانکشن را در یک زمان مدیریت میکند. همانطور که میبینید برعکس متد بالا در اینجا هر پروسه فرزند میتواند چندین Thread داشته باشد. در حقیقت این MPM آپاچی را به یک وب سرور Multi Thread و Multi Process تبدیل میکند.متد Worker MPM یک سرور چند نخی چند پروسسی ترکیبی را پیاده سازی میکند. در حقیقت چندین پروسس فرزند که چندین thread را در بر میگیرند به علاوه یک thread که در حال گوش دادن است (listening thread)  و Worker درخواست های بیشتری را با منابع کمتری نسبت به Prefork مدیریت میکند.وظیفه thread گوش دهنده اینه که به کانکشن ها گوش میدهد و آنها را به محض ورود به یک  thread برای پردازش هدایت میکند. همانطور که در بالا گفته شد مصرف مموری کمتری نسبت به Prefork MPM دارد.در حالت عمومی برای سرورهایی که ترافیک بالایی داشتند تا قبل از نسخه ۲.۴ این روش توصیه میشد. Worker ها با کتابخانه های non-thread امن سازگاری ندارند و اگر نیاز دارید برنامه ای اجرا کنید که thread safe نیست بهتر است از روش بالا یعنی Prefork استفاده کنید.متد سه - Event MPMاین روش که در نسخه ۲.۴ آپاچی معرفی شد خیلی شبیه به Worker MPM است با این تفاوت که هر Theread میتواند بیشتر از یک وطیفه را انجام دهد و آپاچی منابع خیلی کمتری در این روش مصرف میکند. متد Event MPM برای مدیریت بارهای سنگین (hight load) طراحی شده است و خب باید در نظر داشته باشید فقط در سرورهایی که آپاچی ۲.۴ دارند پشتیبانی میشود و برای استفاده از مزایای آن حتما باید نسخه آپاچی را به روز کنید. چون با نسخه های قبل ۲.۴ سازگاری ندارد.این روش با محول کردن بعضی از کارهای پردازش به thread های پشتیبان به درخواست های بیشتری به صورت همزمان سرویس میدهد. این متد کانکشن های بزرگ و طولانی را به صورت موثرتری بر روی یک thread مدیریت میکند. با استفاده از این MPM آپاچی موضوع keep alive problem را که توسط متدهای دیگر به وجود آمده به این صورت که وقتی کلاینت اولین درخواست را کامل میکند بتواند کانکشن را باز نگه دارد و درخواست های بیشتری را از این سوکت ارسال کند حل میکند و این موضوع باعت کار کاهش اضافه بار میشود. برای خواندن مقالات مرتبط به بلاگ من سر بزنید ali ali Fri, 04 Oct 2019 20:45:25 +0330 https://virgool.io/phpadmin/%D8%A2%DB%8C%D9%86%D8%AF%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-php-%D8%A2%DB%8C%D8%A7-%D9%88%D8%A7%D9%82%D8%B9%D8%A7-php-%D9%85%D8%B1%D8%AF%D9%87-avgpqsjfdl1c آینده زبان PHPزبان PHP بدون شک روزهای بهتری نسبت به الان داشته است ولی آیا واقعا مرده؟توی تمام سایت ها یا فروم ها  مثل Stackoverflow که نگاه کنید شاید بحثی راجع به این موضوع پیدا کنید که همه راجع به این صحبت میکنند که PHP تمام شده است. آیا آنها واقعا درست میگن؟ یا اینو بعضی ها فقط به این دلیل میگن که PHP رو دوست ندارن یا از این زبان خوششون نمیاد؟اجازه بدین یه بررسی ای راجع به زبان PHP انجام بدیم.زبان PHP هنوز هم در دنیای وب برجسته است.اگر یک نگاه ساده به تعداد وبسایت ها یا فریمورک های PHP بیندازید قطعا به این نتیجه میرسید که PHP نمرده و هنوز با فاصله زیاد پر استفاده ترین زبان برنامه نویسی به عنوان زبان سمت سرور است. تقریبا ۷۵ درصد تمام پیج های وب با این زبان توسعه داده شده اند. شکل زیر را مشاهده کنید. بر اساس این آمار خیلی درست نیست که بگیم PHP مرده در صورتی که تقریبا ۷۵ درصد وب بر روی اون استواره. ۷۵ درصد عدد منطقی ای برای یک زبان مرده نیست.برای مطالعه ادامه این مقاله بر روی این لینک کلیک کنید. ali ali Tue, 01 Oct 2019 23:49:29 +0330 https://virgool.io/@alifalahati/%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF-docker-compose-%DA%86%DB%8C%D9%87-%D9%88-%DA%86%D8%B1%D8%A7-%D8%A8%D8%A7%DB%8C%D8%AF-%D8%A7%D8%B2%D8%B4-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%DA%A9%D9%86%DB%8C%D9%85-lyvlyesyqjir docker composeاصطلاحا Docker Compose گرداننده و یا راهنمای کانتینر داکر است. معنی این جمله چیه؟خب اگر دیده باشید توی گروه های موسیقی یک رهبر ارکستر وجود داره که وظیفش هدایت گروه تحت نظرشه و اونه که مشخص میکنه چگونه یک گروه باید در حین اجرا رفتار کنه، صدای کم یا زیاد، ریتم و غیره .این دقیقا همون کاریه که Docker compose انجام میده، ولی توی این مورد ما رهبر ارکستر هستیم! در حقیقت این ماییم که تعیین میکنیم کانتینر یا کانتینرها چگونه با استفاده از یک فایل رفتار کنند. تمام داستان نوشتن یک فایل با فرمت Yaml است (Yaml Ain’t Markup Language) . شبیه به چیزی که در فایلهای Dockerfile داریم با ساز و کاری متفاوت. یک قالب encode شده داده ها ی قابل خواندن توسط انسان. که خواندن و فهمیدن کاری که compose انجام میده را راحت تر میکند.ادامه مقاله ali ali Wed, 25 Sep 2019 01:12:47 +0330 https://virgool.io/phpadmin/%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%AE%D9%88%D8%A8-%DB%8C%D8%A7-%D8%A8%D8%AF-%D9%85%D8%B2%D8%A7%DB%8C%D8%A7-%D9%88-%D9%85%D8%B9%D8%A7%DB%8C%D8%A8-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-wug7yargqhsz در این مقاله قصد داریم نگاه کلی به فواید و معایب استفاده از معماری میکروسرویس و مقایسه‌ی آن با معماری یکپارچه (monolith) که بسیاری از افراد با آن آشنایی دارند ارائه دهیم.شرکت‌هایی مانند نتفلیکس (Netflix)، آمازون (Amazon) و دیگر شرکت‌ها ایده‌ی استفاده از میکروسرویس‌ها را در محصول‌هایشان به کار گرفته‌اند. میکروسرویسها یکی از جدیدترین موضوع‌های صنعت نرم‌افزار هستند و حتی میتوان گفت یکی از داغ ترین مباحث مهندسی نرم افزار و بسیاری از شرکت‌ها خواهان استفاده از آن‌ها هستند. نکته‌ی مهمی که وجود دارد این است که میکروسرویس و DevOps هماهنگی خوبی با یکدیگر می‌توانند داشته باشند و در بسیاری از شرکت ها طراحی معماری میکروسرویس جزو وظایف تیم DevOps محسوب میشود.با این وجود میکروسرویس چیست؟ چرا یک شرکت باید از آن استفاده کند؟به منظور فهم آن‌ها ابتدا اجازه دهید نگاهی به معماری Monolitic  بیندازیم.در این معماری ما به طور اساسی از یک معماری سه لایه استفاده می‌کنیم:لایه‌ی نمایش (Presentation layer)لایه‌ی کسب و کار(Business layer)لایه‌ی دسترسی به داده‌ها (Data access layer)فرض کنید یک کلاینت سنتی (یک مرورگر) درخواستی را ارسال می‌کند. لایه‌ی کسب و کار منطق کسب و کار را اجرا می‌کند، پایگاه داده (Database) داده‌های ماندگار مختص اپلیکیشن (application specific persistence data‌) را جمع آوری یا ذخیره می‌کند و رابط کاربری (UI) داده‌ها را به کاربر نشان می‌دهد.با این حال این نوع سیستم دارای چند مشکل است. همه‌ی کدها (لایه‌ی نمایش، لایه‌ی کسب و کار و لایه‌ی دسترسی به داده‌ها) در یک بخش و قسمت حفظ می‌شوند. یعنی یک اپلیکیشن یا فریمورک وجود دارد و تمامی بخش ها در آن قسمت نگهداری و حفظ میشوند. اگرچه ما قاعدتاً سرویس‌هایی مانند سرویس JMS و سرویس دسترسی داده‌ها (Data-Access service) را تقسیم می‌کنیم، آن‌ها در همان فریمورک یا مجموعه کدها هستند ولی به صورت مجزا توسعه داده میشوند. ممکن است هربخشی تیم مجزایی داشته باشد که روی یک سرویس یا بخش کار کنند ولی تمام کدها یک جا مستقر هستند.در معماری مونولیتیک حتی با اینکه پروژه‌ای چند ماژولی ایجاد کرده‌ایم، یک ماژول به ماژول دیگری وابسته است و از این گذشته ممکن است این ماژول به ماژول‌های وابسته‌ در مسیر کلاس خود نیاز داشته باشد. یعنی ممکن است مثلا کلاس پرداخت از یک نمونه از کلاس کاربر (Instance )  یا محصول نیاز داشته باشد که در همان مسیر باشد و یا در مسیر دیگر.شاید حتی در این معماری از محیط توزیع شده (Distributed) استفاده می‌کنیم، ولی خب این ماژول  یا ماژول ها تحت شرایط فرآیندی واحدی اجرا می‌شود.بنابراین در یک فرآیند واحد (منظور یک فرآیندی است که قرار است یک کار یکتا انجام دهد) سرویس‌های گوناگونی با یکدیگر در ارتباط هستند. برای دستیابی به این امر تمامی برنامه‌ها و کتابخانه‌های مورد نیاز آن‌ها در هر بخشی (scope) از اپلیکیشن مورد نیاز است.به عنوان مثال فرض کنید یک سرویس JMS میخواهد از لایه دسترسی به داده ها استفاده کند. کانتینر JMS به فایل های JAR لایه دسترسی به داده ها و نیز فایل های JAR که در لایه دسترسی به داده ها وابسته هستند (وابستگی های سطح دوم ) نیاز پیدا میکند. در این معماری ایرادهای زیادی وجود دارد و معماری در ماهیت خود انعطاف‌ پذیر نیست.در اینجا برخی از ایرادهای که در معماری مونولیتیک با آن رو به رو می‌شویم را معرفی می‌کنیم.ایراد اولگفتیم که در این معماری یک فریمورک واحد وجود دارد و به تدریج رشد می‌کند (برای اینکه برایتان روشن تر شود فرض کنید یک اپلیکیشن با فریمورک Spring یا لاراول نوشته شده است و تمام تیم ها بر روی همان فریمورک کار میکنند. تیم های بکند و فرانت جداگانه بر روی بخش های مختلف آن در حال کار هستند). هر برنامه نویس، چه یک توسعه دهنده‌ی رابط کاربری باشد یا یک توسعه دهنده‌ی لایه‌ی کسب و کار، در یک جا یعنی همان پایگاه کد یکسان کامیت می‌کنند که باعث بسیاری از مشکلات خواهد شد. ممکن است تضاد پیش بیاید و یا کدها کارآیی خودشان را بخاطر خطاهای انسانی از دست بدهند و در نتیجه مدیریت آن بسیار مشکل خواهد بود. فرض کنید که یک توسعه دهنده‌ای به تنهایی بر روی ماژول JMS کار می‌کند. او مجبور است که کل کدها و فریمورک نوشته شده را بر روی کامپیوتر خودش pull کند و کل ماژول را طوری تنظیم کند که تنها روی سرور لوکال (local server) خودش کار کند. چرا؟ او تنها باید روی ماژول JMS تمرکز کند ولی وضعیت فعلی به او این اجازه را نمی‌دهد.ایراد دومهمان طور که یک پایگاه کد وجود دارد و ماژول‌ها به یکدیگر وابسته هستند کوچک‌ترین تغییر در یک ماژول نیاز به تولید دوباره‌ی همه‌ی برنامه‌ها و استقرار آن‌ها روی تمام سرورهای موجود در یک محیط توزیع شده دارد.فرض کنید در یک پروژه‌ی چند ماژولی که ماژول JMS و ماژول کسب و کار به ماژول دسترسی به داده‌ها وابسته هستند. یک تغییر ساده در ماژول دسترسی به داده‌ها بدین معنی است که ما باید دوباره ماژول JMS و ماژول کسب و کار را پیکربندی و آن‌ها را روی تمام سرورهای موجود مستقر کنیم.ایراد سومهمان طور که نرم‌افزار یکپارچه از معماری سه لایه استفاده می‌کند سه تیمی که توانایی اجرای وظایف مختلف دارند در توسعه‌ی یک ویژگی دخیل هستند و یک هدف مشترک دارند. با این که یک معماری سه لایه اجازه‌ی تقسیم وظایف را می‌دهد در دراز مدت مرزها جا به جا می‌شوند و لایه‌ها روان بودنشان را از دست می‌دهند و سخت و انعطاف ناپذیر می‌شوند.فرض کنید که یک ویژگی مدیریت فهرست اموال توسعه داده شده است. رابط کاربری (UI)، لایه‌ی کسب و کار و لایه‌ی دسترسی به داده‌ها وظایف خود را دارند اما همه خواهان به دست گرفتن کنترل بخش کسب و کار اصلی هستند تا وقتی که خطاها مشاهده شدند بتوانند آن‌ها را برطرف کنند و به لایه‌ی توسعه دهنده‌ی دیگری وابسته نباشند. به خاطر این رقابت مرزها به جا به جا شدن ختم می‌شوند که منجر به ناکارآمدی معماری می‌شود.ایراد چهارمدر بسیاری از پروژه‌ها متوجه شدم که یک تیم توسعه دهنده و یک تیم پیشتیبانی وجود دارد. تیم توسعه دهنده فقط پروژه را توسعه می‌دهد و پس از این که پروژه عرضه شد آن را به تیم پشتیبانی واگذار می‌کنند. من شخصاً از این فرهنگ حمایت نمی‌کنم. اگرچه طی این واگذاری انتقال دانش اتفاق می‌افتد، این فرهنگ مشکل را حل نمی‌کند. به دلیل حوادث مهم تیم پشتیبانی مجبور است از تیم توسعه دهنده کمک بخواهد که به اعتبار آن‌ها لطمه می‌زند.ایراد پنجمبه این علت که سیستم ما یکپارچه است مدیریت تیم نیز همین طور است. اغلب ما تیم‌ها را بر اساس لایه ها مانند توسعه دهنده‌های رابط کاربری، توسعه دهنده‌های بک‌اند (backend)، برنامه نویسان پایگاه داده و… ایجاد می‌کنیم. آن‌ها در حیطه‌ی کاری خود متخصص هستند ولی دانش کمی درباره‌ی لایه‌های دیگر دارند. بنابراین وقتی مشکل مهمی به وجود می‌آید تمام لایه ها را در برمی‌گیرد و بازی سرزنش آغاز می‌شود(هرکسی بقیه را متهم میکند). نه فقط این موضوع بلکه زمان زیادی صرف تصمیم گیری برای این که کدام لایه دچار مشکل شده است و چه کسی باید این مشکل را حل کند می‌شود یعنی هزینه پیدا کردن باگ و خطایابی بالاست.نتفلیکس و آمازون این مشکل را با راه حلی به نام میکروسرویس‌ها بر طرف کرده‌اند.  شکل زیر یک شمای کامل و مفهومی ازین معماری ارائه میدهد:معماری میکروسرویس به ما می‌گوید که محصول یا پروژه‌ای را به سرویس‌های مستقل تقسیم کنیم تا بتواند به تنهایی در آن سطح مستقر و مدیریت شود و به سرویس‌های دیگر وابسته نباشد.سوالی که بعد از دیدن این تعریف به ذهن می آید این است که بر چه اساسی پروژه‌ام را به سرویس‌های مستقل تقسیم کنم؟بسیاری از افراد تفکر غلطی راجع به میکروسرویس‌ها دارند. مفهوم میکروسرویس‌ها این نیست که پروژه‌تان را بر اساس لایه مانند JMS، رابط کاربری، لاگینگ (logging) و… تقسیم کنید.قطعاً این طور نیست. ما باید بر اساس قابلیت و کاربرد آن‌ را تقسیم کنیم. یک قابلیت کامل ممکن است شامل رابط کاربری، کسب و کار، لاگینگ، JMS، دسترسی به داده‌ها، سرویس جست‌وجوی JNDI و… باشد.قابلیت نباید قابل تقسیم باشد یعنی سرویس یا کاربرد مورد نظر را در حد بهینه کوچک و کاربردی در نظر بگیرید و همچنین نباید به قابلیت‌های دیگر وابسته باشد.البته شکستن پروژه به سرویس های کوچک همیشه آسان نیست و تصمیم اینکه چه قابلیت هایی وجود داشته باشد تصمیم آسانی نخواهد بود. همچنین باید به قدر کافی تجربه این کار را داشته باشید که سرویس های کوچک زیاد تولید نکنید که مدیریت آنها بسیار سخت تر از قبل باشد.اگر پروژه از ماژول‌های انبارداری، ثبت سفارش، ایجاد فاکتور، ارسال و سبد خرید تشکیل شده باشد می‌توانیم هر سرویس را به ماژول‌های قابل استقرار مستقل تقسیم کنیم. هر کدام تیم نگهداری، مانیتورینگ مخصص به خود، کش (cache) مربوط به خود، سرورها و پایگاه داده‌ی خود را دارند. بنابراین به وسیله‌ی میکروسرویس‌ها پایگاه داده‌ی متمرکزی وجود ندارد و هر ماژول پایگاه داده‌ی مخصوص به خود را دارد.این پایگاه داده می‌تواند رابطه‌ای یا NoSQL باشد. این انتخاب بر اساس ماژول به خودتان بستگی دارد و امکان استفاده از فناوری‌های ذخیره سازی مختلف را به وجود می‌آورد.مهم‌ترین بعد فرهنگ میکروسرویس این است که هرکسی که سرویس را توسعه می‌دهد این وظیفه‌ی تیم است که آن را مدیریت کند. این عمل از ایده‌ی واگذاری و مشکلات همراه با آن جلوگیری می‌کند.مزایا و معایب میکروسرویسمزیت اولدرمعماری مونولیتیک شما تنها در قالب یک زبان مانند جاوا (Java) به عنوان کد بیس اصلی برنامه خودتان توسعه می‌دهید اما به وسیله‌ی میکروسرویس‌ها همان طور که هر سرویس مستقل و هر سرویس پروژه‌ای جدید است هر سرویس می‌تواند به هر زبانی که مناسب آن است توسعه داده شود.مزیت دومتوسعه دهندگان و برنامه نویسان تنها بر سرویس مشخصی متمرکز هستند. بنابراین کد بیس بسیار کوچک خواهد بود و توسعه دهنده کد را بسیار خوب خواهد شناخت.مزیت سومهنگامی که سرویسی نیاز به صحبت کردن با سرویس دیگری را دارد این کار را با استفاده از پروتکل های شبکه و API ها مخصوصا REST APIها انجام میدهند. یک سرویس REST وسیله‌ای برای برقراری ارتباط است. بنابراین تبدیل کوچکی به وجود می‌آید. برخلاف SOA پیام‌های میکروسرویس نسبت به ESB حجم کمتری دارند زیرا ESB اطلاعات زیادی برای تبدیل، دسته بندی و مسیریابی پیام‌ها ذخیره می‌کند.پیوست : ESB به مثابه یک مخزن تمامی سرویس‌های ارتباطی نرم‌افزارها را در خود نگهداری می‌کند و هرگاه نیاز به اطلاعاتی از اجزای مختلف سیستم اطلاعاتی باشد ESB سرویس مورد نیاز را در اختیار درخواست کننده قرار می‌دهد.اگر میخواهید بیشتر در مورد ESB بدانید از این لینک استفاده کنیدمزیت چهارمهیچ پایگاه داده‌ی متمرکزی وجود نخواهد داشت. هر ماژول پایگاه داده‌ی خودش را دارد پس داده‌ها دیگر متمرکز نیستند. می‌توانید از پایگاه داده‌ی NoSQL یا رابطه‌ای بسته به ماژول استفاده کنید که همان طور که قبلاً اشاره کردم امکان استفاده از فناوری‌های ذخیره سازی مختلف وجود دارد.بسیاری از افراد فکر می‌کنند که SOA و میکروسرویس‌ها در واقع یک چیز هستند. با توجه به تعریف به نظر یکسان می‌آیند اما SOA به منظور برقراری ارتباط بین سیستم‌های مختلف در طی یک ESB جایی که ESB وظیفه‌ی مدیریت داده‌ها، دسته‌بندی کردن و… را دارد استفاده می‌شود.با این وجود پیام‌هایی که بین میکروسرویس‌ها منتقل میشوند در زمان انتقال تغییر نمی‌کنند (مایکروسرویس ها از یک درگاه پیام گنگ استفاده میکنند و فقط ورودی ها رو از یک سرویس به سرویس دیگر انتقال میدهند) اما گیرنده به اندازه کافی هوشمند است که بتواند کارهایی که ذکر کردیم را انجام دهد. میکروسرویس‌ یک درگاه پیام گنگ دارد اما گیرنده‌های هوشمندی دارد.از آن جایی که میکروسرویس‌ها به وسیله‌ی REST ارتباط برقرار می‌کنند حوزه‌ی تبدیل بسیار کوچک است و تنها یک سرویس از طریق تماس API به سرویس دیگر متصل می‌شود.معایب میکروسرویس‌هااز آن جا که هر بخشی از نرم افزار و هر کاربرد اصلی یک سرویس جداگانه است پس در یک پروژه‌ی بزرگ سرویس‌های بسیار زیادی وجود دارد. مانیتور کردن این سرویس‌ها باعث افزایش سربار می‌شود.نه تنها این مشکل بلکه وقتی که خرابی در سرویسی به وجود می‌آید پیدا کردن آن می‌تواند کاری طاقت فرسا باشد.سرویس‌ها با یکدیگر مدام تماس می‌گیرند و در نتیجه ردیابی مسیر (Tracking path) و عیب یابی را دشوار می‌کند.هر سرویس یک لاگ (log) تولید می‌کند و بنابراین هیچ مانیتورینگ لاگ مرکزی وجود ندارد. این کار بسیار پردردسر است شما فرض کنید صد سرویس دارید و هرکدام لاگ جداگانه برای خودشان دارند حالا بررسی این لاگ ها در زمان وقوع یک خطای مهلک خیلی سخت است و بنابراین ما برای آن به یک سیستم مدیریت لاگ بسیار خوب نیاز پیدا می‌کنیم که جداگانه باید برای اپلیکیشن کلی خود توسعه دهیم.به وسیله‌ی میکروسرویس‌ها هر سرویس به وسیله‌ی API یا فراخوانی از راه دور (remote calls) ارتباط برقرار می‌کند که سربار بیشتری نسبت به فراخوانی‌ هایی که بین فرآیندها در نرم‌افزار مونولینیک صورت می‌گیرند دارد.با این وجود علی رغم همه‌ی خسارت‌ها میکروسرویس‌ها به معنای واقعی تقسیم وظایف را انجام می‌دهند.در مقالات آینده سعی میکنیم تک تک اجزای مایکروسرویس ها را به تفصیل توضیح دهیم.لینک مقاله وبسایت آموزشی PHPADMIN ali ali Sun, 22 Sep 2019 22:59:54 +0330 https://virgool.io/@alifalahati/%D8%AA%D8%BA%DB%8C%DB%8C%D8%B1-%DA%A9%D8%B3%D8%A8-%D9%88-%DA%A9%D8%A7%D8%B1-%D8%AA%D9%88%D8%B3%D8%B7-%D8%A7%D8%A8%D8%B1-%D8%AF%D8%A7%DA%A9%D8%B1-docker-npjhujmo0g5a آیا داکر و کوبرنتس (Kubernetes) نسلی جدید از سرویس‌های ابری هیبریدی ارائه می‌دهند و باعث استقرار نرم‌افزارهای کارآمد می‌شوند؟سازمان‌ها در چند سال گذشته تمرکز خود را از بخش خصوصی به زیرساخت‌های ابری هیبریدی تغییر داده‌اند. انعطاف‌پذیری که ابر هیبریدی ارائه می‌دهد انکارناپذیر است.داکربا این حال مدیران ارشد فنی به سرعت چند راه‌حل ابری هیبریدی یافته‌اند که به آن‌ها اجازه‌ی مدیریت کامل بر زیرساخت‌ها را به هنگام استقرار نرم‌افزارها در شبکه‌هایشان می‌دهد. VMware و OpenStack برای برای حل این مشکل‌ها تلاش کرده‌اند.با به وجود آمدن داکر و کوبرنتس که خود را به عنوان گزینه‌ی متن باز برای استقرار نرم‌افزارهای سازمانی ارائه می‌کنند. ابر هیبریدی (Hybrid cloud) به خودی خود پلتفرمی انعطاف‌پذیر است.گاهیل لوی (Gahl Levy) مدیر تولید در DataStax که مسؤول توسعه‌ی محصولات شرکت در کانتینرها و کوبرنتیس است می‌گوید: «داکر وقتی ارائه شد به تنهایی قواعد بازی را عوض کرد و باعث شد که استقرار نرم‌افزارها بدون وابستگی به پلتفرم در کلِ زیرساخت سازمان ساده‌تر و راحت‌تر شود. پرسنل DevOps به جای رسیدگی به نیازهای سرور فردی می‌توانند بر کانتینر کردن نرم‌افزارها تمرکز کنند. سپس آن‌ها می‌فهمند که نرم‌افزارها به همان شیوه در محل و در محیط‌های ابری هیبرید در کلِ ابر کار می‌کنند.جا به جا کردن نرم‌افزارها به کانتینرهای استاندارد شده کارآمدی و مدیریت سیستم را بهبود می‌بخشد. یک کانتینر می‌تواند شامل تمامی خصوصیت‌های ران‌تایم‌ (runtime) مانند کد، ابزارهای سیستم، کتابخانه‌ی سیستم و تنظیمات باشد. برخلاف ماشین‌های مجازی کانتینرها کارآمدی بیشتری دارند و علاوه بر آن قابل حمل هستند که یک سناریوی ایده‌آل برای استقرار ابر هیبریدی است.ابر داکربرای فهمیدن اینکه داکر و معماری‌های کانتینر باید مرکز توجه مدیران ارشد فناوری اطلاعات باشد سیلیکون (Silicon) با مارکو پالادینو (Marco Palladino) هم‌بنیان‌گذار و مدیر ارشد فنی کونگ (Kong) که گسترده‌ترین پلتفرم متن باز API را داراست صحبت کرده‌است.سیلیکون با پرسیدن این سؤال که آگاهی کنونی داکرها میان مدیران ارشد فناوری اطلاعات چیست شروع کرد.«داکر، فناوری ای که در سال ۲۰۱۳ (شش سال پیش) به وجود آمد، اکنون به اندازه‌ی کافی محبوب هست که توسط جمع کثیری از مدیران ارشد فناوری اطلاعات به خصوص به خاطر استفاده این فناوری در بانکداری و امور مالی شناخته شود.» پالادینو بیان کرد: « چیزی که باعث تفاوت می‌شود میزان تخصص و درک این فناوری است. با این حال پس از گذشت بیش از نیمی از یک دهه لازم به ذکر است که اگاهی داکر برقرار شده‌است.»چه اندازه داکر و کوبرنتس در خلق موفقیت آمیز و استقرار سرویس‌های ابری هیبریدی حیاتی بودند؟«سرویس‌های ابری هیبریدی الگوی وابسته به معماری را توصیف می‌کنند در حالی که داکر و کوبرنیتس فناوری‌اند. مزایای اصلی داکر ارائه‌ی راهی استاندارد شده برای بسته بندی و توزیع کردن نرم‌افزارها در کل پلتفرم‌های مختلف بدون در نظر گرفتن سیستم عامل اصلی یا معماری آن‌ها است.»docker - kubernates«کوبرنتس وابستگی را به APIهای متعلق به یک شرکت خاص (مانند AWS API، the Azure API و …) از بین می‌برد و آن را با API پرتابل و غیر وابسته به پلتفرم جایگزین می‌کند و به همین ترتیب این فناوری را کاملاً مناسب محیط‌های هیبریدی می‌کند. کوبرنتس به هیچ وجه یک فناوری ساده نیست و نباید به عنوان یک علاج قطعی برای مشکلات زیرساختی و معماری موجود دیده شود. سازمان باید منابع را صرف ساختن یک تیم تحقیق و توسعه‌ی توانا به منظور بردن بیشترین نفع از تجهیز کردن جدید و مدرن کند.»نقاط فشار کنونی که مدیران ارشد فناوری اطلاعات به هنگام مدیریت داکر در کسب و کارها یا سازمان‌هایشان احساس می‌کنند چیست؟«پراکندگی (Fragmentation). هنگامی که ممکن است برخی ورک لودها (workload) در داکر و پلتفرم‌های مدرن که برای هماهنگ کردن کانتینرها مانند کوبرنتس به کار می‌روند به خوبی اجرا شوند هنوز احتمال اینکه نرم‌افزارهای قدیمی در این محیط‌های چالش‌برانگیز اجرا شوند سخت است که به طرز مؤثری اختلاف سرعت در سازمان به وجود می‌آورد که می‌تواند در طی زمان باعث پراکندگی شود.»«هم‌چنین وجود برنامه‌ای در محل برای تطبیق دادن این پراکندگی با داشتن راهبردی که به مدیران ارشد فنی اجازه‌ی وصل کردن، امن کردن، مانیتور کردن و مستقر کردن نرم‌افزارهای مدرن و قدیمی را در کل محیط‌های قدیمی و هم زمان در کانتینرها می‌دهد مهم است. این برنامه هم‌چنین به جلوگیری از قفل شدن عرضه‌کننده ابر (cloud vendor) به هرقیمتی به هنگام به کارگیری یک راهبرد چند ابری (multi-cloud strategy) کمک می‌کند.»آیا ماشین‌های مجازی اضافی‌اند؟ آیا کانتینرهای داکر آینده‌ی توسعه و استقرار در کل ابر هیبریدی هستند؟«هنوز برای اجرای کانتینرهای داکر به ماشین‌های مجازی نیاز است چون جایی است که پلتفرم‌های مدرن که برای هماهنگ کردن کانتینرها مانند کوبرنتس به کار می‌روند در نهایت اجرا می‌شوند. من داکر را جایگزینی برای ماشین‌های مجازی در نظر نمی‌گیرم. داکر یک لایه‌ی انتزاعی اضافی است که بالای ماشین‌های مجازی قرار دارد و به آن‌ها اجازه می‌دهد تا یک مدیر منابع کارآمد هنگامی که در حال ارائه‌دادن توزیع استاندارد شده برای هر ورک لود در هر ابر و مرکز داده هستند باشند. به همین خاطر من داکر را به عنوان آینده‌ی ابر هیبریدی می‌بینم.»از دید DevOps، آیا داکر و همکاران راهی جدید برای دستیابی توسعه‌ی نرم‌افزار به پلتفرم‌های ابری پیشنهاد می‌دهد؟«داکر و اکوسیستم آن روش تفکر غیر وابسته به پلتفرم و توزیع شده درباره‌ی نرم‌افزارهای ما ارائه می‌دهد. بدین وسیله آن‌ها ساختن سیستم‌های جداشده که از سیستم‌های یکپارچه‌ی قدیمی فاصله می‌گیرند را راحت‌تر می‌کند.»«در اینجا ضروری است که به چالش‌های جدید هنگام به کارگیری معماری‌های مدرن که بهره‌وری تیمی را به وسیله‌ی کم‌کردن ناسازگاری با ساختن، بسته‌بندی کردن و توزیع کردن نرم‌افزارمان بالا می‌برد اشاره کرد. این چالش‌ها شامل امنیت داده‌ها، کاهش تأخیر عملکرد و اجرای سیستم‌های گسترده، جدا شده و توزیع‌شده در چندین پلتفرم هستند.»«داکر و کوبرنتس فرصت بزرگی را جهت مدرن سازی و اثرگذاری مثبت بر کسب و کار تا زمانی که سازمان به سرمایه‌گذاری بر تیم تحقیق و توسعه ادامه می‌دهد و فناوری توانمند را که برای بهتر کار کردن با عصر جدید از نرم‌افزار ساخته شده است به کار می‌گیرد ارائه می‌دهد.»چگونه داکر و کوبرنتس معماری‌های میکروسرویس‌ها را تغییر می‌دهند؟«با اجازه دادن به نرم‌افزارها جهت بسته‌بندی شدن، توزیع شدن و مستقر شدن سریع در محیط‌های هیبرید و چندابری، داکر و کوبرنتس کار ساختن نرم‌افزارهای جداشده(Decoupled) و توزیع شده که هرجایی می‌توانند راه‌اندازی شوند را راحت‌تر می‌کند.«با این حال هنگامی که سیستم‌هایمان را به میکروسرویس‌ها تقسیم می‌کنیم قادر به استفاده بیشتری از ارتباط API روی یک شبکه در نرم‌افزارهایمان هستیم. عملکرد و امنیت جهت رمزگذاری، امن کردن و سرعت دادن به جریان اطلاعات در سرویس‌هایمان حیاتی‌تر می‌شود.هنگامی که داکر و کوبرنتس به ما اجازه‌ی استقرار ورک لودها را در چندین ابر و پلتفرم می‌دهد، این امر مهم است که زیاد به راه‌حل‌های عرضه کننده‌ی ابر برای امن و مانیتور کردن ترافیکمان متکی نباشیم. این عمل در بلند مدت باعث ایجاد ناسازگاری‌ها و پراکندگی می‌شود. در عوض، ما خواستار به کارگیری فناوری غیر وابسته به پلتفرم هستیم که می‌تواند در دسته‌ی کوبرنتس ما که چگونگی مدیریت و اداره کردن سرویس‌هایمان را در هر محیط و ابری تقویت می‌کند مستقر شود.»آینده‌ی نرم‌افزارهای کانتینرشده به چه صورت است؟«ما قادر به استفاده‌ی کامل از نرم‌افزارهای کانتینرشده هنگامی که ما مسیری توانمند کننده برای نرم‌افزارهای قدیمی و استفاده‌‌ی مجدد از مواردی که به تغییر به این معماری‌های مدرن منجر می‌شوند فراهم می‌کنیم هستیم.»«نرم‌افزارهای کانتینرشده اساس و پایه‌ی کاری که به وسیله‌ی آن سیستم‌های پیچیده‌تر و خود ترمیم در طول زمان می‌سازیم خواهند شد. فناوری‌های بدون سرور و FaaS (Function as a service) نیز گرایش‌های جالب فناوری‌اند چون آن‌ها دیدگاهی از آینده را ترسیم می‌کنند. جایی که دیگر به کانتینرها نیازی نداریم.»آینده‌ی کانتینرهااز آنجا که ابر هیبریدی بسط و توسعه می‌‌یابد مدیریت این شبکه‌ها و نرم‌افزارهایی که شامل می‌شوند نیازمند رویکردی جدید خواهد بود. جابه‌جایی پلتفرم‌هایی مانند داکر و کوبرنتس توانایی تغییر چگونگی استقرار شبکه‌ها توسط مدیران ارشد فناوری اطلاعات و مدیران ارشد فنی را دارد.به گفته‌ی لی اچیسون (Lee Atchison) مدیر ارشد و معمار ابری شرکت نیو رلیک (New Relic) کانتینرها کوچکتر و چابک‌تر خواهند شد. «بیشتر تمرکز روی ایمیج‌های پایه استاندارد شده خواهد بود که باعث می‌شود وزن کانتینرها سبک‌تر شود و به سیستم عامل اصلی اجازه‌ی تمرکز بر بهینه‌سازی انواع ایمیج‌های پایه را می‌دهد.»با سخنان اسکات مک‌کارتی (Scott McCarty) مدیر ارشد محصول، واحد مدیریت کانتینرها در شرکت رد هت (Red Hat) نتیجه‌گیری می‌شود: «ما از سال ۲۰۱۴ توسعه جدی در آگاهی کانتینرها مشاهده کرده‌ایم. به کارگیری کانتینرها مانند لینوکس نهضت رو به رشدی بود. این امر با پیش قدم شدن توسعه دهندگان و مدیران سیستم‌ها در جستجوی مدیریت بهتر استقرارها (و حذف آن‌ها در پایان کار) آغاز شد. این عمل در ۱۸الی۲۴ ماه اخیر به مسیری راهبردی برای مؤسسه‌ها تبدیل و توجه بیشتر مدیران ارشد فناوری اطلاعات به آن جلب شد.»استفاده‌ی فعلی از ماشین‌های مجازی تا پشتیبانی کردن از اکثریت استقرار نرم‌افزارها در ابر هیبریدی برای آینده‌ای قابل پیش‌بینی ادامه خواهد داشت. با این حال کانتینرها قوی‌تر و انعطاف‌پذیرتر هستند. به ویژه DevOps جهشی را به سمت این فناوری در کوتاه مدت خواهد داشت. از آنجا که کسب و کار نیاز به چابک‌تر شدن دارد، داکر و کوبرنتس فناوری‌هایی هستند که تعداد کمی از مدیران ارشد فناوری اطلاعات و مدیران ارشد فنی می‌توانند آن‌ها را نادیده بگیرند.برای دیدن مطالب بیشتر به وبسایت PHPADMIN سر بزنید :) ali ali Thu, 19 Sep 2019 23:57:35 +0430 https://virgool.io/coderlife/%D9%85%D9%81%D9%87%D9%88%D9%85-trait-%D8%AF%D8%B1-%D8%B2%D8%A8%D8%A7%D9%86-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-php-jnvydhvrutq2 trait in php - مفهوم trait یکی از مشکلاتی که در زبان PHP وجود دارد و در زبان های دیگر هم این موضوع وجود دارد عدم ارث بری یک کلاس از چندین کلاس است. یعنی در آن واحد کلاس شما میتواند از یک کلاس ارث بری کند در صورتی که در بعضی از مواقع کلاس شما نیاز دارد از چندین کلاس ارث بری کند. خب این موضوع چه اثری دارد؟ قاعدتا ارث بری متدها از چندین کلاس مختلف برای بهینه نوشتن کد ها مطلوب تر است. مثلا شما یک تکه کد دارید که در چند کلاس نیاز هست که استفاده شود حال در یک کلاس به خصوص از این تکه کد باید استفاده کنید و همچنین از تابع دیگری که در کلاس دیگر نوشته شده است نیز باید استفاده کنید.خب راه حل چیست؟در PHP 5.4 یک ویژگی جدید به نام Trait  افزوده شد که دقیقا این مشکل را برای ما حل میکند و در حقیقت کاربرد اصلی اونها از بین بردن محدودیتی بود که کلاس های php  با آن روبه رو بودند و اون محدودیتی بود که در بالا به آن اشاره کردیم. الان با استفاده از فراخوانی یک trait در واقع میتونیم بگیم داریم ازیک کلاس ارت بری کنیم.به زبان ساده Traits ، یک گروه از متدها است که می خواهید در کلاس دیگری قرار دهید. برای استفاده از آنها کافیست در اول فایل بنویسید trait. به همین سادگی!فرض کنید یک کلاس User داریم و قرار است از یک سری مجموعه تابع که نقش ها و مجوز های کاربر را بررسی میکنند استفاده کنیم ... برای خواندن ادامه مقاله بر روی این لینک کلیک کنید. ali ali Fri, 13 Sep 2019 21:04:53 +0430 https://virgool.io/phpadmin/%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-%D9%84%D8%A7%D8%B1%D8%A7%D9%88%D9%84-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D8%A8%D8%B2%D8%B1%DA%AF-%D9%88-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86%DB%8C-enterprise-app-z4jfn2g0pffo Laravel Framework این مطلب ترجمه مطلب منتشر شده در وب سایت لاراول دیلی و مصاحبه با Taylor Otwell و Jeffrey Way در مورد قابلیت های لاراول است. لینک اصلی مطلبدیروز به قسمت جدید پادکست لاراول با حضور تیلور آتول (Taylor Otwell)، جفری وی (Jeffrey Way) و مت استافر (Matt Stauffer) گوش دادم. آن‌ها در نهایت درباره‌ی ساختن نرم‌افزارهای بزرگ به وسیله‌ی لاراول صحبت کردند. در آخر این سؤال که «آیا لاراول به اندازه‌ی کافی مناسب استفاده در پروژه‌های مهم و بزرگ است؟» بسیار پرسیده شد. به این خاطر که از پادکست‌ رونوشتی ارائه نمی‌شود و گوش دادن به پادکست ۵۰دقیقه‌ای بسیار خسته‌کننده است تصمیم گرفتم که خلاصه‌ای به همراه نقل قول‌ها به صورت مکالمه و پاسخ‌ها را به شکل خواناتری مانند پرسش و پاسخ و نکته‌های مهم و همچنین لینک‌های مربوط بنویسم. پس بیایید شروع کنیم! ادامه مطلب ali ali Thu, 29 Aug 2019 00:18:21 +0430