مقدمة
الآن المزيد والمزيد من الشركات تتبنى Spring Cloud. SPRING BOOT هو الجيل القادم من أطر العمل و Spring Cloud هو الرائد في أحدث الخدمات المجهرية والأكثر شعبية. ما السبب الذي عليك أن ترفضه؟ بدأ العديد من الطلاب في جافا أيضًا في تعلم سحابة الربيع. في الواقع ، هناك مشكلة أخرى هنا: على الرغم من أن الجميع قد تعلموا Eureka ، Ribbon ، Hystrix ، Zuul ، Feign ، وما إلى ذلك ، لا يزال من الصعب تطبيقه على المشاريع الفعلية.
تكمن صعوبة الخدمات المجهرية في تقسيم الخدمات. الإطار هو مجرد أداة ، وسيستخدمها الكثير من الناس. تقسيم الخدمة والعلاقة بين الخدمات هي الأشياء التي يجب مراعاتها أثناء الانقسام.
اليوم أرسل لي زميل في الفصل بريدًا إلكترونيًا يسألني عن السؤالين التاليين:
فيما يلي بعض الإجابات بناءً على تجربتي الخاصة ، للرجوع إليها فقط:
بخصوص API في السؤال الأول هل وحدة التحكم تحت كل خدمة microservice؟
ما نسميه API هو في الواقع واجهة ، ويتم تطوير معظمها باستخدام Spring MVC ، وهي طريقة مشروحة في وحدة التحكم. التعليقات التوضيحية هي تلك التي نستخدمها غالبًا:
فيما يتعلق بالسؤال الأول ، هل يتطلب مشروعًا موحدًا لتغليف وحدة تحكم الخدمات الدقيقة الأخرى؟
في الواقع لا يوجد نمط ثابت. يتم إعادة توجيه معظم هذا مباشرة إلى خدمات عملك من خلال بوابة API
خذ فئة الأعمال من مواقع المدونة مثل Yuantiandi كمثال:
هناك وظيفة عمل. عندما أشاهد منشورات مدونة محددة ، فإن المعلومات التي أحتاج إلى إرجاعها هي كما يلي:
في هذا الوقت ، تتضمن الواجهة لعرض المقالة بالفعل ثلاثة أجزاء من البيانات ، ومعلومات المقالة نفسها ، ومعلومات التعليق ، ومعلومات المؤلف.
هناك 3 خدمات وخدمات المستخدمين وخدمات المدونة وخدمات التعليقات
وبالتالي فإن السؤال هو أنه ينطوي على التفاعل بين خدمات متعددة من قبل. في الواقع ، سألني نفس السؤال الذي سألني زميله أعلاه. هل أحتاج إلى مشروع موحد وتجميع الخدمات الأخرى؟ هل يمكن أن يطلق عليهم بعضهم البعض؟
أوصي بطريقتين لتنفيذ هذا:
1. تتقدم بوابة API مباشرة إلى خدمة المدونة
واجهة برمجة التطبيقات الخاصة بنا هي واجهة للحصول على معلومات نشر المدونة. يجب أن تكون الهيئة الرئيسية هي خدمة المدونة. هناك واجهة لمعلومات نشر المدونة في خدمة المدونة. في الواجهة ، ندعو واجهة معلومات المستخدم التي توفرها خدمة المستخدم ، كما ندعو معلومات التعليق المنشور في المدونة في خدمة التعليق. دعونا نرى رمز الزائفة:
getMapping ("/blog/delation/{id}") public bloginfo bloginfo (pathvariable ("id") id id) {// get blog blog blog = blogservice.getById (id) ؛ // الحصول على معلومات المستخدم userInfo userInfo = userFeignClient.getuserInfo (blog.getuserid ()) ؛ // الحصول على معلومات التعليق commentInfo commentInfo = commentFeignClient.getCommentInfo (id) ؛ إرجاع تجميع جميع المعلومات والعودة. }2. أضف طبقة خدمة التجميع
طبقة خدمة التجميع هي زميل في الفصل أعلاه ، هل من الضروري أن يكون لديك مشروع موحد للقيام بخدمات التجميع؟ هذا يعني أن خدمة المدونة الخاصة بنا لا تزال توفر معلومات مدونة أساسية ، ويتم إضافة خدمة تجميع أعمال منفصلة لتجميع هذه المعلومات وإعادتها إلى المتصل بشكل موحد. الرمز الزائف كما يلي:
getMapping ("/blog/delation/{id}") public bloginfo bloginfo (pathVariable ("id") id id) {// الحصول على معلومات المدونة بلوق = blogfeignclient.getById (id) ؛ // الحصول على معلومات المستخدم userInfo userInfo = userFeignClient.getuserInfo (blog.getuserid ()) ؛ // الحصول على معلومات التعليق commentInfo commentInfo = commentFeignClient.getCommentInfo (id) ؛ إرجاع تجميع جميع المعلومات والعودة. }تسمى البيانات عن بُعد ، بالطبع يمكنك تسميتها بالتوازي هنا. طريقة أخرى هي إجراء عملية التجميع في بوابة API. هذا الحل ممكن أيضا. أقترح ألا تفعل ذلك في البوابة. بوابة واجهة برمجة التطبيقات بسيطة قدر الإمكان والآخر إلى الأمام. تعد إضافة طبقة خدمة التجميع خيارًا جيدًا.
إذا تم تصميم حوكمة الخدمة الخاصة بك باستخدام Dubbo ، فإن طبقة خدمة التجميع هي أيضًا طريقة أفضل. يوفر تجميع خدمة Dubbo واجهة HTTP للمكالمات الخارجية.
3. يحصل المتصل على مختلف البيانات بمفرده
طريقة أخرى هي الاتصال بواجهة المدونة ، وواجهة التعليق ، وواجهة المستخدم نفسها. وبهذه الطريقة ، تحتاج الواجهة فقط إلى الانتباه إلى بياناتها وتسليم مشكلة التجميع للمستخدم. هذا يستخدم بشكل عام أقل. من الأفضل إرجاع البيانات إلى المتصل في وقت واحد ، والاتصال بها مرارًا وتكرارًا ، خاصة على محطة الهاتف المحمول ، والتي تتطلب الكثير من الطلبات وحركة المرور.
لخص
بالنسبة لكيفية تجميع البيانات ، عليك أن تقرر ذلك بنفسك. يمكنك وضع التجميع في خدمات الأعمال المقابلة ، أو إضافة خدمة تجميع لتجميعها بشكل منفصل ، أو السماح للعميل بتجميعها بنفسه.
يمكن بالتأكيد أن تسمى الخدمات بعضها البعض. إذا كان لا يمكن استدعاؤهم بعضهم البعض ، فما الهدف من تفكيكهم؟ استخدم Feign للاتصال بواجهة الخدمة ، وتعاملها فقط كمكالمة بين الخدمات.
حسنًا ، ما سبق هو المحتوى الكامل لهذه المقالة. آمل أن يكون لمحتوى هذه المقالة قيمة مرجعية معينة لدراسة أو عمل الجميع. إذا كان لديك أي أسئلة ، فيمكنك ترك رسالة للتواصل. شكرا لك على دعمك إلى wulin.com.