لماذا تحتاج بوابة؟
نحن نعلم أننا نريد إدخال خدمة بحد ذاتها ، ومن الواضح أنه ليس لدينا طريقة جيدة بشكل خاص. ندخل مباشرة عنوان المنفذ IP +. نحن نعلم أن هذا النهج سيء للغاية. هناك مشكلة كبيرة مع هذا النهج. أولاً ، يكشف عنوان IP الخاص بجهازنا الفعلي. عندما ينظر الآخرون إلى عنوان IP الخاص بك ، فإنهم يعرفون أين يتم نشر الخدمة ، مما يسمح للآخرين بإجراء عمليات الهجوم بشكل مريح للغاية.
ثانياً ، لدينا الكثير من الخدمات ، هل يتعين علينا أن نسميها واحدة تلو الأخرى؟ لنفترض أننا قمنا بإجراء مصادقة إذن ، وأن كل من عملائنا يصل إلى برامج الخدمة على JVMs المختلفة التي تعمل على أجهزة مختلفة. كل من خدماتنا تحتاج إلى مصادقة الخدمة. هل هذا مزعج؟ من الواضح أنه مزعج للغاية.
ثم نواجه هذين ومشاكلهم العامة في هذا الوقت ، ونحن بحاجة إلى وسيلة لحلها. بادئ ذي بدء ، دعونا نلقي نظرة على تعرض عنوان IP ومشكلة النقطة الواحدة الناجمة عن كتابة عنوان IP بعد الوفاة. هل أحتاج أيضًا إلى الحفاظ على قائمة الخدمات لمثل هذه الخدمة نفسها ديناميكيًا؟ أحتاج إلى استدعاء هذه الخدمة نفسها ، هل أحتاج أيضًا إلى موازنة التحميل؟
هناك أيضًا أشياء حول تعرض عنوان IP. هل يجب أن أكون وكيلًا ، مثل الوكيل العكسي لـ Nginx ، وهناك أيضًا أشياء تنشر وحدات عامة على هذا الشيء ، مثل التحقق من الإذن لجميع البوابات. لذلك نحن الآن بحاجة إلى بوابة Zuul API. يحل المشكلة أعلاه. إذا كنت ترغب في الاتصال بخدمة معينة ، فسيتم تعيينك عليها ورسم خريطة عنوان IP لخدمتك في
إذا قمت بإدخال المسار ، فإنه يطابقه وسيصل إلى الخدمة لك. سيكون لها عملية إعادة توجيه الطلب. مثل NGINX ، القوة المحددة لمثيل جهاز الخدمة ، لن تصل مباشرة إلى IP ، وسوف ينتقل إلى مركز تسجيل Eureka للحصول على معرف مثيل الخدمة ، أي اسم الخدمة. لقد استخدمت شريط موازنة تحميل العميل للوصول إلى إحدى مثيلات الخدمة مرة أخرى.
تُستخدم بوابة API بشكل أساسي لحل مشكلة المكالمات الخارجية من خلال الخدمة نفسها ، وحل مشكلة التحقق من الإذن. يمكنك دمج سلسلة من المرشحات هنا ، مثل دمج Shiro و SpringSecurity وأشياء أخرى.
يمكن لـ Zuul تحميل آلية تصفية ديناميكية لتحقيق الوظائف التالية:
1. التحقق والأمان: تحديد متطلبات التحقق لمختلف الموارد ورفض الطلبات التي لا تتطابق مع المتطلبات.
2. المراجعة والمراقبة: تتبع البيانات ذات المغزى والنتائج الإحصائية في مواقع الحافة ، مما يجعلنا استنتاجات دقيقة حول حالة الإنتاج.
3. التوجيه الديناميكي: طلبات المسار إلى مجموعات مختلفة من الواجهة الخلفية ديناميكيًا حسب الحاجة.
4. اختبار الإجهاد: زيادة تدفق الحمل تدريجيا إلى الكتلة لحساب مستوى الأداء.
5. تخصيص التحميل: تعيين السعة المقابلة لكل نوع تحميل وإهمال الطلبات التي تتجاوز قيمة الحد.
6. معالجة الاستجابة الثابتة: قم بإنشاء استجابات جزئية مباشرة في مواقع الحافة لمنعها من التدفق إلى الكتلة الداخلية.
7. مرونة في المنطقة المتعددة: تم تصميم طلب التوجيه عبر مناطق AWS لتحقيق استخدام ELB المتنوع والتأكد من أن مواقع الحافة قريبة قدر الإمكان للمستخدمين.
بعد ذلك ، انتقل إلى عرض تجريبي صغير
الخطوة الأولى هي إنشاء وحدة Zuul جديدة ضمن المشروع الأصلي وإدخال التبعيات. الرمز كما يلي:
<Rependency> <roupeD> org.springframework.cloud </rougiD> <intifactid> spring-cloud-starter-eureka </fruntifactid> <sophy> 1.3.5 <splection> 1.3.5.release </version> </sependency>
ثم اكتب enablezuulproxy enoutation على فئة بدء التشغيل ، والرمز كما يلي:
الخادم: المنفذ: 5000SPRING: التطبيق: الاسم: API-GETEWAYZUUL: ROUTES: #IDEDIDENTY اسم خدمتك ، والتي يمكن تعريفها من قبل نفسك هنا. بشكل عام ، فإن الراحة والمواصفات هي نفس اسم الخدمة Hello-Service:#The Path of Service Mapping ، من خلال هذا المسار ، يمكنك الوصول إلى خدمتك من الخارج. والغرض من ذلك هو تجنب تعريض IP الخاص بجهازك والطريق الموجهة نحو الخدمة ، واختيار مسار متاح لك. # yere ، يعتمد Zuul تلقائيًا على Hystrix و Ribbon ، وليس للمسار المستقل: /Hello-Service /**# يجب أن يكون هذا هو اسم الخدمة في مركز تسجيل Eureka الخاص بك. لذلك ، يتم تكوين ServiceId هنا لأنه يتم دمجه مع Eureka. إذا كنت تستخدم Zuul وحدها ، فيجب عليك كتابة عنوان IP الخاص بجهازك الخاص. #such as url: http: // localhost: 8080/هذا ليس جيدًا بما يكفي لكتابة IP Dead. إذا فشل هذا IP وكان هذا متوفرًا مرتفعًا ، فلن يتم استخدام مجموعة تسجيل الخدمة. ServiceId: Hello-Serviceeureka: #Client: #Registration Center عنوان الخدمة-url: DefaultZone: http: // localhost: 8888/eureka/، http: // localhost: 8889/eureka/
ثم ابدأ مركز التسجيل ومقدمي خدمات خدمة Hello-Service في المقالة السابقة. ثم نديرها ونلقي نظرة على وظيفة إعادة توجيه الطلبات لمعرفة ما إذا كانت استطلاعات الرأي في الخدمتين.
أدخل المضيف المحلي: 5000/خدمة Hello-Service/Hello ، على النحو التالي:
ثم تحديث مرة أخرى:
يمكنك أن ترى أن Zuul قدم طلبًا لتوزيعه. يتم تعيينه إلى جهاز معين يعتمد على اسم الخدمة Hello-Servie. أليس هذه وظيفة الوكيل العكسي؟
يمكن لـ Zuul أيضًا تنفيذ تصفية الطلب ، لذلك دعونا نؤدي التحقق المميز لإظهاره. أولاً ، نحتاج إلى إنشاء فئة جديدة من الرمز المميز لترث فئة Zuulfilter وتنفيذ واجهاتها الأربعة. الرمز كما يلي:
حزمة hjc.zuul ؛ استيراد com.netflix.zuul.zuulfilter ؛ استيراد com.netflix.zuul.context.requestcontext */TokenFilter العام العام يمتد Zuulfilter {// أربعة أنواع: Pre ، التوجيه ، الخطأ ، post // pre: يتم استخدامه بشكل أساسي في مرحلة تعيين التوجيه للعثور على جدول تعيين التوجيه // التوجيه: مرشح توجيه التوجيه المحدد موجود على جهاز التوجيه. عند إعادة توجيه الطلب المحدد ، سيتم استدعاؤه // خطأ: بمجرد حدوث خطأ المرشح السابق ، سيتم استدعاء مرشح الخطأ. // Post: لن يتم استدعاء هذا المرشح بعد التوجيه وينجز الخطأ. إنه Override Public String FilterType () {return "pre" ؛ } // تخصيص ترتيب تنفيذ المرشحات. كلما زادت القيمة ، في وقت لاحق التنفيذ. كلما كانت القيمة أصغر ، كلما تم تنفيذها ، كلما تم تنفيذها أولاً. Override public int filterorder () {return 0 ؛ } // التحكم في المرشح ليصبح ساري المفعول أم لا. يمكنك كتابة سلسلة من المنطق في ذلك للتحكم في Override boolean يجب أن يكون filter () {return true ؛ } // تنفيذ filter logicoverride الكائن العام run () {requestContext context = requestContext.getCurrentContext () ؛ httpservletrequest request = context.getRequest () ؛ TRING TOKEN = request.getParameter ("Token") ؛ if (token == null) {context.setSendzUulResponse (false) ؛ context.setResponsestatuscode (401) ؛ context.setResponseBody ("غير مؤرخ") ؛ العودة لاغية. } إرجاع فارغ ؛ }}FilterType: إرجاع سلسلة تمثل نوع المرشح. يتم تعريف أربعة أنواع مرشحات ذات دورات حياة مختلفة في Zuul ، على النحو التالي:
1. pre : يمكن استدعاؤه قبل توجيه الطلب. يتم استخدامه للعثور على جدول تعيين التوجيه أثناء مرحلة تعيين التوجيه.
2.route : يتم استدعاؤه أثناء طلب التوجيه. سيتم استدعاء مرشح إعادة توجيه التوجيه المحدد عند توجيه إعادة توجيه الطلب المحدد لجهاز التوجيه.
3. error : يسمى عند حدوث خطأ أثناء معالجة الطلب
4. post : لن يتم استدعاء المرشح بعد الانتهاء من التوجيه والخطأ ، وهو في المرحلة الأخيرة.
نعلن هنا الاستثناء الذي يحدث عندما ينفذ مرشح Zuul طلب شبكة. لا يمكن إلقاء الاستثناء الذي تم صيده بواسطة Try-Catch مباشرة على الصفحة في المرشح. يمكن إرجاع الاستثناء الذي ألقاه التطبيق إلى الصفحة باستخدام طريقة context.set () في الصيد. على النحو التالي:
حاول {Business Logic ...} catch (استثناء e) {requestContext context = requestContext.getCurrentContext () ؛ context.set ("error.status_code" ، 401) ؛ conext.set ("error.exception" ، e) ؛ context.set ("error.message" ، "SFDFSDF") ؛}بعد ذلك ، تحتاج إلى إضافة هذا المرشح إلى الربيع والسماح لـ Spring بإدارته. الرمز كما يلي:
حزمة hjc ؛ استيراد hjc.zuul.tokenfilter ؛ استيراد org.springframework.boot.springapplication ؛ استيراد org.springframework.boot.autoconfigure.SpringBroXy org.springframework.context.annotation.bean ؛@springbootapplication@enablezuulproxypublic zuulapplication {public static void main (string [] args) {springapplication.run (zuulapplication.class ، args) ؛ }. }}بعد ذلك ، لنبدأ فئة بدء التشغيل والوصول الأول بدون الرموز ، على النحو التالي:
يمكنك أن ترى أنه يتم إرجاع رسالة بدون إذن. هنا أريد أن أقول أنه يتم وضع الرموز عادة في رأس الطلب. نحن هنا لا نفعل ذلك لأغراض التوضيح.
ثم خذ الرمز المميز وزيارته ، على النحو التالي:
يمكنك أن ترى أنه تم إرسال طلبنا.
هنا سأتحدث عن ما هو المسار الافتراضي وحذف تكوين Zuul ، على النحو التالي:
الخادم: المنفذ: 5000SPRING: التطبيق: الاسم: API-getewayeureka: #client العميل:#Register Center عنوان الخدمة-url: DefaultZone: http: // localhost: 8888/eureka/، http: // localhost: 8889/eureka/
ثم ، أعد تشغيل ومواصلة الوصول ، على النحو التالي:
و
يمكنك أن ترى أنه لا يزال بإمكاننا الاستمرار في الوصول. ليس لدينا ما نفعله ، لكن لا يزال بإمكاننا الوصول إليه. هذا لأنه ، افتراضيًا ، يتم إعلانك تلقائيًا باسم الخدمة Hello-Service.
لذا ، إذا كنت لا أريد أن تعلن ذلك تلقائيًا بالنسبة لي وأريد تعريفه بنفسي ، فيمكنني استخدام الخدمات Zuu.UGURED في ملف تكوين YML لتصفيةه مثل التصفية ، على النحو التالي: "
Zuul: #if الخدمات التي تم تجاهلها:* يعني أن جميع الطرق الافتراضية قد انتهت صلاحيتها. عليك أن تتطابق معهم واحدا تلو الآخر. لن يكون أي شخص مارس الجنس للغاية ، إلا إذا واجهت الخدمات التجارية الغريبة:
لنتحدث عن قواعد التعيين ، على سبيل المثال
Zuul: Routes: #IdideDy اسم خدمتك ، يمكنك تحديدها بنفسك هنا. بشكل عام ، فإن الراحة والمواصفات هي نفس اسم الخدمة Hello-Service:#Service Path ، من خلال هذا المسار ، يمكنك الوصول إلى خدمتك من الخارج. والغرض من ذلك هو تجنب تعريض IP الخاص بجهازك ، والطريق الموجهة للخدمة يناسبك. يعتمد#Zuul تلقائيًا على Hystrix و Ribbon ، وليس للمسار المستقل: /Hello-Service /**#يجب أن يكون هذا هو اسم خدمة التسجيل Eureka الخاصة بك ، وبالتالي يتم تكوين ServiceId هنا لأنه يتم دمجه مع Eureka. إذا كنت تستخدم Zuul وحدها ، فيجب عليك كتابة IP الخاص بجهازك ، #Such كـ URL: http: // localhost: 8080/هذا سيء ، فهذا يعني كتابة IP Dead. إذا فشل هذا IP وارتفاع التوفر ، فلن يتم استخدام مجموعة تسجيل الخدمة ServiceId: Hello-Servicezuul: Routes: Hello-Service: Path:/Hello-Service/Ext/** ServiceId: Hello-Service
مسارات تعيين تكوين Zuul هنا لديها /Hello-Service /. يمكنك أن ترى ذلك/خدمة hello/** يشمل/Help-Service/Ext/**. هل هناك أي صراعات عند مطابقة هذين المسارين؟ كيف تتعامل معها؟ من سيتطابق أولاً؟
هنا هو الترتيب المحدد في YML لمطابقة. إذا كان ملف تكوين في تنسيق Application.Properties ، فلا يمكن ضمان هذا الطلب. ملفات التكوين بتنسيق YML متسلسل ، والتي يمكن ضمانها. يرجى ملاحظة هذا هنا.
ماذا لو أردنا تحديد قاعدة مطابقة؟ ثم نحتاج إلى تحديد الفول في فئة بدء التشغيل ، والذي يحدد طريقك ، على النحو التالي:
لن أظهرها هنا. عندما تحتاجها ، اذهب وابحث عن المعلومات ببطء.
هناك أيضًا نماذج تجاهل: على النحو التالي:
Zuul: Routes: #IdideDy اسم خدمتك ، يمكنك تحديدها بنفسك هنا. بشكل عام ، فإن الراحة والمواصفات هي نفس اسم الخدمة Hello-Service:#Service Path ، من خلال هذا المسار ، يمكنك الوصول إلى خدمتك من الخارج. والغرض من ذلك هو تجنب تعريض IP الخاص بجهازك ، والطريق الموجهة للخدمة يناسبك. يعتمد#Zuul تلقائيًا على Hystrix و Ribbon ، وليس للمسار المستقل: /Hello-Service /**#يجب أن يكون هذا هو اسم خدمة التسجيل Eureka الخاصة بك ، وبالتالي يتم تكوين ServiceId هنا لأنه يتم دمجه مع Eureka. إذا كنت تستخدم Zuul وحدها ، فيجب عليك كتابة IP الخاص بجهازك ، #Such كـ URL: http: // localhost: 8080/هذا سيء ، فهذا يعني كتابة عنوان IP ميت. إذا فشل هذا IP وارتفاع التوفر ، فلن يتم استخدام مجموعة تسجيل الخدمة ServiceId: Hello-Service Transhed-Patterns: /Hello /**
تجاهل النماذج: يشير إلى أن مسار /hello /** محظور. حتى لو لم يكن ذلك/خدمة مرحبا/مرحبًا/** ، فلا يزال بإمكانك حظره. يمكننا تحسين هذا التكوين. على سبيل المثال ، إذا كنت لا أرغب في توجيه واجهة /hello ، فيمكننا تكوينها على النحو الوارد أعلاه
ماذا لو كنا نريد أيضًا تكوين بادئة الخدمة؟ الرمز كما يلي:
Zuul: Routes: #IdideDy اسم خدمتك ، يمكنك تحديدها بنفسك هنا. بشكل عام ، فإن الراحة والمواصفات هي نفس اسم الخدمة Hello-Service:#Service Path ، من خلال هذا المسار ، يمكنك الوصول إلى خدمتك من الخارج. والغرض من ذلك هو تجنب تعريض IP الخاص بجهازك ، والطريق الموجهة للخدمة يناسبك. يعتمد#Zuul تلقائيًا على Hystrix و Ribbon ، وليس للمسار المستقل: /Hello-Service /**#يجب أن يكون هذا هو اسم خدمة التسجيل Eureka الخاصة بك ، وبالتالي يتم تكوين ServiceId هنا لأنه يتم دمجه مع Eureka. إذا كنت تستخدم Zuul وحدها ، فيجب عليك كتابة IP الخاص بجهازك ، #Such كـ URL: http: // localhost: 8080/هذا ليس جيدًا بما يكفي لكتابة عنوان IP ميت. إذا فشل هذا IP وارتفاع التوفر ، فلن يتم استخدام مجموعة تسجيل الخدمة ServiceId: Premix Hello-Service: /API /**
يمكنك أن ترى أن الخدمات التي تزورها يجب أن تكون مسبقة بـ/API/، مثل/API/Hello-Service/**
ماذا يجب أن نفعل إذا أردنا القفز إلى منطقتي المحلية إذا أردنا القيام بالوصول إلى المسار؟
آمل أن يتمكن المستخدم من القفز تلقائيًا إلى هذه الطريقة عند الوصول /المحلي. لذلك في هذا الوقت ، نحتاج إلى استخدام القفزة المحلية لـ Zuul ، وطريقة التكوين هي كما يلي:
Zuul: بادئة:/API المتجاهلان:/**/Hello/** المسارات: محلي: المسار:/Hello-Service/** url: forward:/local
سيحصل بعض الأشياء الشائعة الاستخدام ، التي تتصل بـ Springsecurity أو بعض مكونات الطرف الثالث ، على بعض معلومات ملفات تعريف الارتباط الخاصة بك. لذلك قتلت Zuul Gateway جميع معلومات ملفات تعريف الارتباط الخاصة بك لأسباب أمنية ، ولا توجد طريقة لصنع ملفات تعريف الارتباط. يقتل افتراضيا.
يوفر Zuul هنا Zuul.Selational-Headers لصنع ملفات تعريف الارتباط والرؤوس هذه لك ، ولا يقومون بتصفية هذه المعلومات. التحكم في معلوماتك الحساسة.
بشكل افتراضي ، لا يمكن تمرير معلومات الرأس الحساسة عبر بوابة API. يمكننا أن نجعلها قابلة للمسار من خلال التكوين التالي:
Zuul: المسارات: Hello-Service: Path: /Hello-Service /** ServiceId: Hello-Service Sensitive Headers: Cookie ، header وغيرها من الأشياء
يمكن أيضًا استخدامه مع بعض التكوينات التفصيلية لـ Hystrix ، كما ذكر من قبل. لن أتحدث عن ذلك هنا
ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.