اصول معماری میکروسرویس

هنگامی که تیم های محصول و مهندسی کوچک و محکم هستند ، آنها اغلب مجموعه ای از اصول ناگفته و بدون مستند را به اشتراک می گذارند که پیشرفت آنها را راهنمایی می کند. این اصول از طریق بحث و گفتگو ، بررسی کد و مراسم چرخه عمر توسعه محصول به صورت ارگانیک بوجود می آیند. اما هنگامی که تیم ها فراتر از شماره Dunbar دوم (15) رشد می کنند ، توسعه ارگانیک و انتشار اصول دشوار می شود. گردش مالی بالا یا رشد سریع در سازمان را اضافه کنید و مشکل تشدید می شود. عدم وجود اصول متداول در سراسر سازمان منجر به تنوع بالای کیفیت ، در دسترس بودن ، مقیاس پذیری ، هزینه عملیات و هزینه توسعه می شود. ما در دو سال اول خود به عنوان یک شرکت ، این مشکل را در چندین مشتری مشاهده کردیم و وقتی نسخه اول هنر مقیاس پذیری را راه اندازی کردیم ، بخشی را فقط به اصول معماری اختصاص دادیم. در حالی که ما هنوز از این اصول در عمل خود استفاده می کنیم ، و در حالی که آنها در مورد انواع پیاده سازی ها از جمله راه حل های میکروسرویس اعمال می شوند ، ما هرگز آنها را اصلاح نکردیم تا مستقیماً با نیازهای معماری خدمات ریز و درشت صحبت کنند. با افزایش رشد و معماری سازمان و معماری ، میکروسرویس مزایای زیادی برای سازمان ها ارائه می دهد. این که آیا شما در حال اصلاح مجدد یک یکپارچه برای ایجاد هزینه بهتر مقیاس در سازمان خود هستید ، ایجاد یک راه حل جدید از ابتدا یا فقط تلاش برای تعیین اینکه آیا تفکیک خدمات برای داشتن مجموعه ای از اصول برای راهنمایی بحث و توسعه کمک خواهد کرد. اصول زیر ترکیبی از اصول اصلی معماری ما است (هر یک از آنها حتی اگر در زیر وجود نداشته باشد) علاوه بر برخی اصول جدید که با نیازهای منحصر به فرد محصولات متشکل از خدمات سروکار دارد. بسیاری از اصول همچنین الگوهای طراحی خاصی برای کمک به پیاده سازی ها دارند و برخی از آنها ضد الگوی دارند تا از هر هزینه خودداری کنند. ضد الگوی وجود دارد تا نشان دهد چه نوع تعامل باعث نقض اصل به ضرر یک یا چند مورد غیر کاربردی مانند در دسترس بودن ، مقیاس پذیری و هزینه عملکرد یا توسعه می شود.

1. اهمیت اندازه - کوچکتر همیشه بهتر نیست

    

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

سرعت توسعه دهنده:یکی از مهمترین مزایای جداسازی خدمات ، سرعت تیم است. با رشد تیم ها ، هزینه بالای هماهنگی بین اعضای تیم که روی یک سرویس واحد کار می کنند به عنوان مربعی از اندازه تیم رشد می کند. به همین ترتیب فواید زیادی در تقسیم پایه کد برای ایجاد سرعت بالاتر وجود دارد ، اما فرض می کند که هر سرویس متعلق به یک تیم واحد است. وقتی یک تیم واحد بیش از یک سرویس داشته باشد ، ما سرعت را به میزان قابل توجهی افزایش نمی دهیم و در واقع اگر یک تیم دارای خدمات زیادی باشد ، می توانیم با نیاز به اعضای تیم برای جابجایی بین خدمات و مخازن ، سرعت را کاهش دهیم. ما اغلب نشان می دهیم که یک تیم نباید بیش از 3 سرویس داشته باشد و هیچ دو تیم نباید صاحب همان خدمات باشند.متن نوشته:زمینه ، به طور بالقوه با کمک توسعه دامنه ها (مانند طراحی دامنه محور) در شناسایی مؤلفه هایی که می توانند از هم جدا شوند مهم است. در یک سیستم برنامه ریزی منابع سازمانی (ERP) ، مفهوم صورتحساب به وضوح یک زمینه جداگانه از حقوق و دستمزد است. در حالی که هر دو اطلاعاتی را نشان می دهند که در صورت درآمد ، بیانیه جریان نقدی و ترازنامه ارائه شده اند ، جدایی کافی وجود دارد که این دو می توانند در خدمات جداگانه باشند. هیچ یک از اینها استدلال نمی کنند که آنها باید در خدمات جداگانه باشند ، بلکه نامزدهای خوبی برای جدایی هستند. همیشه در هنگام تعریف مرزهای مربوط به زمینه برای خدمات ، دیدگاه مشتری را در نظر بگیرید - از مشتری به جای مهندس رو به جلو - در حال توسعه است. نتیجه این امر این است که بعضی چیزها نباید تقسیم شوند.

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

• همه چیز لازم نیست که کوچک باشد - مهم نیست که "یک کار را انجام دهد". انجام "یک چیز" با ارزش تجاری بسیار ارتباط ندارد و در صورت افراط و تفریط ، در نتیجه خدمات بیش از حد کوچک می تواند با افزایش هزینه توسعه و کاهش در دسترس بودن ، ارزش کسب و کار را از بین ببرد.

   

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

   

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

برای مطالعه بیشتر در مورد DOS و Dont of State Cube Session State Cube ما را بررسی کنید.

• به شما امکان می دهد دقیقاً آنچه را که آزمایش می کنید مستقر کنید. با فرض اینکه ظرف را از DEV به محیط های مناسب QA منتقل می کنید و متعاقباً به تولید می دانید که آنچه آزمایش می کنید همان چیزی است که شما مستقر خواهید کرد. این به نوبه خود این احتمال را کاهش می دهد که تغییرات بین محیط ها نقص های جدیدی را در راه حل شما ایجاد کرده و به افزایش کیفیت کلی کمک می کند.

   

ظروف سطح انتزاع را ایجاد می کنند که به افزایش کیفیت و افزایش سهولت راه حل های نزدیکتر به مشتری و انواع ارائه دهندگان کمک می کند و از این طریق انعطاف پذیری عملیاتی و تجاری را افزایش می دهد.

• نظارت بر اثربخشی و استفاده و مقایسه آن با رفتارهای مورد انتظار.

   

سفر به میکروسرویس را سوار می کنید؟AKF Partners بیش از یک دهه به شرکتها در اجرای محصولات از طریق خدمات کمک می کند. با ما تماس بگیرید یا به ما ایمیل بزنید - ما می توانیم کمک کنیم!

AKF Partners آموزش معماری را برای معماری خدمات برای اطلاعات بیشتر با ما تماس می گیرد.