دوگانگی داده ها: بازنگری در رابطه بین داده ها و خدمات

سلام به همه! ما خبرهای خوبی داریم، OTUS این دوره را دوباره در ژوئن راه اندازی می کند "معمار نرم افزار"، در رابطه با آن ما به طور سنتی مطالب مفیدی را با شما به اشتراک می گذاریم.

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

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

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

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

بنابراین امروز به این خواهیم پرداخت که قوانین چگونه تغییر کرده‌اند، چرا باید در نحوه برخورد با سرویس‌ها و داده‌هایی که آنها به یکدیگر منتقل می‌کنند تجدید نظر کنیم، و چرا برای انجام آن به ابزارهای کاملاً متفاوتی نیاز داریم.

کپسولاسیون همیشه دوست شما نخواهد بود

میکروسرویس ها می توانند مستقل از یکدیگر عمل کنند. این ویژگی است که به آنها بیشترین ارزش را می دهد. همین ویژگی به خدمات اجازه می دهد تا مقیاس و رشد کنند. نه به معنای مقیاس دهی به چهار میلیارد کاربر یا پتابایت داده (اگرچه این داده ها می توانند به شما کمک کنند)، بلکه به معنای مقیاس بندی از نظر افراد به عنوان تیم ها و سازمان ها به طور مداوم رشد می کنند.

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

به عنوان بخشی از رویکرد استاندارد، آنها به سادگی سعی می کنند از تغییرات آزاردهنده انتها به انتها اجتناب کنند و عملکردها را به وضوح بین سرویس ها تقسیم کنند. در اینجا سرویس Single Sign-on می تواند مثال خوبی باشد. نقش مشخصی دارد که آن را از سایر خدمات متمایز می کند. این تفکیک واضح به این معنی است که در دنیایی که تقاضاها به سرعت در حال تغییر برای سرویس‌های اطراف است، بعید است که سرویس ثبت نام واحد تغییر کند. در یک زمینه کاملاً محدود وجود دارد.

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

بیشتر خدمات تجاری جریان داده یکسانی را به اشتراک می گذارند، بنابراین کار آنها همیشه در هم تنیده است.

بنابراین به نکته مهمی می رسیم که ارزش صحبت کردن را دارد. در حالی که خدمات برای مؤلفه‌های زیرساختی که عمدتاً به صورت مجزا عمل می‌کنند، به خوبی کار می‌کنند، اکثر خدمات تجاری در نهایت بسیار نزدیک‌تر در هم تنیده می‌شوند.

دوگانگی داده ها

رویکردهای سرویس گرا ممکن است در حال حاضر وجود داشته باشند، اما هنوز بینشی در مورد نحوه به اشتراک گذاری مقادیر زیادی داده بین سرویس ها ندارند.

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

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

و در اینجا یک دوراهی پیش می آید. تناقض. دوگانگی. به هر حال، سیستم های اطلاعاتی در مورد ارائه داده ها هستند و خدمات مربوط به پنهان کردن هستند.

این دو نیرو اساسی هستند. آنها زیربنای بسیاری از کارهای ما هستند و دائماً برای برتری در سیستم هایی که می سازیم می جنگند.

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

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

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

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

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

هرچه کپی‌ها تغییرپذیرتر باشند، داده‌ها در طول زمان تغییر خواهند کرد.

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

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

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

چرخه شکست داده ها

جریان ها: یک رویکرد غیرمتمرکز به داده ها و خدمات

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

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

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

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

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

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

دوگانگی داده ها را با جداسازی جریان حالت تغییرناپذیر حذف کنید. سپس این قابلیت را با استفاده از حالت Stateful Stream Processing به هر سرویس اضافه کنید.

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

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

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

بنابراین، رویکرد مورد بحث امروز چندین مزیت دارد:

• داده ها به شکل جریان های معمولی استفاده می شوند که می توانند برای مدت طولانی در گزارش ها ذخیره شوند، و مکانیسم کار با داده های مشترک در هر زمینه جداگانه ای تنظیم شده است که به سرویس ها اجازه می دهد به راحتی و سریع کار کنند. به این ترتیب می توان دوگانگی داده ها را متعادل کرد.
• داده های حاصل از سرویس های مختلف را می توان به راحتی در مجموعه ها ترکیب کرد. این کار تعامل با داده های مشترک را ساده می کند و نیاز به نگهداری مجموعه داده های محلی در پایگاه داده را از بین می برد.
• حالت Stateful Stream Processing فقط داده‌ها را در حافظه پنهان نگه می‌دارد و منبع حقیقت همان گزارش‌های عمومی است، بنابراین مشکل خرابی داده‌ها در طول زمان چندان حاد نیست.
• در هسته خود، سرویس ها مبتنی بر داده هستند، به این معنی که با وجود افزایش روزافزون حجم داده ها، خدمات همچنان می توانند به سرعت به رویدادهای تجاری پاسخ دهند.
• مسائل مقیاس پذیری بر عهده کارگزار است نه خدمات. این به طور قابل توجهی پیچیدگی خدمات نوشتن را کاهش می دهد، زیرا نیازی به فکر کردن در مورد مقیاس پذیری نیست.
• افزودن سرویس‌های جدید نیازی به تغییر سرویس‌های قدیمی ندارد، بنابراین اتصال سرویس‌های جدید آسان‌تر می‌شود.

همانطور که می بینید، این چیزی بیش از REST است. ما مجموعه‌ای از ابزارها را دریافت کرده‌ایم که به شما امکان می‌دهد با داده‌های مشترک به صورت غیرمتمرکز کار کنید.

در مقاله امروز همه جنبه ها پوشش داده نشد. ما هنوز باید بفهمیم که چگونه بین پارادایم درخواست-پاسخ و پارادایم رویداد محور تعادل برقرار کنیم. اما دفعه بعد به این موضوع می پردازیم. موضوعاتی وجود دارد که باید آنها را بهتر بشناسید، به عنوان مثال، چرا پردازش جریانی Stateful اینقدر خوب است. در مقاله سوم در این مورد صحبت خواهیم کرد. و ساختارهای قدرتمند دیگری وجود دارد که اگر به آنها متوسل شویم، می توانیم از آنها استفاده کنیم، برای مثال، دقیقا یک بار پردازش. این یک تغییر دهنده بازی برای سیستم های تجاری توزیع شده است زیرا تضمین های معاملاتی را برای آن فراهم می کند XA به شکل مقیاس پذیر در مقاله چهارم به این موضوع پرداخته خواهد شد. در نهایت، ما باید جزئیات اجرای این اصول را مرور کنیم.

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

درباره دوره بیشتر بدانید.

منبع: www.habr.com