כיצד לחלוק DTO על מיקרו-שירותים
1. סקירה כללית
שירותי מיקרו הפכו פופולריים בשנים האחרונות. אחד המאפיינים החיוניים של שירותי המיקרו הוא שהם מודולריים, מבודדים וקלים להרחבה. שירותי המיקרו צריכים לעבוד יחד ולהחליף נתונים. כדי להשיג זאת, אנו יוצרים אובייקטים משותפים להעברת נתונים הנקראים DTO.
במאמר זה נציג דרכים בהן DTOs משותפים בין מיקרו-שירותים.
2. חשיפת אובייקטים מתחום כ- DTO
מודלים המייצגים את תחום היישום מנוהלים באמצעות מיקרו-שירותים. מודלים של דומיינים הם דאגות שונות, ואנחנו מפרידים אותם ממודלים של נתונים בשכבת DAO.
הסיבה העיקרית לכך היא שאנחנו לא רוצים לחשוף את המורכבות של התחום שלנו באמצעות השירותים ללקוחות. במקום זאת, אנו חושפים DTOs בין השירותים שלנו המשרתים לקוחות יישומים באמצעות ממשקי API של REST. בעוד ש- DTO עוברים בין שירותים אלה, אנו ממירים אותם לאובייקטים של תחומים.
הארכיטקטורה מוכוונת השירות שלמעלה מציגה באופן סכמטי את הרכיבים והזרימה של DTO לאובייקטים של תחום.
3. שיתוף DTO בין מיקרו-שירותים
ניקח כדוגמה את התהליך של לקוח המזמין מוצר. תהליך זה מבוסס על הזמנת לקוח דֶגֶם. בואו נסתכל על התהליך מהצד של ארכיטקטורת השירות.
בואו נגיד ששירות הלקוחות שולח נתוני בקשה לשירות ההזמנות כ:
"order": {"customerId": 1, "itemId": "A152"}שירותי הלקוח וההזמנה מתקשרים זה עם זה באמצעות חוזים.החוזה, שהוא אחרת בקשת שירות, מוצג בפורמט JSON. כמודל ג'אווה, ה- OrderDTO class מייצג חוזה בין שירות הלקוחות לשירות ההזמנות:
מעמד ציבורי OrderDTO {int clientId פרטי; פריט מחרוזת פרטיId; // קונסטרוקטור, גטרס, סטרים}3.1. שיתוף DTO באמצעות מודולי לקוח (ספריות)
שירות מיקרו דורש מידע מסוים משירותים אחרים בכדי לעבד כל בקשה. נניח שיש שירות מיקרו שלישי שמקבל בקשות לתשלום הזמנה. בשונה משירות ההזמנה, שירות זה דורש פרטי לקוח שונים:
מחלקה ציבורית CustomerDTO {שם פרטי פרטי מחרוזת; שם משפחה פרטי מחרוזת; כרטיס מחרוזת פרטי מספר; // קונסטרוקטור, גטרס, סטרים}אם נוסיף גם שירות משלוחים, פרטי הלקוח יהיו:
מחלקה ציבורית CustomerDTO {שם פרטי פרטי מחרוזת; שם משפחה פרטי מחרוזת; בית מחרוזת פרטי כתובת; פרטי מחרוזת contactNumber; // קונסטרוקטור, גטרס, סטרים}אז, הצבת CustomerDTO בכיתה במודול משותף כבר לא משרת את המטרה המיועדת. כדי לפתור זאת, אנו ניגשים לשיטה אחרת.
בכל מודול מיקרו-שירות, בואו ליצור מודול לקוח (ספרייה)ולצידו מודול שרת:
שירות הזמנות | __ הזמנת לקוח | __ שרת הזמנותה לקוח הזמנות המודול מכיל DTO המשותף עם שירות הלקוחות. לכן, ה לקוח הזמנות למודול המבנה הבא:
שירות הזמנות └── הזמנת לקוח OrderClient.java OrderClientImpl.java OrderDTO.java ה OrderClient הוא ממשק המגדיר להזמין שיטה לעיבוד בקשות הזמנה:
ממשק ציבורי OrderClient {OrderResponse order (OrderDTO orderDTO); }כדי ליישם את להזמין בשיטה, אנו משתמשים ב- RestTemplate מתנגד לשלוח בקשת POST לשירות ההזמנות:
מחרוזת serviceUrl = "// localhost: 8002 / service-service"; OrderResponse orderResponse = restTemplate.postForObject (serviceUrl + "/ create", בקשה, OrderResponse.class);חוץ מה לקוח הזמנות המודול מוכן לשימוש. כעת היא הופכת לספרייה תלויה של שירות לקוחות מודול:
[INFO] --- תוסף maven-dependency: 3.1.2: list (ברירת מחדל-cli) @ שירות לקוחות --- [INFO] הקבצים הבאים נפתרו: [INFO] com.baeldung.orderservice: order- לקוח: צנצנת: 1.0-SNAPSHOT: קומפילציהכמובן, אין לכך מטרה ללא שרת הזמנות מודול לחשיפת נקודת הקצה של השירות "/ create" ללקוח ההזמנה:
@PostMapping ("/ create") ציבורי OrderResponse createOrder (@RequestBody OrderDTO בקשה)הודות לנקודת סיום שירות זו, שירות הלקוחות יכול לשלוח בקשת הזמנה דרך לקוח ההזמנה שלה. על ידי שימוש במודול הלקוח, שירותי המיקרו מתקשרים זה עם זה בצורה מבודדת יותר. תכונות ב- DTO מתעדכנות בתוך מודול הלקוח. לכן, הפרת חוזים מוגבלת לשירותים המשתמשים באותו מודול לקוח.
4. מסקנה
במאמר זה, הסברנו דרך לשתף אובייקטים של DTO בין מיקרו-שירותים. במקרה הטוב, אנו משיגים זאת על ידי עריכת חוזים מיוחדים כחלק ממודולי לקוח מיקרו-שירות (ספריות). באופן זה, אנו מפרידים בין לקוח השירות לבין חלק השרת המכיל את משאב ה- API. כתוצאה מכך ישנם כמה יתרונות:
- אין יתירות בקוד ה- DTO בין השירותים
- פריצת חוזים מוגבלת לשירותים המשתמשים באותה ספריית לקוחות
דוגמת קוד של יישום Spring Boot זמינה ב- GitHub.
