پیش نیازهای میکروسرویس ها

همانطور که با مردم در مورد استفاده از سبک معماری میکروسرویس صحبت می کنم، خوش بینی های زیادی می شنوم. توسعه دهندگان از کار با واحدهای کوچکتر لذت می برند و انتظارات ماژولار بودن بهتری نسبت به یکپارچه ها دارند. اما مانند هر تصمیم معماری، معاوضه هایی وجود دارد. به ویژه در مورد ریزسرویس‌ها، عواقب جدی برای عملیات‌ها وجود دارد، که اکنون مجبورند اکوسیستمی از خدمات کوچک را به جای یک مونولیت واحد و کاملاً تعریف شده مدیریت کنند. در نتیجه، اگر شایستگی‌های پایه خاصی ندارید، نباید از سبک میکروسرویس استفاده کنید.تهیه سریع: شما باید بتوانید یک سرور جدید را در عرض چند ساعت راه اندازی کنید. طبیعتاً این با Cloud Computing مطابقت دارد، اما همچنین کاری است که می‌توان بدون یک سرویس ابری کامل انجام داد. برای اینکه بتوانید چنین تدارکات سریعی را انجام دهید، به اتوماسیون زیادی نیاز دارید - ممکن است برای شروع لازم نباشد کاملاً خودکار باشد، اما برای انجام ریزسرویس‌های جدی بعداً باید به آن راه برسد.نظارت اولیه: با بسیاری از سرویس‌هایی که در تولید با همدیگر همکاری می‌کنند، چیزهایی که در محیط‌های آزمایشی به سختی قابل تشخیص هستند، اشتباه می‌شوند. در نتیجه ضروری است که یک رژیم نظارتی برای شناسایی سریع مشکلات جدی وجود داشته باشد. خط پایه در اینجا تشخیص مسائل فنی (شمارش خطاها، در دسترس بودن خدمات و غیره) است، اما ارزش نظارت بر مسائل تجاری (مانند تشخیص کاهش سفارشات) را نیز دارد. اگر یک مشکل ناگهانی ظاهر شد، باید اطمینان حاصل کنید که می‌توانید به سرعت به عقب برگردید، بنابراین…استقرار سریع برنامه: با بسیاری از خدمات برای مدیریت، باید بتوانید به سرعت آنها را هم برای آزمایش محیط ها و هم برای تولید به کار بگیرید. معمولاً این شامل یک DeploymentPipeline است که می تواند در کمتر از چند ساعت اجرا شود. برخی از مداخلات دستی در مراحل اولیه مشکلی ندارند، اما به زودی به دنبال خودکارسازی کامل آن خواهید بود.این قابلیت ها حاکی از یک تغییر سازمانی مهم است - همکاری نزدیک بین توسعه دهندگان و عملیات: DevOpsCulture. این همکاری برای اطمینان از اینکه تدارک و استقرار می‌تواند به سرعت انجام شود، لازم است، همچنین مهم است که اطمینان حاصل شود که می‌توانید در زمانی که نظارت شما مشکلی را نشان می‌دهد، سریع واکنش نشان دهید. به طور خاص، هر گونه مدیریت حادثه نیاز به مشارکت تیم توسعه و عملیات دارد، هم در رفع مشکل فوری و هم در تجزیه و تحلیل علت ریشه ای برای اطمینان از رفع مشکلات اساسی.با این نوع تنظیم، شما برای اولین سیستم با استفاده از تعداد انگشت شماری میکروسرویس آماده هستید. این سیستم را مستقر کنید و از آن در تولید استفاده کنید، انتظار داشته باشید در مورد سالم نگه داشتن آن و اطمینان از اینکه همکاری devops به خوبی کار می کند چیزهای زیادی یاد بگیرید. برای انجام این کار به خودتان زمان بدهید، از آن بیاموزید، و قبل از اینکه تعداد خدمات خود را افزایش دهید، توانایی بیشتری کسب کنید.اگر اکنون این قابلیت ها را ندارید، باید اطمینان حاصل کنید که آنها را توسعه داده اید تا زمانی که یک سیستم میکروسرویس را وارد مرحله تولید کنید آماده باشند. در واقع اینها قابلیت هایی هستند که شما واقعاً باید برای سیستم های یکپارچه نیز داشته باشید. در حالی که آنها به طور جهانی در سازمان‌های نرم‌افزاری وجود ندارند، مکان‌های بسیار کمی وجود دارند که نباید در اولویت قرار گیرند.فراتر رفتن از تعداد انگشت شماری از خدمات، به موارد بیشتری نیاز دارد. شما باید تراکنش‌های تجاری را از طریق چندین سرویس ردیابی کنید و با پذیرش کامل Continuous Delivery، تهیه و استقرار خود را خودکار کنید. همچنین تغییر به سمت تیم های محصول محور است که باید راه اندازی شود. شما باید محیط توسعه خود را سازماندهی کنید تا توسعه دهندگان بتوانند به راحتی بین چندین مخزن، کتابخانه و زبان جابه جا شوند. برخی از مخاطبین من احساس می‌کنند که می‌تواند یک MaturityModel مفید در اینجا وجود داشته باشد که می‌تواند به سازمان‌ها در هنگام اجرای میکروسرویس‌های بیشتر کمک کند - ما باید در چند سال آینده شاهد گفتگوهای بیشتری در مورد آن باشیم.