معماری Monolithic چیست؟ 

 ارزش معماری Microservices

افزایش یک سرویس خاص

فواید استفاده از فریم‌ورک Seneca  

{
    "name": "seneca-example",
    "dependencies": {
        "seneca": "0.6.5",
        "express": "latest"
    }
}

var seneca = require("seneca")();

seneca.add({role: "accountManagement", cmd: "login"}, function(args, respond){
});
seneca.add({role: "accountManagement", cmd: "register"}, function(args, respond){
});

seneca.act({role: "accountManagement", cmd: "register", username:
"parham", password: "12345!"}, function(error, response){
});

seneca.act({role: "accountManagement", cmd: "login", username:
"parham", password: "12345!"}, function(error, response){
});

function account(options){
    this.add({init: "account"}, function(pluginInfo, respond){
        console.log(options.message);
        respond();
    })  

    this.add({role: "accountManagement", cmd: "login"}, function(args, respond){
     }); 

    this.add({role: "accountManagement", cmd: "register"}, function(args, respond){
    });
}

seneca.use(account, {message: "Plugin Added"});

module.exports = function(options){
    this.add({init: "account"}, function(pluginInfo, respond){
        console.log(options.message);
        respond();
    })

    this.add({role: "accountManagement", cmd: "login"}, function(args, respond){
    });

    this.add({role: "accountManagement", cmd: "register"},function(args, respond){
    });

    return "account";
}  

seneca.use("./account.js", {message: "Plugin Added"});

var seneca = require("seneca")();
seneca.use("./account.js", {message: "Plugin Added"});
seneca.listen({port: "9090", pin: {role: "accountManagement"}});

seneca.client({port: "9090", pin: {role: "accountManagement"}});

 معماری میکرو سرویس یا یکپارچه؟

برای درک میکروسرویس‌ها، باید بدانیم کاربرد سیستم‌های یکپارچه چیست و چه چیزی باعث شد در زمان‌های اخیر از برنامه‌های یکپارچه به میکروسرویس‌ها حرکت کنیم.

 سیستم‌های یکپارچه ( Monolithic applications  )

اگر تمام عملکردهای یک پروژه در یک بخش واحد وجود داشته باشند، آن برنامه به عنوان یک برنامه‌ی یکپارچه شناخته می‌شود. ما برنامه‌ی خود را در لایه‌های مختلفی مانند Presentation ، Service ، UI  طراحی می‌کنیم و سپس آن بخش از کدهای نوشته شده را به عنوان یک فایل خروجی به کار می‌گیریم. این چیزی نیست جز یک برنامه‌ی یکپارچه، که در آن " mono " یک پایگاه کد منفرد حاوی تمام عملکردهای مورد نیاز را نشان می‌دهد.

چرا اصلا به سمت میکروسرویس‌ها برویم؟

خب برای جواب به این سوال بهتر است معایب سیستم‌های یکپارچه را مرور کنیم:

1. مدیریت دشوار بخاطر گسترش برنامه در گذشت زمان
2. برای تغییری کوچک، کل برنامه را دوباره باید منتشر ( publish ) کنیم
3. با تغییر و آپدیت برنامه، زمان انتشار افزایش می‌یابد.
4. درک دشوار برای توسعه دهنده‌های جدید هر پروژه
5. برای تقسیم ترافیک روی قسمت‌های مختلف برنامه، باید نمونه‌های کل برنامه را در چندین سرور منتشر کنیم که بسیار ناکارآمد و باعث استفاده‌ی بیهوده از منابع میشود
6. اگر از فناوری یا تکنولوژی‌های جدید استفاده کنیم، برای عملکردی خاص، چه از نظر هزینه و چه از نظر زمان، بر کل برنامه تاثیر گذار است
7. و در نهایت وجود یک باگ در هر ماژول میتواند کل برنامه را مختل کند.

و اما مزایای سیستم‌های یکپارچه:

1. توسعه‌ی آن نسبت به میکروسرویس‌ها ساده است.
2. انتشار آن آسان‌تر است؛ زیرا فقط یک خروجی، مستقر شده‌است.
3. در مقایسه با معماری میکروسرویس‌ها، توسعه‌ی آن نسبتا آسان‌تر و ساده‌تر است.
4. مشکلات تأخیر و امنیت شبکه در مقایسه با معماری میکروسرویس‌ها نسبتاً کمتر است.
5. توسعه دهندگان نیازی به یادگیری برنامه‌های مختلف ندارند؛ آنها می‌توانند تمرکز خود را بر روی یک برنامه حفظ کنند.

میکروسرویس ها

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

معماری میکروسرویس تأثیر بسزایی در رابطه‌ی بین برنامه و پایگاه داده دارد. بجای اشتراک گذاری یک پایگاه داده با سایر میکروسرویس‌ها، هر میکروسرویس، پایگاه داده خاص خود را دارد که اغلب منجر به تکثیر برخی از داده‌ها می‌شود، اما اگر می‌خواهید از این معماری بهره مند شوید، داشتن یک پایگاه داده در هر میکروسرویس، ضروری است؛ زیرا اتصال ضعیف را تضمین می‌کند. مزیت دیگر داشتن یک پایگاه داده‌ی مجزا برای هر میکروسرویس این است که هر میکروسرویس می‌تواند از نوع پایگاه داده‌ای که برای نیازهای خود مناسب‌تر است، استفاده کند. هر سرویس یک ماژول را ارائه می‌دهد، به طوری که خدمات مختلف را می‌توان به زبان‌های برنامه نویسی مختلف نوشت. الگوهای زیادی در معماری میکروسرویس دخیل هستند مانند discovery و registry service ، Caching ، ارتباط API ، امنیت و غیره.

اصول میکروسرویس‌ها:

تک مسئولیتی: یکی از اصولی است که به عنوان بخشی از الگوی طراحی SOLID تعریف شده است. بیان می‌کند که یک Unit ، یا یک کلاس، یک متد یا یک میکروسرویس باید تنها یک مسئولیت را داشته باشد. هر میکروسرویس باید یک مسئولیت داشته باشد و یک عملکرد واحد را ارائه دهد. شما همچنین می‌توانید بگویید تعداد میکروسرویس‌هایی که باید توسعه دهید، برابر با تعداد عملکردهای مورد نیاز شما است. پایگاه داده نیز غیرمتمرکز است و به طور کلی، هر میکروسرویس، پایگاه داده خاص خود را دارد.

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

طراحی برای مدیریت خطاها: میکروسرویس‌ها باید با در نظر گرفتن مدیریت خطاها طراحی شوند. میکروسرویس‌ها باید از مزیت این معماری استفاده کنند و پایین آمدن یک میکروسرویس نباید بر کل سیستم تأثیر بگذارد و سایر عملکردها باید در دسترس کاربر باقی بمانند. اما در برنامه‌های کاربردی سیستم‌های یکپارچه که خطای یک ماژول منجر به سقوط کل برنامه می‌شود، اینگونه نبود.

مزایای میکروسرویس ها:

1. مدیریت آن آسان است زیرا نسبتا کوچکتر است.
2. اگر در یکی از میکروسرویس‌ها، بروزرسانی وجود داشته باشد، باید فقط آن میکروسرویس را مجدداً منتشر کنیم.
3. میکروسرویس‌ها مستقل هستند و از این رو به طور مستقل منتشر می‌شوند. زمان راه اندازی و انتشار آنها نسبتاً کمتر است.
4. برای یک توسعه‌دهنده جدید بسیار آسان است که وارد پروژه شود، زیرا او باید فقط یک میکروسرویس خاص را که عملکردی را که روی آن کار می‌کند، درک کند و نه کل سیستم را.
5. اگر یک میکروسرویس خاص به دلیل استفاده بیش از حد کاربران از آن عملکرد، با بار زیادی مواجه است، ما باید فقط آن میکروسرویس را تنظیم کنیم. از این رو، معماری میکروسرویس از مقیاس بندی افقی پشتیبانی می‌کند.
6. هر میکروسرویس بر اساس نیازهای تجاری می‌تواند از فناوری‌های مختلفی استفاده کند.
7. اگر یک میکروسرویس خاص به دلیل برخی باگ‌ها از کار بیفتد، بر روی سایر میکروسرویس‌ها تأثیر نمی‌گذارد و کل سیستم دست نخورده باقی می‌ماند و به ارائه سایر عملکردها به کاربران ادامه می‌دهد.

معایب میکروسرویس ها:

1. پیچیده است و پیچیدگی آن با افزایش تعداد ریز سرویس‌ها افزایش می‌یابد.
2. نیاز به نیروهای متخصص
3. استقرار مستقل میکروسرویس‌ها پیچیده‌است.
4. میکروسرویس‌ها از نظر استفاده از شبکه پرهزینه هستند؛ زیرا نیاز به تعامل با یکدیگر دارند و همه این تماس‌های راه دور منجر به تأخیر شبکه می‌شود.
5. امنیت کمتر به دلیل ارتباط بین سرویس‌ها
6. اشکال زدایی دشوار است

مایکرو سرویس چیست ؟

 معماری پیازی توسط جفری پالرمو در سال 2008 ابداع شد. این معماری راه بهتری را برای ساخت برنامه‌های کاربردی جهت تست پذیری، نگهداری و قابلیت اطمینان بهتر بر روی زیرساخت‌هایی مانند پایگاه‌های داده و خدمات ارائه می‌دهد. هدف اصلی این معماری، پرداختن به چالش‌های پیش روی معماری 3 لایه و ارائه راه حلی برای مشکلات رایج مانند اتصال و جداسازی وابستگی‌ها است. دو نوع اتصال وجود دارند؛ اتصال محکم و اتصال ضعیف که در ادامه آنها را بررسی میکنیم.

اتصال محکم

هنگامی که یک کلاس، به یک وابستگی مشخصی وابسته است، گفته می‌شود که به شدت با آن کلاس همراه است. یک اتصال محکم جفت شده، به یک شیء دیگر وابسته است. این بدان معناست که تغییر یک شیء در یک برنامه‌ی با اتصال محکم جفت شده، اغلب نیاز به تغییر در تعدادی از اشیاء دیگر دارد. هنگامیکه یک برنامه کوچک است، دشوار نیست، اما در یک برنامه‌ی بزرگ، ایجاد تغییرات بسیار دشوار است.

اتصال ضعیف

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

مزایای معماری پیازی

چندین مزیت برای معماری پیازی وجود دارند که در زیر ذکر شده‌اند:

• قابلیت نگهداری بهتری را فراهم می‌کند؛ زیرا همه کدها به لایه‌ها یا مرکز، بستگی دارند.
• تست پذیری بهتری را فراهم می‌کند؛ زیرا آزمون واحد را می‌توان برای لایه‌های جداگانه، بدون تأثیر بر سایر ماژول‌های برنامه ایجاد کرد.
• این برنامه یک برنامه‌ی کاربردی با اتصال آزاد را ایجاد می‌کند؛ زیرا لایه بیرونی برنامه، همیشه از طریق واسط‌ها با لایه داخلی، ارتباط برقرار می‌کند.
• هرگونه پیاده سازی پیوسته، در زمان اجرا به برنامه ارائه می‌شود.
• موجودیت‌های دامنه، هسته و بخش مرکزی هستند. می‌تواند به هر دو لایه پایگاه داده و UI دسترسی داشته باشد.
• لایه‌های داخلی هرگز به لایه خارجی وابسته نیستند. کدی که ممکن است تغییر کرده باشد، باید بخشی از یک لایه خارجی باشد.

لایه‌های معماری پیاز

این معماری به شدت به اصل وارونگی وابستگی، متکی است. رابط کاربری از طریق واسط‌ها با منطق تجاری ارتباط برقرار می‌کند و دارای چهار لایه است. لایه‌ها به سمت مرکز هستند. بخش مرکزی، موجودیت‌های Domain است که نشان‌دهنده موضوعات تجاری و رفتاری است. این لایه‌ها می‌توانند متفاوت باشند اما لایه موجودیت‌های دامنه، همیشه بخشی از دامنه‌ی مرکزی است. لایه دیگر، رفتار بیشتر یک شیء را تعریف می‌کند. در ادامه به توضیح لایه‌های معماری پیاز توجه فرمایید:

Domain Entities Layer

این بخش مرکزی معماری است. تمام اشیاء دامنه‌ی برنامه را در خود نگه می‌دارد. اگر برنامه ای با چهارچوب موجودیت ORM توسعه داده شود، این لایه دارای کلاس‌های POCO (Code First) یا Edmx (Database First) با موجودیت‌ها است. این نهادهای دامنه هیچ وابستگی ندارند.

Repository Layer

این لایه برای ایجاد یک لایه Abstraction بین لایه نهادهای دامنه و لایه منطق تجاری یک برنامه، در نظر گرفته شده‌است. این یک الگوی دسترسی به داده‌است که باعث می‌شود یک رویکرد مرتبط‌تر برای دسترسی به داده‌ها وجود داشته باشد. ما یک مخزن عمومی را ایجاد می‌کنیم که منبع داده را برای داده‌ها جستجو می‌کند، داده‌ها را از منبع داده به یک نهاد تجاری نگاشت می‌کند و تغییرات موجودیت تجاری را به منبع داده ارائه می‌دهد.

Service Layer

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

UI Layer

خارجی‌ترین لایه است و می‌تواند برنامه‌ی وب، Web API یا پروژه واحد تست باشد. این لایه دارای یک پیاده سازی از جنس Dependency Inversion Principle است بطوری که برنامه، یک برنامه‌ی کاربردی جفت شده‌ی آزاد می‌سازد و از طریق واسط‌ها با لایه داخلی ارتباط برقرار می‌کند.

در مطالب بعدی با مبحث معماری پیازی، نکات تکمیلی و مهمتری از لایه پیاز را تشریح میکنیم و یک پروژه را با معماری پیاز، راه اندازی میکنیم.

ویژگی‌های یک مایکرو سرویس چیست؟

Componentization via Services 

Scaling