Scope چیست ؟ در Spring هر bean میتواند چرخه عمر و میدان دید متفاوتی را داشته باشد که بسته به نیازمان میتوانیم از آنها استفاده کنیم تا نسخه کنونی Spring (نسخه 5) 6 نوع scope در Spring تعریف شده است :
- Singleton
- Prototype
- Request
- Session
- Application
- Websocket
به لیست annotaion هایی که در پکیج org.springframework.beans.factory.annotation و org.springframework.context.annotation قرار دارند Spring Core Annotaion میگویند که عمدتا برای استفاده در Dependency Injection کاربرد دارند و قدرت مانور بالایی در Develop Time به ما می دهند که در ادامه به انها می پردازیم :
maven : یکی از پر کاربردترین ابزار های جاوا برای package بندی , build , deploy , compile , test , document generation پروژه ها است که باعث میشود همه توسعه دهنده ها با استفاده از maven از یک استاندارد پیروی کنند و از اعمال سلیقه هر توسعه دهنده تا حد زیادی جلوگیری میشود و توسعه دهنده بعدی میتواند با ساختار پروژه راحت ارتباط بر قرار میکند
plugin ها : در maven تعداد بسیار زیادی plugin برای کارهای مختلف وجود دارد ما نیز میتوانیم پلاگین مورد نیاز خودمان را هم بنویسیم
Archetype : به مشخصه پروژه میپردازد و کمک میکند ساختار پروژه را ایجاد بکنیم و شامل حداقل سه جزییات groupid , artifactid , version است
- groupid همان packaging ما است که مشخص میکنیم
- artifactid اسم پروژه است که در انتهای packaging ما قرار میگیرد
- version هم طبق semantic versioning شماره ورژن جاری را مشخص میکنیم
repository : در maven بصورت محلی یک repository روی دیسک ایجاد میکند و در دفعات بعد که یک کتابخانه را بخواهیم استفاده کنیم دوباره آنرا دانلود نمیکند
بعد از دانلود و خارج کردن از حالت فشرده میبایست مسیر آنرا بصورت local variable به سیستم معرفی کنیم
export MVN_HOME=/opt/maven export PATH=$MVN_HOME/bin:$PATH
config : برای ست کردن config مورد نظر باید در آدرس MVN_HOME/conf/setting.xml فایل xml را ویرایش کنیم
pom.xml : در این فایل کلیه تنظیمات و مشخصات و dependency های پروژه در آن وجود دارد که بعد از ایجاد پروژه با maven در اختیار ما خواهد بود و اگر بخواهیم تغییری را اعمال کنیم از طریق این فایل میتوانیم
در تگ dependencies میتوانیم کتابخانه های مورد نیاز و وابستگی ها را اضافه کنیم که هر وابستگی در تگ dependency قرار میگیرد و شامل حداقل تگ های داخلی groupid , artifactid , version , scope است با scope مشخص میکنیم که این کتابخانه در چه مرحله ای از پروژه قرار است مورد استفاده قرار گیرد که شامل موارد زیر است :
- test : فقط در جریان توسعه نرم افزار که همراه با تست است آن کتابخانه را استفاده میکند مثل junit
- providen : یعنی در آینده این کتابخانه توسط ما یا عامل دیگری برای پروژه قراهم خواهد شد و طی فرایند کامپایل و ساخت jar فایل انرا اضافه نمیکند مثل کتابخانه servlet که در servlet container ها موجود است
- compile : بصورت پیش فرض روی این گزینه ست شده است و یعنی این کتابخانه را هنگامی که پروژه کامپایل و ساخته میشود استفاده کند
- runtime : مشابه provided است
- system : که اشاره میکند این کتابخانه در سیستم موجود است و باید به مسیر کتابخانه های پروژه آنرا اضافه کند
دستورات maven :
قبل از پرداختن به دستورات maven در محیط ترمینال اطمینان حاصل کنید که شاخه جاری ای که در آن قرار گرفته اید شاخه اصلی پروژه است و فایل pom.xml موجود است چون maven تنها میتواند از روی این فایل کار کند و دستورات را روی پروژه اعمال کند
mvn clean : شاخه target و فایل های داخلش را که مربوط به build گرفتن پروژه بوده را پاک میکند و پروژه را اماده build میکند
mvn package : این دستور پروژه را compile میکند و آنرا build میکند و شاخه target را هم میسازد
mvn clean install : این دستور علاوه بر compile کردن آنرا در لیست مخزن محلی قرار میدهد
test skip کردن : در طی فرآیند compile و build تست هم انجام میشود که لاگ آنرا در کنسول میتوان دید برای انجام نشدن تست میبایست سویچ مورد نظر را اعلام کرد : mvn clean install -DskipTests=true
در گذشته برنامه هایی که ساخته میشد بصورت Monolithic بود و فقط میتوانستیم از Vertical Scaling استفاده کنیم که آن هم محدودیت افزایش منابع را داشت و در نقطه ای دیگر افزایش منابع امکان پذیر نبود و یا هزینه ای بسیار زیاد داشت از این رو توسعه روی ماشین های توزیع شده ارزان و نا محدود مورد توجه قرار گرفت و معماری میکرو سرویس مورد توجه قرار گرفت
Cloud Native Applications : از متدولوژی 12 فاکتور برای تولید نرم افزار های SaaS استفاده میشود
4 جز دارند که شامل :
- Microservices
- Containers
- DevOps
- Continuous Delivery
که یک از این بخش ها Microservices است
معماری میکروسرویس : هر گاه توسط یک تیم کوچک و مستقل بخش های مختلف یک برنامه بزرگ را مستقل از کل برنامه طوری که به تنهایی قابل اجرا ، تست ، توسعه ، نگهداری ،دیپلوی و مقایس پذیری بصورت افقی روی تعدادی ماشین مجزا باشند تقسیم بندی کنیم معماری برنامه بصورت میکروسرویس خواهد شد که خود بسته به طراحی و نیاز میتواند در جزییات طراحی تفاوت هایی داشته باشد مثلا :
هر میکروسرویس دیتابیس خود را داشته باشد و کلاینت ها هر یک به میکروسرویسی که سرویس مورد نیاز را تامین میکنند متصل شوند
یا یک Gateway API داشته باشیم که تمامی کلاینت ها به آن درخواست میدهند و بسته به نوع ، درخواست از Gateway API به میکروسرویس مورد نظر میرسد و بعد از آماده شدن پاسخ مورد نیاز به Gateway API برگشت داده میشود و آن پاسخ در نهایت به کلاینت ارسال میشود
دیتابیس در معماری میکروسرویس میتواند به صورت مستقل زیر ساخت خود را داشته باشد اینطوری مشکل مدیریت تراکنش های مدیریت شده هم بسیار کمتر خواهد بود
برای ارتباط داخلی میکروسرویس ها به چند صورت قابل انجام است :
- CQRS , Event Sourcing
- Message Broker
- REST
- GRPC
بخش های داخلی Gateway API :
- Routing : میتوانیم درخواست ها را روی میکروسرویس مورد نیاز map کنیم
- Security : میتوانیم درخواست ها و کاربران را از نظر امنیتی چک کنیم Authentication & Authurization
- Monitoring : سرویس های توزیع شده ، درخواست ها ، آمارها و... را میتوانیم مانیتور کنیم ابزار هایی مثل eureka , hystrix , prometheus , micrometer , zipkin , ...
- Canarying : میتوانیم از هر میکروسرویسی بیش از یک instance داشته باشیم و بسته به استراتژی میتوانیم درخواست ها را به instance ها هدایت کنیم ، مثلا میتوانیم نسخه جدید میکروسرویس را که دیپلوی کردیم درخواست ها را به نسخه جدید هدایت کنیم یا درخواست های مربوط به یک کشور خاص را هدایت کنیم روی instance خاص و ... هر نوع استراتژی ای که مد نظرمان بود روی درخواست ها و میکروسرویس ها اعمال کنیم
- Resiliency : میتوانیم سرویس را با مقاومت بیشتری روی failover داشته باشیم ، در کل هیچ وقت نمیتوان انتظار داشت که یک سرویس همواره به سرویس دهی خود ادامه دهد و امکان fail شدن همیشه وجود دارد و این fail شدن سرویس نباید روی بقیه سرویس های دیگر تاثیری بگذارد مثلا اگر سرویس پرداخت fail شد کاربر همچنان بتواند سفارش هایی را به سبد خود اضافه کند
تکنولوژی و فریم ورک ها :
Protobuf - Protocol Buffers : پروتکلی است که میتوان دیتای مورد نیاز را بین سرویس ها جابجا کرد و طبق گفته خودش 10 برابر از Rest سریعتر است و دارای زبان مختص به خود است و کامپایلر خود را دارد و میتوان در زبان های دیگر مورد استفاده قرار گیرد و وقتی ما در جاوا استفاده میکنیم بجای کار با JSON به ما ابجکت برمیگرداند
gRPC : یک فریم ورکی است که با استفاده از Protocol Buffers پیاده سازی شده و ارتباط بین کلاینت و سرویس را فراهم میکند و کلاینت موقع کار با این RPC همانند این است که یک کد مستقیما یک کد دیگر را اجرا کند
Vert.X : تولکیتی برای ساخت میکروسرویس های React-Application است که React-Application ها 4 جز دارند :
- Responsive : به معنای این است که در یک بازه زمانی به درخواست ها میتوانند پاسخ منطقی بدهند
- Resilient : وقتی یکی از سرویس ها از کار می افتد بقیه سرویس ها باید بتوانند به کارشان ادامه دهند
- Elastic : باید بتوانیم کل سرویس را Horizontal-Scale کنیم
- Message-Driven : ارتباط بین سرویس ها توسط message ها انجام میگیرد
اگر یادتون باشه در بخش 2 آموزش هایبرنیت یک اشاره ای به ارث بری کردیم حالا در این بخش به بررسی کاملتر پیاده سازی ارث بری در دنیای رابطه ای می پردازیم
