https://virgool.io/phpadmin/feed وب سایت برنامه نویسی fa 2026-06-10 21:26:14 https://files.virgool.io/upload/publication/c7mcy2v7uklw/m6tb8g.png https://virgool.io/phpadmin 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 phpadmin 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 ورودی را بر اساس یک عبارت معمولی بازنویسی می کند تا یک بلوک موقعیت مکانی دیگر بتواند آن را اداره کند.مقالات جدید در وب سایت phpadmin 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 را که توسط متدهای دیگر به وجود آمده به این صورت که وقتی کلاینت اولین درخواست را کامل میکند بتواند کانکشن را باز نگه دارد و درخواست های بیشتری را از این سوکت ارسال کند حل میکند و این موضوع باعت کار کاهش اضافه بار میشود. برای خواندن مقالات مرتبط به بلاگ من سر بزنید phpadmin 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 مرده در صورتی که تقریبا ۷۵ درصد وب بر روی اون استواره. ۷۵ درصد عدد منطقی ای برای یک زبان مرده نیست.برای مطالعه ادامه این مقاله بر روی این لینک کلیک کنید. phpadmin ali Tue, 01 Oct 2019 23:49:29 +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 phpadmin ali Sun, 22 Sep 2019 22:59:54 +0330 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) گوش دادم. آن‌ها در نهایت درباره‌ی ساختن نرم‌افزارهای بزرگ به وسیله‌ی لاراول صحبت کردند. در آخر این سؤال که «آیا لاراول به اندازه‌ی کافی مناسب استفاده در پروژه‌های مهم و بزرگ است؟» بسیار پرسیده شد. به این خاطر که از پادکست‌ رونوشتی ارائه نمی‌شود و گوش دادن به پادکست ۵۰دقیقه‌ای بسیار خسته‌کننده است تصمیم گرفتم که خلاصه‌ای به همراه نقل قول‌ها به صورت مکالمه و پاسخ‌ها را به شکل خواناتری مانند پرسش و پاسخ و نکته‌های مهم و همچنین لینک‌های مربوط بنویسم. پس بیایید شروع کنیم! ادامه مطلب phpadmin ali Thu, 29 Aug 2019 00:18:21 +0430