Apache APISIX توحد إدارة حركة المرور الكاملة مع Service Mesh

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

الوضع الحالي ونقاط الألم في Service Mesh

ظهور Service Mesh مرتبط ارتباطًا وثيقًا بالتطور الحالي لبنية الأعمال. مع ازدهار اتجاه Cloud Native، بدأت معظم الشركات في التحول إلى الخدمات المصغرة (microservices)، حيث وجدنا أن التطبيقات بدأت تصبح أصغر وأصغر، وكل تطبيق يحتوي على بعض الوظائف المشتركة داخله. لذلك بدأنا نفكر، "هل هناك تقنية يمكنها حل السيناريوهات المشتركة؟ وهكذا ظهرت Sidecar.

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

ومع ذلك، فإن ظهور Sidecar جعل الناس يدركون ببطء بعض نقاط الألم في التطبيق العملي، مثل:

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

لذلك، في ظل الوضع التجاري ونقاط الألم، بدأنا نفكر في ما إذا كان يمكن أن يكون هناك حل Service Mesh مثالي يمكنه حل هذه المشكلات.

كيف يبدو Service Mesh المثالي؟

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

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

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

حل Service Mesh القائم على APISIX

Apache APISIX هو بوابة API سحابية ديناميكية، في الوقت الفعلي، عالية الأداء توفر ميزات غنية لإدارة الحركة مثل موازنة الحمل، المنبع الديناميكي، الإصدار التدريجي (canary release)، كسر الدائرة، المصادقة، المراقبة، والمزيد.

تطبق المئات من الشركات حول العالم Apache APISIX للتعامل مع حركة الأعمال الحرجة، تغطي التمويل، الإنترنت، التصنيع، التجزئة، الناقلين، إلخ، مثل NASA، European Factory Platform، China Airlines، China Mobile، Tencent، Huawei، Weibo، Netease، Ke Holdings Inc.، 360، Taikang، Nayuki Holdings Limited، إلخ. لذلك، فإن حل Service Mesh القائم على APISIX سيكون مطلوبًا بشدة ليس فقط على مستوى الاستخدام ولكن أيضًا عند مواجهة قطاعات صناعية مختلفة.

هندسة حل Service Mesh الحالي تعتمد على Istio كطائرة تحكم وAPISIX كطائرة بيانات.

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

الطائرة البيانات هي المكان الذي يمكن لـ Apache APISIX أن يستفيد منه. كبوابة API سحابية، ما هي الإجراءات التي اتخذتها APISIX كطائرة بيانات لـ Istio في هذا الحل لـ Service Mesh؟

الأشخاص الذين يعرفون APISIX يعرفون أن APISIX يستخدم etcd لتخزين البيانات. ولكن إذا استخدمنا APISIX كـ Sidecar، من أين يأتي تكوينه؟ هذا هو السؤال الذي يجب النظر فيه. إذا وضعنا مكون etcd في Sidecar أيضًا، سنجد أن استهلاك الموارد بأكمله كبير جدًا وغير مرن بما فيه الكفاية.

لذلك، في هذه العملية، أضفنا أولاً مركز تكوين يسمى xDS إلى APISIX لإلغاء الحاجة إلى etcd، ثم قدمنا Amesh، كما هو موضح أعلاه، وهو برنامج Go تم تجميعه في مكتبة ارتباط ديناميكي يتم تحميلها عند بدء APISIX. يستخدم بروتوكول xDS للتفاعل مع Istio. ثم، يكتب التكوين الذي تم الحصول عليه في مركز تكوين xDS لـ APISIX، الذي يولد قواعد توجيه محددة ويستخدم في النهاية APISIX لتوجيه الطلبات المقابلة.

بعد تكوين الهندسة أعلاه، يمكن تحقيق النتائج التالية:

Amesh وAPISIX يحافظان على نفس دورة الحياة ويمكن تشغيلهما وإيقافهما معًا.
بفضل دعم APISIX الأصلي لـ xDS Discovery، يتم تحويل البيانات إلى بعضها البعض عبر بروتوكول xDS، مما يؤدي إلى مستوى استهلاك موارد يمكن التحكم فيه.
يمكن استخدام CRD لتوسيع الحل بأكمله بسرعة وسهولة، خاصة للميزات التي لم يدعمها Istio بعد. على سبيل المثال، يتم تكوين أغنى تكوينات الإضافات لـ APISIX بواسطة CRD؛ باستخدام المتحكم وIstio معًا، يتم تعظيم قابلية التوسع لحل Service Mesh لـ Istio وAPISIX.

الأداء المحدد للحل

تحسن كبير في الأداء

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

سيناريو الاختبار هو "مطابقة المسار 3000 من أصل 5000 مسار". بسبب العدد الكبير من سيناريوهات الاختبار، يتم وصف فقط المسارات التي تطابق الجزء الأوسط أدناه، وهناك أيضًا سيناريوهات تطابق المسارات في البداية والنهاية. (هناك الكثير من البيانات لعرضها، لذا فإن البيانات التالية هي نتيجة الاختبار بحجم 3000 مسار).

كما ترى من البيانات أعلاه، يظهر APISIX تحسنًا في الأداء بمقدار 5 أضعاف على مستوى QPS لنفس الضغط ونفس تكوين الجهاز. أيضًا، على مستوى زمن الاستجابة، يكون APISIX أقل من Envoy بترتيب من حيث الحجم، حيث يكون زمن استجابة APISIX في نطاق الميكروثانية وزمن استجابة Envoy في نطاق الميلي ثانية. بالطبع، يمكنك أيضًا أن ترى أن في هذا القياس، استهلاك وحدة المعالجة المركزية لـ APISIX هو فقط 50% عندما تكون وحدة المعالجة المركزية لـ Envoy تعمل بكامل طاقتها.

تقليل استخدام الموارد

عند حقن Sidecar في حل Service Mesh، يتم استهلاك موارد إضافية عادةً. يمكن للحل القائم على API تقليل استهلاك الموارد بنسبة 60%. لماذا هذا ممكن؟

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

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

مع APISIX، يمكنك تجنب كل هذه المشاكل. تكوين APISIX واضح ومباشر، مما يقلل من البيانات المخزنة في الذاكرة، وبالاقتران مع أدائه العالي، يقلل من استهلاك موارد وحدة المعالجة المركزية. يتم تقليل استهلاك الموارد للحل بأكمله بنحو 60%.

تكلفة تعلم منخفضة وقدرة تخصيص عالية

أولاً، كمشروع مفتوح المصدر نشط من مؤسسة Apache Software Foundation، يوفر APISIX ثروة من الوثائق وموارد التعلم في المجتمع، مما يقلل من تكلفة التعلم لأولئك الذين يرغبون في البدء مع APISIX.

ثانيًا، يتم تنفيذ كود مصدر APISIX باستخدام Lua، وهو لغة برمجة نصية خفيفة الوزن، مما يجعل قراءة وفهم كود APISIX أسهل.

أخيرًا، التطوير الثانوي القائم على APISIX سهل للغاية. عندما ترغب في تخصيص الإضافات لأعمالك، لا يتم دعم لغة Lua الأصلية فقط، ولكن يمكنك أيضًا استخدام Plugin Runner لـ APISIX لتنفيذ التطوير الثانوي بلغات أكثر شيوعًا مثل Python، Java، Go، وحتى Wasm.

قوة النظام البيئي لـ APISIX ترجع أيضًا إلى قابلية التوسع القوية للمنتج.

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

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

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

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

التوقعات المستقبلية لحل Service Mesh القائم على APISIX

بالنظر إلى الوراء، فإن حل Service Mesh القائم على APISIX يعمل بالفعل نحو نقاط الألم المذكورة في المقالة السابقة، ويعمل نحو حل Service Mesh المثالي.

مع حل Service Mesh القائم على APISIX، يمكنك أن ترى أن الحركة تأتي من الخارج عبر APISIX Ingress ويتم معالجتها عبر APISIX في المنتصف. في هذه العملية، يتعامل APISIX Ingress مع الحركة الشمالية-الجنوبية، ويتعامل Amesh + Istio مع الحركة الشرقية-الغربية.

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

في التكرارات اللاحقة، سيستمر حل Service Mesh القائم على APISIX في التعمق، وتحقيق الاتجاهات المخطط لها مثل:

بناء تنفيذات لقدرات xRPC بالاقتران مع وظائف APISIX.
تنفيذ دعم أصلي للبروتوكولات المتعددة غير المتجانسة.
تغطية جميع أنواع السيناريوهات والتكوينات، بما في ذلك Istio، لتقليل تكاليف هجرة المستخدمين بشكل كبير.

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