در گذشته برنامه هایی که ساخته میشد بصورت 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 ها انجام میگیرد