مرحبا بالجميع. سوف أخبرك عن الخدمات المصغرة ، ولكن من وجهة نظر مختلفة قليلاً عن فاديم ماديسون في المنشور "ماذا نعرف عن الخدمات المصغرة" . بشكل عام ، أنا أعتبر نفسي مطور قاعدة بيانات. ما علاقة الخدمات الدقيقة بها؟ يستخدم Avito: Vertica ، و PostgreSQL ، و Redis ، و MongoDB ، و Tarantool ، و VoltDB ، و SQLite ... إجمالاً ، لدينا 456+ قاعدة بيانات لأكثر من 849 خدمة. وبطريقة ما تحتاج إلى العيش معها.

في هذا المنشور ، سوف أخبركم عن كيفية تطبيقنا لاكتشاف البيانات في بنية خدمات microservice. هذه المشاركة هي نسخة مجانية من تقريري مع Highload ++ 2018 ، يمكن مشاهدة الفيديو هنا .

يجب أن يعلم الجميع كيف ينبغي بناء بنية الخدمات المصغرة من حيث القواعد. هنا هو النمط الذي يبدأ به الجميع عادة. هناك قاعدة مشتركة بين الخدمات. على الشريحة ، المستطيلات البرتقالية عبارة عن خدمات ، وهناك قاعدة مشتركة بينها.

لا يمكنك العيش على هذا المنوال ، لأنه لا يمكنك اختبار الخدمات بمعزل عن غيرها ، بالإضافة إلى التواصل المباشر بينها ، يكون هناك أيضًا اتصال عبر قاعدة البيانات. قد يبطئ طلب خدمة ما خدمة أخرى. هذا سيء

من وجهة نظر العمل مع قواعد البيانات لهندسة الخدمات microservice ، يجب استخدام نمط DataBase لكل خدمة - لكل خدمة قاعدة بيانات خاصة بها. إذا كان هناك الكثير من القطع في قاعدة البيانات ، فيجب مشاركة القاعدة بحيث تتم مزامنتها. هذه نظرية ، لكنها في الحقيقة ليست كذلك.

في الشركات الحقيقية ، لا يستخدمون خدمات ميكروية فحسب ، بل يستخدمون متجانسة أيضًا. هناك خدمات مكتوبة بشكل صحيح. وهناك خدمات قديمة لا تزال تستخدم نمطًا أساسيًا مشتركًا.

أظهر فاديم ماديسون في عرضه هذه الصورة بترابط. هو فقط أظهر ذلك بدون مكون واحد ، وكانت الشبكة فيه موحدة. في هذه الشبكة في الوسط ، هناك نقطة متصلة بالعديد من النقاط (الخدمات الصغيرة). هذا متراصة. انها صغيرة في الرسم البياني. ولكن في الواقع ، متراصة كبيرة. عندما نتحدث عن شركة حقيقية ، فأنت بحاجة إلى فهم الفروق الدقيقة في التعايش بين الخدمات الميكروية ، المولودة ، والهندسة المعمارية المتجانسة الصادرة ، ولكن لا تزال مهمة.

كيف يمكن إعادة كتابة متراصة إلى بنية microservice على مستوى التخطيط؟ بالطبع ، هذا هو نمذجة المجال. تقول في كل مكان أنك تحتاج إلى القيام بنمذجة المجال. ولكن ، على سبيل المثال ، أنشأنا في Avito لعدة سنوات خدمات ميكروية دون نمذجة المجال. ثم أخذت ذلك ومطوري قاعدة البيانات. نحن ندرك تدفقات البيانات كاملة. تساعد هذه المعرفة في تصميم نموذج مجال.

يحتوي اكتشاف البيانات على تفسير كلاسيكي - وهو كيفية التعامل مع البيانات المنتشرة في مستودعات مختلفة من أجل الوصول إلى استنتاجات مجمعة وإجراء أي استنتاجات صحيحة. هذا هو في الواقع كل هراء التسويق. تتعلق هذه التعريفات بكيفية تنزيل جميع البيانات من خدمات microservices إلى التخزين. حول هذا كان لدي تقارير منذ عدة سنوات ، ونحن لن نتناول هذا.

سوف أخبرك عن عملية أخرى ، أقرب إلى عملية التحول إلى خدمات microservices. أريد أن أوضح كيف يمكنك أن تفهم مدى تعقيد نظام يتطور باستمرار من حيث البيانات ، من حيث الخدمات المجهرية. أين ترى الصورة الكاملة لمئات الخدمات والقواعد والفرق والأشخاص؟ في الواقع ، هذا السؤال هو الفكرة الرئيسية للتقرير.

لكي لا تموت في بنية الخدمة microservice هذه ، فأنت بحاجة إلى توأم رقمي. شركتك هي مجموع كل شيء يوفر البنية التحتية التكنولوجية. تحتاج إلى إنشاء صورة كافية لكل هذه الصعوبات ، والتي يمكنك على أساسها حل المشكلات بسرعة. وهذا ليس مستودع تحليلي.

ما المهام التي يمكننا تعيينها لمثل هذا التوأم الرقمي؟ بعد كل شيء ، بدأ كل شيء بأبسط اكتشاف للبيانات.

الأسئلة:

• ما هي الخدمات تخزين البيانات الهامة؟
• في أي البيانات الشخصية لا يتم تخزينها؟
• لديك مئات القواعد. ما هي البيانات الشخصية هناك؟ والتي لا؟
• كيف تتدفق البيانات المهمة بين الخدمات؟
• على سبيل المثال ، لم يكن لدى الخدمة بيانات شخصية ، ثم بدأ في الاستماع إلى الحافلة ، وظهرت. أين يتم نسخ البيانات عند محوها؟
• من يستطيع العمل مع ما البيانات؟
• من يمكنه الوصول مباشرة من خلال الخدمة ، والبعض الآخر من خلال قاعدة البيانات ، والبعض الآخر عبر الحافلة؟
• من من خلال خدمة أخرى يمكنه سحب مقبض API (طلب) وتنزيل شيء ما؟

الإجابة على هذه الأسئلة هي دائمًا رسم بياني للعناصر ، رسم بياني للعلاقات. يجب ملء هذا الرسم البياني وتحديثه وصيانته ببيانات جديدة. قررنا أن نسمي هذا الرسم البياني نسيج ثابت (في الترجمة - النسيج تذكر). هنا هو تصوره.

دعونا نرى ما يمكن أن يكون في هذا النسيج تذكر.

نقاط واجهة . هذه هي عناصر تفاعل المستخدم مع واجهة الرسوم البيانية. يمكن أن يكون هناك العديد من نقاط واجهة المستخدم على صفحة واحدة. هذه هي ، نسبيا ، الإجراءات الرئيسية المخصصة.

نقاط النهاية . نقاط واجهة المستخدم رعشة نقاط النهاية. في التقليد الروسي ، وهذا ما يسمى الأقلام. مقابض الخدمات. نقاط النهاية سحب الخدمات.

الخدمات. مئات الخدمات. الخدمات مرتبطة ببعضها البعض. نحن نفهم الخدمة التي يمكن أن تسحب الخدمة. نحن نتفهم أي مكالمة لنقاط UI يمكنها الاتصال بالخدمات الموجودة في السلسلة.

القواعد (بالمعنى المنطقي) . القاعدة كمصطلح تخزين تبدو سيئة ، لأن هذا المصطلح يشير إلى شيء تحليلي. الآن نحن نعتبر قاعدة البيانات والتخزين. على سبيل المثال ، Redis ، PostgreSQL ، Tarantool. إذا كانت الخدمة تستخدم قاعدة بيانات ، فعادة ما تستخدم عدة قواعد بيانات.

• لتخزين البيانات على المدى الطويل ، على سبيل المثال ، PostgreSQL.
• يستخدم Redis كذاكرة تخزين مؤقت.
• Tarantool ، والتي يمكن أن تحسب بسرعة شيء في دفق البيانات.

المضيفين. قاعدة البيانات لديها نشر للمضيفين. قاعدة واحدة ، يمكن أن يعيش Redis فعليًا على 16 جهازًا (الحلقة الرئيسية) و 16 عبيدًا حيًا آخر. هذا يعطي فهمًا للخوادم التي تحتاج إلى تقييد الوصول إليها حتى لا تتسرب بعض البيانات المهمة.

الكيانات . يتم تخزين الكيانات في قواعد البيانات. أمثلة على الكيانات: المستخدم ، الإعلان ، الدفع. يمكن تخزين الكيانات في عدة قواعد بيانات. وهنا من المهم ليس فقط معرفة أن هذا الكيان موجود. من المهم أن تعرف أن هذا الكيان لديه وحدة تخزين واحدة هي Golden Source. Golden Source هي القاعدة التي يتم فيها إنشاء الكيان وتحريره. جميع القواعد الأخرى هي مخابئ وظيفية. نقطة مهمة. إذا كان الله ، لا سمح ، لأي كيان مصدر ذهبي ، فإن التنسيق الشاق بين المصادر المنفصلة أمر ضروري. يجب منح الكيانات الموجودة في قاعدة البيانات حق الوصول إلى الخدمة إذا كنا نريد إثراء هذه الخدمة بوظائف جديدة.

فرق . الفرق التي تملك الخدمات. الخدمة التي لا تنتمي إلى الفرق هي خدمة سيئة. من الصعب عليه العثور على شخص مسؤول.

الآن سوف أكون على صلة قوية بتقرير فاديم ماديسون ، لأنه ذكر أن الشخص الذي كان آخر من ارتكب هناك ينعكس في الخدمات. هذه نقطة انطلاق جيدة. لكن على المدى الطويل ، هذا أمر سيء ، لأن الشخص الذي ارتكب آخر هناك يمكن أن يستقيل.

لذلك ، تحتاج إلى معرفة الفريق والأشخاص الموجودين فيها ودورهم. لدينا مثل هذا الرسم البياني البسيط ، حيث يوجد في كل طبقة عدة مئات من العناصر. هل تعرف نظامًا يمكن تخزين كل هذا فيه؟

النقطة الرئيسية. لكي تعيش هذه القماش الدائم ، يجب ألا تملأ مرة واحدة فقط. يتم إنشاء الخدمات ، وموتها ، وتخزينها ، ونقلها حول الخوادم ، وإنشاء فرق ، وتكسير ، والناس بالتبديل إلى فرق أخرى. الكيانات جديدة ، تم إضافتها إلى خدمات جديدة ، تم حذفها. يتم إنشاء نقاط النهاية وتسجيلها ، كما يتم إعادة هيكلة مسارات المستخدم من وجهة نظر واجهة المستخدم الرسومية. الشيء الأكثر أهمية هو أنه ليس في مكان ما تحتاج إلى تخزينه تقنيًا. الشيء الأكثر أهمية هو جعل كل طبقة نسيج ثابت جديدة ومحدثة. أن يتم تحديثه.

أقترح المشي من خلال الطبقات. سأوضح كيف نفعل ذلك. سأبين كيف يمكن القيام بذلك على مستوى الطبقات الفردية.

يمكن الحصول على معلومات حول الفريق من الهيكل التنظيمي لـ 1C. أريد هنا أن أوضح أن Persistent Fabric لا تحتاج إلى ملء الرسم البياني العملاق بأكمله ليتم تعبئته. كل طبقة تحتاج إلى ملء بشكل صحيح.

يمكن الحصول على معلومات حول الأشخاص من LDAP. يمكن لشخص واحد القيام بأدوار مختلفة في فرق مختلفة. هذا طبيعي للغاية. الآن جعلنا نظام Avito People ومنه نأخذ ارتباط الأشخاص بالفرق وأدوارهم. الشيء الأكثر أهمية هو أن مثل هذه البيانات البسيطة تذهب بحيث تحتفظ على الأقل بروابط إلى نهايات الروابط ، بحيث تتوافق أسماء الفرق مع الفرق من الهيكل التنظيمي 1C.

الخدمات. للحصول على الخدمة ، تحتاج إلى الحصول على الاسم والفريق الذي يملكها. المصدر هو اكتشاف الخدمة. هذا هو النظام الذي ذكره فاديم ماديسون تحت اسم أطلس. أطلس هو سجل عام للخدمات.

من المفيد أن نفهم أن جميع هذه الأنظمة تقريبًا مثل Atlas تخزّن معلومات حول 95٪ من الخدمات. 5 ٪ من الخدمات في مثل هذه النظم غائبة ، ل الخدمات القديمة التي تم إنشاؤها دون تسجيل في أطلس. وعندما تبدأ العمل مع هذا المخطط ، تشعر أنك مفقود.

المخازن هي مستودعات عامة. يمكن أن يكون PostgreSQL ، MongoDB ، Memcache ، Vertica. لدينا العديد من المصادر لاكتشاف التخزين. قواعد بيانات NoSQL تستخدم نصف أطلس الخاص بها. للحصول على معلومات حول قواعد بيانات PostgreSQL ، يتم استخدام تحليل yaml. لكنهم يريدون جعل تخزين الاكتشافات أكثر صحة.

لذلك ، التخزين والمعلومات حول ما تستخدمه الخدمة ، أو تمتلكها (أو هذه أنواع مختلفة) التخزين. انظر ، كل ما وصفته بسيط من حيث المبدأ ، ويمكن ملؤه حتى في أوراق Google.

ما الذي يمكن القيام به مع هذا؟ دعنا نتخيل أن هذا رسم بياني. كيفية العمل مع الرسم البياني؟ إضافته إلى قاعدة الرسم البياني. على سبيل المثال ، في Neo4j. هذه بالفعل أمثلة على استعلامات حقيقية وأمثلة لنتائج هذه الاستعلامات.

السيناريو الأول. نحن بحاجة إلى إصدار حقوق للقاعدة. يجب أن تكون القاعدة في الخدمة بشكل صارم. ينبغي أن تشمل هذه الخدمة فقط وأعضاء الفريق الذي يملك الخدمة فقط. لكننا نعيش في العالم الحقيقي. في كثير من الأحيان ، تجد الفرق الأخرى أنه من المفيد الذهاب إلى قاعدة خدمة أخرى. السؤال: من الذي يسأل عن منح الحقوق؟ المشكلة الكبيرة حقًا هي أن تفهم مئات القواعد من هو المسؤول. على الرغم من حقيقة أن من قام بإنشائه ، استقال منذ فترة طويلة ، أو انتقل إلى منصب آخر ، أو لا يتذكر على الإطلاق من يعمل معه.

وهنا أبسط استعلام الرسم البياني (Neo4j). تحتاج الوصول إلى التخزين. تذهب من التخزين إلى الخدمة التي تمتلكها. انتقل إلى الفريق الذي يملك الخدمة. علاوة على الخدمة ، ستجد من لديه فريق TechLead هذا. في Avito ، لدى فرق المنتج مدير فني ومدير منتج لا يمكنه المساعدة في القواعد. يتم عرض نصف الطلب فقط بالفعل على الشريحة. الوصول إلى التخزين ليس عملية ذرية. للوصول إلى التخزين ، تحتاج إلى الوصول إلى الخوادم التي تم تثبيتها عليها. هذه مهمة منفصلة مثيرة للاهتمام إلى حد ما.

لحلها ، نضيف كيان جديد. هذا هو التثبيت. هنا هي مشكلة المصطلحات. هناك تخزين ، على سبيل المثال قاعدة Redis (redis: address). هناك مضيف - يمكن أن يكون جهازًا فعليًا ، حاوية lxc ، kubernetes. تثبيت التخزين على المضيف نسميه مثيل.

يمكن أن تحتوي على أربع عمليات تثبيت على ثلاثة مضيفات ، كما هو موضح في المثال أعلاه. التخزين للإنتاج من الحكمة التثبيت على أجهزة فعلية منفصلة لزيادة الأداء. بالنسبة لبيئة التطوير ، كل ما عليك فعله هو التثبيت على مضيف واحد وتعيين منافذ مختلفة لـ Redis.

ذهب الطلب الأول لإصدار الحقوق في القاعدة إلى الرأس. أكد الرئيس أنه يمكن منح الحقوق.

التالي يأتي الجزء الثاني من الطلب. يذهب الطلب الثاني من التخزين إلى المثيل والمضيف. يأخذ هذا الطلب في الاعتبار كافة عمليات التثبيت الخاصة بالبيئة المقابلة. على الشريحة مثال على بيئة الإنتاج. بناءً على ذلك ، يتم إصدار حقوق الاتصال بمضيفين محددين ومنافذ محددة بالفعل. كان هذا مثالًا على طلب منحة لموظف غير فريق.

فكر في مثال عندما يحتاج الفريق إلى أخذ موظف جديد. يحتاج إلى منح حق الوصول (بالنسبة للمبتدئين - للقراءة فقط) إلى جميع الخدمات ، إلى كل مساحة تخزين لهذا الأمر. على الشريحة ، الفريق الحقيقي مع مجموعة غير كاملة. الدوائر الخضراء هي قادة الفرق. الدوائر الوردية هي فرق. الصفراء هي الخدمات. وهناك عدد من الخدمات الصفراء لديها تخزين الأزرق. تلك الرمادية هي المضيفين. البنفسجي هو تثبيت التخزين على المضيفين. هذا مثال على وحدة صغيرة. ولكن هناك العديد من الوحدات التي لا تكون خدماتها 7 ، ولكن 27. بالنسبة لهذه الوحدات ، ستكون الصورة كبيرة. إذا كنت تستخدم Persistent Fabric ، فيمكنك تقديم طلبات فيه والحصول على إجابات في قائمة.

دعنا نواصل ملء نسيجنا الذكي والتحدث عن الكيانات التجارية. الكيانات في Avito هي الإعلانات والمستخدمين والمدفوعات وما إلى ذلك. من منشوراتي ( HP Vertica ، تصميم مستودع بيانات ، بيانات كبيرة ، Vertica + Anchor Modeling = البدء في زراعة فطرك) حول مستودعات البيانات ، أنت تعلم أن هناك المئات من هذه الكيانات في Avito. في الواقع ، ليس من الضروري تسجيلهم جميعًا. من أين يمكنني الحصول على قائمة بالكيانات من؟ من المستودع التحليلي. يمكنك تحميل معلومات حول المكان الذي يحصلون منه على هذا الكيان. في المرحلة الأولى ، هذا يكفي.

نطور كذلك هذه المعرفة: لكل كيان نقوم بعمل قائمة من المستودعات أينما كانت. نشير أيضًا إلى أن التخزين يخزن الكيان كذاكرة تخزين مؤقت أو يخزن التخزين الكيان كمصدر ذهبي ، وهذا هو مصدره الأساسي.

عندما تملأ هذا العمود ، لديك الفرصة لتقديم طلبات. لديك بعض الكيان ، وعليك أن تفهم: ما هي الخدمات التي يعيشها الكيان ، وأين يعكسها ، وما هي السعة التخزينية ، على أي مضيف تم تثبيته؟ على سبيل المثال ، عند معالجة البيانات الشخصية ، تحتاج إلى تدمير ملفات السجل. للقيام بذلك ، من المهم للغاية فهم الأجهزة الفعلية التي يمكن أن تظل ملفات السجل عليها.

توضح الشريحة استعلامًا بسيطًا لكيان وهمي. يتم تقليل مقدار التخزين بحيث يلائم الرسم البياني الشريحة. الدوائر الحمراء هي الكيانات. الدوائر الزرقاء هي القواعد التي يوجد بها هذا الكيان. الباقي كما في الشرائح السابقة: الدوائر الرمادية هي مضيفات ، والدوائر الأرجوانية عبارة عن منشآت تخزين على المضيفين.

وفقًا لذلك ، إذا كنت تريد الدخول عبر PCI DSS ، فأنت بحاجة إلى تقييد الوصول إلى كيانات معينة. للقيام بذلك ، تحتاج إلى تقييد الوصول إلى الدوائر الرمادية. إذا كنت بحاجة إلى الوصول في الوقت الفعلي ، فنحن نغلق الوصول إلى الدوائر الأرجواني. هذه معلومات ثابتة.

عندما نتحدث عن بنية microservice ، فإن الشيء الأكثر أهمية هو أنه يتغير. من المهم أن يكون ليس فقط علاقة هرمية بين الكيانات ، ولكن أيضًا العلاقات بين الأخوة والأخوات. مجموعة من الخدمات هي مثال على الاتصالات ذات المستوى الواحد ، والتي قمنا بضخها واستخدامها بشكل جيد. حزمة من نموذج "خدمة مكالمات الخدمة". هناك معلومات حول المكالمات المباشرة - الخدمة تستدعي API لخدمة أخرى.

يجب أن تكون هناك أيضًا معلومات حول اتصال النموذج: الخدمة رقم 1 ترسل الأحداث إلى الحافلة (قائمة الانتظار) ، والخدمة رقم 2 مشتركة في هذا الحدث. هذا يشبه اتصال بطيء غير متزامن يمر عبر ناقل. هذه العلاقة مهمة أيضًا من حيث حركة البيانات. باستخدام هذه الروابط ، يمكنك التحقق من تشغيل الخدمات إذا تم تغيير إصدار الخدمة التي اشتركت فيها.

يوجد كيان ونعلم أنه يتم تخزينه في مساحة تخزين معينة. إذا أخذنا في الاعتبار مشكلة العثور على نقاط استخدام الكيان ، فإن الاستعلام الواضح الذي يظهر معنا هو اختبار المحيط. تخزين تنتمي إلى بعض الخدمات. أين يمكن أن تسرب هذا الكيان (منسوخ) من المحيط؟ يمكن أن تسرب من خلال مكالمات الخدمة. اتصلت الخدمة واستلمت واحتفظت بالمستخدم. يمكن أن تسرب من خلال الإطارات. يمكن للإطارات أن توصلك ببعضها البعض باستخدام RabbitMQ، Londiste. على شريحة Londiste ، لم يتم تحميلها بعد. ولكن تم بالفعل تحميل المكالمات.

فيما يلي مثال لطلب حقيقي: إعلان ، وقاعدتي بيانات حيث يتم تخزينه ، خدمتان تملكان قواعد البيانات هذه. بعد ثلاثة أعمدة هي الخدمات التي تعمل مع الخدمات التي تملك هذا الكيان. هذه هي نقاط التسرب المحتملة تستحق الإضافة.

النهاية. ذكر Vadim أنه يمكنك استخدام الوثائق لإنشاء سجل لخدمات نقاط النهاية. يمكنك أيضًا الحصول على هذه المعلومات من المراقبة. إذا كانت نقطة النهاية مهمة ، فسيضيفها المطورون أنفسهم إلى المراقبة. إذا لم تتم مراقبة نقطة النهاية ، فلن نحتاج إليها.

وفقا لذلك ، يمكن الحصول على المقاييس من المراقبة. ربط المقاييس بالتخزين ، والخدمات ، والمضيفين ، على سبيل المثال (شظايا قاعدة البيانات) ونقطة النهاية.

عندما تواجه عطلًا ، على سبيل المثال ، تصدر نقطة النهاية رمز HTTP لـ 500 ، ثم لتتبع جذر المشكلة ، تحتاج إلى تقديم طلب لنقطة النهاية هذه. من نقطة النهاية ، انتقل إلى الخدمة ، انتقل إلى الخدمات التي تستدعيها هذه الخدمة ، ومن الخدمات ، انتقل إلى التخزين ، ومن التخزين ، انتقل إلى المثيل والمضيفين.

علاوة على ذلك ، إذا ذهبت إلى أسفل هذا الرسم البياني ، فيمكنك الحصول على قائمة من المعرفات للمراقبة على أساسها. يمكنك البحث عن نقطة النهاية هذه في السلسلة بأكملها لأسفل ، مما قد يسبب الفشل. في بنية microservice ، يمكن أن يحدث فشل في نقطة النهاية بسبب فشل في شبكة على بعض الخوادم التي يتم نشر قاعدة بيانات قاعدة بيانات واحدة. يمكن ملاحظة ذلك في المراقبة ، ولكن مع وجود هيكل خدمة كبير ، من الصعب للغاية التحقق من جميع الخدمات في المراقبة.

الاختبار. لاختبار خدمة microservice بشكل صحيح ، تحتاج إلى التحقق من الخدمة مع الخدمات الأخرى التي يحتاجها للعمل. يجب أن ترفع في بيئة الاختبار الخدمات التي تتصل بها. وللحصول على الخدمات ودعا ، ورفع جميع القواعد. في نسيجنا الذي نتذكره ، نحصل على رسم فرعي متصل. في هذا العمود ، ليست جميع الاتصالات ضرورية ، يمكن إهمال بعضها. يمكن عزل هذا الرسم البياني الفرعي اختباره كنظام مغلق بالكامل.

سيكون من الرائع الآن إظهار الرسم البياني لكيان Avito ، حيث يمكن اختبار الرسومات الفرعية المنعزلة للخدمات الصغيرة التي يمكن رفعها بشكل مستقل في الإنتاج. في الواقع ، اتضح أن الرسم الفرعي للنداء الخاص بأي خدمة مجهرية تقريباً يدخل ويترك المتراصة. هذا مثال على حقيقة أنه إذا قمت بتطوير الخدمات المصغرة ولا تفكر في مثل هذه العواقب ، ونتيجة لذلك ، فإن بنية الخدمات المصغرة لا تزال لن تعمل بدون متراصة ولا تسمح بإجراء اختبارات معزولة.

, . , . . .

— , . .

• . . . . storage. — . endpoint. , , .. .
• . «» . , , , connection, connection , . , . ( , Anchor Modeling ). . « ». . Neo4j, .
• , . . , UI points frontend , backend , storage DBA, DevOps , .

in-progress

.
(Londiste, PGQ, RabbitMQ).

. UI points . . (Persistent Fabric), UI points, Endpoint, . , , , , .