الخدمات المصغرة مقابل القوس الأحادي.

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

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

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

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

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

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

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

يمكننا القول أن هناك واجهة برمجة تطبيقات أو GLSK بشكل صحيح، وبهذه الطريقة يتواصلون مع بعضهم البعض حتى نتمكن من القول إنني سأقدم مثالاً يمكنك الحصول على إجابة كما يمكننا القول أنه يمكننا أن نأخذ على سبيل المثال لدينا Amazon Amazon على حق موقع Amazon للتجارة الإلكترونية حيث لديهم بحث لديهم قائمة بجميع المنتجات بشكل صحيح لدينا بحث حيث يمكنك البحث مثل F140 pro

لذلك، كل هذه الأشياء عبارة عن مكون أساسي صغير وأين توجد كل هذه المكونات

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

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

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

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

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

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

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

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

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

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

إذن لماذا هناك حاجة لتطبيق لتوسيع نطاق أجزاء مختلفة من نفسه؟

بنسب مختلفة، أليس كذلك؟ لذا، على سبيل المثال، إذا كان لدي ما يقرب من 1000 مستخدم يستخدمون خمس ميزات لتطبيقي، فلماذا، أعني، إذا أصبح هؤلاء المستخدمين البالغ عددهم 1000 مستخدم 10000 مستخدم، ألن يستخدموا مثل جميع تطبيقاتي، لذلك مثل كل تطبيقي يحتاج إلى التوسع إلى 10x، لماذا سيكون التوسع غير المتناسب مطلبًا؟ نعم، لذلك أقول لكم،

لنتحدث عن كأس العالم FIFA. هذا أكثر عالمية.

إنهم يقومون بالبث المباشر لمباراة كرة القدم. لذلك هناك مكونان. الأول هو مكان J & K في قائمة المباريات. حاليًا أو يمكننا أن نقول المباريات القادمة. فكر الآن في حركة المرور التي نحصل عليها في قائمة المباريات. حيث يمكنك تحديد النتائج حاليًا، وما هي المباريات القادمة. وحركة المرور التي نحصل عليها في البث المباشر.

كلاهما مختلفان للغاية. الآن، يمكنني القول، لا سيما أن هناك من هم هنا على الهواء مباشرة، يشاهدون البث المباشر لمباراة كرة القدم. 20 مليون شخص يشاهدون. 20 مليون شخص يشاهدون البث المباشر على 25x. لذلك هؤلاء الناس لا يأتون إلى

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

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

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

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

لذلك يمكننا القول أن Python أو Django جيدة للإدراج. ولكن إذا كان لدي بنية للخدمات المصغرة مع اختلاف الوضعين، لذلك يمكنني استخدام نص نصي مختلف وقاعدة بيانات مختلفة. ولكن إذا كان هناك خادم واحد فقط، فيجب علي إصلاحه، إما أن أستخدم المزيد من النص أو Python. لذلك وفقًا لحالة القرص الخاصة بي أو الميزات، إذا كنت أرغب في تغيير النص النصي أو قاعدة البيانات الخاصة بي، فيمكن أن يكون ذلك ممكنًا فقط باستخدام Microflash.

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

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

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

الهندسة المعمارية.

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

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

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

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

سواء كان ذلك في الغالب أم لا. لذا فإن الأول هو قابلية التوسع. بمجرد أن نعرف أن هناك مستوى عالٍ، يمكننا الذهاب. الشيء الثاني هو المرونة. الآن، إذا بدأنا نموذجًا، فعلينا تحديد نوع نص واحد، مثل node .js أو Python، والآن، لدينا ميزة جديدة قادمة. لقد قمنا بتغيير الاقتراح.

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

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

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

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

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

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

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

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

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

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

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

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

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

لذلك يمكننا القول أنه يمكن تقليل توقيت النشر باستخدام الخدمة الصغيرة.

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

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

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

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

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

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

الانتقال من بنية Microsoft بشكل صحيح. لذا فإن هذه الخدمة بالذات، البنية التي نتبعها صحيحة أم لا. لأنه في الخدمات المصغرة توجد في Microsoft أيضًا لدينا خدمات مختلفة. سواء كان هناك خادم أو يمكننا القول خادم كهربائي أم لا. سواء كان عليك استخدام lambda للاتصال بـ NK أم لا. لذلك نحن لا نعرف. إذن ما في وسعنا

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

ولكن الآن بسبب العديد من التغييرات، من الجيد الانتقال من MySQL إلى NoSQL. لذلك يجب اتخاذ هذا النوع من القرارات عندما ننتقل من الخدمات المصغرة. يبدو وكأنه تمرين طويل وتعاوني لن يقودنا إلى بناء ميزات جديدة.

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

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

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

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

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

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

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

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

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

‍

‍