میکروسرویس یه رویکرد معماری برای سیستم های توزیع شده است که سرویس های سیستم را به صورت خورد شده با چرخه عمر مستقل ولی در تعامل با هم، ترویج میکند.
آشنایی با میکروسرویس
از آنجا که میکرو سرویس براساس بیزینس مدل و Business Domain ایجاد می شود، مشکلات معماری های چندلایه سنتی و گره خورده به هم را ندارد. با کمک میکروسرویس میتوانیم از تکنولوژی های جدید اخیر نیز براساس کاربرد و عملکرد هر سرویس بصورت مجزا بهره ببریم. ما در این روش معماری، مشکلات افتادن در دام های معماری سرویس گرا SOA یا روش های معماری سنتی را نیز نداریم. معماری میکرو سرویس اساسا همه طراحی Design، توسعه Development، استقرار Deployment و تست Test نرم افزار را شامل میشود.
سال های زیادی ما تلاش میکردیم که روش های بهتری برای تولید نرم افزارهایمان پیدا کنیم، تلاش میکردیم از تکنولوژی هایی که جدیدتر بودند استفاده کنیم، از روش هایی که شرکت های بزرگ و پیشرو برای تولید و طراحی نرم افزار استفاده میکردند، الگو میگرفتیم. سعی میکردیم تولید نرم افزار را به گونه ای انجام دهیم که هم برای ما به صرفه باشد و هم برنامه نویسان ما راضی باشند و همچنین مشتریان از ما راضیتر باشند و بتوانیم تغییرات درخواستی مشتریمان را در کمترین زمان و با کمترین هزینه انجام دهیم.
آقای اریک اوانس Eric Evans یه کتاب معروفی داره به اسم Domain Driven Design که این کتاب به ما کمک میکنه تا بتوانیم دنیای واقعی اطرافمان را بهتر در کدهای نرم افزاری نمایان کنیم و با این معرفی این سیستم فکری به مدل سازی بهتر سیستم های نرم افزارهای ما بسیار کمک کرد.
مفهوم تحویل مداوم Continuous Delivery به ما نشان داد که چگونه موثرتر و کاراتر میتوانیم فرآیند استقرار Deployment را داشته باشیم و فرآیند لانچ محصول میتواند چقدر مفیدتر و بهتر اتفاق بیفتد و هر تغییری و هر Check In ای در نرم افزار میتواند خود یک نسخه و یک Deploy محسوب شود. فهم بهتر ما از اینکه دنیای وب و اینترنت چگونه کار میکنند منجر شد که بتوانیم ارتباط بین ماشین های مختلف را برقرار کنیم. معرفی روش معماری شش ضلعی Hexagonal Architecture به ما فهماند که از روش معماری چندلایه باید دوری کنیم چرا که این روش ها باعث میشوند اعمال تغییرات درخواستی در سمت بیزینس در نرم افزار بسیار دشوار شود. پلتفرم های مجازی سازی به ما این امکان را دادند که منابع ماشین هایمان را در لحظه مانیتور کرده و هرچقدر بخواهیم اضافه کنیم. با اتوماتیک سازی زیرساخت Infrastructure Automation میتوانستیم این ماشین های مجازی را Scale up کنیم. در کنار اینها شرکت های مانند گوگل و آمازون نشان دادند که چگونه تیم های کوچک میتوانند روی هر بخش از نرم افزار کار کنند و نیازی نیست که کل نرم افزار را بدانند و بشناسند و حتی شرکت نتفلیکس روشی برای Scale Up سیستم های نرم افزاری و ماشینی ارائه کرد که در 10 سال قبل این روش ها و این قابلیت ها قابل تصور حتی نبود.
معماری تریپل دی، Domain-Drive-Design، Continuous Delivery، تحویل مستمر، مجازی سازی در لحظه، On Demand Virtualization، اتوماتیک سازی زیرساخت Infrastructure Automation، تیم های برنامه نویسی کوچک و خودمختار و مجزا، Scale up لحظه ای سیستم ها و ... همه اینها یعنی ظهور مفهوم جدیدی به نام معماری میکروسرویس Miroservice Architecture.
میکروسرویس از دنیای همین تکنولوژی هایی که سالها قبل کشف شده اند ظهور کرد و خلق شد. این مفاهیم و کاربردها براساس تجربه شرکت ها ایجاد شدند، این یعنی میکروسرویس نیز از قبل وجود داشته و کاربردی بوده است. من مهدی محمدی در این نوشته تلاش میکنم که تمامی این مفاهیم را در کنار هم قرار دهم و تصویری یکپارچه از میکروسرویس برای شما ارائه کنم.
بسیاری از شرکت ها امروزه به این نتیجه رسیده اند که با استفاده از میکروسرویس و خرد کردن سرویس ها و نرم افزار به اجزای کوچک میتوانند نرم افزار را سریعتر و کم هزینه تر تولید کرده و تحویل دهند و از تکنولوژی های جدید در نرم افزارها استفاده کنند. میکروسرویس بصورت چشمگیری دست ما را در تصمیم گیری های بیزینسی بار میگذارد و به مشترین ما این فرصت را میدهد تا هر تغییری را لازم دارند در سریعترین زمان و کمترین هزینه برایشان انجام دهیم.
میکروسرویس چیست؟
بطور کلی میکروسرویس ها، سرویس های ریز small و خود مختاری autonomous هستند که با همدیگر در ارتباط هستند.
یک میکروسرویس چقدر باید میکرو و کوچک باشد؟ Small Services
در اولین بخش این تعریف در مورد ریز و کوچک بودن هر سرویس صحبت میکنم. تمرکز روی کوچک بودن هر سرویس و درست انجام دادن یک کار کوچک نقطه تمرکز هر سرویسی باید باشد. همانطور که میدانید مخزن کدنویسی Codebase برای هر نرم افزار روز به روز بزرگتر میشود،چرا که ویژگی های Features جدید به نرم افزار همواره در حال اضافه شدن است و همین باعث میشود انجام تغییرات در طول زمان روی نرم افزار دشوارتر شود، چرا که مخزن کد بزرگتر است و پیدا کردن جاهایی که باید تغییر داده شوند دشوارتر میشود. درست است که ما نرم افزارها را بصورت ماژولار مینویسیم و برای هر تغییری آن ماژول مربوطه را اصلاح میکنیم ولی واقعا در طول زمان حفظ مرز این ماژول ها دشوار است و معمولا بعد مدتی این مرزبندی ها کمی در هم قاطی میشوند. مثلا کدی که مربوط به یک فانکشن Function است بعد مدتی در جاهای مختلف هم پخش میشود و همین فرآیند دیباگ و توسعه و نگهداری را دشوارتر میکند.
در سیستم های مونولیتیک Monolithic یا همان معماری یکپارچه ما با تقسیم بندی نرم افزار به ماژول ها Modular Programming یا استفاده از Abstraction ها سعی میکنیم این نظم را در کدهایمان برقرار کنیم. در واقع انسجام Cohesive چیزی است که ما در اینجا با این روش ها میخواهیم برقرار کنیم و همین Cohesion در معماری میکروسرویس هم امری بسیار مهم است. یعنی گروه بندی و بخش بندی کدهای نرم افزار که این موضوع توسط آقای مارتین رابرتز Robert C.Martin به عنوان اصل Single Responsibility Principle قاعده مسئولیت منفرد بیان شده است: چیزهایی که بخاطر یک تغییری مشابه قرار است با هم تغییر کنند با هم دریکجا قرار بده و چیزهایی که به دلایل مختلف و متفاوت ممکن است جدا از هم تغییر کنند از هم جدا قرار بده.
میکروسرویس از همین رویکرد برای سرویس های جدا از هم استفاده میکند. ما محدوده و مرزبندی Boundaries سرویس های نرم افزار را براساس محدوده و Boundary های بیزینسی بنا میکنیم و این باعث میشود کدهای ما براساس نیازمندها و فانکشن های بیزینس تعریف شده و مشخص باشند و با تمرکز هر سرویس روی مرزبندی مشخصاین وسوسه بزرگتر شدن سرویس و متعاقبلا مشکلات بعدی آن را از بین میبرد.
سوالی که من معمولا از من میپرسند اینه که وقتی میگی یه سرویس باید کوچک باشد یعنی دقیقا چقدر کوچک باشد؟ خوب براساس سطرهای کدنویسی نمیشه اینو گفت،چرا که هر کاری تو هر زبان برنامه نویسی به روش های مختلف و با تعداد سطرهای کد و حجم کد متفاوتی ایجاد میشه، پی این ملاک خوبی نیست که براساس سطرهای کد در این مورد اندازه گیری کنیم. یا اینکه هر کدی ممکنه یه سری وابستگی Dependency داشته باشه که کدهای یک سرویس با اون کار میکنند و خود این وابستگی ها هم کدی هستند که به سرویس اضافه میشن. یا اینکه بعضی ماژول ها ممکنه کلا پیچیده باشند و کدهای بیشتری نیاز داشته باشند.
آقای جان ایو Jon Eaves میگه سرویس باید در 2 هفته قابل کدنویسی باشه و معیار زمان رو برای کوچکتر بودن سرویس در نظر میگیره. من در مورد سرویس میگم که درسته باید سرویس کوچک باشه ولی از استانداردی هم نباید کوچکتر باشه و خیلی زیاد ریز باشه، من در یک سمینار پرسیدم کیا سیستم های نرم افزاری دارند که به نظرشون خیلی بزرگه و باید به بخش های ریزتر تقسیم بشه؟ تقریبا همه حاضرین دستشونو بردند بالا و این نشون میده که به نظر ما درک درستی از سیستم ها و سرویس های خیلی بزرگ داریم، پس اگر سرویسی رو حس میکنیم که خیلی بزرگ نیست پس میتونه اندازه درستی برای سرویس ما باشه.
یکی دیگه از فاکتورهایی که میتونیم برای تشخیص کوچک بودن سرویس در نظر بگیریم ساختار تیم هست. یعنی اینکه این سرویس چقدر با Team Structure همراستا و Align شده؟ اگه مخزن کد برای یک سرویس اونقدری بزرگ شده که توسط یک تیم کوچک قابل انجام نیست پس باید سرویس رو ریزتر کنیم.
وقتی صحبت در مورد small بودن یک service میشه در نظر بگیرین که: هرچقدر شما سرویس ها را کوچکتر میکنید، هم مزایا و هم معایب مربوط به معماری میکروسرویس را بیشتر میکنید. هرچقدر کوچکتر میشوید مزایای مربوط به وابستگی متقابل بیشتر میشود ولی در عوض مدیریت کلی ریز سرویس هم مشکلات خودش را دارد. پس باید درک درستی از میزان اندازه و اندازه کوچکی هر سرویس پیدا کنید.
در واقع برای کوچک بودن هر سرویس از چند تا فاکتور، اندازه تیم برنامه نویسی هر سرویس، مدت زمان کدنویسی هر سرویس، خیلی بزرگ نبودن هر سرویس میتوانیم استفاده کنیم.
یک میکروسرویس باید خودمختار باشد Autonomous Service
میکروسرویس ها باید موجودیت های مجزا Separate Entity باشند. چرا که هر سرویسی باید قابلیت اینکه بصورت جدا Deploy بشه یا به عنوان پلتفرمی با کاربرد سرویس Platform AS A Service: PAAS استفاده بشه رو در نظر بگیریم. یا اینکه ممکنه سیستم عاملی که این سرویس روش اجرا میشه کلا متفاوت باشه. در معماری میکرو سرویس ما همواره تلاش میکنیم که چندین تا از سرویس ها رو روی یک ماشین قرار ندیم و Pack شون نکنیم. درسته این جداسازی در این حد سختگیرانه ممکنه کمی سختی داشته باشه و واسه ما سربار Overhead ایجاد کنه اما سادگی حاصل از اینطور مجزا کردن باعث میشه ما بتونیم خیلی راحتتر و آسونتر سیستم توزیع شده رو مدیریت کنیم و البته فناوری های جدید خیلی میتونن برای این شکل از استقرار Deploy به ما کمک کنند.
تمام ارتباطات بین سرویس ها از طریق تماس های شبکه ای Network Calls هست تا جدایی نرم افزاری بین سرویس ها به درستی اعمال شوند و از خطرات اتصال فشرده جلوگیری شود.
سرویس ها باید بتونن به تنهایی تغییرات در اونها اعمال بشه بدون اینکه نیاز باشه سرویس دیگری تغییر کنه و بتونن به تنهایی Deploy بشن بدون اینکه در سرویس های دیگری چه مصرف کننده این سرویس و چه گیرنده این سرویس نیاز باشه دست ببریم. ما باید دقیقا بدونیم که سرویس های ما چه مواردی را باید از سرویس های دیگر افشا کنند و چ مواردی را باید پنهان کنند. اگر اشتراک بیش از حد وجود داشته باشد سرویس های مصرف کننده و خدمت گیرنده در هم درگیر میشوند و این خودمختاری سرویس را کمتر میکند و وقتی سرویس رو تغییر میدیم مجبور میشیم تو سرویس های دیگه هم دست ببریم و این اشتباه است.
هر سرویس ما Api های خودش Application Programming Interface خودش را ارائه میدهد و در معرض سرویس های دیگر قرار میدهد و سرویس ها از طریق این API ها با هم ارتباط برقرار میکنند. همچنین ما باید به این فکر کنیم که هر سرویسی با چه تکنولوژی باید نوشته شود و این سرویس ها تکنولوژی های متفاوت دارند که همین باعث میشه سرویس ها نتونن ارتباط غیر API ای با هم داشته باشند.
اگر سرویس ها از هم جدا نباشند همه چیز خراب میشود. همواره به این سوال طلایی پاسخ بدین: آیا من میتونم یک سرویس را به تنهایی تغییر بدم و به تنهایی روی سرور قرارش بدم Deploy کنم؟ اگر پاسختون به این سوال خیر بود، پس شما میکروسرویس خوبی ندارید و از مزایای این معماری نمیتونید استفاده کنید. برای جداسازی مناسب بین سرویس ها شما باید مدلسازی هر سرویس از روی بیزینس را به درستی انجام بدید و API های مناسبی را در نظر بگیرید.
مزایای اصلی تکنولوژی میکروسرویس Microservice Key Benefits
مزایای معماری میکروسرویس بسیار زیاد و گسترده هستند. بسیاری از این مزایا همان مزایایی هستند که در سیستم های توزیع شده Distributed Systems وجود داشتند. میکروسرویس در عین اینکه این مزایا را دارند بلکه در سطحی بالاتر به این مزایا خواهند رسید و همچنین از مزایای معماری سرویس گرا نیز Service Oriented Architecture:SOA نیز بهره میبرند. در زیر به برخی از این مزایای اصلی معماری سرویس گرا خواهم پرداخت.
مزیت ناهمگنی فناوری ها Technology Heterogenity در میکروسرویس ها
وقتی سیستمی متشکل از سرویس های جدا از هم و مستقل ولی در ارتباط با یکدیگر داریم، میتوانیم برای هر سرویس تکنولوژی های مجزایی انتخاب و استفاده کنیم.این امکان به ما این فرصت رو میده که برای هر کاری ابزار مناسبش رو در یک پروژه استفاده کنیم. یعنی مجبور نیستیم یک پلتفرم یا یک ابزار رو برای پروژه انتخاب کنیم بلکه برای هر کاری در نرم افزار و پروژه مان ابزار متناسب آن را انتخاب کنیم. اگر یک بخش از پروژه ما نیاز داشته باشد که پرفورمنس بهتری را داشته باشد میتوانیم ابزارهای فقط آن بخش را عوض کنیم. همچنین ممکن است نیاز داشته باشیم براساس تغییرات در ذخیره سازی دیتاها بخشی از نرم افزار فقط تغییر کند و با استفاده از این قابلیت میتوانیم نوع دیتا بیس هر سرویس و بخش را جدا انتخاب کنیم. ممکنت است نیاز باشد نوع ذخیره سازی اطلاعات در بخشی بصورت Document-Oriented یعنی همان مدل Nosql باشد و در بخشی دیگر بصورت Graph-Oriented باشد.
همچنین با استفاده از میکروسرویس تغییرات تکنولوژی در پروژه خیلی سریعتر و آسانتر انجام میشود. در مدل Monolithic اگر بخوایم دیتابیس یا پلتفرم یا زبان برنامه نویسی نرم افزار را تغییر دهیم، باید کل پروژه و حجم زیادی از کد را تغییر دهیم ولی در مدل میکروسرویس میتوان ابتدا بخشی را تغییر داد و پرفورمنس جدید را اندازه گیری کرد و این باعث میشود ریسک تغییرات را به شدت کاهش دهیم.
البته ابنم باید در نظر داشت استفاده از تکنولوژی های زیاد برای خودش مشکلاتی را دارد. بسیاری از شرکت ها در مورد Stack مورد استفاده خود و زبان های برنامه نویسی یکسری محدودیت هایی را در نظر میگیرند. مثلا Netflix و Twitter از تکنولوژی Java و JVM که قابل توسعه تر و Sale up تر هستند استفاده میکنند ولی همین باعث میشود واسه کسایی که غیرجاوا کار میکنند این مشکل باشد. پس این بستگی به توانایی شرکت دارد که چقدر بتواند پذیرایی تکنولوژی های جدید و متفاوت باشد و از این مزیت میکروسرویس بهره مند شود.
مزیت تاب آوری Resilience در میکروسرویس ها
در تاب آوری Resilience مهمترین اصلا جداره و فاصله است. یعنی اینکه اگر بخشی از سیستم دچار خطا و توقف شود آیا سایر بخش های سیستم فاصله مناسب با این سرویس دارد که بتوانند خودشان به کارشان ادامه دهند و کل سیستم از کار نیفتد؟ در واقع در میکروسرویس محدوده هر سرویس همان فاصله مورد نظر ما در بحث Resilience است. در معماری مونولیتیک اگر یک بخشی از نرم افزار از کار بیفتد قطعا عمکرد کل سیستم متوقف میشود. در معماری Monolithic ما میتواین نرم افزار را روی چندین ماشین مستقر کنیم تا اگر ماشینی از کار افتاد ماشین دیگر کار کند ولی موضوع این است اینکار پرهزینه است ولی با معماری میکروسرویس ما میتواینم سرویس هایی بسازیم که براساس آنها از کار افتادگی کمتر شود.البته ماشین ها و شبکه ها همواره مستعد از کار افتادن هستند و ما باید با درک درست از اتفاقاتی که میتواند رخ دهد سرویس هایمان و ارتباطات بین آنها را طراحی کنیم.
مزیت توسعه پذیری Scaling در میکروسرویس ها
در یک سیستم مونولیتیک یکپارچه ما باید همه چیز را با هم توسعه دهیم و Scale کنیم. ولی با میکروسرویس ما میتوانیم هر سرویس یا بخشی را که میخواهیم Scale کنیم بصورت جدا اینکار را انجام دهیم.وقتی نرم افزار ما یکپارچه است ما مجبوریم اگر تعداد کاربران یا بازدیدهای یک بخش زیاد شد کل سیستم را ارتقا دهیم ولی اگر سیستم به سرویس های کوچکتر تقسیم شود و هر سرویس را روی یک ماشین مجازی قرار داده باشیم میتوانیم براساس میزان استفاده از آن سرویس بهش منابع تخصیص بدیم و Scale ش کنیم. و این باعث میشه بتوانیم هزینه های سخت افزاری را کنترل کرده و کمتر کنیم.
مزیت راحتی در اسقرار Ease of Deployment در میکروسرویس ها
در سیستم های یکپارچه وقتی ما یک خط ار نرم افزار و کد را تغییر میدهیم همه چندین میلیون سطر برنامه باید دوباره آپلود و Deploy بشن و این باعث ریسک بسیار زیاد در Deploy میشه. در عمل اینطور آپلودها که High-Risk و Large-Impact هستند به دلیل ترسی که ایجاد میکنند به ندرت اتفاق میفتند. این بدان معناست که ما تغییرات کوچک را آپلود نمیکنیم و صبر میکنیم تغییراتی که انجام دادیم زیاد بشوند تا یکجا اونهارو آپلود کنیم و بعدش تست کنیم. و این باعث میشود که بازهم موقع آپلود یکپارچه خطر و ریسک اپلود تغییرات زیاد باشه و اینکه ما تغییرات رو معطل هر Release کردیم.
با استفاده از میکروسرویس ولی ما میتواینم هر سرویس را مستقل از کل نرم افزار Deploy کنیم. همین باعث میشه ما بتونیم دیپلوی های سریعتر داشته باشیم و سریعتر نسخه بدیم و وقتی مشکلی ایجاد شد سریعا رفع کرده و فقط همون سرویس را آپلود کنیم و حتی اگر آپلود مشکل داری داشتیم Rollback سریعتری داشته باشیم. همچنین این کمک میکنه ما ویژگی های جدید به نرم افزارمان را بصورت سریعتر تحویل بدیم. همین دلیل محکمیه که چرا شرکت هایی مثل آمازون و تویتر و نتفلیکس از این معماری میکروسرویس استفاده میکنند.
مزیت همراستایی با سازمان Organizational Alignment در میکروسرویس ها
ما خیلی از مشکلاتی که از تیم های بزرگ و مخزن کد عظیم ایجاد میشه رو تجربه کردیم ولی وقتی هر تیم کوچکی روی یک سرویس تمرکز کنه هم این مشکلات از بین میروند و هم خلاقیت تیم ها و افراد روی توسعه نرم افزار بیشتر میشه. میکروسرویس به ما این امکان میده که معماری و روش پیاده سازی نرم افزار را براساس ساختار سازمانیمون بچینیم. حتی ما میتوانیم افرادی که روی هر سرویس کار میکنند را براساس مالکیت سرویس بین افراد تغییر بدیم.
مزیت ترکیب پذیری Composability در میکروسرویس ها
یکی از مزایای خیلی اصلی که ما در معماری سرویس گرا SOA و سیستم های توزیع شده Distributed System ها داشتیم امکان استفاده مجدد از کدها از فانکشن ها بود. در مدل میکروسرویس ما در واقع این امکان را داریم که Functionalities های ما رای اهداف مختلف و در جاهای مختلف مصرف شود. مخصوصا وقتی نرم افزاری داریم که قراره هم روی وب و هم اپلیکیشن های موبایل و هم نرم افزار دسکتاپ به مشتریان ما سرویس بده، این قابلیت خیلی به کار میاد. در واقع سازمان ها دارن به این سمت میرن که سرویس های خودشون را روی Channel های مختلف ارائه بدن تا Customer Engagement بالاتر بره و برای رسیدن به این هدف باید نرم افزار معماری را داشته باشه که این قابلیت رو فراهم کنه.
مزیت بهینه بودن برای جایگزینی Optmizing for Replacability در میکروسرویس ها
اگر شما در یک سازمان متوسط و یا بزرگ کار میکنید احتمالا با نرم افزارهای کهنه و قدیمی و خیلی بد نوشته شده برخورد میکنید که هیچ کسی جرات نداره بهشون دست بزنه. نرم افزارهایی که فقط روی سخت افزار خاصی که واسه 25 سال پیش هست میتونن اجرا بشن و به زبان برنامه نویسی خیلی قدیمی نوشته شدند. خوب چرا این نرم افزارها جایگزین نمیشن؟ پاسخش مشخصه : چون خیلی بزرگ و عظیم هستند و جایگزین کردنشون خیلی پر ریسک هست. ولی اگر ساختار میکروسرویسی باشد جایگزین کردن یک سرویس کوچک یا کلا حذف کردن یک سرویس کار خیلی سختی نیست. حتی وقتی لازم باشه اعضای تیم میتونن یک سرویس رو کلا بزارن کنار و کدشو از نو بنویسن و اینکار بیشتر از 1-2 هفته زمان نخواهد بود و کار خیلی راحتیه و نکته مهم اینه وقتی یک سرویسی هست که کلا چند صد سطر کد داره، برنامه نویس ها روش خیلی تعصبی ندارن و به راحتی جایگزینش میکنند.
مقایسه میکروسرویس با معماری سرویس گرا Microservice Architecture vs SOA
معماری سرویس گرا Service Oriented Architecture یا همان SOA یک مدل معماری است که در آن چندین سرویس مجزا سعی میکنند یک قابلیت نهایی را ارائه کنند. این سرویس ها کاملا از هم مجزا هستند و حتی سیستم عاملشون هم میتونه فرق کنه و یا روی یک سیستم عامل پراسس های جدایی برای هر سرویس وجود خواهد داشت. ارتباط بین این سرویس ها از طریق لایه شبکه و API ها انجام میشه. معماری سرویس گرا به عنوان رویکردی برای حل مشکلات معماری یکپارچه Monolithic ایجاد شد. این معماری تونست قابلیت استفاده مجدد Reusability رو به شدت افزایش بده و حتی چندین کانال مختلف از نرم افزار میتونساتند از یک سرویس همزمان استفاده کنند. این روش معماری نگهداری و تغییرات در نرم افزار رو کاملا راحتتر کرد حتی این قابلیت رو داد که یک سرویس را بدون ایجاد تغییرات زیاد و جدی در سرویس های دیگر بتوانیم کاملا تغییر بدیم یا جایگزین کنیم. نفس SOA ذاتا ایده خیلی خوبی است با این وجود علیرغم تلاش های بسیار نحوه درست اجرای معماری سرویس گرا خیلی مشخص نیست.
بیشتر مشکلاتی که در این مدل معماری وجود داره نبود تعریف درستی از پروتکل های ارتباطی یا Middleware ها و یا عدم راهنمایی در مورد جزییات سرویس یا راهنمای نادرست در مورد انتخاب مکان تقسیم بندی سیستم به سرویس ها می باشد. بیشتر قراردادهایی که حول SOA وجود دارد کمکی به شما نیمکند که بدانید یک سیستم بزرگ را چگونه به بخش های کوچک تقسیم کند. ولی میکروسرویس این مشکلات را حل کرده است. در واقع میتوان معماری میکروسرویس را یک نمونه و پلتفرم مشخص برای معماری SOA دانست. البته علاوه بر مدل SOA دو تا مدل برای تقسیم سیستم به بخش های کوچک وجود دارد که یکیش مدل Shared Libraries هست که میاد یه سری سرویس های کوچک و کتابخانه ابتدا مینوسیم و بعدش نرم افزار ما از این کتابخونه ها استفاده میکنه و مدل دیگر برنامه نویسی Modular هست که خود پلتفرم برنامه نویسی مثلا بصورت MVC میاد پروژه رو ماژولار میکنه که البته هیچکدام از این دو روش اولین قابلیت میکروسرویس را که همان استفاده از چندین تکنولوژی هست رو به ما نمیدهند و نمیتونند جایگزین معماری میکروسرویس باشند.
البته در نظر بگیرید معماری میکروسرویس یک نهار رایگان یا یه عصای جادویی محسوب نمیشه و مشکلات و پیچیدگی های خاص خودش رو داره. این مدل معماری مدل کدنویسی و معماری و حتی استقرار و تست متفاوتی رو داره و اگر شما از معماری مونولیتیک دارین به سمت میکروسرویس میاین احتمالا کلی پیچیدگی هست که باید یاد بگیرین و حلشون کنید.
