מיקרו-שירותי פייתון: צלילה עמוקה להטמעת Service Mesh

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

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

מהם מיקרו-שירותי פייתון? רענון מהיר

לפני שנצלול לתוך הרשת (mesh), בואו נקבע בסיס משותף. ארכיטקטורת מיקרו-שירותים היא גישה שבה יישום יחיד מורכב משירותים קטנים רבים, המקושרים באופן רופף וניתנים לפריסה באופן עצמאי. כל שירות עצמאי, אחראי ליכולת עסקית ספציפית, ומתקשר עם שירותים אחרים דרך רשת, בדרך כלל באמצעות APIs (כמו REST או gRPC).

פייתון מתאימה באופן יוצא דופן לפרדיגמה זו בזכות:

• פשטות ומהירות פיתוח: התחביר הקריא של פייתון מאפשר לצוותים לבנות שירותים ולחזור עליהם במהירות.
• מערכת אקולוגית עשירה: אוסף עצום של ספריות ומסגרות עבודה לכל דבר, החל משרתי אינטרנט (FastAPI, Flask) ועד מדע נתונים (Pandas, Scikit-learn).
• ביצועים: מסגרות אסינכרוניות מודרניות כמו FastAPI, הבנויות על Starlette ו-Pydantic, מספקות ביצועים דומים ל-NodeJS ו-Go עבור משימות מוכוונות I/O, הנפוצות במיקרו-שירותים.

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

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

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

האתגרים המובנים של ארכיטקטורה מבוזרת

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

חוסר אמינות ברשת

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

ריק התצפית (Observability Void)

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

• מדדים (Metrics): איסוף עקבי של מדדים כמו השהיית בקשות, שיעורי שגיאות ונפח תעבורה (ה'אותות הזהב') מכל שירות.
• רישום (Logging): צבירת יומנים ממאות מופעים של שירותים ותיאום שלהם עם בקשה ספציפית.
• מעקב מבוזר (Distributed Tracing): מעקב אחר מסע של בקשה בודדת דרך כל השירותים שהיא נוגעת בה כדי לדמיין את גרף הקריאות כולו ולזהות השהיות.

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

מבוך האבטחה

כיצד מבטיחים שתקשורת בין שירות ההזמנות לשירות המשתמשים מאובטחת ומוצפנת? כיצד מבטיחים שרק שירות ההזמנות רשאי לגשת לנקודות קצה רגישות של מלאי בשירות המוצרים? בהגדרה מסורתית, ייתכן שתסתמכו על כללי רשת (חומות אש) או תשבצו סודות ולוגיקת אימות בתוך כל יישום. זה הופך לקשה ביותר לניהול בקנה מידה גדול. אתם זקוקים לרשת אפס אמון (zero-trust network) שבה כל שירות מאמת ומורשה כל קריאה, מושג המכונה Mutual TLS (mTLS) ובקרת גישה גרנולרית.

פריסות מורכבות וניהול תעבורה

כיצד משחררים גרסה חדשה של שירות המוצרים מבוסס פייתון מבלי לגרום להשבתה? אסטרטגיה נפוצה היא שחרור קנרי (canary release), שבו אתם מנתבים לאט אחוז קטן מהתעבורה החיה (למשל, 1%) לגרסה החדשה. אם היא מתפקדת היטב, אתם מגדילים בהדרגה את התעבורה. הטמעת זה לעיתים קרובות דורשת לוגיקה מורכבת ברמת ה-load balancer או ה-API gateway. אותו הדבר חל על בדיקות A/B או שיקוף תעבורה למטרות בדיקה.

הכירו את ה-Service Mesh: הרשת עבור שירותים

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

רכיבים עיקריים: מישור בקרה (Control Plane) ומישור נתונים (Data Plane)

ל-Service Mesh יש שני חלקים עיקריים:

• מישור הנתונים (Data Plane): מורכב מקבוצת מתווכים (proxies) רשת קלים, הנקראים sidecars, המותקנים לצד כל מופע של המיקרו-שירות שלכם. מתווכים אלו מיירטים את כל תעבורת הרשת הנכנסת והיוצאת אל ומתוך השירות שלכם. הם לא יודעים ולא אכפת להם שהשירות שלכם כתוב בפייתון; הם פועלים ברמת הרשת. המתווך הפופולרי ביותר המשמש ב-Service Meshes הוא Envoy.
• מישור הבקרה (Control Plane): זהו ה'מוח' של ה-Service Mesh. זהו אוסף של רכיבים איתם אתם, המפעילים, מתקשרים. אתם מספקים למישור הבקרה כללים ומדיניות ברמה גבוהה (למשל, 'נסו שוב בקשות שנכשלו לשירות המוצרים עד 3 פעמים'). מישור הבקרה מתרגם מדיניות זו לתצורות ודוחף אותן לכל מתווכי ה-sidecar במישור הנתונים.

המסר העיקרי הוא זה: ה-Service Mesh מעביר את הלוגיקה של דאגות הרשת אל מחוץ לשירותי הפייתון האישיים שלכם אל שכבת הפלטפורמה. מפתח ה-FastAPI שלכם כבר לא צריך לייבא ספריית ניסיון חוזר או לכתוב קוד לטיפול בתעודות mTLS. הוא כותב לוגיקה עסקית, וה-mesh מטפל בשאר באופן שקוף.

בקשה משירות ההזמנות לשירות המוצרים זורמת כעת כך: שירות הזמנות → Sidecar של שירות הזמנות → Sidecar של שירות מוצרים → שירות מוצרים. כל הקסם—ניסיונות חוזרים, איזון עומסים, הצפנה, איסוף מדדים—קורה בין שני ה-sidecars, בניהול מישור הבקרה.

עמודי התווך של Service Mesh

בואו נפרט את היתרונות ש-Service Mesh מספק לארבעה עמודי תווך מרכזיים.

1. אמינות ועמידות

Service Mesh הופך את המערכת המבוזרת שלכם לחזקה יותר מבלי לשנות את קוד היישום שלכם.

• ניסיונות חוזרים אוטומטיים: אם קריאה לשירות נכשלת עקב שגיאת רשת חולפת, ה-sidecar יכול לנסות שוב את הבקשה באופן אוטומטי על סמך מדיניות מוגדרת.
• פסק זמן (Timeouts): ניתן לאכוף פסק זמן עקביים ברמת השירות. אם שירות קצה אינו מגיב תוך 200ms, הבקשה נכשלת במהירות, מונעת ממשאבים להיתקע.
• מפסק חשמלי (Circuit Breakers): אם מופע של שירות נכשל באופן עקבי, ה-sidecar יכול להסיר אותו זמנית ממאגר איזון העומסים (לתקוף את המפסק). זה מונע כשלים מדורגים ומעניק לשירות הלא תקין זמן להתאושש.

2. יכולת תצפית עמוקה

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

• מדדים: הרשת מייצרת אוטומטית מדדים מפורטים לכל התעבורה, כולל השהיה (p50, p90, p99), שיעורי הצלחה ונפח בקשות. אלו יכולים להיגרד על ידי כלי כמו Prometheus והוצג בממשק כמו Grafana.
• מעקב מבוזר: ה-sidecars יכולים להזריק ולהפיץ כותרות מעקב (כמו B3 או W3C Trace Context) בין קריאות שירות. זה מאפשר לכלי מעקב כמו Jaeger או Zipkin לחבר את המסע המלא של בקשה, ומספק תמונה מלאה של התנהגות המערכת שלכם.
• יומני גישה: קבלו יומנים עקביים ומפורטים עבור כל קריאת שירות-לשירות, המציגים מקור, יעד, נתיב, השהיה וקוד תגובה, כל זאת ללא הצורך בהצהרת `print()` אחת בקוד הפייתון שלכם.

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

3. אבטחה אוניברסלית

Service Mesh יכול לאכוף מודל אבטחה של אפס אמון בתוך האשכול שלכם.

• Mutual TLS (mTLS): ה-mesh יכול להנפיק אוטומטית זהויות קריפטוגרפיות (תעודות) לכל שירות. לאחר מכן הוא משתמש בהן להצפנה ואימות של כל התעבורה בין שירותים. זה מבטיח שאף שירות לא מאומת אינו יכול לדבר עם שירות אחר, וכל הנתונים במעבר מוצפנים. זה מופעל באמצעות מתג תצורה פשוט.
• מדיניות הרשאה: ניתן ליצור כללי בקרת גישה חזקים ומפורטים. לדוגמה, ניתן לכתוב מדיניות האומרת: 'אפשר בקשות `GET` משירותים עם הזהות 'order-service' לנקודת הקצה `/products` בשירות 'product-service', אך דחה את כל השאר.' זה נאכף ברמת ה-sidecar, לא בקוד הפייתון שלכם, מה שהופך אותו להרבה יותר מאובטח וניתן לביקורת.

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

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

• ניתוב דינמי: נתב בקשות על סמך כותרות, עוגיות או מטא-דאטה אחר. לדוגמה, נתב משתמשי בטא לגרסה חדשה של שירות על ידי בדיקת כותרת HTTP ספציפית.
• שחרורי קנרי ובדיקות A/B: הטמע אסטרטגיות פריסה מתוחכמות על ידי פיצול תעבורה לפי אחוז. לדוגמה, שלח 90% מהתעבורה לגרסה `v1` של שירות הפייתון שלך ו-10% ל-`v2` החדש. ניתן לנטר את המדדים עבור `v2`, ואם הכל נראה תקין, להעביר בהדרגה יותר תעבורה עד ש-`v2` יטפל ב-100%.
• הזרקת כשלים (Fault Injection): לבדיקת העמידות של המערכת שלכם, ניתן להשתמש ב-mesh להזרקת כשלים בכוונה, כגון שגיאות HTTP 503 או השהיות רשת, עבור בקשות ספציפיות. זה עוזר לכם למצוא ולתקן חולשות לפני שהן גורמות להשבתה אמיתית.

בחירת ה-Service Mesh שלכם: פרספקטיבה גלובלית

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

Istio

• סקירה: מגובה על ידי גוגל, IBM ואחרים, Istio הוא ה-Service Mesh העשיר ביותר בתכונות והחזק ביותר. הוא משתמש במתווך Envoy שנבדק בקרב.
• חוזקות: גמישות ללא תחרות בניהול תעבורה, מדיניות אבטחה חזקה ומערכת אקולוגית תוססת. זהו הסטנדרט דה פקטו עבור פריסות מורכבות ברמת ארגוני.
• שיקולים: הכוח שלו מגיע עם מורכבות. עקומת הלמידה יכולה להיות תלולה, ויש לו תקורה גבוהה יותר במשאבים בהשוואה למשלבים אחרים.

Linkerd

• סקירה: פרויקט בוגר של CNCF (Cloud Native Computing Foundation) המעדיף פשטות, ביצועים וקלות תפעולית.
• חוזקות: קל להפליא להתקנה ולהתחלה. יש לו טביעת רגל קטנה מאוד במשאבים הודות למתווך המותאם אישית שלו, קל משקל במיוחד, הכתוב ב-Rust. תכונות כמו mTLS פועלות מהקופסה ללא כל תצורה.
• שיקולים: יש לו סט תכונות יותר אופנתי וממוקד. בעוד שהוא מכסה את מקרי השימוש הליבה של יכולת תצפית, אמינות ואבטחה בצורה יוצאת דופן, הוא חסר חלק מיכולות הניתוב התעבורה המתקדמות והאזוטריות של Istio.

Consul Connect

• סקירה: חלק מחבילת הכלים הרחבה של HashiCorp (הכוללת את Terraform ו-Vault). היתרון המרכזי שלו הוא התמיכה מהשורה הראשונה בסביבות רב-פלטפורמה.
• חוזקות: הבחירה הטובה ביותר עבור סביבות היברידיות המשתרעות על פני מספר אשכולות Kubernetes, ספקי ענן שונים, ואפילו מכונות וירטואליות או שרתים פיזיים. האינטגרציה שלו עם קטלוג השירותים של Consul חלקה.
• שיקולים: זהו חלק ממוצר גדול יותר. אם אתם זקוקים רק ל-Service Mesh עבור אשכול Kubernetes יחיד, Consul עשוי להיות יותר ממה שאתם צריכים.

הטמעה מעשית: הוספת מיקרו-שירות פייתון ל-Service Mesh

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

תרחיש

יש לנו `user-service` פשוט הכתוב בפייתון באמצעות FastAPI. יש לו נקודת קצה אחת: `/users/{user_id}`.

שלב 1: שירות הפייתון (ללא קוד ספציפי ל-Mesh)

קוד היישום שלכם נשאר לוגיקה עסקית טהורה. אין ייבוא ​​עבור Istio, Linkerd או Envoy.

main.py:

            from fastapi import FastAPI

app = FastAPI()

users_db = {
    1: {"name": "Alice", "location": "Global"},
    2: {"name": "Bob", "location": "International"}
}

@app.get("/users/{user_id}")
def read_user(user_id: int):
    return users_db.get(user_id, {"error": "User not found"})
            

              
                Copy
              
            
          

קובץ ה-`Dockerfile` המצורף הוא גם סטנדרטי, ללא שינויים מיוחדים.

שלב 2: פריסת Kubernetes

אתם מגדירים את הפריסה והשירות של השירות שלכם ב-YAML סטנדרטי של Kubernetes. שוב, שום דבר ספציפי ל-Service Mesh עדיין.

            apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service-v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: user-service
      version: v1
  template:
    metadata:
      labels:
        app: user-service
        version: v1
    spec:
      containers:
      - name: user-service
        image: your-repo/user-service:v1
        ports:
        - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
  - port: 80
    targetPort: 8000
            

              
                Copy
              
            
          

שלב 3: הזרקת מתווך ה-Sidecar

כאן קורה הקסם. לאחר התקנת ה-Service Mesh שלכם (למשל, Istio) באשכול ה-Kubernetes שלכם, אתם מאפשרים הזרקת sidecar אוטומטית. עבור Istio, זו פקודה חד-פעמית עבור הנפח שלכם:

            kubectl label namespace default istio-injection=enabled
            

              
                Copy
              
            
          

כעת, כאשר אתם פורסים את `user-service` שלכם באמצעות `kubectl apply -f your-deployment.yaml`, מישור הבקרה של Istio משנה אוטומטית את מפרט הפוד לפני שהוא נוצר. הוא מוסיף את קונטיינר מתווך Envoy לפוד. לפוד שלכם יש כעת שני קונטיינרים: `user-service` הפייתון שלכם וה-`istio-proxy`. לא שיניתם את ה-YAML כלל.

שלב 4: החלת מדיניות Service Mesh

שירות הפייתון שלכם הוא כעת חלק מה-mesh! כל תעבורה אליו וממנו מתווכת. כעת תוכלו להחיל מדיניות חזקה. בואו נאכוף mTLS קפדני עבור כל השירותים בנפח.

peer-authentication.yaml:

            apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT
            

              
                Copy
              
            
          

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

כעת ניצור כלל ניתוב תעבורה לביצוע שחרור קנרי. נניח שיש לכם `user-service-v2` פרוס.

virtual-service.yaml:

            apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: user-service
spec:
  hosts:
  - user-service
  http:
  - route:
    - destination:
        host: user-service
        subset: v1
      weight: 90
    - destination:
        host: user-service
        subset: v2
      weight: 10
            

              
                Copy
              
            
          

עם `VirtualService` זה ו-`DestinationRule` מתאים (המגדיר את תתי-קבוצות `v1` ו-`v2`), הוריתם ל-Istio לשלוח 90% מהתעבורה לשירות הישן שלכם ו-10% לחדש. כל זה נעשה ברמת התשתית, שקוף לחלוטין ליישומי הפייתון ולקוראים שלהם.

מתי כדאי להשתמש ב-Service Mesh? (ומתי לא)

Service Mesh הוא כלי רב עוצמה, אך הוא אינו פתרון אוניברסלי. אימוץ שלו מוסיף שכבת תשתית נוספת לניהול.

אמצו Service Mesh כאשר:

• מספר המיקרו-שירותים שלכם גדל (בדרך כלל מעל 5-10 שירותים), וניהול האינטראקציות שלהם הופך לכאב ראש.
• אתם פועלים בסביבה פוליגלוטית שבה אכיפת מדיניות עקבית עבור שירותים הכתובים בפייתון, Go ו-Java היא דרישה.
• יש לכם דרישות אבטחה, יכולת תצפית ועמידות מחמירות שקשה לעמוד בהן ברמת היישום.
• הארגון שלכם כולל צוותי פיתוח ותפעול נפרדים, ואתם רוצים להעצים מפתחים להתמקד בלוגיקה עסקית בעוד צוותי התפעול מנהלים את הפלטפורמה.
• אתם מושקעים מאוד באורקסטרציה של קונטיינרים, במיוחד Kubernetes, שם Service Meshes משתלבים בצורה החלקה ביותר.

שקלו חלופות כאשר:

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

מסקנה: העצמת מיקרו-שירותי הפייתון שלכם

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

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

על ידי אימוץ Service Mesh כמו Istio או Linkerd, אתם מעצימים את מפתחי הפייתון שלכם לעשות את מה שהם עושים הכי טוב: לבנות תכונות מצוינות ולספק ערך עסקי. הם משוחררים מהנטל של הטמעת לוגיקת רשת מורכבת, boilerplate, ויכולים במקום זאת להסתמך על הפלטפורמה שתספק עמידות, אבטחה ותובנה. עבור כל ארגון שרציני לגבי קנה מידה של ארכיטקטורת המיקרו-שירותים שלו, Service Mesh הוא השקעה אסטרטגית שמחזירה דיבידנדים באמינות, אבטחה ופרודוקטיביות מפתחים.