حسنًا ، دعنا نستمر في الحديث عن المقال من المقال السابق. في المقالة السابقة ، ذكرنا أنه إذا أردنا تحديث جميع تكوينات الخدمات الصغيرة وتحديث التكوين دون إعادة التشغيل ، فيمكننا الاعتماد فقط على Cloud Config. ومع ذلك ، نحتاج إلى إرسال طلبات البريد من خدمة إلى أخرى.
هل يمكننا تحملها؟ هذا أفضل بكثير من النقص السابق في مركز التكوين. فكيف يمكننا الاستمرار في تجنب إرسال طلبات البريد إلى الخدمة واحدة تلو الأخرى لإبلاغ الخدمة؟ لقد تغيرت معلومات التكوين الخاصة بك وتحتاج إلى تعديل معلومات التكوين في الذاكرة في الوقت المناسب.
في هذا الوقت ، لا ينبغي لنا أن ننسى نموذج الاشتراك في قائمة انتظار الرسائل. جميع الخدمات تشترك في هذا الحدث. عندما يتغير هذا الحدث ، يمكن إخطار جميع الخدمات المجهرية بتحديث معلومات تكوين الذاكرة الخاصة بهم. في هذا الوقت ، يمكن لحافلة رسائل الحافلة حلها. تحتاج فقط إلى إصدار تحديث على جانب خادم Config SpringCloud لإطلاق جميع تحديثات الخدمات الصغيرة.
كما هو موضح في الرسم البياني المعماري التالي:
بالإضافة إلى دعم التكوين الآلي لـ RabbitMQ ، يدعم Spring Cloud Bus أيضًا كافكا ، والتي تستخدم الآن على نطاق واسع. في هذه المقالة ، سنقوم ببناء بيئة محلية من Kafka ونستخدمها لمحاولة استخدام Spring Cloud Bus لدعم Kafka لتنفيذ وظيفة ناقل الرسائل.
يتم تنفيذ Kafka باستخدام Scala ويستخدم كخط أنابيب لتجهيز البيانات النشط للبيانات والتشغيل من LinkedIn ، ويستخدم الآن على نطاق واسع من قبل العديد من شركات الإنترنت كخط أنابيب لتدفق البيانات وأنظمة الرسائل.
مخطط هندسة Kafak كما يلي:
Kafka هو نظام مراسلة يتم تنفيذه بناءً على وضع نشر الرسائل/الاشتراك. أهداف التصميم الرئيسية هي على النحو التالي:
1. استمرار الرسالة: توفير قدرة ثبات الرسالة في تعقيد الوقت O (1) ، وحتى البيانات فوق مستوى TB يمكن أن تضمن أداء الوصول مع تعقيد الوقت المستمر.
2. الإنتاجية العالية: يمكن أن تدعم أيضًا إنتاجية أكثر من 100 ألف في الثانية على آلات تجارية رخيصة
3. الموزع: دعم رسائل تقسيم والاستهلاك الموزعة ، وضمان ترتيب الرسائل داخل القسم
4.
5. في الوقت الفعلي: دعم معالجة البيانات في الوقت الفعلي ومعالجة البيانات في وضع عدم الاتصال
6. قابلية التوسع: دعم التوسع الأفقي
بعض المفاهيم الأساسية المشاركة في كافكا:
1. Broker: تحتوي مجموعة Kafka على خادم واحد أو أكثر ، يسمى الوسطاء.
2.TOPIC: تشبه منطقيًا قائمة انتظار قائمة انتظار Rabbit ، يجب أن يكون لكل رسالة منشورة على مجموعة Kafka موضوع. (يتم تخزين الرسائل ذات المواضيع المختلفة بشكل منفصل. على الرغم من أن الرسالة المنطقية للموضوع يتم تخزينها على واحد أو أكثر من الوسطاء ، إلا أن المستخدم يحتاج فقط إلى تحديد موضوع الرسالة لإنتاج البيانات أو استهلاكها دون الاهتمام بمكان تخزين البيانات)
3. التقسيم: التقسيم هو قسم في المفهوم المادي. من أجل توفير إنتاجية النظام ، سيتم تقسيم كل موضوع فعليًا إلى قسم أو أكثر ، ويتوافق كل قسم مع مجلد (تخزين محتوى الرسالة وملف الفهرس للقسم المقابل).
4. المنتج: منتج الرسائل ، المسؤول عن إنتاج الرسائل وإرسالها إلى Kafka Broker.
5.Consumer: مستهلك الرسائل ، العميل الذي يقرأ الرسائل إلى وسيط كافكا ويعالجها.
6.Consumer Group: ينتمي كل مستهلك إلى مجموعة معينة (يمكن تحديد كل مستهلك كمجموعة ، وإذا لم يتم تحديده ، فهو ينتمي إلى المجموعة الافتراضية). يمكن استخدام المجموعة لتنفيذ وظائف مثل الرسالة التي يستهلكها أعضاء متعددين في المجموعة.
يمكنك أن ترى من مخطط هندسة Kafka أن Kafka يتطلب دعم Zookeeper. تحتاج إلى تحديد مكان وجود ZookeEper في تكوين Kafka الخاص بك. إنه يضمن بعض الموثوقية من خلال Zookeeper وهو سيد وعبد الوسيط. نحتاج أيضًا إلى معرفة أن رسائل كافكا منظمة في نموذج الموضوع. يقوم المنتجون بإرسال رسائل نموذج الموضوع ، ويتم تقسيم المستهلكين وفقًا للمجموعات ، وبالتالي فإن مجموعة من المستهلكين ستحتاج جميعًا إلى نفس رسائل نموذج الموضوع. على جانب الخادم ، فإنه يصنع أيضًا بعض القطع ، لذلك قد يتم توزيع موضوع على شظايا مختلفة ، مما يسهلنا إلى توسيع ونشر آلات متعددة. يتم توزيع كافكا بشكل طبيعي. للتظاهر هنا ، نحتاج فقط إلى استخدام تكوينه الافتراضي وصنع عرضًا تجريبيًا صغيرًا على Windows.
نركز بشكل أساسي على دعم SPRING Cloud Bus لـ Kafka ، والذي ينفذ وظيفة ناقل الرسائل. بالنسبة لقوائم رسائل Kafka و RabbitMQ المحددة ، نأمل أن نجد معلومات لتعلمها بنفسك. مع بعض الدعم المفاهيم ، نقوم ببعض العروض التوضيحية.
على النحو التالي: أولاً ، قم بإنشاء وحدة SPRINGCLOUD-CONFIG-CLIENT1 الجديدة لتسهيل اختبارنا. التبعيات المقدمة هي كما يلي:
<Rependency> <roupeD> org.springframework.boot </rougiD> <artifactid> Spring-boot-starter-actuator </suntifactid> </sependency> <reperency> <roupid> org.springframework.boot </supleid> <roupl> org.springframework.cloud </groupId> <StifactId> Spring-Cloud-Config </shintifactid> <sored> 1.4.0.Release </version> </redenced> <redency> <roupend> org.springframework.cloud </groupid> <sophy> 1.3.5.release </version> </sependency> <reperence> <roupiD> org.springframework.cloud </rougeid> <StifactId> spring-cloud-starter-bus-kafka </shintifactid> <soph>
بعد ذلك ، يرجى ملاحظة أنه يجب تغيير ملف التكوين الخاص بـ Client1 إلى bootstrap.yml ، لأن تنسيق التكوين هذا مفضل. كما هو مذكور في المقال السابق ، فإن تكوين Client1 كما يلي:
الخادم: المنفذ: 7006spring: التطبيق: الاسم: Cloud-Config Cloud: Config:#ما هو البيئة المستخدمة للبدء؟ يمثل DEV بيئة التنمية. يرتبط هذا باحتفال الملف في المستودع الخاص بك. على سبيل المثال ، فإن تنسيق التسمية لملف تكوين المستودع هو Cloud-config-dev.properties ، لذلك يجب كتابة ملف تعريف ملف تعريف DEC: Dev Discovery: True# هذا الاسم هو اسم خدمة جانب خادم التكوين ، ولا يمكنك كتابته بشكل عمياء. معرف الخدمة: config-server#register eureka: العميل: service-url: defaultZone: http: // localhost: 8888/eureka/، http: // localhost: 8889/eureka/##لا يلزم الحصول على إذن؟ الافتراضي صحيح. إذا لم تكن خطأ ، فلن يُسمح لك بسحب المحتوى الذي تم تحديثه بواسطة إدارة خادم مركز التكوين: الأمان: ممكّن: خطأ
ثم ابدأ الفصل على النحو التالي:
@springbootapplication@enableScoveryClientPublic Client1application {public static void main (string [] args) {springapplication.run (client1application.class ، args) ؛ }}ثم قم بتعيين نسخة من testController في العميل إلى Client1 ، الرمز هو كما يلي:
@restController // قد يتم تحديث الخصائص هنا. إذا تغير مركز التكوين في GIT ، فيجب تحديثه. بدون هذا التعليق التوضيحي ، لا يمكن تحديث التكوين في Time @REFRESHSCOPEPEPPUBLUBERS TESTCONTROLLER {value ("$ {name}") اسم السلسلة الخاصة ؛ Value ("$ {Age}") عصر عدد صحيح خاص ؛ requestMapping ("/test") test string public () {return this.name+this.age ؛ }}ثم أضف التكوين التالي إلى خادم التكوين في الوحدة النمطية في المقال السابق:
#ما إذا كان الإذن مطلوبًا للسحب ، يكون الافتراضي صحيحًا. إذا لم تكن خطأ ، فلن يُسمح لك بسحب المحتوى الذي تم تحديثه بواسطة إدارة خادم مركز التكوين: الأمان: ممكّن: خطأ
بعد ذلك ، نحتاج إلى القيام بشيء واحد: يجب أن يقدم Config-Client و Config-Client1 و Config Server تبعيات Kafka ، على النحو التالي:
<Rependency> <roupeD> org.springframework.cloud </rougiD> <artifactid> spring-cloud-starter-bus-kafka </shintifactid> <sophy> 1.3.2.reease </version> </sependency>
مشروعنا جاهز ، لذلك سنضعه هنا في الوقت الحالي. دعنا نثبت وتنزيل كافكا أدناه. أولاً ، نذهب إلى موقع Kafka الرسمي kafka.apache.org/downloads للانتقال إلى الإصدار الموصى به على الموقع الرسمي.
أولاً ، ندخل دليل kafka الذي تم تنزيله وتحرير kafka-run-class.bat بموجب kafka_2.11-1.1.0/bin/windows على النحو التالي:
ابحث عن هذا التكوين على النحو التالي:
انسخ الرمز على النحو التالي: set command = ٪ java ٪ kafka_heap_opts ٪ kafka_jvm_performance_opts ٪ kafka_jmx_opts ٪ kafka_log4j_opts ٪ -cp ٪ classpath ٪ kafka_opts ٪*
يمكنك أن ترى أن ٪ classpath ٪ لا يوجد لديه عروض أسعار مزدوجة.
لذلك ، أرفقها في عروض أسعار مزدوجة ، وإلا لا يمكن أن تبدأ. يقال أن JDK الخاص بك لم يتم تثبيته بشكل صحيح. بعد التعديل ، هو كما يلي:
انسخ الرمز على النحو التالي: set command = ٪ java ٪ kafka_heap_opts ٪ kafka_jvm_performance_opts ٪ ٪ kafka_jmx_opts ٪ kafka_log4j_opts ٪ -cp "٪ classpath" ٪ kafka_opts ٪*
بعد ذلك ، افتح server.properties في مجلد التكوين وتكوينه على النحو التالي:
يمكنك أن ترى أنه متصل بمنطقة Zookeeper المحلية.
ثم نبدأ Zookeeper أولاً ، ثم كافكا ، على النحو التالي:
عندما ترى المعلومات المذكورة أعلاه ، يثبت أن بدء تشغيل ZookeEper ناجح. و
بعد ذلك ، ابدأ Kafka مع CMD آخر ، على النحو التالي:
رؤية هذه المعلومات تعني أنه تم إطلاق كافكا بنجاح
حسنًا ، دعنا نبدأ المشروع السابق ، ومراكزان للتسجيل ، وخادم واحد من SpringCloud-Config-Server ، واثنين من SpringCloud-Config-Client ، و Springcloud-Config-Client1.
يمكنك أن ترى أن SpringCloudbus موجود على 0 Shard. إذا ظهرت المعلومات أعلاه على كلا العازفين التكوين ، فإن ذلك يثبت أن بدء التشغيل ناجح.
حسنًا ، دعنا نصل الآن إلى جانب خادم التكوين ، على النحو التالي:
تفضل بزيارة عميلين آخرين ، على النحو التالي:
حسنًا ، بدأ العرض. الآن نذهب إلى مستودع GIT لتعديل ملف مركز التكوين وتغيير العمر إلى 24 ، على النحو التالي:
بعد ذلك ، نستخدم Refresh لتحديث تكوين خادم التكوين وإخطار العملاء بتحديث معلومات التكوين في الذاكرة. استخدم ساعي البريد لإرسال مضيف محلي: 7000/ناقل/تحديث ، على النحو التالي:
يمكنك أن ترى أنه لا يتم إرجاع أي معلومات ، ولكن لا تقلق ، هذا إشعار ناجح لجميع العملاء لتحديث المعلومات في الذاكرة.
ثم نعيد إعادة تكوين خادم التكوين وعملتين لتحديث الصفحة ، والنتيجة هي كما يلي:
العميلان على النحو التالي:
يمكنك أن ترى أن جميع العملاء تحديث معلومات التكوين تلقائيًا في الذاكرة.
حتى الآن ، قام ما ورد أعلاه بتحديث معلومات التكوين. لا بأس أيضًا إذا أردنا تحديث معلومات التكوين الخاصة بخدمة معينة. يمكننا تحديد نطاق التحديث على النحو التالي:
حدد نطاق التحديث
في المثال أعلاه ، نقوم بإعداد /refresh لحالات الخدمة الأخرى في الحافلة من خلال طلب واجهة SPRING Cloud BUS /bus/refresh من مثيل الخدمة. ومع ذلك ، في بعض السيناريوهات الخاصة (مثل الإصدار الرمادي) ، نأمل أن نتحقق من تكوين مثيل معين في الخدمات الدقيقة.
لدى Spring Cloud Bus أيضًا دعمًا جيدًا لهذا السيناريو: توفر واجهة /bus/refresh أيضًا معلمات destination لتحديد التطبيق المحدد لتحديثه. على سبيل المثال ، يمكننا طلب /bus/refresh?destination=服务名字:9000 . في هذا الوقت ، ستحدد كل مثيل تطبيق في الحافلة ما إذا كان اسم المثيل الخاص به استنادًا إلى قيمة سمة destination .
إذا تم استيفاء التكوين ، فسيتم تحديث التكوين. إذا لم يتطابق التكوين ، فسيتم تجاهل الرسالة.
بالإضافة إلى وضع مثيلات محددة ، يمكن أيضًا استخدام معلمات destination لوضع خدمات محددة. يتم تنفيذ مبدأ خدمات تحديد المواقع باستخدام Spring's PathMatecher ، على سبيل المثال: /bus/refresh?destination=customers:** ، والتي ستؤدي إلى تحديث جميع مثيلات خدمة customers .
ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.