ملحوظة. ترجمة.: شبكة الخدمة هي ظاهرة ليس لها حتى الآن ترجمة مستقرة إلى اللغة الروسية (منذ أكثر من عامين اقترحنا خيار "شبكة للخدمات"، وبعد ذلك بقليل بدأ بعض الزملاء في الترويج بنشاط لمجموعة "منخل الخدمة"). أدى الحديث المستمر عن هذه التكنولوجيا إلى وضع تتشابك فيه المكونات التسويقية والتقنية بشكل وثيق للغاية. هذه المادة الرائعة من أحد مؤلفي المصطلح الأصلي تهدف إلى توفير الوضوح للمهندسين وغيرهم.
كوميدي من
مقدمة
إذا كنت مهندس برمجيات تعمل في مكان ما في مجال أنظمة الواجهة الخلفية، فمن المحتمل أن مصطلح "شبكة الخدمة" قد أصبح بالفعل راسخًا في ذهنك على مدار العامين الماضيين. وبفضل صدفة غريبة، أصبحت هذه العبارة تسيطر على الصناعة أكثر فأكثر، وتنمو الضجة والعروض الترويجية المرتبطة بها مثل كرة الثلج التي تطير على منحدر ولا تظهر عليها أي علامات على التباطؤ.
ولدت شبكة الخدمة في المياه الغامضة والمتحيزة للنظام البيئي السحابي الأصلي. ولسوء الحظ، فإن هذا يعني أن الكثير من الجدل المحيط به يتراوح من "الحديث منخفض السعرات الحرارية" إلى - إذا استخدمنا مصطلحًا تقنيًا - الهراء الصريح. ولكن إذا قمت بتجاوز كل الضوضاء، فستجد أن شبكة الخدمة لها وظيفة حقيقية ومحددة ومهمة للغاية.
في هذا المنشور، سأحاول القيام بذلك: تقديم دليل صادق ومتعمق يركز على المهندسين لشبكة الخدمة. لن أكتفي بالإجابة على السؤال: "ما هو؟"، - لكن أيضا "لماذا؟"و "لماذا الان؟". أخيرًا، سأحاول توضيح السبب (في رأيي) الذي سببت فيه هذه التكنولوجيا بالذات مثل هذه الضجة المجنونة، وهي قصة مثيرة للاهتمام في حد ذاتها.
то я؟
أهلاً بكم! اسمي هو . أنا أحد المبدعين — أول مشروع شبكة خدمة والمشروع المسؤول عن ظهور هذا المصطلح شبكة الخدمة على هذا النحو (آسف يا شباب!). (ملاحظة ترجمة.: بالمناسبة، في فجر ظهور هذا المصطلح، منذ أكثر من عامين ونصف، قمنا بالفعل بترجمة المادة المبكرة لنفس المؤلف بعنوان “. ") أنا أيضا رئيس هي شركة ناشئة تقوم بإنشاء أشياء شبكية رائعة للخدمة مثل Linkerd و .
ربما يمكنك تخمين أن لدي رأيًا متحيزًا وذاتيًا للغاية بشأن هذه القضية. ومع ذلك، سأحاول إبقاء التحيز عند الحد الأدنى (باستثناء قسم واحد: "لماذا يوجد الكثير من الحديث عن شبكة الخدمة؟"، - حيث سأظل أشارك أفكاري المسبقة). وسأبذل قصارى جهدي أيضًا لجعل هذا الدليل موضوعيًا قدر الإمكان. للحصول على أمثلة محددة، سأعتمد بشكل أساسي على خبرة Linkerd، مع الإشارة إلى الاختلافات (إن وجدت) التي أعرفها في تنفيذ أنواع شبكات الخدمة الأخرى.
حسنًا، حان الوقت للانتقال إلى الأشياء الجيدة.
ما هي شبكة الخدمة؟
على الرغم من كل هذه الضجة، فإن هيكل شبكة الخدمة بسيط للغاية. هذه مجرد مجموعة من وكلاء مساحة المستخدمين الموجودة "بجوار" الخدمات (سنتحدث قليلاً عن "التالي" لاحقًا)، بالإضافة إلى مجموعة من عمليات التحكم. يتم استدعاء الوكلاء بشكل جماعي طائرة البيانات، وتسمى عمليات التحكم طائرة مراقبة. يعترض مستوى البيانات المكالمات بين الخدمات ويفعل "كل أنواع الأشياء المختلفة" معهم؛ وبناءً على ذلك، يقوم مستوى التحكم بتنسيق سلوك الوكيل ويوفر لك الوصول، على سبيل المثال. المشغل، إلى واجهة برمجة التطبيقات (API)، مما يسمح بمعالجة الشبكة وقياسها ككل.
أي نوع من الوكيل هذا؟ هذا هو وكيل TCP المدرك للطبقة السابعة (أي "مع مراعاة" الطبقة 7 من نموذج OSI) مثل HAProxy وNGINX. يمكنك اختيار وكيل حسب رغبتك؛ يستخدم Linkerd وكيل Rust، المسمى ببساطة . لقد قمنا بتجميعها خصيصًا لشبكة الخدمة. تفضل الشبكات الأخرى الوكلاء الآخرين (يعد Envoy خيارًا شائعًا). ومع ذلك، فإن اختيار الوكيل هو مجرد مسألة تنفيذ.
ماذا تفعل هذه الخوادم الوكيلة؟ من الواضح أنهم يقومون بالاتصال بالوكالة من وإلى الخدمات (بالمعنى الدقيق للكلمة، يعملون كوكلاء ووكلاء عكسيين، ويتعاملون مع المكالمات الواردة والصادرة). ويقومون بتنفيذ مجموعة ميزات تركز على المكالمات بين خدمات. هذا التركيز على حركة المرور بين الخدمات هو ما يميز وكيل شبكة الخدمة عن، على سبيل المثال، بوابات API أو وكلاء الدخول (يركز الأخير على المكالمات الواردة إلى المجموعة من العالم الخارجي). (ملحوظة. ترجمة.: لإجراء مقارنة بين وحدات تحكم Ingress الحالية لـ Kubernetes، والتي يستخدم الكثير منها Envoy المذكور بالفعل، راجع .)
لذلك، قمنا بفرز مستوى البيانات. مستوى التحكم أبسط: فهو عبارة عن مجموعة من المكونات التي توفر جميع الآليات التي يحتاجها مستوى البيانات للعمل بطريقة منسقة، بما في ذلك اكتشاف الخدمة، وإصدار شهادات TLS، والتجميع المتري، وما إلى ذلك. ويبلغ مستوى البيانات مستوى التحكم بما يلي: سلوكه؛ وفي المقابل، يوفر مستوى التحكم واجهة برمجة التطبيقات (API) التي تسمح لك بتغيير ومراقبة سلوك مستوى البيانات ككل.
يوجد أدناه رسم تخطيطي لمستوى التحكم ومستوى البيانات في Linkerd. كما ترون، يتضمن مستوى التحكم عدة مكونات مختلفة، بما في ذلك مثيل Prometheus الذي يجمع المقاييس من الخوادم الوكيلة، بالإضافة إلى مكونات أخرى مثل destination (اكتشاف الخدمة)، identity (سلطة التصديق، CA) و public-api (نقاط النهاية للويب وCLI). في المقابل، مستوى البيانات عبارة عن وكيل رابط بسيط بجوار مثيل التطبيق. هذا مجرد مخطط منطقي. في عملية النشر في العالم الحقيقي، قد يكون لديك ثلاث نسخ متماثلة لكل مكون من مكونات مستوى التحكم ومئات أو آلاف الوكلاء في مستوى البيانات.
(ترمز المستطيلات الزرقاء في هذا المخطط إلى حدود حاويات Kubernetes. يمكنك أن ترى أن الحاويات التي تحتوي على وكيل linkerd موجودة في نفس الحاوية مثل حاويات التطبيق. يُعرف هذا المخطط باسم حاوية جانبية.)
بنية شبكة الخدمة لها العديد من الآثار الهامة. أولاً، نظرًا لأن مهمة الوكيل هي اعتراض المكالمات بين الخدمات، فإن شبكة الخدمة تكون منطقية فقط إذا تم إنشاء التطبيق الخاص بك لمجموعة معينة من الخدمات. مش يمكن للمرء يمكن استخدامه مع وحدات متراصة، ولكن من الواضح أن هذا زائد عن الحاجة من أجل وكيل واحد، ومن غير المرجح أن تكون وظائفه مطلوبة.
والنتيجة المهمة الأخرى هي أن شبكة الخدمة تتطلب ذلك تسربت عدد الوكلاء. في الواقع، يقوم Linkerd بإرفاق وكيل رابط لكل مثيل لكل خدمة (تضيف التطبيقات الأخرى وكيلًا إلى كل عقدة/مضيف/جهاز افتراضي. وهذا كثير على أي حال). يحمل هذا الاستخدام النشط للوكلاء في حد ذاته عددًا من التعقيدات الإضافية:
- يجب أن يكون الوكلاء في مستوى البيانات سريع، نظرًا لوجود مكالمتين لكل مكالمة إلى الوكيل: واحدة من جانب العميل وواحدة من جانب الخادم.
- كما ينبغي أن يكون الوكلاء صغير и وزن خفيف. سيستهلك كل منها الذاكرة وموارد وحدة المعالجة المركزية، وسينمو هذا الاستهلاك خطيًا مع التطبيق.
- ستحتاج إلى آلية لنشر وتحديث عدد كبير من الوكلاء. إن القيام بذلك يدويًا ليس خيارًا.
بشكل عام، تبدو شبكة الخدمة على هذا النحو (على الأقل من منظور علوي): تقوم بنشر مجموعة من وكلاء مساحة المستخدمين الذين "يفعلون شيئًا" مع حركة المرور الداخلية بين الخدمات، ويستخدمون مستوى تحكم لمراقبتهم وإدارتهم.
والآن حان الوقت لطرح السؤال "لماذا؟"
ما هي شبكة الخدمة ل؟
يمكن أن نغفر لأولئك الذين واجهوا فكرة شبكة الخدمة لأول مرة شعورهم بالخوف قليلاً. ويعني تصميم شبكة الخدمة أنه لن يؤدي فقط إلى زيادة زمن الوصول في التطبيق، بل سيفعل ذلك أيضًا تستهلك الموارد و سوف يضاف مجموعة من الآليات الجديدة في البنية التحتية. أولاً، تقوم بإعداد شبكة خدمة، ثم تجد نفسك فجأة بحاجة إلى خدمة مئات (إن لم يكن الآلاف) من الوكلاء. السؤال هو من سيفعل هذا طواعية؟
الجواب على هذا السؤال يتكون من جزأين. أولاً، يمكن تقليل تكاليف المعاملات المرتبطة بنشر هؤلاء الوكلاء بشكل كبير بفضل بعض التغييرات التي تحدث في النظام البيئي (المزيد عن هذا لاحقًا).
ثانيًا، يعد جهاز مثل هذا في الواقع طريقة رائعة لإدخال منطق إضافي في النظام. ليس فقط لأن شبكة الخدمة يمكن أن تضيف الكثير من الوظائف الجديدة، ولكن أيضًا لأنه يمكن القيام بذلك دون التدخل في النظام البيئي. في الواقع، يعتمد نموذج شبكة الخدمة بالكامل على هذه الفرضية: في نظام متعدد الخدمات، بغض النظر عن الأمر جعل الخدمات الفردية، وحركة المرور بينهم هي النقطة المثالية لإضافة وظيفة.
على سبيل المثال، في Linkerd (كما هو الحال في معظم الشبكات) تركز الوظيفة بشكل أساسي على مكالمات HTTP، بما في ذلك HTTP/2 وgRPC*. الوظيفة غنية جدًا - يمكن تقسيمها إلى ثلاث فئات:
- الميزات المتعلقة إمكانية الإعتماد على. الطلبات المتكررة، المهلات، النهج الكناري (تقسيم/إعادة توجيه حركة المرور)، إلخ.
- الميزات المتعلقة يراقب. تجميع معدلات النجاح والتأخير وأحجام الطلب لكل خدمة أو اتجاهات فردية؛ بناء الخرائط الطوبولوجية للخدمات، الخ.
- الميزات المتعلقة سلامة. TLS المتبادل، والتحكم في الوصول، وما إلى ذلك.
* من وجهة نظر Linkerd، لا يختلف gRPC عمليًا عن HTTP/2: فهو يستخدم فقط protobuf في الحمولة. من وجهة نظر المطور، الأمران مختلفان بالطبع.
تعمل العديد من هذه الآليات على مستوى الطلب (ومن هنا يأتي "وكيل L7"). على سبيل المثال، إذا قامت خدمة Foo بإجراء مكالمة HTTP إلى خدمة Bar، فيمكن للوكيل linkerd الموجود على جانب Foo إجراء موازنة تحميل ذكية وتوجيه المكالمات من مثيلات Foo إلى Bar بناءً على زمن الاستجابة المرصود؛ يمكنه تكرار الطلب إذا لزم الأمر (وإذا كان عاجزًا)؛ يمكنه تسجيل رمز الاستجابة والمهلة، وما إلى ذلك. وبالمثل، يمكن لـ linkerd-proxy الموجود على الجانب Bar رفض الطلب إذا كان غير مسموح به أو تم تجاوز حد الطلب؛ قد تسجل تأخيرًا من جانبها، وما إلى ذلك.
يمكن للوكلاء "فعل شيء ما" على مستوى الاتصال أيضًا. على سبيل المثال، يمكن لـ linkerd-proxy على جانب Foo بدء اتصال TLS، ويمكن لـ linkerd-proxy على جانب Bar إنهاء الاتصال، ويمكن لكلا الجانبين التحقق من شهادات TLS لبعضهما البعض*. وهذا لا يوفر التشفير بين الخدمات فحسب، بل يوفر أيضًا طريقة آمنة للتشفير لتحديد الخدمات: يستطيع Foo and Bar "إثبات" هويتهما كما يدعيان.
* "المتبادل بين الأصدقاء" يعني أنه تم التحقق من شهادة العميل أيضًا (TLS المتبادل). في TLS "الكلاسيكي"، على سبيل المثال، بين المتصفح والخادم، يتم عادةً التحقق من شهادة جانب واحد فقط (الخادم).
سواء كانت تعمل على مستوى الطلب أو الاتصال، فمن المهم التأكيد على أن جميع وظائف شبكة الخدمة تعمل التشغيل شخصية. Linkerd غير قادر على تحويل دلالات الحمولة - على سبيل المثال، إضافة حقول إلى جزء JSON أو إجراء تغييرات على protobuf. سنتحدث عن هذه الميزة المهمة لاحقًا عندما نتحدث عن ESB والبرمجيات الوسيطة.
هذه هي مجموعة الميزات التي تقدمها شبكة الخدمة. السؤال الذي يطرح نفسه: لماذا لا يتم تنفيذها مباشرة في التطبيق؟ ولماذا تهتم بالوكيل على الإطلاق؟
لماذا تعتبر شبكة الخدمة فكرة جيدة
على الرغم من أن قدرات شبكة الخدمة مثيرة، إلا أن قيمتها الأساسية لا تكمن في الواقع في ميزاتها. في النهاية نحن علبة قم بتنفيذها مباشرة في التطبيق (سنرى لاحقًا أن هذا هو أصل شبكة الخدمة). لمحاولة تلخيص ذلك في جملة واحدة، قيمة شبكة الخدمة هي: فهو يوفر ميزات مهمة لتشغيل برامج الخادم الحديثة بطريقة متسقة عبر المجموعة بأكملها ومستقلة عن كود التطبيق.
دعونا نحلل هذا الاقتراح.
«الميزات الهامة لتشغيل برامج الخادم الحديثة" إذا كنت تقوم بإنشاء تطبيق خادم معاملات متصل بالإنترنت العام، وقبول الطلبات من العالم الخارجي والرد عليها في وقت قصير - على سبيل المثال، تطبيق ويب، وخادم API، والغالبية العظمى من التطبيقات الحديثة الأخرى - وإذا قمت بتنفيذه كمجموعة من الخدمات التي تتفاعل بشكل متزامن مع بعضها البعض، وإذا كنت تقوم بتحديث هذا البرنامج باستمرار، وإضافة ميزات جديدة، وإذا كنت مجبرًا على الحفاظ على هذا النظام في حالة عمل أثناء عملية التعديل - في هذا الحالة، تهانينا، أنت تقوم بإنشاء برنامج خادم حديث. وكل هذه الميزات الرائعة المذكورة أعلاه تبين أنها في الواقع مهمة بالنسبة لك. يجب أن يكون التطبيق موثوقًا وآمنًا ويجب أن تكون قادرًا على مراقبة ما يفعله. هذه هي بالضبط الأسئلة التي تساعد شبكة الخدمة في حلها.
(حسنًا، لا تزال الفقرة السابقة تتضمن اعتقادي بأن هذا النهج هو الطريقة الحديثة لإنشاء برنامج الخادم. ويفضل آخرون تطوير وحدات متراصة و"الخدمات الصغيرة التفاعلية" وأشياء أخرى لا تندرج تحت التعريف المذكور أعلاه. ربما يكون لهؤلاء الأشخاص ما يناسبهم الرأي مختلف عن رأيي، وأنا بدوري أعتقد أنهم "مخطئون" - على الرغم من أن شبكة الخدمة ليست مفيدة جدًا بالنسبة لهم على أي حال).
«موحدة للمكدس بأكمله" إن الوظائف التي توفرها شبكة الخدمة ليست مجرد مهمة حرجة. وهي تنطبق على جميع الخدمات في التطبيق، بغض النظر عن اللغة المكتوبة بها، والإطار الذي تستخدمه، ومن كتبها، وكيف تم نشرها، وأي تفاصيل أخرى تتعلق بتطويرها واستخدامها.
«مستقلة عن رمز التطبيق" وأخيرًا، لا توفر شبكة الخدمة وظائف متسقة عبر المجموعة بأكملها فحسب، بل إنها تفعل ذلك بطريقة لا تتطلب تحرير التطبيق. الأساس الأساسي لوظيفة شبكة الخدمة، بما في ذلك مهام التكوين والتحديث والتشغيل والصيانة وما إلى ذلك، يقع بالكامل على مستوى النظام الأساسي وهو مستقل عن التطبيق. يمكن تغيير التطبيق دون التأثير على شبكة الخدمة. وفي المقابل، يمكن أن تتغير شبكة الخدمة دون أي مشاركة من التطبيق.
باختصار، لا توفر شبكة الخدمة وظائف حيوية فحسب، بل تقوم بذلك أيضًا بطريقة عالمية وموحدة ومستقلة عن التطبيق. وهكذا، على الرغم من إمكانية تنفيذ وظيفة شبكة الخدمة في كود الخدمة (على سبيل المثال، كمكتبة مضمنة في كل خدمة)، فإن هذا النهج لن يوفر التوحيد والاستقلال الذي يعد ذا قيمة كبيرة في حالة شبكة الخدمة.
وكل ما عليك فعله هو إضافة مجموعة من الوكلاء! أعدك بأننا سننظر في التكاليف التشغيلية المرتبطة بإضافة هؤلاء الوكلاء قريبًا جدًا. لكن دعونا أولاً نتوقف وننظر إلى فكرة الاستقلال من وجهات نظر مختلفة. الناس.
من الذي تساعده شبكة الخدمة؟
على الرغم من أن الأمر قد يكون غير مريح، لكي تصبح التكنولوجيا جزءًا مهمًا من النظام البيئي، يجب أن يقبلها الناس. إذن من يهتم بشبكة الخدمة؟ ومن يستفيد من استخدامه؟
إذا كنت تقوم بتطوير برنامج خادم حديث، فيمكنك التفكير في فريقك كمجموعة أصحاب الخدمةالذين يقومون معًا بتطوير وتنفيذ منطق الأعمال، و أصحاب المنصةوتطوير المنصة الداخلية التي تعمل عليها هذه الخدمات. في المؤسسات الصغيرة، قد يكون هؤلاء هم نفس الأشخاص، ولكن مع نمو الشركة، تميل هذه الأدوار إلى أن تصبح أكثر وضوحًا وحتى مقسمة إلى أدوار فرعية... (هناك الكثير مما يمكن قوله هنا عن الطبيعة المتغيرة للمطورين، التأثير التنظيمي للخدمات الصغيرة، وما إلى ذلك) ن. لكن الآن دعونا نأخذ هذه الأوصاف كما هي).
ومن وجهة النظر هذه، فإن المستفيدين الواضحين من شبكة الخدمة هم أصحاب المنصة. بعد كل شيء، هدف فريق المنصة في نهاية المطاف هو إنشاء منصة داخلية يمكن لأصحاب الخدمة من خلالها تنفيذ منطق الأعمال والقيام بذلك بطريقة تضمن استقلالهم قدر الإمكان عن التفاصيل الغامضة لتشغيلها. لا توفر شبكة الخدمة قدرات مهمة لتحقيق هذا الهدف فحسب، بل إنها تفعل ذلك بطريقة لا تفرض بدورها تبعيات على مالكي الخدمة.
ويستفيد أصحاب الخدمات أيضًا، وإن كان بطريقة غير مباشرة. هدف مالك الخدمة هو أن يكون منتجًا قدر الإمكان في تنفيذ منطق عملية الأعمال، وكلما قل قلقه بشأن المشكلات التشغيلية، كان ذلك أفضل. فبدلاً من الاضطرار إلى التعامل مع تنفيذ سياسات إعادة المحاولة أو TLS، على سبيل المثال، يمكنهم التركيز فقط على أهداف العمل ويأملون أن تعتني المنصة بالباقي. هذه ميزة كبيرة بالنسبة لهم.
ولا يمكن المبالغة في تقدير القيمة التنظيمية لمثل هذا التقسيم بين أصحاب المنصات والخدمات. أعتقد أنها تساهم أساسي المساهمة في قيمة شبكة الخدمة.
لقد تعلمنا هذا الدرس عندما أخبرنا أحد المعجبين الأوائل بـ Linkerd عن سبب اختيارهم لشبكة الخدمة: لأنها سمحت لهم "بالحفاظ على الحد الأدنى من متجر التحدث". فيما يلي بعض التفاصيل: قام رجال من إحدى الشركات الكبيرة بترحيل منصتهم إلى Kubernetes. وبما أن التطبيق يتعامل مع معلومات حساسة، فقد أرادوا تشفير جميع الاتصالات عبر المجموعات. إلا أن الوضع تعقد بسبب وجود مئات الخدمات ومئات فرق التطوير. إن احتمالية الاتصال بالجميع وإقناعهم بتضمين دعم TLS في خططهم لم يجعلهم سعداء على الإطلاق. بعد تثبيت Linkerd، قاموا بنقله مسؤولية من المطورين (من وجهة نظرهم التي كانت هذه مشكلة غير ضرورية) إلى منصات الألعاب، الذين كانت هذه أولوية عالية المستوى بالنسبة لهم. بمعنى آخر، لم يحل Linkerd لهم مشكلة فنية بقدر ما حل مشكلة تنظيمية.
باختصار، تعتبر شبكة الخدمة بمثابة حل، وليس حلاً تقنيًا، ولكن الاجتماعية التقنية مشاكل. (شكرًا لك للتعريف بهذا المصطلح.)
هل ستحل شبكة الخدمة جميع مشاكلي؟
نعم. اعني لا!
إذا نظرت إلى الفئات الثلاث من الميزات الموضحة أعلاه - الموثوقية والأمان وقابلية المراقبة - يصبح من الواضح أن شبكة الخدمة ليست حلاً كاملاً لأي من هذه المشكلات. في حين أن Linkerd يمكنه إعادة إصدار الطلبات (إذا كان يعلم أنها غير فعالة)، فإنه غير قادر على اتخاذ قرارات بشأن ما يجب إعادته إلى المستخدم إذا فشلت الخدمة بشكل دائم - يجب أن يتم اتخاذ هذه القرارات عن طريق التطبيق. يمكن لـ Linkerd الاحتفاظ بإحصائيات الطلبات الناجحة، لكنه غير قادر على النظر في الخدمة وتوفير مقاييسها الداخلية - يجب أن يحتوي التطبيق على مثل هذه الأدوات. وعلى الرغم من أن Linkerd قادر على تنظيم mTLS، إلا أن الحلول الأمنية الكاملة تتطلب أكثر من ذلك بكثير.
تتعلق مجموعة فرعية من الميزات الموجودة في هذه المجالات التي تقدمها شبكة الخدمة ميزات المنصة. وأعني بهذا الوظائف التي:
- مستقلة عن منطق الأعمال. الطريقة التي يتم بها إنشاء الرسوم البيانية للمكالمات بين Foo وBar مستقلة تمامًا عن لماذا فو يدعو بار.
- من الصعب تنفيذها بشكل صحيح. في Linkerd، يتم تحديد معلمات إعادة المحاولة باستخدام جميع أنواع الأشياء الفاخرة مثل ميزانيات إعادة المحاولة (إعادة محاولة الميزانيات)، نظرًا لأن النهج غير المتطور والمباشر لتنفيذ مثل هذه الأشياء سيؤدي بالتأكيد إلى ظهور ما يسمى بـ "سيل من الطلبات" (إعادة المحاولة العاصفة) وغيرها من المشاكل المميزة للأنظمة الموزعة.
- أكثر فعالية عند تطبيقها بشكل موحد. آلية TLS تكون منطقية فقط إذا تم تطبيقها في كل مكان.
وبما أن هذه الوظائف يتم تنفيذها على مستوى الوكيل (وليس على مستوى التطبيق)، فإن شبكة الخدمة توفرها على مستوى منصة، وليس التطبيقات. وبالتالي، لا يهم ما هي اللغة التي كتبت بها الخدمات، وما هو الإطار الذي تستخدمه، ومن كتبها ولماذا. تعمل الوكلاء خارج كل هذه التفاصيل، والأساس الأساسي لهذه الوظيفة، بما في ذلك مهام التكوين والتحديث والتشغيل والصيانة وما إلى ذلك، يقع فقط على مستوى النظام الأساسي.
أمثلة على قدرات شبكة الخدمة
لتلخيص ذلك، لا تعد شبكة الخدمة حلاً كاملاً للموثوقية أو إمكانية المراقبة أو الأمان. يتطلب نطاق هذه المجالات مشاركة مالكي الخدمات وفرق العمليات/SRE وكيانات الشركة الأخرى. توفر شبكة الخدمة فقط "شريحة" على مستوى النظام الأساسي لكل منطقة من هذه المناطق.
لماذا أصبحت شبكة الخدمة شائعة الآن؟
ربما تتساءل الآن: حسنًا، إذا كانت شبكة الخدمة جيدة جدًا، فلماذا لم نبدأ في نشر ملايين الوكلاء في المكدس قبل عشر سنوات؟
هناك إجابة عادية على هذا السؤال: قبل عشر سنوات، قام الجميع ببناء متراصة، ولم يكن أحد بحاجة إلى شبكة خدمة. هذا صحيح، لكن في رأيي هذه الإجابة تخطئ الهدف. حتى قبل عشر سنوات، كان مفهوم الخدمات الصغيرة كوسيلة واعدة لبناء أنظمة واسعة النطاق موضع نقاش واسع النطاق وتم تطبيقه في شركات مثل Twitter وFacebook وGoogle وNetflix. كان الرأي العام - على الأقل في أجزاء الصناعة التي كنت على اتصال بها - هو أن الخدمات الصغيرة هي "الطريقة الصحيحة" لبناء أنظمة كبيرة، حتى لو كان الأمر صعبًا للغاية.
بالطبع، على الرغم من أنه قبل عشر سنوات كانت هناك شركات تدير خدمات صغيرة، إلا أنها لم تضع الوكلاء في كل مكان يمكنها تشكيل شبكة خدمة. ومع ذلك، إذا نظرت عن كثب، ستجد أنهم فعلوا شيئًا مشابهًا: طلبت العديد من هذه الشركات استخدام مكتبة داخلية خاصة للاتصالات عبر الشبكة (تسمى أحيانًا مكتبة العميل الكثيفة)، مكتبة العميل السمين).
كان لدى Netflix مكتبة Hysterix، وكان لدى Google Stubby، وكان لدى Twitter مكتبة Finagle. Finagle، على سبيل المثال، كان إلزاميا لكل خدمة جديدة على تويتر. لقد تعامل مع كل من اتصالات العميل والخادم، وسمح للطلبات المتكررة، وتوجيه الطلب المدعوم، وموازنة التحميل والقياس. لقد وفرت طبقة متسقة من الموثوقية وإمكانية المراقبة عبر مجموعة Twitter بأكملها، بغض النظر عما كانت تفعله الخدمة. بالطبع، كان يعمل فقط مع لغات JVM وكان يعتمد على نموذج برمجة يجب استخدامه للتطبيق بأكمله. ومع ذلك، كانت وظيفتها تقريبًا نفس وظيفة شبكة الخدمة. (في الواقع، كان الإصدار الأول من Linkerd عبارة عن Finagle ملفوفًا في شكل وكيل.)
وهكذا، قبل عشر سنوات لم تكن هناك خدمات صغيرة فحسب، بل كانت هناك أيضًا مكتبات شبكية خاصة للخدمة الأولية تحل نفس المشكلات التي تحلها شبكة الخدمة اليوم. ومع ذلك، فإن شبكة الخدمة نفسها لم تكن موجودة في ذلك الوقت. كان لا بد من وجود تحول آخر قبل ظهورها.
وهنا تكمن الإجابة الأعمق، مخفية في تغيير آخر حدث على مدى السنوات العشر الماضية: انخفضت تكلفة نشر الخدمات الصغيرة بشكل كبير. الشركات المذكورة أعلاه والتي استخدمت الخدمات الصغيرة قبل عشر سنوات - تويتر، ونيتفليكس، وفيسبوك، وجوجل - كانت شركات ذات حجم هائل وموارد هائلة. لم تكن لديهم الحاجة فحسب، بل كانت لديهم أيضًا القدرة على بناء ونشر وتشغيل التطبيقات الكبيرة القائمة على الخدمات الصغيرة. إن الطاقة والجهد الذي بذله مهندسو تويتر للانتقال من نهج متجانس إلى نهج الخدمات الصغيرة أمر مذهل. (لكي نكون منصفين، كذلك حقيقة أنها نجحت). وكانت هذه الأنواع من مناورات البنية التحتية مستحيلة بالنسبة للشركات الصغيرة.
سريع إلى الأمام حتى الوقت الحاضر. هناك شركات ناشئة اليوم حيث تبلغ نسبة الخدمات الصغيرة إلى المطورين 5:1 (أو حتى )، والأكثر من ذلك، أنهم يتعاملون معها بنجاح! إذا كان بإمكان شركة ناشئة مكونة من 5 أشخاص تشغيل 50 خدمة صغيرة بسهولة، فمن الواضح أن شيئًا ما قد أدى إلى خفض تكلفة تنفيذها.
1500 خدمة صغيرة في مونزو؛ كل سطر عبارة عن قاعدة شبكة محددة تسمح بحركة المرور
إن الانخفاض الكبير في تكلفة تشغيل الخدمات الصغيرة هو نتيجة لعملية واحدة: تزايد شعبية الحاويات и منسقين. هذه هي بالضبط الإجابة العميقة على سؤال ما الذي ساهم في ظهور شبكة الخدمة. نفس التكنولوجيا جعلت كلاً من شبكات الخدمة والخدمات الصغيرة جذابة: Kubernetes وDocker.
لماذا؟ حسنًا، يحل Docker مشكلة واحدة كبيرة - مشكلة التغليف. من خلال تجميع التطبيق وتبعيات وقت التشغيل (غير المتصلة بالشبكة) في حاوية، يقوم Docker بتحويل التطبيق إلى وحدة قابلة للتبديل يمكن استضافتها وتشغيلها في أي مكان. وفي الوقت نفسه، فإنه يبسط العملية إلى حد كبير متعدد اللغات المكدس: نظرًا لأن الحاوية عبارة عن وحدة تنفيذ ذرية، لأغراض النشر والتشغيل، فلا يهم ما بداخلها، سواء كان تطبيق JVM أو Node أو Go أو Python أو Ruby. أنت فقط تطلقه وهذا كل شيء.
يأخذ Kubernetes كل شيء إلى المستوى التالي. الآن بعد أن أصبح هناك الكثير من "الأشياء التي يجب تشغيلها" والعديد من الأجهزة لتشغيلها، هناك حاجة إلى أداة يمكنها ربطها ببعضها البعض. بالمعنى الواسع، أنت تعطي Kubernetes الكثير من الحاويات والكثير من الأجهزة، وتقوم بربطها ببعضها البعض (بالطبع، هذه عملية ديناميكية ومتغيرة باستمرار: تتحرك الحاويات الجديدة حول النظام، وتبدأ الآلات وتتوقف ، وما إلى ذلك. ومع ذلك، يأخذ Kubernetes كل هذا في الاعتبار ).
بمجرد تكوين Kubernetes، تختلف تكلفة الوقت لنشر وتشغيل خدمة واحدة قليلًا عن تكلفة نشر وتشغيل عشر خدمات (في الواقع، هي نفسها تقريبًا بالنسبة لـ 100 خدمة). أضف إلى هذه الحاويات آلية التعبئة والتغليف التي تشجع التنفيذ متعدد اللغات، وسيكون لديك مجموعة من التطبيقات الجديدة التي يتم تنفيذها في شكل خدمات صغيرة مكتوبة بلغات مختلفة - بالضبط نوع البيئة التي تناسبها شبكة الخدمة تمامًا.
لذلك، نأتي إلى إجابة السؤال لماذا أصبحت فكرة شبكة الخدمة شائعة الآن: التجانس الذي يوفره Kubernetes للخدمات ينطبق بشكل مباشر على التحديات التشغيلية التي تواجه شبكة الخدمة. يمكنك تجميع الوكلاء في حاويات، وإعطاء Kubernetes مهمة لصقهم أينما أمكن، وفويلا! ونتيجة لذلك، تحصل على شبكة خدمة، بينما تتم إدارة جميع آليات نشرها بواسطة Kubernetes. (على الأقل من وجهة نظر عين الطائر. وبطبيعة الحال، هناك العديد من الفروق الدقيقة في هذه العملية.)
لتلخيص ذلك: السبب وراء انتشار شبكات الخدمة الآن، وليس قبل عشر سنوات، هو أن Kubernetes وDocker لم يزدا بشكل ملحوظ فحسب يحتاج في ذلك، بعد تبسيط تنفيذ التطبيقات كمجموعات من الخدمات الصغيرة متعددة اللغات، ولكن أيضًا تم تقليلها بشكل كبير التكاليف لتشغيلها، وتوفير آليات لنشر ودعم أساطيل الوكيل الجانبية.
لماذا هناك الكثير من الحديث عن شبكة الخدمة؟
تحذير: في هذا القسم أستخدم جميع أنواع الافتراضات والتخمينات والافتراءات والمعلومات الداخلية.
قم بالبحث عن "شبكة الخدمة" وستجد الكثير من المحتوى منخفض السعرات الحرارية المُعاد تدويره، والمشاريع الغريبة، ومشكال من التشويه يستحق غرفة الصدى. أي تقنية جديدة متطورة تفعل ذلك، ولكن في حالة شبكة الخدمة تكون المشكلة حادة بشكل خاص. لماذا؟
حسنًا، جزء منه هو خطأي. لقد بذلت قصارى جهدي للترويج لـ Linkerd والخدمة في كل فرصة أحصل عليها من خلال عدد لا يحصى من منشورات المدونة والمقالات المشابهة لهذه المقالة. لكنني لست بهذه القوة. للإجابة على هذا السؤال حقا، نحتاج أن نتحدث قليلا عن الوضع العام. ومن المستحيل الحديث عنه دون ذكر مشروع واحد: عبارة عن شبكة خدمة مفتوحة المصدر تم تطويرها بشكل مشترك بواسطة Google وIBM وLyft.
(للشركات الثلاث أدوار مختلفة تمامًا: يبدو أن مشاركة Lyft تكون بالاسم فقط؛ فهم مؤلفو Envoy، لكنهم لا يستخدمون أو يشاركون في تطوير Istio. وتشارك IBM في تطوير Istio وتستخدمه. وتشارك Google بنشاط في تطوير Istio. Development ، ولكن لا يستخدمه فعليًا بقدر ما أستطيع أن أقول.)
يتميز مشروع Istio بشيئين. أولاً، هناك الجهد التسويقي الهائل الذي تبذله شركة Google، على وجه الخصوص، للترويج لها. أقدر أن معظم الأشخاص الذين يعرفون مفهوم شبكة الخدمة اليوم علموا به لأول مرة من خلال Istio. والشيء الثاني هو مدى سوء استقبال Istio. في هذا الشأن، من الواضح أنني طرف مهتم، لكني أحاول أن أبقى موضوعيًا قدر الإمكان، وما زلت لا أستطيع المساعدة ، ليست مميزة جدًا (على الرغم من أنها ليست فريدة من نوعها: يتبادر إلى ذهني systemd، ...) لمشروع مفتوح المصدر.
(من الناحية العملية، يبدو أن Istio يواجه مشاكل ليس فقط مع التعقيد وتجربة المستخدم، ولكن أيضًا مع الأداء. على سبيل المثال، أثناء في دراسة أجرتها جهة خارجية، وجد الباحثون مواقف كان فيها زمن استجابة Istio أعلى 100 مرة من Linkerd، بالإضافة إلى مواقف نقص الموارد حيث استمر Linkerd في العمل بنجاح بينما توقف Istio عن العمل تمامًا.)
وبغض النظر عن نظرياتي حول سبب حدوث ذلك، أعتقد أن الإثارة الغامرة حول شبكة الخدمة تفسرها مشاركة جوجل. وهي مزيج من العوامل الثلاثة التالية:
- ترويج Google المتطفل لـ Istio؛
- موقف نقدي غير موافق تجاه المشروع؛
- الارتفاع السريع الأخير في شعبية Kubernetes، والذي لا تزال ذكرياته حية.
تجتمع هذه العوامل معًا لتخلق بيئة مذهلة وخالية من الأكسجين، حيث تضعف القدرة على الحكم العقلاني، ولا يبقى سوى التنوع الغريب. .
من وجهة نظر لينكيرد، هذا... ما يمكن أن أصفه بأنه نعمة ونقمة. أعني أنه من الرائع أن تدخل شبكة الخدمة إلى الاتجاه السائد بطريقة لم تحدث في عام 2016 عندما بدأت Linkerd لأول مرة وكان من الصعب حقًا حث الناس على الاهتمام بالمشروع. الآن لا توجد مثل هذه المشكلة! لكن الأخبار السيئة هي أن مشهد شبكات الخدمة مربك للغاية اليوم لدرجة أنه يكاد يكون من المستحيل فهم المشاريع التي تنتمي فعليًا إلى فئة شبكات الخدمة (ناهيك عن فهم المشروع الأكثر ملاءمة لحالة استخدام معينة). يعد هذا بالتأكيد بمثابة كسر للصفقات للجميع (وهناك بالتأكيد بعض الحالات التي يكون فيها Istio أو مشروع آخر أكثر ملاءمة من Linkerd، نظرًا لأن الأخير لا يزال ليس حلاً عالميًا).
من ناحية لينكيرد، كانت استراتيجيتنا تتمثل في تجاهل الضجيج، والاستمرار في التركيز على حل مشكلات المجتمع الحقيقية، والانتظار بشكل أساسي حتى يهدأ الضجيج. في النهاية، سوف يهدأ الضجيج ويمكننا مواصلة العمل بهدوء.
وفي غضون ذلك، علينا جميعا أن نتحلى بالصبر قليلا.
هل ستكون شبكة الخدمة مفيدة بالنسبة لي، كمهندس برمجيات متواضع؟
الاستبيان التالي سيساعدك على الإجابة على هذا السؤال:
هل أنت مشترك فقط في تنفيذ منطق الأعمال؟ في هذه الحالة، لن تكون شبكة الخدمة مفيدة لك. هذا بالطبع قد يثير اهتمامك، ولكن من الناحية المثالية، يجب ألا تؤثر شبكة الخدمة بشكل مباشر على أي شيء في بيئتك. استمر في العمل على ما تدفع لك مقابله.
هل تدعم النظام الأساسي في شركة تستخدم Kubernetes؟ نعم، في هذه الحالة، تحتاج إلى شبكة خدمة (ما لم تكن، بالطبع، تستخدم K8s فقط لتشغيل وحدة متراصة أو معالجة مجمعة - ولكن بعد ذلك أود أن أسأل لماذا تحتاج إلى K8s). من المحتمل أن ينتهي بك الأمر بالحصول على الكثير من الخدمات الصغيرة التي كتبها أشخاص مختلفون. تتفاعل جميعها مع بعضها البعض وترتبط بمجموعة متشابكة من تبعيات وقت التشغيل، وتحتاج إلى إيجاد طريقة للتعامل مع كل ذلك. يتيح لك استخدام Kubernetes اختيار شبكة خدمة "لنفسك". للقيام بذلك، تعرف على إمكانياتها وميزاتها وأجب عن سؤال ما إذا كان أي من المشاريع المتاحة مناسبًا لك (أوصي ببدء البحث مع Linkerd).
هل أنت شركة منصة في شركة لا تستخدم Kubernetes ولكنها تستخدم الخدمات المصغرة؟ في هذه الحالة، ستكون شبكة الخدمة مفيدة لك، لكن استخدامها لن يكون بسيطًا. بالتأكيد تستطيع التقليد تتشابك خدمة العمل عن طريق وضع مجموعة من الوكلاء، ولكن الميزة المهمة لـ Kubernetes هي نموذج النشر: ستتطلب صيانة هذه الوكلاء يدويًا المزيد من الوقت والجهد والنفقات.
هل أنت مسؤول عن المنصة في شركة تعمل مع الوحدات المتراصة؟ في هذه الحالة، ربما لا تحتاج إلى شبكة خدمة. إذا كنت تعمل مع وحدات متراصة (أو حتى مجموعات من الوحدات المتراصة) التي تحتوي على أنماط تفاعل محددة جيدًا ونادرًا ما تتغير، فلن يكون لدى شبكة الخدمة الكثير لتقدمه لك. لذلك يمكنك ببساطة تجاهله والأمل في أن يختفي مثل حلم مزعج ...
اختتام
ربما، لا يزال لا ينبغي تسمية شبكة الخدمة بأنها "التكنولوجيا الأكثر إثارة للاهتمام في العالم" - ربما ينتمي هذا الشرف المشكوك فيه إلى Bitcoin أو AI. ربما تكون في المراكز الخمسة الأولى. ولكن إذا قمت باختراق طبقات الضوضاء، يصبح من الواضح أن شبكة الخدمة تجلب فوائد حقيقية لأولئك الذين يقومون ببناء التطبيقات على Kubernetes.
أود منك تجربة Linkerd - تثبيته على مجموعة Kubernetes (أو حتى Minikube على كمبيوتر محمول) ، ويمكنك أن ترى بنفسك ما أتحدث عنه.
الأسئلة الشائعة
— إذا تجاهلت شبكة الخدمة، هل ستختفي؟
— يجب أن أخيب ظنك: شبكة الخدمة معنا لفترة طويلة.
- لكنني لا أريد استخدام شبكة الخدمة!
- حسنا، ليس من الضروري! ما عليك سوى قراءة استبياني أعلاه لتفهم ما إذا كان يجب عليك على الأقل التعرف على أساسياته.
- أليس هذا برنامج ESB/وسيط قديم جيد مع صلصة جديدة؟
— تتعامل شبكة الخدمة مع المنطق التشغيلي، وليس المنطق الدلالي. ناقل خدمة المؤسسة (). يساعد الحفاظ على هذا الفصل شبكة الخدمة على تجنب نفس المصير.
- كيف تختلف شبكة الخدمة عن بوابات API؟
- هناك مليون مقال حول هذا الموضوع. فقط جوجل انها.
— المبعوث هو شبكة الخدمة؟
- لا، Envoy ليس شبكة خدمة، بل هو خادم وكيل. يمكن استخدامه لتنظيم شبكة الخدمة (وأكثر من ذلك بكثير - إنه وكيل للأغراض العامة). ولكنها في حد ذاتها ليست شبكة خدمة.
— شبكة خدمة الشبكة هي شبكة الخدمة؟
- لا. على الرغم من الاسم، هذه ليست شبكة خدمة (كيف تحب المعجزات التسويقية؟).
— هل ستساعد شبكة الخدمة في النظام التفاعلي غير المتزامن القائم على قائمة انتظار الرسائل؟
- لا، شبكة الخدمة لن تساعدك.
— ما هي شبكة الخدمة التي يجب أن أستخدمها؟
- ، بدون تفكير.
- المقال مقرف! / المؤلف مرحب به!
- يرجى مشاركة الرابط الخاص به مع جميع أصدقائك حتى يتمكنوا من رؤيته!
شكر وتقدير
كما قد خمنت من العنوان، هذا المقال مستوحى من أطروحة جاي كريبس الرائعة "" التقيت جاي قبل عشر سنوات عندما أجريت مقابلة معه على موقع Linked In، وكان مصدر إلهام لي منذ ذلك الحين.
على الرغم من أنني أحب أن أطلق على نفسي اسم "مطور Linkerd"، إلا أن الحقيقة هي أنني أكثر من مشرف على ملف README.md في المشروع. يتم العمل على Linkerd اليوم , , الناس، وهذا المشروع لم يكن ليحدث لولا مشاركة مجتمع رائع من المساهمين والمستخدمين.
وأخيرًا، شكر خاص لمبدع Linkerd، (بريموس إنتر باريس)، الذي انغمس معي منذ سنوات عديدة في كل هذه الضجة المتعلقة بشبكة الخدمة.
PS من المترجم
اقرأ أيضًا على مدونتنا:
- «"؛
- «"؛
- «"؛
- «"؛
- «".
المصدر: www.habr.com