التواصل المريح بين التطبيقات المحلية فكرة جيدة؟

Question

أتساءل عما إذا كانت فكرة جيدة السماح للتطبيقات المحلية (في نفس الخادم) بالتواصل مع بعضها البعض تمامًا من خلال API المريح؟

أعلم أن هذا ليس شيئًا غير مألوف ، لأن لدينا بالفعل تطبيقات مثل CouchDB التي تستخدم HTTP REST للاتصال ، حتى مع التطبيقات المحلية.

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

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

لكن لدي بعض الأسئلة:

• هل هذه فكرة جيدة؟
• هل سيكون نقل البيانات بينهما بطيئًا؟
• إذا قمت بذلك ، فيجب أن يكون كل تطبيق/وحدة خادم HTTP صحيحًا؟ لذا ، إذا كان طلبي يستخدم 100 تطبيق/وحدات ، فيجب أن يكون كل واحد من هذه الخادم HTTP ويب محليًا يتم تشغيله في منفذ مختلف (http: // localhost: 81 ، http: // localhost: 82, http: // localhost: 83 وهكذا) أليس كذلك؟
• أي أفضل الممارسات/gotchas يجب أن أعرفها؟

Answer 1

• هل هذه فكرة جيدة؟

بالتأكيد ، ربما.

• هل سيكون نقل البيانات بينهما بطيئًا؟

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

• إذا قمت بذلك ، فيجب أن يكون كل تطبيق/وحدة خادم HTTP صحيحًا؟ لذا ، إذا كان طلبي يستخدم 100 تطبيق/وحدات ، فيجب أن يكون لدي 100 خادم ويب HTTP محليًا لأعلى وتشغيل كل منها باستخدام منفذ مختلف (http: // localhost: 81 ،http: // localhost: 82, http: // localhost: 83 وهلم جرا)؟

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

• أي أفضل الممارسات/gotchas يجب أن أعرفها؟

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

هل تتحدث فعليًا باستخدام بنية الراحة أو مجرد إرسال الأشياء ذهابًا وإيابًا عبر HTTP؟ (هذه أشياء مختلفة) تتحمل REST تكاليفها الخاصة ، وتشمل الروابط المدمجة ، وأنواع البيانات في كل مكان وشائع ، إلخ.

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

هذا ، يمكن القول ، هو "أفضل الممارسات" لهم جميعًا.

تحرير - الرد على التعليق:

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

لا ، لا يهزم الغرض.

ها هي الصفقة.

لنفترض أن لديك 3 خدمات.

• http://store.example.com/service1

• http://blog.example.com/service2

• http://forum.example.com/service3

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

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

يتيح لك HTTP تعيين جميع أنواع الأشياء. HTTP نفسها هي آلية التجريد.

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

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

يمكن أن تعمل هذه الخدمات الثلاثة على آلة واحدة تخدمها عملية واحدة. من ناحية أخرى ، يمكنهم تمثيل 1000 آلة. كم عدد الآلات التي تعتقد أنها ترد على "www.google.com"؟

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

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

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

Answer 2

هل هذه فكرة جيدة؟

نعم. يتم ذلك طوال الوقت. هذه هي الطريقة التي تعمل بها جميع خوادم قاعدة البيانات ، على سبيل المثال. Linux مليئة بتطبيقات العميل/الخادم التي تتواصل من خلال TCP/IP.

هل سيكون نقل البيانات بينهما بطيئًا؟

لا. استخدامات TCP/IP localhost كاختصار لحفظ القيام بالشبكة الفعلية I/O.

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

إذا قمت بذلك ، فيجب أن يكون كل تطبيق/وحدة خادم HTTP صحيحًا؟

ليس بالضرورة. يمكن أن تكون بعض الوحدات عملاء وليس لديها خادم.

لذا ، إذا كان طلبي يستخدم 100 تطبيق/وحدات ، فيجب أن يكون كل واحد من هذه الخادم HTTP ويب محليًا يتم تشغيله في منفذ مختلف (http: // localhost: 81 ، http: // localhost: 82, http: // localhost: 83 وهكذا) أليس كذلك؟

نعم. هذه هي الطريقة التي تعمل بها.

أي أفضل الممارسات/gotchas يجب أن أعرفها؟

لا تقم بأرقام المنافذ "الرمز الصلب".

لا تستخدم أرقام المنافذ "المميزة" (تحت 1024).

استخدم مكتبة WSGI وستكون أسعد في جعل جميع وحداتك في تطبيقات WSGI. يمكنك بعد ذلك استخدام خادم HTTP Trivial 2 للف الوحدة النمطية الخاصة بك.

اقرا هذا. http://docs.python.org/library/wsgiref.html#examples

Answer 3

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

• كيفية مشاركة البيانات عبر المؤسسة

Answer 4

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

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

Answer 5

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

• اكتب تطبيقًا منظمًا جيدًا برمز جيد ونظيف.
• اختبره بأحمال الإنتاج المتوقعة
• إذا لزم الأمر - Refactor في طبقات هي خوادم - ولكن .....

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

إذا كنت تبحث عن التعقيد - تجاهل إجابتي. :-)