سیب فارسی

شب و روزنوشته های من | داستان سیبی که هر روز به زمین می خورد!

Microservices vs SOA: What’s the Difference?

30 مارس 19

Microservices Architecture (MSA) and Service-Oriented Architecture (SOA) both rely on services as the main component. But they vary greatly in terms of service characteristics.

SOA defines 4 basic service types as depicted below:

coordination-768x330

Business services are coarse-grained services that define core business operations. They are usually represented through XML, Web Services Definition Language (WSDL) or Business Process Execution Language (BPEL).

Enterprise services implement the functionality defined by business services. They rely on application services and infrastructure services to fulfill business requests.

Application services are fine-grained services that are bound to a specific application context. These services can be invoked directly through a dedicated user interface.

Infrastructure services implement non-functional tasks such as authentication, auditing, security, and logging. They can be invoked from either application services or enterprise services.

MSAs have limited service taxonomy. The architecture consists of 2 service types as depicted below.

Minimal-coordination

 support specific business operations. The services are accessed externally and they are usually not shared with any other service. As in SOA, infrastructure services implement tasks such as auditing, security, and logging. The services are not exposed to the outside world and they are available internally.

Key differences between SOA and MSA

SOA-architecture-vs-microservices

MSA
Built on the idea of “share-as-much-as-possible” architecture approach Built on the idea of “share-as-little-as-possible” architecture approach
More importance on business functionality reuse More importance on the concept of “bounded context”
Common governance and standards Relaxed governance, with more focus on people collaboration and freedom of choice
Uses enterprise service bus (ESB) for communication Uses less elaborate and simple messaging system
Supports multiple message protocols Uses lightweight protocols such as HTTP/REST & AMQP
Common platform for all services deployed to it Application Servers not really used. Platforms such as Node.JS could be used
Multi-threaded with more overheads to handle I/O Single-threaded usually with use of Event Loop features for non-locking I/O handling
Use of containers (Dockers, Linux Containers) less popular Containers work very well in MSA
Maximizes application service reusability More focused on decoupling
Uses traditional relational databases more often Uses modern, non-relational databases
A systematic change requires modifying the monolith A systematic change is to create a new service
DevOps / Continuous Delivery is becoming popular, but not yet mainstream Strong focus on DevOps / Continuous Delivery

Let’s explore the differences in more detail:

  • Coordination: In SOA, you need to coordinate with multiple groups to create business requests. But there is little or no coordination among services in MSA. If coordination is needed among service owners, it is done through small application development teams, and services can be quickly developed, tested and deployed.
  • Service granularity: The prefix “micro” in Microservices refers to the granularity of the internal components. Service components within MSA are generally single purpose services that do one thing really well. Services usually include much more business functionality in SOA, and they are often implemented as complete subsystems.
  • Component sharing: SOA enhances component sharing, whereas MSA tries to minimize on sharing through “bounded context.” A bounded context refers to the coupling of a component and its data as a single unit with minimal dependencies. As SOA relies on multiple services to fulfill a business request, systems built on SOA are likely to be slower than MSA.
  • Middleware vs API layer: The messaging middleware in SOA offers a host of additional capabilities not found in MSA, including mediation and routing, message enhancement, message and protocol transformation. MSA has an API layer between services and service consumers.
  • Remote services: SOA architectures rely on messaging (AMQP, MSMQ) and SOAP as primary remote access protocols. Most MSAs rely on two protocols – REST and simple messaging (JMS, MSMQ), and the protocol found in MSA is usually homogeneous.
  • Heterogeneous interoperability: SOA promotes the propagation of multiple heterogeneous protocols through its messaging middleware component. MSA attempts to simplify the architecture pattern by reducing the number of choices for integration. If you would like to integrate several systems using different protocols in heterogeneous environment, you need to consider SOA. If all your services could be exposed and accessed through the same remote access protocol, then MSA is a better option.
  • Contract decoupling: Contract decoupling is the holy grail of abstraction. It offers the greatest degree of decoupling between services and consumers. It is one of the fundamental capabilities offered within SOA. But MSA doesn’t support contract decoupling.

Microservices are not invented. Enterprises such as Amazon, Netflix, and eBay used the divide and conquer strategy to functionally partition their monolithic applications into smaller units, and resolved many issues. Following the success of these companies, many other companies started adopting this as a common pattern to refactor their applications. Eventually the pattern was termed as Microservices Architecture. Nothing radically new has been introduced in MSA. MSA is the logical evolution of SOA and supports modern business use cases.

SOA is better suited for large and complex business application environments that require integration with many heterogeneous applications. However, workflow based applications that have a well defined processing flow are a bit difficult to implement using SOA patterns. Small applications are also not a good fit for SOA as they don’t need messaging middleware component. The MSA pattern is well suited for smaller and well partitioned web based systems. The lack of messaging middleware is one of the factors that makes it unfit for complex environments.

If you are developing an application, then MSA gives you greater control as a developer. If you are trying to orchestrate a number of business processes, SOA probably provides a better set of tools.

Also in the early stages of your business, you might find that MSA is a good choice. As the business grows, you may need capabilities such as complex request transformation and heterogeneous systems integration. In such situations, you may likely turn to SOA pattern to replace MSA.

Both SOA and MSA are the same set of standards used at different layers of an enterprise. The existence of MSA comes down to the success of SOA pattern. Hence, MSA pattern is a subset of SOA. Here the main focus is on the runtime autonomy of each service.

enterprise service bus

30 مارس 19

An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA). It implements a software architecture as depicted in the picture. As it implements a distributed computing architecture, it implements a special variant of the more general client-server model, wherein, in general, any application using ESB can behave as server or client in turns. ESB promotes agility and flexibility with regard to high-level protocol communication between applications. The primary goal of the high-level protocol communication is enterprise application integration (EAI) of heterogeneous and complex service or application landscapes (a view from the network level).

The concept is analogous to the bus concept found in computer hardware architecturecombined with the modular and concurrent design of high-performance computer operating systems. The motivation for the development of ESB was to find a standard, structured, and general purpose concept for describing implementation of loosely coupled software components (called services) that are expected to be independently deployed, running, heterogeneous, and disparate within a network. ESB is also a common implementation pattern for service-oriented architecture.

Working

An ESB applies the design concept of modern operating systems to independent services running within networks of disparate and independent computers. Like concurrent operating systems, an ESB provides commodity services in addition to adoption, translation and routing of client requests to appropriate answering services.

The primary duties of an ESB are:

  • Route messages between services
  • Monitor and control routing of message exchange between services
  • Resolve contention between communicating service components
  • Control deployment and versioning of services
  • Marshal use of redundant services
  • Provide commodity services like event handling, data transformation and mapping, message and event queuing and sequencing, security or exception handling, protocol conversion and enforcing proper quality of communication servic

Key benefits

  • Scales from point-solutions to enterprise-wide deployment (distributed bus)
  • More configuration rather than integration coding
  • No central rules-engine, no central broker
  • Easy plug-in and plug-out and loosely coupling system

Key disadvantages

  • Slower communication speed, especially for those already compatible services
  • Single point of failure, can bring down all communications in the Enterprise
  • High configuration and maintenance complexity

میکروسرویس (Microservice) چیست؟

30 مارس 19

پیش نوشت: این مطلب مقدمه ای است برای مطلب: اصول طراحی: مقدمه ای بر microservics و enterprise service bus (مقدمه یک)

میکروسرویس (Microservice) چیست؟

امروزه با نیاز رو به رشدی که به اپلیکیشن‌های بزرگ اینترپرایز به وجود آمده است، مفهومی تحت عنوان میکروسرویس هم در صنعت توسعهٔ نرم‌افزار رواج یافته است چرا که دولوپرها برای توسعهٔ سیستم‌های بزرگ تجاری چاره‌ای جز به‌کارگیری از معماری میکروسرویس ندارند. در ظاهر مفهوم میکروسرویس کمی پیچیده به نظر می‌رسد اما در واقعیت هرگز این‌گونه نیست و در این پست قصد داریم چیستی، چرایی و همچنین مزایا و معایب به‌کارگیری از میکروسرویس‌ها را مورد بررسی قرار دهیم.

معماری Monolithic چیست؟
برای درک ماهیت میکروسرویس‌ها، ابتدا باید ببینیم که معماری Monolithic چگونه کار می‌کند. به طور کلی، در این نوع معماری ما سه لایه داریم تحت عناوین:

– Model (منطق اپلیکیشن)
– View (خروجی اپلیکیشن)
– Controller (رابط مابین خروجی و منطق اپلیکیشن)

برای روشن‌تر شدن این مسئله، مثالی می‌زنیم. در حال حاضر که مشغول مطالعهٔ این مقاله هستید، به محض اینکه وارد این صفحه شدید، یک ریکوئست (درخواست) برای سرور وردپرس سیب فارسی ارسال گردیده است که لایهٔ مرتبط با Controller این درخواست را گرفته و برای لایهٔ Model ارسال می‌کند و این لایه هم با دیتابیس ارتباط برقرار ساخته و دیتای مرتبط با این مقاله را از دیتابیس فراخوانی کرده و در صورت نیاز یکسری کارها برای تر و تمیز کردن داده‌ها انجام داده و در نهایت مجدد دیتا در اختیار Controller قرار می‌دهد و این لایه هم دیتای موجود را در اختیار View می‌گذارد و این لایه هم خروجی این صفحه از وبلاگ سیب فارسی را داخل مرورگر شما نشان می‌دهد.

مشکلات مرتبط با معماری Monolithic
این نوع معماری که تحت عنوان معماری MVC هم شناخته می‌شود دارای یکسری نواقصی است. به عبارت دیگر، تمامی لایه‌ها (مدل، ویو و کنترلر) زیر پرچم یک پلتفرم واحد مدیریت می‌شوند و ارتباط بسیار تنگاتنگی با یکدیگر دارند و مثلاً به سادگی نمی‌توان Model یک اپلیکیشنی که تحت معماری MVC نوشته شده را برداشته و در پروژهٔ دیگری استفاده کرد.

from-the-monolith-to-microservices-craftconf-2015-6-638

همان‌طور که در تصویر فوق مشخص است، در معماری Monolithic یک هستهٔ مرکزی داریم که کاربران و حتی دیگر سرویس‌ها از طُرق مختلف می‌توانند با آن ارتباط برقرار سازند و می‌بینیم گرچه خودِ این هستهٔ مرکزی ماژولار (بخش‌بندی) است، اما همگی تحت یک پلتفرم واحد کنار یکدیگر قرار گرفته‌اند و امکان مجزاسازی این ماژول‌ها وجود ندارد و یا اگر هم چنین امکانی وجود داشته باشد، بسیار دشوار خواهد بود.
اگرچه که در معماری MVC کدها ماژولار هستند و نسبت به گذشته که تمامی فایل‌ها در یک پوشه گذاشته می‌شدند و اصلاً مفهومی تحت عنوان ماژول در کار نبود شرایط به مراتب بهتر است، اما همان‌طور که گفته شد، هر ماژول برای کارکرد صحیح و اصولی خود نیاز به سایر ماژول‌ها دارد. به طور کلی، مشکلات مرتبط با معماری Monolithic را می‌توان به دسته‌های زیر تقسیم‌بندی کرد:

– از آنجا که یک سورس‌کد اصلی بیشتر وجود ندارد، تک‌تک اعضای تیم، از دولوپر فرانت‌اند گرفته تا برنامه‌نویس‌های سمت سرور و غیره، باید روی یک سورس‌کد کار کنند و به طور مثال اگر کسی بخواهد صرفاً روی بخش مدیریت کاربران کار کند، باید کل پروژه را دریافت کرده، یک هاست لوکال پیکره‌بندی کرده و شروع به کار روی پروژه کند.

– یک تغییر کوچک در یکی از ماژول‌ها، ممکن است عملکرد دیگر ماژول‌ها را تحت‌تأثیر خود قرار دهد.

– درست است که در این نوع معماری مفهومی داریم تحت عنوان MVC،‌ اما در طول زمان این سه لایه آن‌قدر با یکدیگر عجین خواهند شد که به سختی می‌توان مرز مشخصی مابین آن‌ها ایجاد کرد.

– کامپوننت‌ها را به سادگی نمی‌توان با یک معماری جدیدتر و بهینه‌تر جایگزین کرد چرا که کل معماری نرم‌افزار باید دستخوش تغییر گردد.

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

– و یک باگ در یکی از ماژول‌ها، به احتمال زیاد کل پروژه را تحت‌الشعاع خود قرار خواهد داد.

اینجا است که پای میکروسرویس‌ها به میان می‌آید و مزایایش منجر بدین گشته تا کمپانی‌های بزرگی همچون آمازون یا نتفلیکس به استفاده از میکروسرویس‌ها ترغیب شوند.

معماری Microservice چیست؟
میکروسرویس‌ روشی به منظور تقسیم‌بندی کردن یک اپلیکیشن (نرم‌افزار) به بخش‌ها یا سرویس‌های کوچک، سبُک، مستقل از یکدیگر و قابل‌مدیریت است. به عبارت دیگر، میکروسرویس یک معماری توسعهٔ‌ نرم‌افزار به اصطلاح Distributed است.

همان‌طور که در تصویر فوق مشاهده می‌شود، این نوع سرویس‌ها صرفاً به منظور هندل کردن یک تَسک خاص طراحی می‌شوند. به طور مثال، یک سرویس صرفاً وظیفهٔ مدیریت کاربران را دارا است و سرویس دیگر فقط و فقط برای بخش جستجوی سایت کاربرد دارد و با توجه به اینکه میکروسرویس‌ها مجزا و مستقل از یکدیگر هستند، به راحتی قادر خواهیم بود تا آن‌ها را با زبان‌های برنامه‌نویسی مختلفی نوشته و برای ذخیره‌سازی داده‌های مرتبط با آن‌ها نیز از سیستم‌های مدیریت دیتابیس مختلفی استفاده کنیم (به عبارت دیگر، جاهایی که نیاز به ذخیره‌سازی سنتی داده‌ها داریم می‌توانیم از MySQL استفاده کنیم و جاهایی دیگر هم به خاطر ساختار غیرقابل پیش‌بینی دیتای خود می‌توانیم به استفاده از دیتابیس‌های به اصطلاح NoSQL بپردازیم.)

حال ممکن است این پرسش مطرح شود که سرویس‌های مختلف یک اپلیکیشن با معماری میکروسرویس چگونه با یکدیگر ارتباط برقرار می‌کنند؟ در پاسخ به این سؤال باید گفت، همان‌طور که در تصویر فوق مشخص است، با استفاده از ریکوئست‌هایی از جنس HTTP و یکسری API به اصطلاح RESTful این ارتباط برقرار خواهد شد.

آشنایی با معماری Service Oriented Architecture
اینجا سؤال دیگری به ذهن می‌رسد و آن هم اینکه با این تفاسیر تفاوت چندانی مابین Service Oriented Architecture یا به اختصار SOA با Microservice وجود ندارد که در پاسخ به این سؤال هم می‌توان گفت که Microservice نوعی SOA (معماری مبتنی بر سرویس) است که طی ده‌های گذشته خیلی مطرح بوده است اما در عین حال میکروسرویس نسبت به معماری مبتنی بر سرویس انعطاف‌پذیرتر است چرا که به سادگی می‌توان یک سرویس یا ماژول را از پروژه‌ای برداشت و بدون پیکره‌بندی خاصی آن را در پروژه‌ٔ دیگری استفاده کرد اما این در حالی است که معماری SOA داخل یک معماری اصطلاحاً Monolithic پیاده‌سازی می‌شود.

به عبارت دیگر، در معماری SOA ما کامپوننت‌ها یا ماژول‌هایی داریم که سرویس‌هایی را در اختیار دیگر کامپوننت‌های قرار می‌دهند و این در حالی است که این کامپوننت‌ها می‌توانند منحصر به یک اپلیکیشن خاص باشند اما در مقابل در معماری یک Microservice این کامپوننت‌ها به عنوان سرویس‌های کاملاً مستقلی هستند که به صورت تکی هم می‌توان آن‌ها را دیپلوی کرد. نکتهٔ دیگری که در ارتباط با تفاوت‌های این دو معماری نرم‌افزار باید مد نظر داشت، سایز ماژول‌ها است. به عبارت دیگر، میکروسرویس‌ها به مراتب کوچک‌ترند و همین مسئله مدیریت آن‌ها را به مراتب ساده‌تر می‌سازد.

آشنایی با تفاوت‌های معماری‌های Microservice ،Monolithic و SOA
برای درک بهتر تفاوت‌های مابین معماری‌های Microservice ،Monolithic و SOA می‌توان اولین تصویری که در این مقاله استفاده شده را مد نظر قرار داد. در واقع از چپ به راست، معماری‌های SOA ،Monolithic و Microservice در قالب خوراکی به تصویر کشیده‌ شده‌اند.

در تصویر سمت چپ می‌بینیم که معماری Monolithic به گونه‌ای است که ارتباط تنگاتنگی مابین ماژول‌های مختلف اپلیکیشن وجود دارد که اصطلاحاً گفته می‌شود Tightly Coupled است و در صورتی که بخواهیم تغییری در یکی از بخش‌ها دهیم با مشکل مواجه خواهیم شد و همین مسئله Continous Deployment یا به اختصار CD را دشوار می‌سازد. در تصویر وسط که نشانگر معماری SOA است، می‌بینیم که اوضاع نسبت به معماری Monolithic به مراتب بهتر بوده به طوری می‌توانیم اپلیکیشن را به بخش‌های مجزا از یکدیگر تقسیم‌بندی کنیم اما در عین حال، هر بخش زیر چتر پلتفرم اصلی قرار دارد و در تصویر سمت راست هم که معماری Microservice در آن به تصویر کشیده شده است،‌ بر خلاف دو معماری دیگر می‌بینیم که هر ماژول کاملاً مستقل از دیگر ماژول‌ها است که اصطلاحاً گفته می‌شود Loosely Coupled است و همچون یک پیراشکی، می‌توان آن را به تنهایی میل کرد!

monolithic-vs-microservices

مزایای استفاده از میکروسرویس‌ها
امروزه ماژولار بودن به یک مزیت رقابتی در هر صنعتی مبدل شده‌اند؛ از مبلمان IKEA گرفته تا گوشی‌های موبایل ماژولار و حتی اسباب‌بازی‌های LEGO و این در حالی است که ایدهٔ پشت میکروسرویس‌ها این است تا این امکان به دولوپرها داده شود تا اپلیکیشن‌های خود را بر مبنای اجزا یا سرویس‌هایی که مستقل از یکدیگر هستند و به سادگی قابل‌تغییر، حذف و به‌روزرسانی می‌باشند توسعه دهند بدون اینکه کل اپلیکیشن تحت‌الشعاع قرار گیرد. روی هم رفته، مهم‌ترین مزایای استفاده از معماری میکروسرویس‌ عبارتند از:

– بر خلاف معماری مونولیتیک، در یک اپلیکیشنی که در آن از معماری میکروسرویس استفاده شده باشد سرویس‌ها هرگز بر اساس معماری MVC تقسیم‌بندی نمی‌شوند بلکه بر اساس کاری که انجام می‌دهند به بخش‌های مختلف تقسیم می‌شوند. به عبارت دیگر، یک سرویس همچون آپلود فایل شامل بخش‌هایی همچون رابط کاربری، مدل‌های مرتبط با دیتابیس، کنترلر، سیستم لاگینگ و … خواهد بود (در چنین شرایطی، فرض کنیم دولوپر سرویسی تحت عنوان File Uploader می‌سازد و از آن پس به سادگی قادر خواهد بود سرویس مد نظر را در دیگر پروژه‌ها که کاربرد یکسانی دارند نیز استفاده کند.)

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

– علاوه بر موارد فوق، میکروسرویس‌ها اصطلاحاً Scalable (قابل‌توسعه) هستند. ماهیت مستقل ماژول‌های مختلف یک میکروسرویس این امکان را برای‌مان فراهم می‌آورند تا با استفاده از زبانی خاص، دیتابیسی خاص و همچنین سروری خاص به توسعهٔ اپلکیکشن مد نظر خود بپردازیم و در صورت نیاز صرفاً منابع همان پلتفرم را ارتقاء دهیم.

معایب استفاده از میکروسرویس‌ها
تا اینجای بحث از خوبی‌ها میکروسرویس‌ها گفتیم اما باید توجه داشته باشیم که این نوع معماری توسعهٔ اپلیکیشن نقاط ضعف خاص خود را هم دارا است که برخی از مهم‌ترین آن‌ها عبارتند از:

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

– با توجه به اینکه سرویس‌ها برای برطرف کردن نیازهای خود دیگر سرویس‌ها را کال (فراخوانی) می‌کنند، رصد کردن آن‌ها و بالتبع فرایند دیباگینگ بسیار دشوار خواهد شد.

– هر سرویس لاگ‌گیری اختصاصی خود را دارا است و از همین روی هیچ سیستم مانیتورینگ مرکزی برای بررسی لاگ‌ها وجود ندارد و در چنین شرایطی نیاز به یک سیستم مدیریت لاگ مرکزی وجود خواهد داشت.

– با توجه به اینکه ارتباط سرویس‌ها با یکدیگر از طریق API است، تعداد رکوئست‌ها نسبت به یک معماری مونولیتیک به مراتب بیشتر خواهد بود.

– دیپلوی کردن اپلیکیشن‌هایی که با استفاده از معماری میکروسرویس طراحی شده‌اند به صورت دستی مشکل است و در چنین شرایطی نیاز به ابزارهای اتوماسیون پیشرفته خواهد بود.

– ورژن‌بندی میکروسرویس‌ها باید به صورت مجزا از یکدیگر صورت گیرد و اینجا است که نیاز داریم تا مشخص کنیم به طور مثال کدام ورژن سرویس A با کدام ورژن سرویس Z باید دیپلوی شود.

– مستندات‌سازی چنین اپلیکیشن‌هایی مشکل‌تر است چرا که با توجه به ماهیت مستقل هر ماژول، سرویس‌ها باید به صورت کامل مستندسازی شوند.

– با توجه به اینکه ممکن است از چندین زبان‌ برنامه‌نویسی و تکنولوژی مختلف در چنین اپلیکیشن‌هایی استفاده شود، هزینهٔ نگهداری چنین سیستم‌ها گاهی‌ اوقات زیاد می‌شود به طوری که مثلاً نیاز به استخدام دولوپر زبان‌های مختلف خواهیم داشت.

– امروزه اکثر اپلیکیشن‌ها نیاز دارند تا در آنِ واحد چندین رکورد را در دیتابیس حذف یا به‌روزرسانی کنند. در چنین مواقعی با توجه به اینکه در معماری مونولیتیک صرفاً یک دیتابیس وجود دارد، اینکار به سادگی صورت خواهد گرفت اما در میکروسرویس‌ها چنین حذف یا به‌روزرسانی‌هایی چالشی خواهند شد چرا که ممکن است رکوردی در دیتابیس یکی از سرویس‌ها در یک سرور خاص به همراه رکورد دیگری در سرویس‌ دیگری روی سرور دیگری بخواهند با یکدیگر سینک شوند.

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

– چنانچه سورس‌کد پروژه‌ٔ شما آن‌قدر حجیم شده است که توسعهٔ آن به صورت لوکال، مثلاً لود کردن کل پروژه داخل یک IDE، کار دشواری شده است و نیاز به توضیح نیست که فرایند ‌بیلد کردن برخی از پروژه‌های بسیار بزرگ که به صورت مونولیتیک نوشته شده‌اند گاهی ده‌ها دقیقه به طول می‌انجامد.

– صرفاً برخی بخش‌های اپلیکیشن نیاز به توسعه دارند و این در حالی است که در معماری مونولیتیک شما باید به یک باره کل منابع سیستمی خود را ارتقاء دهید و این در صورتی است که ممکن است اصلاً نیاز به ارتقاء به این شکل نباشد.

– چنانچه دولوپرها در کنار یکدیگر نیستند و نمی‌توانند به صورت مستقل از یکدیگر روی پروژه کار کنند.

جمع‌بندی
مبحث معماری میکروسرویس بسیار گسترده است و زمانی که بخواهیم وارد این حوزه شویم، نیاز است تا با مفاهیمی همچون Continuous Integration ،‌Continuous Deploymnet ،Container و همچنین ابزارهای دیپلوی خودکار نیز آشنا شویم اما آشنایی در همین حدی که در این پست صورت گرفت، برای هر دولوپری فارغ از اینکه بخواهد وارد این حوزه شود یا خیر، ضروری است.

 

این مطلب منتشر شده در سیب فارسی از وبلاگ سکان آکادمی