streamalism.org

1. סקירה כללית

במדריך זה נבין את מתודולוגיית האפליקציה שתים עשרה גורמים.

נבין גם כיצד לפתח מיקרו-שירות בעזרת Spring Boot. בתהליך נראה כיצד ליישם את מתודולוגיית שנים עשר הגורמים לפיתוח מיקרו-שירות כזה.

2. מהי מתודולוגיית שנים עשר הגורמים?

המתודולוגיה של שנים עשר גורמים היא קבוצה של שתים עשרה שיטות עבודה מומלצות לפיתוח יישומים שפותחו להפעלה כשירות. זה תוכנן במקור על ידי Heroku ליישומים שנפרסו כשירותים בפלטפורמת הענן שלהם, עוד בשנת 2011. עם הזמן זה הוכיח את עצמו כגנרי מספיק לכל פיתוח תוכנה כשירות (SaaS).

אז למה אנו מתכוונים בתוכנה כשירות? באופן מסורתי אנו מתכננים, מפתחים, פורסים ומתחזקים פתרונות תוכנה כדי להפיק מהם ערך עסקי. אך איננו צריכים לעסוק בתהליך זה בכדי להשיג אותה תוצאה בהכרח. לדוגמה, חישוב המס החל הוא פונקציה כללית בתחומים רבים.

כעת, אנו עשויים להחליט לבנות ולנהל שירות זה בעצמנו או להירשם כמנוי לשירות שירות מסחרי. כגון הצעות שירות הן מה שאנחנו מכירים כתוכנה כשירות.

בעוד שתוכנה כשירות אינה מטילה כל הגבלה על הארכיטקטורה שהיא פותחה עליה; זה די שימושי לאמץ כמה שיטות עבודה מומלצות.

אם אנו מתכננים את התוכנה שלנו להיות מודולרית, ניידת וניתנת להרחבה בפלטפורמות ענן מודרניות, היא נוחה למדי לשירותי השירות שלנו. זה המקום בו מתודולוגיית שתים עשרה הגורמים עוזרת. נראה אותם בפעולה בהמשך המדריך.

3. מיקרו-שירות עם מגף קפיץ

Microservice הוא סגנון אדריכלי לפיתוח תוכנה כשירותים המשולבים באופן רופף. הדרישה המרכזית כאן היא שה- השירותים צריכים להיות מאורגנים סביב גבולות התחום העסקי. לרוב זהו החלק הקשה ביותר לזיהוי.

יתר על כן, לשירות כאן הסמכות הבלעדית על נתוניו וחושף פעולות לשירותים אחרים. התקשורת בין השירותים היא בדרך כלל על פרוטוקולים קלים כמו HTTP. התוצאה היא שירותים ניתנים לפריסה וניתנים להרחבה.

כעת, ארכיטקטורת מיקרו-שירות ותוכנה כשירות אינם תלויים זה בזה. אבל, לא קשה להבין את זה מתי פיתוח תוכנה כשירות, מינוף ארכיטקטורת המיקרו-שירות מועיל למדי. זה עוזר להשיג הרבה יעדים עליהם דנו קודם, כמו מודולריות ומדרגיות.

Spring Boot הוא מסגרת יישומים המבוססת על Spring אשר מורידה המון תנור הקשורים לפיתוח יישום ארגוני. זה נותן לנו פלטפורמה דעתנית מאוד אך גמישה לפיתוח מיקרו-שירותים. לצורך הדרכה זו, ננצל את Spring Boot על מנת לספק שירות מיקרו באמצעות מתודולוגיה של שנים עשר גורמים.

4. יישום מתודולוגיה של שנים עשר גורמים

בואו נגדיר כעת יישום פשוט אותו ננסה לפתח בעזרת הכלים והפרקטיקות שדנו זה עתה. כולנו אוהבים לצפות בסרטים, אבל זה מאתגר לעקוב אחר הסרטים שכבר צפינו בהם.

עכשיו, מי רוצה להקים סרט ואז לנטוש אותו אחר כך? מה שאנחנו צריכים זה שירות פשוט להקלטה ולשאילת סרטים שצפינו בהם:

זהו שירות מיקרו פשוט וסטנדרטי למדי עם מאגר נתונים ונקודות קצה של REST. עלינו להגדיר מודל אשר ימפה גם להתמדה:

סרט בכיתה ציבורית @Entity {@ Id פרטי מזהה ארוך; כותרת מחרוזת פרטית; שנת מחרוזת פרטית; דירוג מחרוזת פרטי; // גטרים וקובעים}

הגדרנו ישות JPA עם מזהה ועוד כמה מאפיינים. בואו נראה עכשיו איך נראה בקר ה- REST:

@RestController בכיתה ציבורית MovieController {@ MovieRepository MovieRepository פרטי; @GetMapping ("/ סרטים") רשימה ציבורית retrieveAllStudents () {return movieRepository.findAll (); } @ GetMapping ("/ movies / {id}") סרט ציבורי retrieveStudent (@PathVariable מזהה ארוך) {return movieRepository.findById (id) .get (); } @PostMapping ("/ סרטים") ציבורי Long createStudent (@RequestBody Movie Movie) {return movieRepository.save (movie) .getId (); }}

זה מכסה את בסיס השירות הפשוט שלנו. אנו נעבור את שאר היישום כאשר אנו דנים כיצד אנו מיישמים את מתודולוגיית שנים עשר הגורמים בסעיפי המשנה הבאים.

4.1. קוד קוד

השיטה המומלצת הראשונה של יישומי שתים עשרה גורמים היא לעקוב אחריה במערכת בקרת גרסאות. גיט היא מערכת בקרת הגרסאות הפופולארית ביותר שנמצאת בשימוש כיום והיא נמצאת כמעט בכל מקום. העיקרון קובע זאת יש לעקוב אחר אפליקציה במאגר קוד יחיד ואסור לה לשתף מאגר זה עם אפליקציות אחרות.

Spring Boot מציע דרכים נוחות רבות לאתחול יישום, כולל כלי שורת פקודה וממשק אינטרנט. לאחר שנוצר את יישום ה- bootstrap, נוכל להמיר זאת למאגר git:

git init

יש להפעיל פקודה זו משורש היישום. היישום בשלב זה כבר מכיל קובץ .gitignore שמגביל למעשה את בקרת הגרסאות שנוצרו. אז אנו יכולים ליצור התחייבות ראשונית מייד:

להוסיף git. git commit -m "הוספת ה- bootstrap של היישום."

לבסוף, אנו יכולים להוסיף שלט ולדחוף את ההתחייבויות שלנו לשלט הרחוק אם נרצה בכך (זו לא דרישה מחמירה):

מרחוק git להוסיף מקור //github.com//12-factor-app.git git push -u master origin

4.2. תלות

לאחר מכן, אפליקציה של שנים עשר גורמים צריכה תמיד להכריז במפורש על כל התלות שלה. עלינו לעשות זאת באמצעות מניפסט של הצהרת תלות. ל- Java כלים מרובים לניהול תלות כמו Maven ו- Gradle. אנו יכולים להשתמש באחד מהם כדי להשיג מטרה זו.

לכן, היישום הפשוט שלנו תלוי בכמה ספריות חיצוניות, כמו ספרייה כדי להקל על ממשקי API של REST ולהתחבר למסד נתונים. בואו נראה כיצד נוכל להגדיר אותם באופן הצהרתי באמצעות Maven.

Maven מחייב אותנו לתאר את התלות של הפרויקט בקובץ XML, המכונה בדרך כלל מודל Project Object (POM):

  org.springframework.boot spring-boot-starter-web com.h2database h2 runtime 

למרות שזה נראה פשוט ופשוט, בדרך כלל יש לתלות אלה תלות מעבר. זה מסבך את זה במידה מסוימת אבל עוזר לנו להשיג את המטרה שלנו. כעת אין ליישום שלנו תלות ישירה שאינה מתוארת במפורש.

4.3. תצורות

לאפליקציה בדרך כלל יש הרבה תצורה, שחלקן עשויות להשתנות בין הפריסות בעוד שאחרות נשארות זהות.

בדוגמה שלנו, יש לנו מסד נתונים מתמשך. אנו זקוקים לכתובת האישורים של מסד הנתונים כדי להתחבר אליהם. סביר להניח שזה ישתנה בין הפריסות.

אפליקציה בת שתים עשרה גורמים אמורה להחצין את כל התצורות האלו המשתנות בין הפריסות. ההמלצה כאן היא להשתמש במשתני סביבה עבור תצורות כאלה. זה מוביל להפרדה נקייה של תצורה וקוד.

Spring מספק קובץ תצורה בו נוכל להכריז על תצורות כאלה ולצרף אותו למשתני סביבה:

spring.datasource.url = jdbc: mysql: // $ {MYSQL_HOST}: $ {MYSQL_PORT} / סרטים spring.datasource.username = $ {MYSQL_USER} spring.datasource.password = $ {MYSQL_PASSWORD}

כאן הגדרנו את כתובת האתר ואת אישורי האישור כקונפיגורציות ותמנו את הערכים בפועל שייבחרו ממשתנה הסביבה.

ב- Windows, אנו יכולים להגדיר את משתנה הסביבה לפני הפעלת היישום:

להגדיר MYSQL_HOST = localhost להגדיר MYSQL_PORT = 3306 להגדיר MYSQL_USER = סרטים להגדיר MYSQL_PASSWORD = סיסמה

אנו יכולים להשתמש בכלי לניהול תצורה כמו Ansible או Chef כדי להפוך את התהליך לאוטומטי.

4.4. שירותי גיבוי

שירותי גיבוי הם שירותים שהיישום תלוי בהם להפעלה. למשל מסד נתונים או מתווך הודעות. אפליקציה בת שתים עשרה גורמים צריכה להתייחס לכל שירותי הגיבוי הללו כאל משאבים צמודים. מה שזה אומר למעשה הוא שלא צריך לדרוש כל שינוי קוד כדי להחליף שירות גיבוי תואם. השינוי היחיד צריך להיות בתצורות.

ביישום שלנו השתמשנו ב- MySQL כשירות הגיבוי כדי לספק התמדה.

האביב JPA הופך את הקוד למדי אגנוסטי לספק הנתונים בפועל. עלינו להגדיר רק מאגר המספק את כל הפעולות הסטנדרטיות:

ממשק ציבורי @ מאגר @ MovieRepository מרחיב את JpaRepository {}

כפי שאנו רואים, הדבר אינו תלוי ישירות ב- MySQL. אביב מזהה את מנהל ההתקן של MySQL בשביל הכיתה ומספק יישום ספציפי ל- MySQL של ​​ממשק זה באופן דינמי. יתר על כן, הוא מושך פרטים אחרים מתצורות ישירות.

לכן, אם עלינו לעבור מ- MySQL ל- Oracle, כל שעלינו לעשות הוא להחליף את מנהל ההתקן בתלות שלנו ולהחליף את התצורות.

4.5. בנה, שחרר והפעל

מתודולוגיית שתים עשרה הגורמים מפריד בקפדנות את תהליך המרת קוד הבסיס ליישום פועל כשלושה שלבים נפרדים:

• שלב בנייה: זה המקום בו אנו לוקחים את קוד הקוד, מבצעים בדיקות סטטיות ודינמיות ואז מייצרים חבילת הפעלה כמו JAR. באמצעות כלי כמו Maven, זה די טריוויאלי:

 mvn נקי לקבץ חבילת בדיקה

• שלב השחרור: זהו השלב בו אנו לוקחים את חבילת ההפעלה ומשלבים זאת עם התצורות הנכונות. כאן נוכל להשתמש ב- Packer עם ספק כמו Ansible כדי ליצור תמונות Docker:

 יישום packer. json

• שלב הפעלה: לבסוף, זה השלב בו אנו מריצים את היישום בסביבת ביצוע יעד. אם אנו משתמשים ב- Docker כמכולה לשחרור היישום שלנו, הפעלת היישום יכולה להיות פשוטה מספיק:

 הפעלת העגינה - שם - זה 

לבסוף, אנו לא בהכרח צריכים לבצע את השלבים הללו באופן ידני. זה המקום שבו ג'נקינס נכנס די שימושי עם הצינור ההצהרתי שלהם.

4.6. תהליכים

אפליקציה בת שתים עשרה גורמים צפויה לפעול בסביבת ביצוע כתהליכים חסרי מדינה. במילים אחרות, הם לא יכולים לאחסן מצב מתמשך באופן מקומי בין בקשות. הם עשויים ליצור נתונים קבועים אשר נדרשים להיות מאוחסנים בשירותי גיבוי סטטיים אחד או יותר.

במקרה של הדוגמה שלנו, יש לנו כמה נקודות קצה שנחשפו. בקשה על אחת מנקודות הקצה הללו אינה תלויה לחלוטין בכל בקשה שהוגשה לפניה. לדוגמא, אם אנו עוקבים אחר בקשות המשתמשים בזיכרון ומשתמשים במידע זה כדי להגיש בקשות עתידיות, הוא מפר אפליקציה בת שתיים-גורמים.

לפיכך, אפליקציה בת שתים עשרה גורמים אינה מטילה הגבלה כזו כמו הפעלות דביקות. זה הופך אפליקציה כזו לניידת ולהרחבה. בסביבת ביצוע ענן המציעה קנה מידה אוטומטי, זו התנהגות די רצויה של יישומים.

4.7. קשירת נמל

יישום אינטרנט מסורתי בג'אווה מפותח כארגון WAR או ארכיון אינטרנט. זה בדרך כלל אוסף של Servlets עם תלות, והוא מצפה לזמן ריצה של מיכל תואם כמו Tomcat. אפליקציה בת שתים עשרה גורמים, להיפך, לא מצפה לתלות כזו בזמן ריצה. זה לגמרי עצמאי ודורש רק זמן ריצה כמו Java.

במקרה שלנו, פיתחנו יישום באמצעות Spring Boot. Spring Boot, מלבד יתרונות רבים אחרים, מספק לנו שרת יישומים מוטבע המוגדר כברירת מחדל. לפיכך, ה- JAR שיצרנו קודם באמצעות Maven מסוגל לבצע בכל סביבה רק על ידי זמן ריצה של Java תואם:

java -jar application.jar

כאן, היישום הפשוט שלנו חושף את נקודות הקצה שלו על פני קשירת HTTP ליציאה ספציפית כמו 8080. עם הפעלת היישום כפי שעשינו לעיל, אמורה להיות אפשרות לגשת לשירותים המיוצאים כמו HTTP.

יישום עשוי לייצא שירותים מרובים כמו FTP או WebSocket על ידי כריכה למספר יציאות.

4.8. מקביליות

ג'אווה מציעה פְּתִיל כמודל קלאסי לטיפול במקביל ביישום. חוטים הם כמו תהליכים קלים ומייצגים מסלולי ביצוע מרובים בתוכנית. האשכולות הם חזקים אך יש להם מגבלות מבחינת עד כמה זה יכול לעזור בקנה מידה של יישום.

המתודולוגיה של שנים עשר גורמים מציעה לאפליקציות להסתמך על תהליכים לצורך קנה המידה. מה שמשמעות הדבר ביעילות היא כי יישומים צריכים להיות מתוכננים להפצת עומס עבודה על פני מספר תהליכים. עם זאת, תהליכים בודדים חופשיים למנף מודל מקבילי כמו פְּתִיל כְּלַפֵּי פְּנִים.

יישום Java, כאשר הוא מושק, מקבל תהליך יחיד הקשור ל- JVM הבסיסי. מה שאנו זקוקים לו למעשה הוא דרך להשיק מספר מופעים של היישום עם חלוקת עומס חכמה ביניהם. מכיוון שכבר ארזנו את היישום שלנו כמיכל Docker, Kubernetes היא בחירה טבעית לתזמור כזה.

4.9. חד פעמיות

ניתן לסגור תהליכי יישום בכוונה או באמצעות אירוע לא צפוי. בכל מקרה, אפליקציה בת שתים עשרה גורמים אמורה לטפל בה בחן. במילים אחרות, תהליך הגשת בקשה צריך להיות חד פעמי ללא כל תופעות לוואי לא רצויות. יתר על כן, תהליכים צריכים להתחיל במהירות

למשל, ביישום שלנו, אחת מנקודות הקצה היא ליצור רשומת מסד נתונים חדשה לסרט. כעת, יישום המטפל בבקשה כזו עלול לקרוס באופן בלתי צפוי. עם זאת, זה לא אמור להשפיע על מצב היישום. כאשר לקוח שולח את אותה בקשה שוב, זה לא אמור לגרום לרישומים כפולים.

לסיכום, היישום צריך לחשוף שירותים חסרי יכולת. זהו מאפיין נוסף רצוי מאוד של שירות המיועד לפריסת ענן. זה נותן את הגמישות לעצור, לעבור או לסובב שירותים חדשים בכל עת ללא שום שיקול אחר.

4.10. זוגיות Dev / Prod

זה אופייני ליישומים שפותחו על גבי מכונות מקומיות, נבדקים בסביבות אחרות וניתנים לבסוף לייצור. לעתים קרובות זה המקרה בו סביבות אלה שונות. למשל, צוות הפיתוח עובד על מכונות Windows ואילו פריסת הייצור מתרחשת במכונות לינוקס.

המתודולוגיה של שנים עשר גורמים מציעה לשמור על הפער בין סביבת הפיתוח לבין סביבת הייצור מינימאלית ככל האפשר. פערים אלה יכולים לנבוע ממחזורי פיתוח ארוכים, צוותים שונים המעורבים, או מחסנית טכנולוגית שונה בשימוש.

כעת, טכנולוגיה כמו Spring Boot ו- Docker מגשרת באופן אוטומטי על פער זה במידה רבה. יישום מיכל צפוי להתנהג כך, לא משנה היכן אנו מריצים אותו. עלינו להשתמש באותם שירותי גיבוי - כמו בסיס הנתונים - גם כן.

יתר על כן, עלינו לקבל את התהליכים הנכונים כמו שילוב מתמשך ומסירה כדי להקל על גישור הפער הזה.

4.11. יומנים

יומנים הם נתונים חיוניים שיישום מייצר במהלך חייה. הם מספקים תובנות לא יסולא בפז לגבי תפקוד היישום. בדרך כלל יישום יכול ליצור יומנים במספר רמות עם פרטים משתנים ופלט ii במספר פורמטים שונים.

אפליקציה בת שתים עשרה גורמים, לעומת זאת, מבדילה את עצמה בין יצירת יומני העיבוד שלה. עבור אפליקציה כזו, יומנים אינם אלא זרם אירועים שהוזמן בזמן. זה רק כותב אירועים אלה לפלט הסטנדרטי של סביבת הביצוע. תפיסת האחסון, האצירה והארכיון של זרם כזה צריכה להיות מטופלת על ידי סביבת הביצוע.

ישנם די הרבה כלים העומדים לרשותנו למטרה זו. ראשית, אנו יכולים להשתמש ב- SLF4J כדי לטפל בכניסה באופן מופשט בתוך היישום שלנו. יתר על כן, אנו יכולים להשתמש בכלי כמו Fluentd כדי לאסוף את זרם היומנים מיישומים ושירותי גיבוי.

זה אנו יכולים להזין אלסטיקס לחיפוש לאחסון ואינדקס. לבסוף, אנו יכולים ליצור לוחות מחוונים משמעותיים להדמיה בקיבנה.

4.12. תהליכי מנהל

לעיתים קרובות עלינו לבצע כמה משימות חד פעמיות או הליך שגרתי עם מצב היישום שלנו. למשל, תיקון רשומות גרועות. כעת, ישנן דרכים שונות בהן אנו יכולים להשיג זאת. מכיוון שאולי אנו לא דורשים זאת לעיתים קרובות, אנו יכולים לכתוב סקריפט קטן להפעלתו בנפרד מסביבה אחרת.

עַכשָׁיו, מתודולוגיית שתים עשרה הגורמים מציעה בחום לשמור סקריפטים כאלה של מנהלים יחד עם בסיס קוד היישום. בתוך כך, עליו לפעול על פי אותם עקרונות כמו שאנו חלים על בסיס קוד היישומים הראשי. כמו כן, מומלץ להשתמש בכלי REPL מובנה בסביבת הביצוע להפעלת סקריפטים כאלה על שרתי הייצור.

בדוגמה שלנו, כיצד נזרע את היישום שלנו עם הסרטים שכבר נצפו עד כה? אמנם אנו יכולים להשתמש בנקודת הסיום הקטנה והמתוקה שלנו, אך נראה שזה לא מעשי. מה שאנחנו צריכים זה סקריפט לביצוע עומס חד פעמי. אנו יכולים לכתוב פונקציית Java קטנה כדי לקרוא רשימת סרטים מקובץ ולשמור אותם באצווה במסד הנתונים.

יתר על כן, אנו יכולים להשתמש ב- Groovy המשולב בזמן הריצה של Java כדי להתחיל תהליכים כאלה.

5. יישומים מעשיים

אז, עכשיו ראינו את כל הגורמים שהציעו מתודולוגיית שנים עשר גורמים. פיתוח אפליקציה להיות לאפליקציה של שנים עשר גורמים יש בהחלט את היתרונות שלה, במיוחד כאשר אנו מעוניינים לפרוס אותם כשירותים בענן. אבל, כמו כל שאר ההנחיות, המסגרות, הדפוסים, עלינו לשאול, האם זה כדור כסף?

בכנות, אף מתודולוגיה אחת בעיצוב ופיתוח תוכנה אינה טוענת שהיא כדור כסף. מתודולוגיית שתים עשרה הגורמים אינה יוצאת דופן. בזמן חלק מהגורמים הללו אינטואיטיביים למדיוכנראה שאנחנו כבר עושים אותם, אחרים עשויים שלא לפנות אלינו. חשוב להעריך גורמים אלה על רקע יעדינו ואז לבחור בחוכמה.

חשוב לציין כי כל הגורמים הללו הם שם כדי לעזור לנו לפתח יישום שהוא מודולרי, עצמאי, נייד, מדרגי וניתן לצפייה. בהתאם ליישום, ייתכן שנצליח להשיג אותם בצורה טובה יותר. אין צורך לאמץ את כל הגורמים יחד, אימוץ אפילו כמה מהם עשוי להפוך אותנו לטובים יותר ממה שהיינו.

לבסוף, גורמים אלה הם פשוטים ואלגנטיים למדי. הם מחזיקים בחשיבות רבה יותר בעידן שבו אנו דורשים מהיישומים שלנו תפוקה גבוהה יותר וחביון נמוך יותר ללא השבתה וכשל כמעט. אימוץ גורמים אלה נותן לנו התחלה נכונה מההתחלה. בשילוב עם ארכיטקטורה של שירותי מיקרוסופט ומיכל יישומים, נראה שהם פשוט פוגעים במקום הנכון.

6. מסקנה

במדריך זה עברנו את המושגים של מתודולוגיה של שנים עשר גורמים. דנו כיצד למנף ארכיטקטורת מיקרו-שירות עם Spring Boot כדי לספק אותם ביעילות. יתר על כן, בדקנו כל גורם בפירוט וכיצד ליישם אותם על היישום שלנו. בדקנו גם כמה כלים ליישום גורמים בודדים אלה בצורה יעילה בהצלחה.