راهنمای میکروسرویس های جاوا. بخش 2: استقرار و آزمایش

ترجمه و اقتباس از Microservices جاوا: راهنمای عملی . لینک قسمت اول راهنما هر برنامه جاوا سمت سرور، و در نتیجه هر میکروسرویس، فقط یک فایل با پسوند jar یا .war است. یک چیز عالی در مورد اکوسیستم جاوا یا بهتر است بگوییم JVM وجود دارد: شما فقط باید یک بار کد جاوا بنویسید و تقریباً روی هر سیستم عاملی قابل اجرا است، البته تا زمانی که کد خود را با نسخه جدیدتر جاوا کامپایل نکرده باشید. نسخه JVM را هدف قرار دهید. درک این موضوع مهم است، به خصوص وقتی صحبت از موضوعاتی مانند Docker، Kubernetes یا (درام رول!) The Cloud باشد. چرا؟ بیایید به سناریوهای مختلف استقرار نگاه کنیم.

نمونه استقرار میکروسرویس جاوای مینیمالیستی

بیایید با مثال بانک ادامه دهیم. بنابراین ما یک فایل monobank.jar (مونولیت) و riskengine.jar تازه استخراج شده (اولین میکروسرویس بررسی ریسک) داریم. همچنین فرض کنید که هر دو برنامه، مانند هر برنامه دیگری در جهان، به یک فایل .properties نیاز دارند. در مورد ما، فقط شامل URL پایگاه داده و اعتبارنامه خواهد بود. یک استقرار حداقل ممکن است از دو دایرکتوری تشکیل شده باشد که چیزی شبیه به این هستند: اول:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 monobank-384.jar

ubuntu@somemachine:/var/www/www.monobank.com/java$ java -jar monobank-384.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

دومین:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 risk-engine-1.jar

ubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

این سؤال را باز می گذارد: چگونه فایل های .properties و jar به سرور می رسند؟ متأسفانه، ممکن است پاسخ های زیادی وجود داشته باشد.

نحوه استفاده از Build Tools، SSH و Ansible برای استقرار میکروسرویس های جاوا

توصیه خسته کننده، اما نه کمتر عالی در مورد نحوه استقرار میکروسرویس های جاوا... در واقع، دقیقاً همان روشی است که مدیران سیستم در طی 20 سال گذشته هر برنامه سرور جاوا را در شرکت ها مستقر کرده اند. این ترکیب است:

• ابزار ساخت مورد علاقه شما (Maven، Gradle)
• SSH/SCP خوب قدیمی برای کپی کردن jars در سرورها
• اسکریپت های Bash برای مدیریت اسکریپت های استقرار و سرورها
• یا حتی بهتر: برخی از اسکریپت های Ansible.

البته، این برای مبتکرانی که به یک ابر تنفسی، سرورهایی با تعادل بار خودکار و غیره نیاز دارند، مناسب نیست. این مدرسه قدیمی واقعا خسته کننده است. با این حال کار می کند!

نحوه استفاده از Docker برای استقرار میکروسرویس های جاوا

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

• یک ظرف (ساده شده) شبیه ماشین مجازی خوب قدیمی است، اما "سبک تر". اگر معنای «آسان‌تر» در این زمینه را نمی‌دانید، لطفاً این پاسخ را در Stackoverflow بررسی کنید .
• کانتینر قابلیت حمل خود را تضمین می کند. یعنی در هر جایی کار می کند. آشنا به نظر می رسد، اینطور نیست؟

خنده دار است که با توجه به قابلیت حمل JVM و سازگاری با عقب، این ویژگی چندان مزیتی به نظر نمی رسد. شما به سادگی می توانید JVM.zip را بر روی هر Raspberry Pi (یا حتی تلفن همراه) دانلود کنید، آن را استخراج کنید و هر فایل jar را اجرا کنید. وضعیت در زبان هایی مانند PHP یا Python تغییر می کند، جایی که ناسازگاری نسخه یا تنظیمات استقرار پیچیده تر است. یا اگر برنامه جاوا شما به بسیاری از سرویس های نصب شده دیگر (با شماره نسخه صحیح) بستگی دارد: به عنوان مثال، پایگاه داده Postgres یا ذخیره ارزش کلید Redis. بنابراین، مزیت اصلی Docker برای میکروسرویس‌های جاوا، یا دقیق‌تر برای برنامه‌های جاوا، این است: توانایی راه‌اندازی محیط‌های تست یا یکپارچه‌سازی همگن با استفاده از ابزارهایی مانند Testcontainers . توسعه های پیچیده آسان تر برای نصب هستند. نرم افزار تالار گفتمان را انتخاب کنید . می‌توانید آن را با یک تصویر Docker نصب کنید، و آن یکی شامل همه چیزهایی است که نیاز دارید، از نرم‌افزار Discourse نوشته شده با روبی، پایگاه داده Postgres، Redis و سینک آشپزخانه. اگر استقرارهای شما مشابه هستند یا می خواهید یک پایگاه داده کوچک اوراکل را اجرا کنید، Docker را امتحان کنید. بنابراین به طور خلاصه، به جای اینکه فقط به فایل jar نگاه کنید، اکنون:

• فایل jar خود را در یک تصویر Docker قرار دهید
• این تصویر را به یک رجیستری Docker خصوصی فشار دهید
• این تصویر را روی پلتفرم هدف خود بکشید و اجرا کنید
• یا تصویر Docker را مستقیماً در سیستم تولید خود کپی کرده و اجرا کنید.

نحوه استفاده از Docker Swarm یا Kubernetes برای استقرار میکروسرویس های جاوا

فرض کنید تصمیم گرفتید Docker را امتحان کنید. هر بار که یک میکروسرویس جاوا را استقرار می‌دهید، یک تصویر Docker ایجاد می‌کنید که فایل jar شما را بسته‌بندی می‌کند. فرض کنید شما چند تا از این میکروسرویس های جاوا دارید و می خواهید این سرویس ها را روی چندین ماشین (در یک خوشه) مستقر کنید. این سوال مطرح می شود: چگونه این خوشه را مدیریت کنیم؟ کانتینرهای Docker را اجرا کنید، عملکرد را بررسی کنید، به‌روزرسانی‌ها را مستقر کنید، سیستم را مقیاس‌بندی کنید (brrr)؟ دو پاسخ ممکن برای این سوال Docker Swarm و Kubernetes هستند. پرداختن به جزئیات در مورد هر دو گزینه این آموزش طولانی مدت را بسیار طولانی می کند، اما ما فکر می کنیم ذکر این نکته مهم است که هر دو گزینه در نهایت به نوشتن فایل های YAML (به داستان های تورفتگی Yaml مراجعه کنید ) برای مدیریت خوشه خود متکی هستند. اگر می خواهید بدانید که این در عمل چه احساساتی را برمی انگیزد، کافی است یک عبارت مشابه را در جستجوی توییتر تایپ کنید. بنابراین روند استقرار برای میکروسرویس های جاوا شما چیزی شبیه به این است:

• پیکربندی و مدیریت Docker Swarm/Kubernetes
• تمام مراحل برای Docker (به بالا مراجعه کنید)
• YAML را بنویسید و اجرا کنید تا زمانی که از چشمان شما خونریزی کند تا زمانی که همه چیز درست شود.

نحوه تست میکروسرویس جاوا

فرض کنید تصمیم دارید میکروسرویس ها را در تولید پیاده سازی کنید. چگونه می توانیم ادغام n-microservices را در حین توسعه آزمایش کنیم؟ چگونه می توانید ببینید که کل گردش کار کار می کند، و نه فقط بخش هایی از آن؟ در عمل، می توانید از یکی از سه روش استفاده کنید:

1. با کمی کار (اگر از فریم‌ورک‌هایی مانند Spring Boot استفاده می‌کنید)، می‌توانید همه میکروسرویس‌های خود را در یک کلاس راه‌انداز ترکیب کنید و همه میکروسرویس‌ها را با استفاده از یک کلاس Wrapper.java بارگیری کنید - بسته به اینکه حافظه کافی روی دستگاه خود دارید یا نه. همه میکروسرویس های خود را با آنها اجرا کنید.
2. می توانید تنظیمات Docker Swarm یا Kubernetes را به صورت محلی کپی کنید.
3. فقط تست های ادغام را دیگر به صورت محلی اجرا نکنید. در عوض، یک محیط DEV/TEST اختصاصی را مستقر کنید. این کاری است که تعداد کمی از تیم‌ها در واقع انجام می‌دهند وقتی که تسلیم دردسر راه‌اندازی میکروسرویس محلی می‌شوند.

علاوه بر این، علاوه بر میکروسرویس‌های جاوا، احتمالاً به یک کارگزار پیام در حال اجرا (مانند ActiveMQ یا RabbitMQ) یا شاید یک سرور ایمیل یا هر مؤلفه پیام‌رسان دیگری که میکروسرویس‌های جاوا شما برای برقراری ارتباط با یکدیگر نیاز دارند، نیاز خواهید داشت. این منجر به دست کم گرفتن قابل توجه پیچیدگی در سمت DevOps می شود. به کتابخانه های تست میکروسرویس نگاهی بیندازید، آنها می توانند این درد را کاهش دهند. در هر صورت این پیچیدگی ما را به مشکلات کلی میکروسرویس ها می رساند که همین الان در مورد آن صحبت خواهیم کرد. در قسمت پایانی به سوالات کلی در مورد میکروسرویس های جاوا می پردازیم.