چگونه کوارکوس برنامه نویسی ضروری و واکنشی را با هم ترکیب می کند

امسال قصد داریم به طور جدی تم های کانتینری را توسعه دهیم، Cloud-Native Java и کوبرنیتس. ادامه منطقی این موضوعات داستانی در مورد چارچوب کوارکوس خواهد بود در نظر گرفته شده در هابره مقاله امروز کمتر در مورد طراحی "جاوا فوق سریع زیر اتمی" و بیشتر در مورد وعده ای است که کوارکوس به Enterprise می دهد.

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

جاوا زیراتمی فوق سریع به سطح جدیدی رسیده است!

42 نسخه، 8 ماه کار اجتماعی و 177 توسعه دهنده شگفت انگیز - نتیجه همه اینها انتشار در نوامبر 2019 بود. کوارکوس 1.0، نسخه ای که نقطه عطف مهمی را در توسعه پروژه نشان می دهد و ویژگی ها و قابلیت های جالب زیادی را ارائه می دهد (شما می توانید در مورد آنها بیشتر بخوانید اعلامیه).

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

میکروسرویس ها, معماری های رویداد محور и بدون سرور-functions - همانطور که می گویند همه اینها امروزه در حال افزایش است. اخیراً، ایجاد معماری‌های ابرمحور بسیار آسان‌تر و در دسترس‌تر شده است، اما مشکلات همچنان وجود دارد - به‌ویژه برای توسعه‌دهندگان جاوا. به عنوان مثال، در مورد توابع و میکروسرویس های بدون سرور، نیاز فوری به کاهش زمان راه اندازی، کاهش مصرف حافظه و همچنان ایجاد راحت تر و لذت بخش تر کردن توسعه آنها وجود دارد. جاوا در سال های اخیر پیشرفت های زیادی داشته است، مانند بهبود عملکرد ارگونومی برای ظروف و غیره. با این حال، کارکرد صحیح جاوا در یک کانتینر همچنان چالش برانگیز است. بنابراین ما با بررسی برخی از پیچیدگی‌های ذاتی جاوا، که به ویژه در هنگام توسعه برنامه‌های جاوای کانتینرگرا، شدیدتر می‌شوند، شروع می‌کنیم.

ابتدا بیایید به تاریخ نگاه کنیم.

نهرها و کانتینرها

با شروع نسخه 8u131، جاوا به دلیل بهبود عملکرد ارگونومی، کم و بیش از کانتینرها پشتیبانی کرد. به‌ویژه، JVM اکنون می‌داند که روی چند هسته پردازشگر در حال اجراست و می‌تواند بر این اساس، thread pools (معمولاً fork/join pool) را پیکربندی کند. البته، این عالی است، اما فرض کنید ما یک برنامه وب سنتی داریم که از سرورهای HTTP استفاده می کند و در Tomcat، Jetty و غیره اجرا می شود. در نتیجه، این برنامه به هر درخواست یک رشته مجزا می‌دهد و به آن اجازه می‌دهد تا در زمان انتظار برای عملیات ورودی/خروجی، به عنوان مثال، هنگام دسترسی به پایگاه داده، فایل‌ها یا سرویس‌های دیگر، این رشته را مسدود کند. یعنی اندازه چنین برنامه ای به تعداد هسته های موجود بستگی ندارد، بلکه به تعداد درخواست های همزمان بستگی دارد. علاوه بر این، این بدان معنی است که سهمیه یا محدودیت در Kubernetes در تعداد هسته‌ها در اینجا کمک چندانی نخواهد کرد و موضوع در نهایت به throttling ختم می‌شود.

فرسودگی حافظه

رشته ها حافظه هستند. و محدودیت حافظه درون ظرفی به هیچ وجه نوشدارویی نیست. فقط کافی است تعداد برنامه ها و رشته ها را افزایش دهید و دیر یا زود با افزایش شدید فرکانس سوئیچینگ و در نتیجه کاهش عملکرد مواجه خواهید شد. همچنین، اگر برنامه شما از فریمورک‌های میکروسرویس سنتی استفاده می‌کند، یا به یک پایگاه داده متصل می‌شود، یا از حافظه پنهان استفاده می‌کند، یا در غیر این صورت از حافظه استفاده می‌کند، بدیهی است که به ابزاری نیاز دارید که به شما امکان می‌دهد به داخل JVM نگاه کنید و ببینید که چگونه حافظه را بدون از بین بردن آن مدیریت می‌کند. خود JVM (به عنوان مثال، XX:+UseCGroupMemoryLimitForHeap). و حتی اگر از جاوا 9، JVM یاد گرفته است که cgroup ها را بپذیرد و بر اساس آن سازگار شود، ذخیره و مدیریت حافظه یک موضوع نسبتاً پیچیده باقی مانده است.

سهمیه ها و محدودیت ها

جاوا 11 پشتیبانی از سهمیه های CPU (مانند PreferContainerQuotaForCPUCount) را معرفی کرد. Kubernetes همچنین از محدودیت ها و سهمیه ها پشتیبانی می کند. بله، همه اینها منطقی است، اما اگر برنامه مجدداً از سهمیه تخصیص داده شده فراتر رود، دوباره به اندازه - همانطور که در مورد برنامه های جاوا سنتی است - با تعداد هسته ها و با تخصیص یک رشته مجزا برای هر کدام به دست می آوریم. درخواست، پس معنای کمی در همه این وجود دارد.
علاوه بر این، اگر از سهمیه‌ها و محدودیت‌ها یا عملکردهای مقیاس‌پذیر پلتفرم زیربنایی Kubernetes استفاده کنید، مشکل نیز خود به خود حل نمی‌شود. ما صرفاً منابع بیشتری را برای حل مشکل اصلی صرف می کنیم یا در نهایت به مصرف بیش از حد می پردازیم. و اگر این یک سیستم با بار بالا در یک ابر عمومی عمومی باشد، تقریباً مطمئناً در نهایت از منابع بیشتری از آنچه واقعاً نیاز داریم استفاده می کنیم.

و با همه اینها چه باید کرد؟

به بیان ساده، از کتابخانه ها و چارچوب های ورودی/خروجی ناهمزمان و غیر مسدود کننده مانند Netty استفاده کنید. Vert.x یا آکا آنها به دلیل ماهیت واکنش پذیری که دارند برای کار در ظروف بسیار مناسب تر هستند. به لطف عدم مسدود کردن I/O، همان رشته می تواند چندین درخواست همزمان را پردازش کند. در حالی که یک درخواست منتظر نتایج ورودی/خروجی است، رشته پردازش آن آزاد می شود و توسط درخواست دیگری تحویل می شود. و هنگامی که نتایج I/O در نهایت می رسد، پردازش درخواست اول ادامه می یابد. با پردازش درخواست‌ها در یک رشته، می‌توانید تعداد کل رشته‌ها را کاهش دهید و مصرف منابع برای پردازش درخواست‌ها را کاهش دهید.

با I/O غیر مسدود، تعداد هسته‌ها به یک پارامتر کلیدی تبدیل می‌شود زیرا تعداد رشته‌های ورودی/خروجی را که می‌توان به صورت موازی اجرا کرد را تعیین می‌کند. هنگامی که به درستی استفاده می شود، این به شما امکان می دهد تا به طور موثر بار را بین هسته ها توزیع کنید و بارهای کاری بالاتر را با منابع کمتر مدیریت کنید.

چطور، این همه است؟

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

ابتدا باید یاد بگیرید که چگونه کدی بنویسید که به صورت ناهمزمان اجرا شود. هنگامی که شروع به استفاده از I/O غیر مسدود کردید، باید به صراحت مشخص کنید که هنگام دریافت پاسخ به یک درخواست چه اتفاقی می افتد. به سادگی مسدود کردن و انتظار دیگر کار نخواهد کرد. در عوض، می‌توانید تماس‌های برگشتی را ارسال کنید، از برنامه‌نویسی واکنشی یا ادامه استفاده کنید. اما این همه چیز نیست: برای استفاده از ورودی/خروجی غیرمسدود، هم به سرورهای غیر مسدود کننده و هم به کلاینت ها، ترجیحاً در همه جا نیاز دارید. در مورد HTTP، همه چیز ساده است، اما پایگاه های داده، سیستم های فایل و بسیاری موارد دیگر نیز وجود دارد.

و اگرچه واکنش انتها به انتها کل کارایی را به حداکثر می رساند، چنین تغییری در عمل می تواند دشوار باشد. بنابراین، توانایی ترکیب کد واکنشی و دستوری یک پیش نیاز به منظور:

1. استفاده موثر از منابع در پربارترین مناطق سیستم نرم افزاری؛
2. از کد سبک ساده تری در قسمت های باقی مانده آن استفاده کنید.

معرفی کوارکوس

در واقع، این جوهر کوارکوس است - ترکیب مدل‌های واکنشی و ضروری در یک محیط زمان اجرا.

Quarkus مبتنی بر Vert.x و Netty است، با طیف وسیعی از چارچوب‌ها و افزونه‌های واکنش‌گرا برای کمک به توسعه‌دهنده. کوارکوس نه تنها برای ساخت میکروسرویس های HTTP، بلکه برای معماری های رویداد محور نیز طراحی شده است. به دلیل ماهیت واکنشی آن، با سیستم های پیام رسانی (آپاچی کافکا، AMQP و غیره) بسیار موثر عمل می کند.

ترفند این است که چگونه از یک موتور واکنشی یکسان برای کد دستوری و واکنشی استفاده کنید.

کوارکوس این کار را به خوبی انجام می دهد. انتخاب بین امری و واکنشی واضح است - از یک هسته واکنشی برای هر دو استفاده کنید. چیزی که واقعاً به آن کمک می کند کد سریع و غیر مسدود کننده است که تقریباً همه چیزهایی را که از رشته رویداد-حلقه عبور می کند، با نام IO thread کنترل می کند. اما اگر REST کلاسیک یا برنامه های کاربردی سمت کلاینت دارید، Quarkus یک مدل برنامه نویسی ضروری را آماده کرده است. به عنوان مثال، پشتیبانی از HTTP در Quarkus مبتنی بر استفاده از یک موتور غیر مسدود کننده و واکنشی (Eclipse Vert.x و Netty) است. تمام درخواست های HTTP دریافت شده توسط برنامه شما ابتدا از طریق یک حلقه رویداد (IO Thread) ارسال می شود و سپس به بخشی از کد ارسال می شود که درخواست ها را مدیریت می کند. بسته به مقصد، کد مدیریت درخواست را می توان در یک رشته مجزا فراخوانی کرد (به اصطلاح در مورد سرولت ها و Jax-RS استفاده می شود) یا از نخ منبع ورودی/خروجی (مسیر واکنشی) استفاده کرد.

اتصال‌دهنده‌های سیستم پیام‌رسان از کلاینت‌های غیرمسدود کننده در بالای موتور Vert.x استفاده می‌کنند. بنابراین، می توانید به طور موثر پیام ها را از سیستم های میان افزاری پیام رسانی ارسال، دریافت و پردازش کنید.

این سایت Quarkus.io در اینجا چند آموزش خوب برای کمک به شما برای شروع کار با Quarkus آورده شده است:

• استفاده از مسیرهای واکنشی
• کلاینت های واکنشی SQL
• استفاده از آپاچی کافکا با پیام‌رسانی واکنشی
• استفاده از AMQP با پیام‌رسانی واکنشی
• با استفاده از Vertx API

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

منابع مفید

• 4 دلیل برای امتحان کوارکوس
• وب سایت پروژه کوارکوس – quarkus.io
• پروژه کوارکوس در GitHub – github.com/quarkusio/quarkus
• پروژه کوارکوس توییتر – twitter.com/QuarkusIO
• گفتگوی پروژه کوارکوس – quarcusio.zulipchat.com
• انجمن های پروژه کوارکوس – group.google.com/forum/#!forum/quarkus-dev

10 درس ویدیویی در مورد کوارکوس برای آشنایی با موضوع

همانطور که در وب سایت می گویند Quarkus.io, کوارکوس - آیا کوبرنیتسپشته جاوا گرا، که برای GraalVM و OpenJDK HotSpot طراحی شده و از بهترین کتابخانه ها و استانداردهای جاوا مونتاژ شده است.

برای کمک به درک موضوع، ما 10 درس ویدیویی را انتخاب کرده ایم که جنبه های مختلف کوارکوس و نمونه هایی از استفاده از آن را پوشش می دهد:

1. معرفی Quarkus: The Next Generation Java Framework برای Kubernetes

توسط توماس کوارنستروم و جیسون گرین
هدف پروژه Quarkus ایجاد یک پلتفرم جاوا برای Kubernetes و محیط های بدون سرور و ترکیب مدل های برنامه نویسی واکنشی و ضروری در یک محیط زمان اجرا واحد است تا توسعه دهندگان بتوانند به طور انعطاف پذیری رویکرد خود را هنگام کار با طیف گسترده ای از معماری های کاربردی توزیع شده تغییر دهند. در سخنرانی مقدماتی زیر اطلاعات بیشتری کسب کنید.

2. کوارکوس: جاوا زیراتمی فوق سریع

نویسنده: بر ساتر
این آموزش ویدیویی از DevNation Live نشان می‌دهد که چگونه می‌توان از Quarkus برای بهینه‌سازی برنامه‌های جاوا، APIها، میکروسرویس‌ها و عملکردهای بدون سرور در محیط Kubernetes/OpenShift استفاده کرد و آنها را بسیار کوچک‌تر، سریع‌تر و مقیاس‌پذیرتر کرد.

3. Quarkus و GraalVM: شتاب Hibernate به سرعت فوق العاده و کوچک کردن آن به اندازه های زیر اتمی

نویسنده: سانه گرینوورو
از ارائه یاد خواهید گرفت که کوارکوس چگونه به وجود آمده است، چگونه کار می کند، و چگونه به شما اجازه می دهد کتابخانه های پیچیده ای مانند Hibernate ORM را با تصاویر بومی GraalVM سازگار کنید.

4. توسعه برنامه های بدون سرور را یاد بگیرید

نویسنده: مارتین لوتر
ویدیوی زیر نحوه ایجاد یک برنامه ساده جاوا با استفاده از Quarkus و استقرار آن به عنوان یک برنامه بدون سرور در Knative را نشان می دهد.

5. کوارکوس: از کدنویسی لذت ببرید

نویسنده: ادسون یاناگا
یک راهنمای ویدیویی برای ایجاد اولین پروژه کوارکوس، به شما این امکان را می دهد تا بفهمید چرا کوارکوس قلب توسعه دهندگان را به دست می آورد.

6. جاوا و کانتینرها - آینده آنها با هم چگونه خواهد بود

ارسال شده توسط مارک لیتل
این ارائه تاریخچه جاوا را معرفی می کند و توضیح می دهد که چرا کوارکوس آینده جاوا است.

7. کوارکوس: جاوا زیراتمی فوق سریع

نویسنده: دیمیتریس آندریدیس
مروری بر مزایای Quarkus که توسط توسعه دهندگان به رسمیت شناخته شده است: سادگی، سرعت فوق العاده بالا، بهترین کتابخانه ها و استانداردها.

8. کوارکوس و سامانه های موشکی زیر اتمی

نویسنده: کلمنت اسکوفیه
از طریق ادغام با GraalVM، Quarkus یک تجربه توسعه فوق العاده سریع و یک محیط زمان اجرا زیراتمی را فراهم می کند. نویسنده در مورد جنبه واکنشی کوارکوس و نحوه استفاده از آن برای ساخت برنامه های واکنشی و استریم صحبت می کند.

9. کوارکوس و توسعه سریع برنامه در Eclipse MicroProfile

نویسنده: جان کلینگان
با ترکیب Eclipse MicroProfile و Quarkus، توسعه‌دهندگان می‌توانند برنامه‌های MicroProfile با ویژگی‌های کامل ایجاد کنند که در ده‌ها میلی‌ثانیه راه‌اندازی می‌شوند. این ویدئو به جزئیات نحوه کدگذاری یک برنامه MicroProfile کانتینری برای استقرار در پلتفرم Kubernetes می‌پردازد.

10. جاوا، نسخه "توربو".

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

منبع: www.habr.com