الگوی Geode شامل استقرار مجموعه‌ای از سرویس‌های پشتیبان در مجموعه‌ای از گره‌های جغرافیایی است که هر کدام می‌توانند هر درخواستی را برای هر مشتری در هر منطقه ارائه دهند. این الگو اجازه می‌دهد تا درخواست‌ها را به سبک فعال - فعال (active-active) ارائه کند، با توزیع توان پردازشی مربوط به درخواست‌ها در سراسر جهان، تأخیر زمانی را بهبود بخشد و دسترسی را افزایش دهد.
بسیاری از سرویس‌هایی که مقیاس بزرگی دارند، چالش‌های خاصی در مورد دسترسی جغرافیایی و مقیاس‌پذیری دارند. طرح‌های کلاسیک اغلب داده‌ها را با ذخیره داده‌ها در یک سرور SQL ریموت که به‌عنوان لایه محاسباتی برای آن داده‌ها عمل کرده و محاسبه و پردازش می‌کنند که باتوجه‌به افزایش مقیاس (scale-up) کردن سرویس‌های می‌توان این توان محاسباتی را افزایش داد. رویکرد کلاسیک ممکن است تعدادی چالش را به همراه داشته باشد: * مشکلات تأخیر شبکه برای کاربرانی که از آن‌سوی جهان می‌آیند تا به host endpoint متصل شوند. * مدیریت ترافیک برای افزایش ناگهانی تقاضا که می‌تواند سرویس‌ها را در یک منطقه تحت‌الشعاع قرار دهد. * پیچیدگی و پرهزینه بودن استقرار نسخه‌های زیرساخت برنامه در چندین منطقه برای یک سرویس با مصرف ماهانه به‌صورت 24x7 که به معنی ۲۴ ساعت در ۷ روز هفته است. زیرساخت‌های ابری مدرن برای فعال‌کردن توزیع بار جغرافیایی (geographic load balancing) جهت سرویس‌های front-end، تکامل‌یافته است. درحالی‌که امکان تکثیرکردن جغرافیایی (geographic replication) سرویس‌ها backend را فراهم می‌کند. پس برای افزایش کیفیت موردهایی مثل دردسترس‌بودن(availability) و کارایی(performance) بهتر است نزدیک‌تر کردن مکان فیزیکی اطلاعات به کاربرها رو به‌عنوان یک گزینه خوب در نظر بگیریم. هنگامی داده‌ها از نظر فیزیکی و جغرافیایی دور از کاربر قرار دارد، ذخیره‌ساز یا datastore توزیع‌شده‌ی - جغرافیایی(geo-distributed) نیز باید با منابع محاسباتی که داده‌ها را پردازش می‌کنند در کنار هم قرار گیرند. در این حالت الگوی Geode منابع محاسباتی و پردازشی لازم را برای داده‌ها ممکن می‌کند.
این سرویس را در تعدادی از استقرارهای ماهواره‌ای (satellite deployments) که در سرتاسر جهان پخش شده‌اند، مستقر کنید که هر کدام از آنها یک Geode نامیده می‌شوند. الگوی Geode از ویژگی‌های کلیدی Azure برای هدایت ترافیک از طریق کوتاه‌ترین مسیر به Geode نزدیک استفاده می‌کند که تأخیر زمانی و کارایی را بهبود می‌بخشد. هر Geode پشت یک متعادل‌سازی بار سراسری (global load balancer) قرار دارد و از یک سرویس خواندن - نوشتن تکثیرشونده جغرافیایی(geo-replicated) مانند Azure Cosmos DB برای میزبانی و host کردن داده‌ها استفاده می‌کند و از یکپارچگی داده‌های geode متقابل (cross-geode data consistency) اطمینان حاصل می‌کند. سرویس‌های تکرارکننده داده‌ها (Data replication) تضمین می‌کنند که ذخیره‌های داده در سراسر Geodeها یکسان هستند، بنابراین همه درخواست‌ها می‌توانند از همه Geodeها ارائه شوند.
تفاوت اصلی بین deployment stamp و Geode در این است که Geodeها هرگز به‌صورت مجزا وجود ندارند. همیشه باید بیش از یک Geode در یک پروداکشن پلتفرم وجود داشته باشد.
Geodeها دارای مشخصات زیر هستند:
* شامل مجموعه‌ای از انواع منابع متفاوت است که اغلب در یک قالب تعریف می‌شوند.
* هیچ وابستگی خارج از محدوده Geode ندارند و مستقل هستند. هیچ Geode ای برای کارکردن به دیگری وابسته نیست و اگر یکی از بین برود بقیه آنها به کار خود ادامه می‌دهند.
* از طریق یک شبکه لبه (edge network) و صفحه پشتی تکرارشونده (replication backplane) به‌صورت ضعیف متصل می‌شوند. به‌عنوان‌مثال، می‌توانید از Azure Traffic Manager یا Azure Front Door برای قسمت جلویی Geodeها استفاده کنید، درحالی‌که Azure Cosmos DB می‌تواند به‌عنوان replication backplane عمل کند. البته Geodeها به گروه یا دسته‌های یکسان شبیه نیستند، زیرا آنها یک replication backplane را به اشتراک می‌گذارند، بنابراین پلتفرم از مسائل حداقلی رسیدگی می‌کند.
الگوی Geode در معماری‌های کلان‌داده‌ها (big data) رخ می‌دهد که از این نوع روش برای پردازش داده‌های موجود در یک ماشین و از MapReduce (برای یادآوری MapReduce به مقدمه رجوع شود) برای ادغام نتایج در بین ماشین‌ها استفاده می‌کنند. کاربرد دیگر محاسبات نزدیک به لبه (near-edge compute) است که برای کاهش زمان پاسخ، محاسبات را به لبه هوشمند شبکه(intelligent edge of the network) نزدیک می‌کند.
سرویس‌ها می‌توانند از این الگو در ده‌ها یا صدها Geode استفاده کنند. علاوه بر این، انعطاف‌پذیری کل با هر Geode اضافه‌شده افزایش می‌یابد، زیرا اگر یک یا چند Geode آفلاین شود، هر Geode می‌تواند کار را به دست بگیرد.
همچنین می‌توان تکنیک‌های دردسترس‌بودن محلی(local availability)، مانند مناطق در دسترس یا مناطق paired را با الگوی Geode برای دردسترس‌بودن جهانی افزایش داد. اگر چه این مورد پیچیدگی را افزایش می‌دهد، اما در صورتی مفید است که معماری شما توسط یک موتور ذخیره‌سازی مانند blob storage که فقط می‌تواند به یک منطقه paired شده تکثیر (replicate) شود، پشتیبانی شود. شما می‌توانید Geodeها را در یک ناحیه درون منطقه‌ای باتوجه‌به محدودیت‌های نظارتی یا تأخیر زمانی محدودکننده در موقعیت موردنظر، مستقر کنید.
برای اجرای این الگو از تکنیک‌ها و فناوری‌های زیر استفاده کنید:
- استفاده از روش‌ها و ابزارهای مدرن DevOps برای تولید و deploy سریع Geodeهای یکسان در تعداد زیادی از مناطق یا نمونه‌های مختلف.
- مقیاس‌دهی خودکار (Autoscaling) برای ارتقای منابع محاسباتی و توان عملیاتی پایگاه‌داده در یک Geode. هر Geode به طور جداگانه با درنظرگرفتن محدودیت‌های پشتیبان مشترک، مقیاس‌بندی می‌شود.
- یک سرویس front-end مانند Azure Front Door که فرایند شتاب‌دهی به محتوای پویا (dynamic content acceleration) و [split TCP] (https://learn.microsoft.com/en-us/azure/frontdoor/front-door-traffic-acceleration?pivots=front-door-standard-premium) و [Anycast routing] (https://en.wikipedia.org/wiki/Anycast) را انجام می‌دهد.
- یک ذخیره‌سازی داده در حالت تکراری (replicating) مانند Azure Cosmos DB برای کنترل یکپارچگی داده‌ها.
- فناوری‌های [Serverless] (https://en.wikipedia.org/wiki/Serverless_computing) در صورت امکان، برای کاهش هزینه‌های deployment، به‌ویژه زمانی که load در سرتاسر جهان مرتباً متعادل (rebalanced) می‌شود. این راهبُرد به بسیاری از Geodeها اجازه می‌دهد تا با حداقل سرمایه‌گذاری اضافی deploy شوند. فناوری‌های پرداخت صورت‌حساب Serverless و مبتنی بر مصرف ([pay as you go] (https://en.wikipedia.org/wiki/Pay_as_you_go))، هزینه‌های ناشی از deploymentهای تکراری شونده و توزیع‌شده جغرافیایی (geo-distributed) را کاهش می‌دهند.
- API Management برای پیاده‌سازی در این الگوی طراحی لازم نیست، اما می‌توان آن را به هر Geode ای که در جلوی Azure Function App در یک ناحیه قرار می‌گیرد اضافه کرد تا یک‌لایه API قوی‌تر ارائه کند، به‌عنوان‌مثال، اجرای عملکردهای اضافی مانند محدودیت نرخ یا rate limit را ممکن می‌سازد. هنگام تصمیم‌گیری در مورد نحوه اجرای این الگو به نکات زیر توجه کنید:
- انتخاب کنید که داده‌ها به‌صورت محلی در هر منطقه پردازش شوند یا به‌صورت تجمعی در یک Geode توزیع شوند و در نهایت در سراسر جهان تکثیر (replicate) شود. [Azure Cosmos DB change feed processor] (https://learn.microsoft.com/en-us/azure/cosmos-db/change-feed-processor) این کنترل دانه‌ای (granular control که به معنی توانایی تنظیم و مدیریت دسترسی کاربر به مناطق مختلف یک سیستم در یک سطح بسیار خاص) را با استفاده از مفهوم lease container و leasecollectionprefix در [Azure Functions binding] (https://learn.microsoft.com/en-us/azure/cosmos-db/change-feed-functions) مربوطه ارائه می‌کند. هر رویکرد دارای مزایا و معایب متمایز است.
- Geodeها می‌توانند پشت‌سرهم کار کنند، با استفاده از تغییر ورودی Azure Cosmos DB و یک پلتفرم ارتباطی بلادرنگ مانند SignalR این Geodeها می‌توانند از طریق Geodeهای دیگر در یک الگوی مش (mesh) مانند با کاربران remote ارتباط برقرار کنند، بدون اینکه بدانند کاربر remote کجا قرار دارد یا اهمیتی بدهد.
- این الگوی طراحی به طور ضمنی همه چیز را از هم جدا می‌کند و در نتیجه یک معماری بسیار پراکنده و جدا شده ایجاد می‌کند. نحوه ردیابی اجزای مختلف یک request را در نظر بگیرید؛ زیرا ممکن است به‌صورت ناهم‌زمان (asynchronous) در نمونه‌های مختلف اجرا شوند. پس برای این کار یک راهبُرد نظارتی مناسب بسیار مهم است. هر دو Azure Front Door و Azure Cosmos DB را می‌توان به‌راحتی با Log Analytics ادغام کرد و Azure Functions باید در کنار Application Insights مستقر یا deploy شوند تا یک سیستم نظارتی قوی در هر جزء در معماری ارائه دهند.
- استقرارهای توزیع شده (Distributed deployments) دارای تعداد بیشتری از رمزها یا secretها و نقاط ورودی (ingress) هستند که به تمهیدات امنیتی خاص نیاز دارند. Key Vault یک‌لایه امن برای secret management ارائه می‌کند و هر لایه در معماری API باید به‌درستی ایمن‌سازی شود تا تنها نقطه ورودی (ingress) برای API سرویس front-end مانند Azure Front Door باشد. Azure Cosmos DB باید ترافیک را به Azure Function Apps و Function appها را به Azure Front Door با استفاده از Microsoft Entra ID یا اقداماتی مانند محدودیت IP، محدود کند.
- کارایی (Performance) در این الگو به‌شدت تحت‌تأثیر تعداد Geodeهایی است که deploy می‌شوند، همین‌طور App Service خاص اعمال شده در API در هر Geode نیز روی کارایی تأثیرپذیر است. استقرار Geodeهای اضافی یا حرکت به سمت موردهای پریمیوم (premium) با افزایش هزینه برای حافظه اضافی و محاسبات همراه است، اما این کار را بر اساس هر تراکنش انجام ندهید. آزمایش تست بار (load testing) در معماری API را پس از deploy و contrast افزایش تعداد Geodeها با افزایش سطح قیمت در نظر بگیرید تا مقرون‌به‌صرفه‌ترین مدل برای نیازهای شما استفاده شود.
- الزامات دردسترس‌بودن (availability) داده‌های خود را تعیین کنید. Azure Cosmos DB دارای flagهای اختیاری برای فعال‌کردن نوشتن چندمنطقه‌ای (multi-region)، مناطق در دسترس و موارد دیگر است. این موارد دردسترس‌بودن را برای نمونه Azure Cosmos DB افزایش می‌دهد و یک‌لایه داده انعطاف‌پذیرتر ایجاد می‌کند که با هزینه‌های اضافی همراه است.
- Azure انواع متعادل‌کننده‌های بار (load balancers) را ارائه می‌دهد که عملکردهای مختلفی را برای توزیع ترافیک ارائه می‌دهد. از [decision tree] (https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/load-balancing-overview#decision-tree-for-load-balancing-in-azure) برای کمک به انتخاب گزینه مناسب برای قسمت front end API خود استفاده کنید.
از این الگو استفاده کنید:
- برای پیاده‌سازی یک پلتفرم در مقیاس بالا (high-scale) که کاربران در یک منطقه گسترده توزیع شده‌اند.
- برای هر سرویسی که به ویژگی‌های دردسترس‌بودن (availability) و انعطاف‌پذیری شدید نیاز دارد، زیرا سرویس‌ها مبتنی بر الگوی Geode می‌توانند ازدست‌دادن چندین سرویس در منطقه‌های مختلف که به طور هم‌زمان اتفاق بیفتد، جان سالم به در ببرند. این الگو ممکن است مناسب نباشد
- معماری‌هایی که دارای محدودیت‌هایی هستند به‌طوری‌که همه Geodeها نمی‌توانند برای ذخیره‌سازی داده‌ها، برابر باشند. برای مثال، ممکن است الزامات ذخیره داده وجود داشته باشد، برنامه‌ای که نیاز به حفظ حالت موقت برای یک سشن ([session] (https://en.wikipedia.org/wiki/Session_(computer_science))) خاص دارد، یا وزن سنگین requestها برای یک منطقه واحد. در این مورد، استفاده از [deployment stamps] (./Deployment%20Stamps%20pattern.md را در ترکیب با یک صفحه مسیردهی سراسری در نظسراسرید که از محل قرارگیری داده‌های کاربر آگاه است، مانند مؤلفه مسیریابی ترافیک که در الگوی [deployment stamps] (./Deployment%20Stamps%20pattern.md) توضیح داده شده است.
- موقعیت‌هایی که نیازی به توزیع جغرافیایی نیست. در عوض، مناطق در دسترس و مشترک را برای گروه‌بندی (cluster) کردن در نظر بگیرید.
- موقعیت‌هایی که یک پلتفرم قدیمی نیاز به مقاوم‌سازی و بهبود دارد. این الگو فقط برای توسعه ابری کار می‌کند و به‌روزرسانی آن دشوار است.
- معماری‌ها و الزامات ساده که در آن افزونگی جغرافیایی و توزیع جغرافیایی موردنیاز یا سودمند نیست.
- مورد Windows Active Directory یک نوع اولیه از این الگو را پیاده‌سازی می‌کند. Multi-primary replication به این معنی است که همه به‌روزرسانی‌ها و درخواست‌ها در تئوری می‌توانند از تمام گره‌های قابل سرویس‌دهی ارائه شوند، اما وظیفه Flexible Single Master Operation (FSMO) به این معنی است که همه Geodeها برابر نیستند.
- [geode pattern accelerator] (https://github.com/mspnp/geode-pattern-accelerator) در GitHub این الگوی طراحی را در عمل به نمایش می‌گذارد و برای کمک به توسعه‌دهندگان طراحی شده است که آن را با APIهای دنیای واقعی پیاده‌سازی کنند.
- [QnA sample application] (https://github.com/xstof/qnademo) در GitHub این الگوی طراحی را در عمل به نمایش می‌گذارد.