ہیلتھ کیئر پورٹلز کے لیے مائیکرو سروسز پر مبنی REST API کیسے بنایا جائے۔

مائیکرو سروسز آرکیٹیکچر ہیلتھ کیئر پورٹلز کو حساس ڈیٹا کو پیمانہ، محفوظ اور تیزی سے تیار کرنے کی اجازت دیتا ہے۔

ASP.NET 10 اور C# آپ کو مریض، اپائنٹمنٹ، اور تصدیق جیسی خدمات کے لیے آزاد REST APIs بنانے کی اجازت دیتے ہیں، ہر ایک کا اپنا ڈیٹا بیس اور تعیناتی لائف سائیکل۔

یہ نقطہ نظر، ایک API گیٹ وے، JWT پر مبنی سیکیورٹی، مشاہداتی صلاحیت، اور کنٹینرائزیشن کے ساتھ مل کر، ایک قابل اعتماد، برقرار رکھنے کے قابل، اور قابل پیداوار صحت کی دیکھ بھال کے نظام کو یقینی بناتا ہے۔

اس ٹیوٹوریل میں، ASP.NET 10 اور C# کا استعمال کرتے ہوئے مائیکرو سروسز پر مبنی ہیلتھ کیئر پورٹل کو ڈیزائن اور بنانے کا طریقہ سیکھیں۔ یہ خدمات کو ترتیب دینے، REST APIs کو لاگو کرنے، اختتامی مقامات کو محفوظ کرنے، سروس مواصلات کو فعال کرنے، اور جدید کنٹینرائزیشن کے طریقوں کو استعمال کرتے ہوئے تعیناتی کا احاطہ کرتا ہے۔

آخر تک، آپ کو ایک قابل توسیع، محفوظ، اور پیداوار کے لیے تیار صحت کی دیکھ بھال کا نظام بنانے کے بارے میں واضح طور پر سمجھ آجائے گی۔

انڈیکس

شرطیں

شروع کرنے سے پہلے، آپ کو درج ذیل جاننا چاہیے:

• C# اور ASP.NET کور کی بنیادی باتیں

• REST API تصورات (HTTP طریقے، روٹنگ، اسٹیٹس کوڈز)

• مائیکرو سروس فن تعمیر کی بنیادی تفہیم

اوزار کی ضرورت ہے:

خاکہ

صحت کی دیکھ بھال کے پورٹلز اہم کام کے بہاؤ کی حمایت کرتے ہیں جیسے کہ مریض کی رجسٹریشن، اپائنٹمنٹ شیڈولنگ، الیکٹرانک ہیلتھ ریکارڈز (EHR)، بلنگ، اور ٹیلی ہیلتھ۔ ان سسٹمز کو حساس ڈیٹا، اعلیٰ دستیابی کے تقاضوں اور بار بار اپ ڈیٹس کو سنبھالنا چاہیے۔

روایتی طور پر، صحت کی دیکھ بھال کی بہت سی ایپلی کیشنز کو یک سنگی نظام کے طور پر بنایا گیا تھا۔ Monoliths شروع کرنا آسان ہے، لیکن تیزی سے پیمانہ، برقرار رکھنے، اور محفوظ کرنا مشکل ہو جاتا ہے۔ ایک غلطی پورے سسٹم کو متاثر کر سکتی ہے، پوری ایپلیکیشن کو دوبارہ تعینات کرنے کے لیے تھوڑی سی تبدیلی کی بھی ضرورت ہوتی ہے۔

مائیکرو سرویس فن تعمیر ایپلی کیشن کو چھوٹی، آزاد خدمات میں تقسیم کرکے ان مسائل کو حل کرتا ہے۔ ہر سروس ایک مخصوص علاقے کا احاطہ کرتی ہے، جیسے کہ مریض کی دیکھ بھال یا ملاقات کا شیڈولنگ، اور اسے آزادانہ طور پر تیار، تعینات، اور اسکیل کیا جا سکتا ہے۔

اس مضمون میں، آپ ASP.NET 10 اور C# کا استعمال کرتے ہوئے مائکرو سروسز پر مبنی ہیلتھ کیئر REST API کو ڈیزائن اور لاگو کرنے کا طریقہ سیکھتے ہیں۔ ہم آرکیٹیکچرل ڈیزائن، سروس کے نفاذ، مواصلات کے پیٹرن، سیکورٹی، مشاہداتی، اور تعیناتی کی حکمت عملی کو دیکھیں گے۔

ہیلتھ کیئر پورٹلز کے لیے مائیکرو سروسز کیوں استعمال کریں؟

صحت کی دیکھ بھال کے نظام فطری طور پر پیچیدہ ہیں۔ اس میں متعدد ڈومینز شامل ہیں جیسے مریض کے ریکارڈ، ملاقاتیں، بلنگ، تصدیق، اور اجازت۔ مائیکرو سروسز اپروچ ان ڈومینز میں سے ہر ایک کو آزادانہ طور پر ہینڈل کرنے کی اجازت دیتا ہے۔ اس نقطہ نظر کے بہت سے فوائد ہیں:

• توسیع پذیری: سروس کی توسیع صرف اس وقت ہوتی ہے جب بوجھ زیادہ ہو (مثلاً چوٹی کے اوقات میں ملاقاتیں)

• فالٹ آئیسولیشن: اگر ایک سروس ناکام ہو جائے تو پورا نظام نہیں رکتا۔

• تیز تر تعیناتی۔: ٹیمیں آزادانہ طور پر اپ ڈیٹس تعینات کر سکتی ہیں۔

• سیکیورٹی میں اضافہ: حساس خدمات تک رسائی کے سخت کنٹرول ہو سکتے ہیں۔

مثال کے طور پر، مریض کی خدمات ذاتی ڈیٹا پر کارروائی کر سکتی ہیں، جبکہ بلنگ سروسز ہر ایک ٹرانزیکشن کو منظم کرنے کے لیے مختلف سیکیورٹی پالیسیاں استعمال کرتی ہیں۔

اعلی سطحی فن تعمیر

ایک عام ہیلتھ کیئر مائیکرو سروسز آرکیٹیکچر میں ایک API گیٹ وے (مرکزی داخلی نقطہ)، مائیکرو سروسز (مریض، ملاقات، تصدیق)، سروس کے لیے مخصوص ڈیٹا بیس، اور سروس کمیونیکیشن پرت شامل ہوتی ہے۔

درخواست کا بہاؤ کلائنٹ کی درخواست بھیجنے کے ساتھ شروع ہوتا ہے۔ API گیٹ وے پھر درخواست کو روٹ کرتا ہے اور ہدف مائیکرو سروس اس پر کارروائی کرتا ہے۔ پھر جواب دیا جاتا ہے۔ یہ علیحدگی ماڈیولریٹی اور برقرار رکھنے کو یقینی بناتی ہے۔

صحت کی دیکھ بھال کے لیے ایک REST API ڈیزائن کرنا

مائیکرو سروسز آرکیٹیکچر میں REST API کو ڈیزائن کرنے کے لیے واضح اور مستقل نام کے کنونشنز کی ضرورت ہوتی ہے تاکہ اختتامی نقطے بدیہی، پیش قیاسی، اور کلائنٹس اور دیگر خدمات کے لیے استعمال میں آسان ہوں۔

نام دینے کا کنونشن

REST APIs وسائل پر مبنی ہیں۔ یعنی، یو آر ایل کو ہستیوں (اسموں) کی نمائندگی کرنی چاہیے، اعمال (فعل) کی نہیں۔ ہر وسیلہ سسٹم میں ڈومین آبجیکٹ سے مطابقت رکھتا ہے، جیسے مریض، اپوائنٹمنٹ، یا بلنگ ریکارڈ۔

کلیدی اصول:

• وسائل کے لیے جمع اسم استعمال کریں، جیسے /patients، /appointments)

• URLs میں فعل استعمال کرنے سے گریز کریں۔ /getPatients)

• رشتوں کے لیے درجہ بندی کا استعمال کریں، جیسے /patients/{id}/appointments)

• تمام خدمات میں اپنا نام یکساں رکھیں۔

یہ قواعد API پڑھنے کی اہلیت، ڈویلپر کے تجربے اور آپ کی ٹیم میں برقرار رکھنے کی صلاحیت کو بہتر بناتے ہیں۔

مثال: مریض API کا اختتامی نقطہ

درج ذیل اختتامی نقطے مریض کے انتظام کے لیے معیاری CRUD (تخلیق، پڑھیں، اپ ڈیٹ، حذف) آپریشنز کی نمائندگی کرتے ہیں۔

GET    /api/patients        // Retrieve all patients
GET    /api/patients/{id}   // Retrieve a specific patient
POST   /api/patients        // Create a new patient
PUT    /api/patients/{id}   // Update an existing patient
DELETE /api/patients/{id}   // Delete a patient

ہر HTTP طریقہ کار انجام دینے کی قسم کی وضاحت کرتا ہے۔

• GET: ڈیٹا حاصل کریں (صرف پڑھنے کے لیے)

• پوسٹ: ایک نیا وسیلہ بنائیں

• PUT: موجودہ وسائل کو اپ ڈیٹ کریں۔

• حذف کریں: وسائل کو ہٹا دیں۔

یہ آپریشنز REST معیارات کی پیروی کرتے ہیں، تمام سروسز میں مستقل مزاجی کو یقینی بناتے ہیں اور API کو فرنٹ اینڈ ایپس، موبائل کلائنٹس، یا تھرڈ پارٹی ہیلتھ کیئر سسٹم کے ساتھ مربوط کرنا آسان بناتے ہیں۔

ہیلتھ کیئر REST API ڈیزائن کے بہترین طریقے

صحت کی دیکھ بھال کے نظام کے لیے ایک REST API ڈیزائن کرنے کے لیے معیاری قواعد سے زیادہ کی ضرورت ہوتی ہے۔ کارکردگی، ڈیٹا کی حساسیت، اور انٹرآپریبلٹی کو احتیاط سے سمجھا جانا چاہیے۔

1. مناسب HTTP طریقہ استعمال کریں۔

یقینی بنائیں کہ ہر اختتامی نقطہ صحیح HTTP فعل (GET, POST, PUT, DELETE) کا استعمال کرتے ہوئے اپنے مقصد کو واضح طور پر بتاتا ہے۔ یہ API کی پیش گوئی کو بہتر بناتا ہے اور صحت کی دیکھ بھال کے پلیٹ فارمز میں استعمال ہونے والے REST معیارات کے ساتھ ہم آہنگ ہوتا ہے۔

2. ایک معنی خیز اسٹیٹس کوڈ واپس کریں۔

مناسب HTTP اسٹیٹس کوڈ کا استعمال کرتے ہوئے درخواست کے نتیجے کی نشاندہی کریں۔ مثال کے طور پر:

• کامیاب تلاش کے لیے 200 ٹھیک ہے۔

• 201 کامیاب وسائل کی تخلیق کے لیے بنایا گیا۔

• توثیق کی خرابی کے لیے 400 غلط درخواست

• 404 نہیں ملا اگر وسیلہ موجود نہیں ہے۔
  کلیئر اسٹیٹس کوڈز کلائنٹس کو جوابات پر صحیح طریقے سے کارروائی کرنے میں مدد کرتے ہیں۔

صحت کی دیکھ بھال کے نظام اکثر ڈیٹا کی بڑی مقدار کو ہینڈل کرتے ہیں (مثلاً مریض کے ریکارڈ، ملاقات کے نوشتہ جات)۔ جوابی سائز کو محدود کرنے کے لیے صفحہ بندی کا استعمال کریں۔

GET /api/patients?page=1&pageSize=20

اس سے کارکردگی بہتر ہوتی ہے اور سرور کا بوجھ کم ہوتا ہے۔

4. API ورژن استعمال کریں۔

اپنے API ورژن کی وضاحت کریں تاکہ تبدیلیاں موجودہ کلائنٹس کو نہ توڑیں۔

/api/v1/patients

یہ صحت کی دیکھ بھال کے شعبے میں خاص طور پر اہم ہے جہاں وقت کے ساتھ ساتھ بیرونی نظاموں کے ساتھ انضمام کو مستحکم رہنا چاہیے۔

5. ان پٹ ڈیٹا کی تصدیق اور حذف کرنا

غلطیوں سے بچنے اور ڈیٹا کی سالمیت کو یقینی بنانے کے لیے ہمیشہ آنے والے ڈیٹا کی توثیق کریں۔ مثال کے طور پر، مریض کا نام، تاریخ پیدائش، اور رابطے کی تفصیلات جیسے مطلوبہ فیلڈز کا اطلاق کریں۔

6. حساس ڈیٹا کی حفاظت کریں۔

مریض کی حساس معلومات کو غیر ضروری طور پر ظاہر نہ کریں۔ صحت کی دیکھ بھال کے ڈیٹا کے ضوابط کی تعمیل کرنے کے لیے ضرورت کے مطابق فلٹرنگ، ماسکنگ، یا فیلڈ لیول ایکسیس کنٹرول کا استعمال کریں۔

7. مسلسل ردعمل کے ڈھانچے کو یقینی بنائیں

ڈیٹا، اسٹیٹس، اور میسج فیلڈز سمیت معیاری فارمیٹ میں جواب لوٹاتا ہے۔ یہ آپ کے API کو متعدد سروسز میں استعمال اور ڈیبگ کرنا آسان بناتا ہے۔

ASP.NET 10 کے ساتھ مائیکرو سروسز کیسے بنائیں

آئیے ایک سادہ مریض کی خدمت کو نافذ کریں۔

مرحلہ 1: ایک پروجیکٹ بنائیں

اس مرحلے میں، آپ ایک نیا ASP.NET Web API پروجیکٹ بنائیں گے جو مریض کی مائیکرو سروس کے طور پر کام کرے گا۔ یہ پروجیکٹ اختتامی نقطوں کی وضاحت، HTTP درخواستوں کو سنبھالنے، اور نظام کے دیگر حصوں سے آزادانہ طور پر خدمات کو ترتیب دینے کے لیے ایک بنیاد فراہم کرتا ہے۔

dotnet new webapi -n PatientService
cd PatientService

مرحلہ 2: ماڈل کی وضاحت کریں۔

اگلا، ہم مریض کی نمائندگی کرنے والے ایک سادہ ڈیٹا ماڈل کی وضاحت کریں گے۔ ایک ماڈل ڈیٹا کی ساخت کی وضاحت کرتا ہے جسے API بھیجتا اور وصول کرتا ہے، اور عام طور پر اصل ایپلی کیشن میں ڈیٹا بیس کے اداروں کے ساتھ نقشہ بنایا جاتا ہے۔

public class Patient
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
}

مرحلہ 3: ایک کنٹرولر بنائیں

یہاں ہم آنے والی HTTP درخواستوں کو سنبھالنے کے لیے ایک کنٹرولر بناتے ہیں۔ کنٹرولرز API کے اختتامی نقطوں کی وضاحت کرتے ہیں اور درخواستوں پر کارروائی کرنے، ڈیٹا کے ساتھ تعامل کرنے اور کلائنٹ کو جوابات واپس کرنے کے لیے منطق پر مشتمل ہوتے ہیں۔

[ApiController]
[Route("api/patients")]
public class PatientController : ControllerBase
{
    private static List patients = new();

    [HttpGet]
    public IActionResult GetPatients()
    {
        return Ok(patients);
    }

    [HttpPost]
    public IActionResult AddPatient(Patient patient)
    {
        patients.Add(patient);
        return CreatedAtAction(nameof(GetPatients), patient);
    }
}

سروس پیٹرن کے لحاظ سے ڈیٹا بیس

ہر مائیکرو سروس کو اپنے ڈیٹا بیس کا انتظام کرنا چاہیے تاکہ ڈھیلے جوڑے اور آزادانہ عمل کو یقینی بنایا جا سکے۔ یہ آپ کو دیگر خدمات کو متاثر کیے بغیر خدمات کو تیار کرنے، اسکیل کرنے اور تعینات کرنے کی اجازت دیتا ہے۔ یہ ڈیٹا آئسولیشن کو بھی بہتر بناتا ہے اور مائیکرو سروسز فن تعمیر کے بنیادی اصولوں سے مطابقت رکھتا ہے۔

ہستی فریم ورک کور کی ایک مثال یہ ہے:

public class PatientDbContext : DbContext
{
    public PatientDbContext(DbContextOptions options)
        : base(options) { }

    public DbSet Patients { get; set; }
}

یہ اہم ہے کیونکہ یہ خدمات کے درمیان انحصار کو روکنے، آزاد اسکیلنگ کو فعال کرنے، اور ڈیٹا کی حفاظت کو بہتر بنا کر مائیکرو سروسز کو زیادہ موثر اور محفوظ بناتا ہے۔

سروس مواصلات

مائیکرو سروسز ڈیٹا کا اشتراک کرنے اور پورے نظام میں ورک فلو کو مربوط کرنے کے لیے ایک دوسرے کے ساتھ بات چیت کرتی ہیں۔ اس مواصلات کو ہم وقت ساز درخواستوں یا غیر مطابقت پذیر پیغام رسانی کے ذریعے سنبھالا جا سکتا ہے، استعمال کے معاملے پر منحصر ہے۔

صحیح نقطہ نظر کا انتخاب اس بات کو یقینی بنانے میں مدد کرے گا کہ آپ کا تقسیم شدہ نظام قابل توسیع، قابل بھروسہ، اور جوابدہ ہے۔

1. ہم وقت ساز مواصلات (HTTP)

var response = await httpClient.GetAsync("http://appointment-service/api/appointments");

2. غیر مطابقت پذیر مواصلات (پیغام رسانی)

RabbitMQ جیسے میسج بروکر کا استعمال:

ہاں:

جب ایک مریض رجسٹر ہوتا ہے، ایک واقعہ پیش آتا ہے اور ریزرویشن سروس شروع ہو جاتی ہے۔

API گیٹ وے کا نفاذ

API گیٹ وے مائیکرو سروسز آرکیٹیکچر میں کلائنٹ کی تمام درخواستوں کے لیے مرکزی انٹری پوائنٹ کے طور پر کام کرتا ہے۔ یہ آسان بناتا ہے کہ کس طرح کلائنٹ روٹنگ، تصدیق، اور جمع کی درخواست کو سنبھال کر متعدد خدمات کے ساتھ تعامل کرتے ہیں۔ یہ تہہ سیکیورٹی، اسکیل ایبلٹی، اور سسٹم کے مجموعی انتظام کو بہتر بنانے میں مدد کرتی ہے۔

یہاں ایک مثال ہے (Ocelot ترتیب):

{
  "Routes": [
    {
      "DownstreamPathTemplate": "/api/patients",
      "UpstreamPathTemplate": "/patients",
      "DownstreamHostAndPorts": [
        { "Host": "localhost", "Port": 5001 }
      ]
    }
  ]
}

فوائد میں مرکزی روٹنگ، تصدیق کی کارروائی، اور شرح کو محدود کرنا شامل ہیں۔

ہیلتھ کیئر APIs میں سیکیورٹی کو نافذ کرنا

مریض کے ڈیٹا کی حساس نوعیت کی وجہ سے، صحت کی دیکھ بھال کے نظام میں سیکورٹی انتہائی اہم ہے۔ APIs کو مضبوط تصدیق، اجازت، اور ڈیٹا کے تحفظ کے طریقہ کار کو نافذ کرنا چاہیے۔ مناسب سیکیورٹی تعمیل کو یقینی بناتی ہے، غیر مجاز رسائی کو روکتی ہے، اور صارف کے اعتماد کی حفاظت کرتی ہے۔

1. JWT کی توثیق

builder.Services.AddAuthentication("Bearer")
    .AddJwtBearer(options =>
    {
        options.Authority = "https://auth-server";
        options.Audience = "healthcare-api";
    });

JSON ویب ٹوکن (JWT) کی توثیق API تک رسائی حاصل کرنے والے صارف کی شناخت کی تصدیق کے لیے کی جاتی ہے۔

توثیق کی اسکیم ("بیرر”) API کو بتاتی ہے کہ ٹوکن کو اجازت کے ہیڈر میں موجود ہونا چاہیے۔ Authorization: Bearer

اتھارٹی قابل اعتماد تصدیقی سرور (شناخت فراہم کنندہ) کی نمائندگی کرتی ہے جو ٹوکن جاری کرتا ہے۔

اور سامعین اس بات کو یقینی بناتے ہیں کہ ٹوکن خاص طور پر اس API کے لیے ڈیزائن کیا گیا ہے۔

جب درخواست کی جاتی ہے تو، API مندرجہ ذیل کام کرتا ہے:

1. درخواست ہیڈر سے JWT نکالیں۔

2. اجازتوں کا استعمال کرتے ہوئے دستخط کی تصدیق کریں۔

3. میعاد ختم ہونے اور سامعین جیسے دعووں کی جانچ کریں۔

4. رسائی صرف اس صورت میں دیتا ہے جب ٹوکن درست ہو۔

یہ یقینی بناتا ہے کہ صرف مجاز صارفین کو صحت کی دیکھ بھال کی خدمات تک رسائی حاصل ہے۔

2. کردار پر مبنی تصدیق

[Authorize(Roles = "Doctor")]
public IActionResult GetSensitiveData()
{
    return Ok();
}

کردار پر مبنی توثیق صارف کے کردار کی بنیاد پر رسائی کو محدود کرتی ہے۔

• کہ [Authorize] پراپرٹی نافذ کرتی ہے کہ صرف مستند صارف ہی اختتامی نقطہ تک رسائی حاصل کرسکتے ہیں۔

• کہ Roles = "Doctor" شرط یہ یقینی بناتی ہے کہ صرف ڈاکٹر کے کردار کے حامل صارفین ہی اس وسائل تک رسائی حاصل کر سکتے ہیں۔

جب کوئی صارف درخواست بھیجتا ہے:

1. JWT ٹوکن کی تصدیق ہو چکی ہے۔

2. سسٹم ٹوکن کے اندر کردار کے دعووں کی تصدیق کرتا ہے۔

3. رسائی صرف اس صورت میں دی جاتی ہے جب مطلوبہ کردار مماثل ہوں۔

یہ صحت کی دیکھ بھال کے نظام میں اہم ہے جہاں ڈاکٹروں کو طبی ریکارڈ تک رسائی حاصل ہے، منتظمین سسٹم کے ڈیٹا کا انتظام کرتے ہیں، اور مریضوں کو صرف اپنی معلومات تک رسائی حاصل ہے۔

3. محفوظ خفیہ انتظام

var connectionString = Environment.GetEnvironmentVariable("DB_CONNECTION");

حساس کنفیگریشن ڈیٹا، جیسے ڈیٹا بیس کنکشن سٹرنگز، کو آپ کی ایپلیکیشن میں ہارڈ کوڈ نہیں کیا جانا چاہیے۔

Environment.GetEnvironmentVariable() اپنے ماحول سے محفوظ طریقے سے راز بازیافت کریں۔ یہ اقدار عام طور پر درج ذیل جگہ پر محفوظ کی جاتی ہیں:

• ماحولیاتی متغیرات

• سیکرٹ مینیجر (ازور کی والٹ، اے ڈبلیو ایس سیکرٹس مینیجر)

• کنٹینر آرکیسٹریشن پلیٹ فارم

منافع:

• سورس کوڈ میں اسناد کی نمائش کو روکتا ہے۔

• ماحول میں محفوظ تعیناتی کی حمایت کرتا ہے۔

• کوڈ میں تبدیلی کے بغیر خفیہ گردش کو آسان بناتا ہے۔

4. HTTPS نفاذ

app.UseHttpsRedirection();

HTTPS اس بات کو یقینی بناتا ہے کہ کلائنٹ اور سرور کے درمیان تمام مواصلت کو خفیہ کیا گیا ہے۔

UseHttpsRedirection() خودکار طور پر HTTP درخواستوں کو HTTPS پر ری ڈائریکٹ کرتا ہے۔ یہ صحت کی دیکھ بھال کے حساس ڈیٹا (مثلاً مریض کے ریکارڈ اور اسناد) کو درمیان میں ہونے والے حملوں، ڈیٹا میں مداخلت اور غیر مجاز رسائی سے بچاتا ہے۔

صحت کی دیکھ بھال کے نظام کے لیے ڈیٹا کے تحفظ کے معیارات اور ضوابط کی تعمیل کرنے کے لیے خفیہ کاری ضروری ہے۔

یہ حفاظتی میکانزم تحفظ کی متعدد پرتیں فراہم کرتے ہیں۔

• توثیق آپ کی شناخت کی تصدیق کرتی ہے۔

• اجازت نامہ رسائی کو کنٹرول کرتا ہے۔

• خفیہ انتظام کے ساتھ اپنی اسناد کی حفاظت کریں۔

• HTTPS ٹرانزٹ میں ڈیٹا کی حفاظت کرتا ہے۔

صحت کی دیکھ بھال کے حساس ڈیٹا کی حفاظت اور صنعت کے معیارات پر عمل کرنے کے لیے یہ تہہ دار نقطہ نظر ضروری ہے۔

مشاہدہ اور لاگنگ

مشاہدہ آپ کو سسٹم کی صحت کی نگرانی کرنے، مسائل کی تشخیص کرنے، اور یہ سمجھنے کی اجازت دیتا ہے کہ خدمات حقیقی وقت میں کیسے تعامل کرتی ہیں۔ لاگنگ، میٹرکس اور ٹریسنگ کو لاگو کرکے، آپ کی ٹیم غلطیوں اور کارکردگی کی رکاوٹوں کی فوری شناخت کر سکتی ہے۔ تقسیم شدہ نظاموں کی وشوسنییتا کو برقرار رکھنے کے لیے یہ ضروری ہے۔

ایک بنیادی لاگنگ مثال درج ذیل ہے:

_logger.LogInformation("Fetching patients");

جب بھی مریض کا ڈیٹا حاصل کیا جاتا ہے تو یہ لائن ایک معلوماتی لاگ انٹری کو ریکارڈ کرتی ہے۔ _logger مثالیں ASP.NET کے بلٹ ان لاگنگ فریم ورک کا حصہ ہیں اور عام طور پر انحصار انجیکشن کے ذریعے کلاسوں میں انجیکشن کی جاتی ہیں۔

لاگنگ کی یہ سطح ڈویلپرز کو ایپلیکیشن کے معمول کے رویے کو ٹریک کرنے اور یہ سمجھنے میں مدد کرتی ہے کہ کچھ کارروائیاں کب ہوتی ہیں، جو خاص طور پر پیداواری ماحول میں ڈیبگنگ اور نگرانی کے دوران مفید ہوتی ہے۔

ایپلیکیشن بصیرت کا انضمام

builder.Services.AddApplicationInsightsTelemetry();

یہ کنفیگریشن ایپلی کیشن انسائٹس کے ساتھ انضمام کی اجازت دیتی ہے، جو کلاؤڈ پر مبنی مانیٹرنگ سروس ہے۔ اس لائن کو شامل کرنے کے بعد، آپ کی ایپلیکیشن خود بخود ٹیلی میٹری ڈیٹا اکٹھا کرے گی جیسے درخواست کی شرح، رسپانس ٹائم، ناکامی کی شرح، اور انحصار کالز۔ یہ ٹیموں کو حقیقی وقت میں ایپلی کیشن کی صحت کی نگرانی کرنے اور تقسیم شدہ مائیکرو سروسز میں کارکردگی کی رکاوٹوں یا غلطیوں کی فوری شناخت کرنے کی اجازت دیتا ہے۔

حسب ضرورت میٹرکس

var telemetryClient = new TelemetryClient();
telemetryClient.TrackMetric("PatientsFetched", 1);

یہاں ہم مانیٹرنگ سسٹم کو کسٹم میٹرکس بھیجنے کے لیے ٹیلی میٹری کلائنٹ مثال استعمال کرتے ہیں۔ TrackMetric طریقہ عددی اقدار کو ریکارڈ کرتا ہے۔ اس صورت میں، ہم مریضوں کو لانے کی تعداد کا پتہ لگاتے ہیں۔

اس طرح کے حسب ضرورت میٹرکس آپ کو کاروبار کے لیے مخصوص آپریشنز کی پیمائش کرنے میں مدد کرتے ہیں اور اس بارے میں گہری بصیرت فراہم کرتے ہیں کہ آپ کے سسٹمز کو معیاری کارکردگی کے میٹرکس سے آگے کیسے استعمال کیا جا رہا ہے۔

صحت کی جانچ

app.MapHealthChecks("/health");

یہ لائن /health میں ہیلتھ چیک اینڈ پوائنٹ کو ظاہر کرتی ہے جسے بیرونی سسٹم اس بات کی تصدیق کے لیے استعمال کر سکتے ہیں کہ سروس صحیح طریقے سے چل رہی ہے۔ جب اس اختتامی نقطہ کو بلایا جاتا ہے، تو یہ ایپلیکیشن کی حالت اور کسی بھی ترتیب شدہ انحصار جیسے ڈیٹا بیس یا بیرونی خدمات کو لوٹاتا ہے۔

صحت کی جانچ عام طور پر لوڈ بیلنسرز، کنٹینر آرکیسٹریٹرز، اور مانیٹرنگ ٹولز میں خود بخود غلطیوں کا پتہ لگانے اور ضرورت پڑنے پر ٹریفک کو دوبارہ شروع کرنے یا دوبارہ روٹ کرنے کے لیے استعمال ہوتی ہے۔

لاگنگ، ٹیلی میٹری، کسٹم میٹرکس، اور ہیلتھ چیکس ایک مکمل مشاہداتی حکمت عملی فراہم کرنے کے لیے اکٹھے ہوتے ہیں۔ اس سے ٹیموں کو نظام کے رویے کو سمجھنے، مسائل کا جلد پتہ لگانے، اور تقسیم شدہ صحت کی دیکھ بھال کی خدمات میں بھروسہ برقرار رکھنے کی اجازت ملتی ہے جہاں اپ ٹائم اور کارکردگی اہم ہے۔

ڈوکر کے ساتھ کنٹینرائزیشن

کنٹینرائزیشن مائیکرو سروسز کو ترقی اور پیداوار میں الگ تھلگ اور مستقل ماحول میں چلانے کی اجازت دیتی ہے۔ ڈوکر آپ کو اپنی درخواست کو اس کے تمام انحصار کے ساتھ پیک کرنے کی اجازت دیتا ہے، پورٹیبلٹی اور آسان تعیناتی کو یقینی بناتا ہے۔ یہ نقطہ نظر اسکیلنگ اور انفراسٹرکچر مینجمنٹ کو آسان بناتا ہے۔

درج ذیل ڈاکر فائل مریض کی خدمت کو کنٹینر کی تصویر میں پیک کرنے کے لیے کم سے کم سیٹ اپ دکھاتی ہے۔

FROM mcr.microsoft.com/dotnet/aspnet:10.0
WORKDIR /app
COPY . .
ENTRYPOINT ["dotnet", "PatientService.dll"]

یہ ڈاکر فائل اس بات کی وضاحت کرتی ہے کہ کس طرح مریض کی خدمت کو کنٹینر امیج میں پیک کیا جاتا ہے تاکہ یہ مختلف ماحول میں مستقل طور پر چل سکے۔

کہ پر کمانڈ بیس امیج کی وضاحت کرتی ہے۔ اس صورت میں، یہ .NET 10 کے لیے آفیشل ASP.NET رن ٹائم امیج ہے۔ اس تصویر میں آپ کی ایپلیکیشن کو چلانے کے لیے درکار تمام ضروری رن ٹائم اجزاء شامل ہیں، لہذا آپ کو کنٹینر کے اندر .NET کو الگ سے انسٹال کرنے کی ضرورت نہیں ہے۔

کہ ورکڈائر/ایپ لائن کنٹینر کے اندر ورکنگ ڈائرکٹری سیٹ کرتی ہے۔ اس ڈائرکٹری کی نسبت بعد کے تمام کمانڈز پر عمل درآمد کیا جاتا ہے، جو آپ کی ایپلیکیشن فائلوں کو ایک متوقع ڈھانچے میں ترتیب دینے میں مدد کرتا ہے۔

کہ کاپی . کمانڈ مشین کی موجودہ پروجیکٹ ڈائرکٹری میں موجود تمام فائلوں کو کنٹینر کی ورکنگ ڈائرکٹری میں کاپی کرتی ہے۔ اس میں مرتب کردہ ایپلیکیشن بائنریز اور کوئی بھی مطلوبہ وسائل شامل ہیں۔

آخر کار داخلہ پوائنٹ اس کمانڈ کی وضاحت کرتا ہے جو کنٹینر شروع ہونے پر چلتا ہے۔ اس صورت میں، ہم PatientService ایپلیکیشن شروع کرنے کے لیے .NET رن ٹائم استعمال کرتے ہیں۔

ایک ساتھ، یہ اقدامات آپ کی مائیکرو سروس کو ایک پورٹیبل ڈیوائس میں پیک کرتے ہیں جسے ترقی، اسٹیجنگ، اور پیداواری ماحول میں مستقل طور پر تعینات کیا جا سکتا ہے۔ یہ یقینی بناتا ہے کہ آپ کی ایپلیکیشن یکساں برتاؤ کرتی ہے قطع نظر اس کے کہ اسے کہاں تعینات کیا گیا ہے، جو کہ مائیکرو سروسز فن تعمیر میں کنٹینرائزیشن کا کلیدی فائدہ ہے۔

تعیناتی کی حکمت عملی

مائیکرو سروسز کی تعیناتی کے لیے ڈاؤن ٹائم کو کم کرنے اور اپ ڈیٹس کے دوران خطرے کو کم کرنے کے لیے حکمت عملی کی ضرورت ہوتی ہے۔

رولنگ اپ ڈیٹس، کینری ریلیز، اور نیلے سبز کی تعیناتی جیسی تکنیکیں ہموار منتقلی کو یقینی بنانے میں مدد کرتی ہیں۔ یہ نقطہ نظر ریلیز کے دوران سسٹم کے استحکام اور صارف کے تجربے کو بہتر بناتا ہے۔

اہم حکمت عملی

مائیکرو سروسز کی تعیناتی کے لیے ڈاؤن ٹائم کو کم سے کم کرنے، خطرے کو کم کرنے اور نظام کے استحکام کو یقینی بنانے کے لیے حکمت عملی کی ضرورت ہوتی ہے۔ یہ صحت کی دیکھ بھال کے نظام میں خاص طور پر سچ ہے جہاں دستیابی اور ڈیٹا کی سالمیت اہم ہے۔

1. رولنگ اپ ڈیٹس

رولنگ اپ ڈیٹس ایک وقت میں ایک ہی وقت میں سروس کی مثالوں کو اپ ڈیٹ کر کے بتدریج تبدیلیاں متعین کرتی ہیں، نہ کہ ایک ساتھ۔ جیسا کہ ایک نیا ورژن تعینات کیا جاتا ہے، پرانی مثالیں مرحلہ وار ختم ہو جاتی ہیں، اس بات کو یقینی بناتے ہوئے کہ آپ کا سسٹم پورے عمل کے دوران دستیاب رہے۔

یہ نقطہ نظر بے وطن خدمات کے لیے موزوں ہے اور عام طور پر کنٹینر آرکیسٹریشن پلیٹ فارمز میں استعمال ہوتا ہے۔ یہ آپ کو مسلسل دستیابی کو یقینی بناتے ہوئے نئی خصوصیات کو محفوظ طریقے سے تعینات کرنے کی اجازت دیتا ہے۔

مندرجہ ذیل معاملات میں رولنگ اپ ڈیٹس کا بہترین استعمال کیا جاتا ہے:

• آپ صفر ڈاؤن ٹائم کے ساتھ تعیناتی چاہتے ہیں۔

• ورژن کے درمیان پیچھے کی طرف مطابقت برقرار ہے۔

• تبدیلی کا خطرہ نسبتاً کم ہے۔

2. کینری تعیناتی۔

کینری کی تعیناتیاں ہر کسی کو تقسیم کرنے سے پہلے سروس کا ایک نیا ورژن صارفین کے چھوٹے سب سیٹ کے لیے جاری کرتی ہیں۔ یہ ٹیم کو محدود نمائش کے ساتھ حقیقی دنیا کے ماحول میں نئے ورژن کے رویے کی نگرانی کرنے کی اجازت دیتا ہے۔

اگر کسی مسئلے کا پتہ چل جاتا ہے تو، زیادہ تر صارفین کو متاثر کیے بغیر تعیناتیوں کو تیزی سے واپس کیا جا سکتا ہے۔

کینری کی تعیناتیاں اس کے لیے مثالی ہیں:

• ہائی رسک یا پیچیدہ خصوصیات کو جاری کرنا

• حقیقی ٹریفک کے تحت کارکردگی کی جانچ

• بتدریج نئی خصوصیات کی تصدیق کریں۔

3. نیلے سبز تعیناتی

نیلے سبز کی تعیناتی میں دو ایک جیسے ماحول کو برقرار رکھنا شامل ہے: ایک موجودہ ورژن (نیلا) چلا رہا ہے اور دوسرا نیا ورژن (سبز) چلا رہا ہے۔ ایک بار جب نیا ورژن مکمل طور پر ٹیسٹ اور تیار ہو جائے گا، ٹریفک نیلے سے سبز ہو جائے گا۔

اگر کچھ غلط ہو جاتا ہے، تو آپ فوری طور پر ٹریفک کو پچھلے ورژن کی طرف موڑ سکتے ہیں۔

یہ حکمت عملی خاص طور پر مفید ہے جب:

• مجھے فوری رول بیک صلاحیت کی ضرورت ہے۔

• سسٹم کا استحکام ضروری ہے۔

• ڈاؤن ٹائم سے مکمل طور پر گریز کرنا چاہیے۔

ہیلتھ کیئر مائیکرو سروسز کے لیے صحیح حکمت عملی کا انتخاب

صحت کی دیکھ بھال کے پورٹلز کے لیے جہاں قابل اعتماد اور مریض کے ڈیٹا کی سالمیت ضروری ہے، نیلے سبز کی تعیناتیاں اکثر محفوظ ترین انتخاب ہوتی ہیں۔ یہ صارفین کو نئے ورژن جاری کرنے سے پہلے مکمل توثیق کی اجازت دیتا ہے اور غلطیوں کی صورت میں فوری رول بیک فراہم کرتا ہے۔

تاہم، پسماندہ مطابقت کو یقینی بنانے کے لیے عام طور پر روٹین اپ ڈیٹس کے لیے رولنگ اپ ڈیٹس کا استعمال کیا جاتا ہے، جب کہ نئی خصوصیات جیسے کہ AI تشخیص یا تجزیاتی ماڈیولز متعارف کرانے کے لیے کینری کی تعیناتیاں مفید ہوتی ہیں۔

مثال: کنٹینرز کا استعمال کرتے ہوئے نیلے سبز کی تعیناتی۔

آئیے کنٹینرز کا استعمال کرتے ہوئے ایک سادہ تصوراتی مثال دیکھیں۔

فرض کریں کہ آپ کے پاس دو ماحول ہیں:

پہلے، صارفین کو متاثر کیے بغیر موجودہ ورژن کے ساتھ نیا ورژن (v2) تعینات کریں۔

پھر ٹیسٹ چلائیں اور تصدیق کریں کہ نیا ورژن صحیح طریقے سے کام کر رہا ہے۔

پھر اپنے لوڈ بیلنسر یا API گیٹ وے کو نیلے رنگ سے سبز کی طرف جانے کے لیے اپ ڈیٹ کریں۔ اس کے بعد نظام کی غلطیوں یا کارکردگی کے مسائل کے لیے نگرانی کی جاتی ہے۔

اگر سب کچھ مستحکم ہے تو، فعال ماحول کے طور پر سبز رکھیں. اگر نہیں، تو اپنی ٹریفک کو فوری طور پر نیلے رنگ میں تبدیل کریں۔

حقیقی دنیا کی ترتیب میں، ٹریفک کے اس موڑ کو عام طور پر اس کے ذریعے سنبھالا جاتا ہے:

• API گیٹ وے

• لوڈ بیلنسر

• Kubernetes سروس

یہ نقطہ نظر اس بات کو یقینی بناتا ہے کہ آپ کی ٹیم کو تعیناتی کے خطرے پر مکمل کنٹرول فراہم کرتے ہوئے، آپ کے صارفین کو کوئی ڈاؤن ٹائم کا تجربہ نہ ہو۔

عملی طور پر، بہت سے پیداواری نظام ان حکمت عملیوں کو یکجا کرتے ہیں (مثال کے طور پر، کینری ریلیز سے شروع کرنا اور پھر رولنگ اپ ڈیٹس کے ساتھ تعیناتی کو مکمل کرنا) خطرے اور کارکردگی کو متوازن کرنے کے لیے۔

بہترین طرز عمل (بشمول مثالیں)

صحت کی دیکھ بھال کے نظام کے لیے قابل اعتماد مائیکرو سروسز ڈیزائن کرنے کے لیے ثابت شدہ نمونوں کو لاگو کرنے کی ضرورت ہوتی ہے جو بھروسے، برقرار رکھنے اور لچک کو بہتر بناتے ہیں۔ یہاں حقیقی دنیا کی مثالوں کے ساتھ کچھ اہم بہترین طرز عمل ہیں:

1. API ورژننگ کو فعال کریں۔

API ورژننگ آپ کی سروس کے تیار ہوتے ہی پسماندہ مطابقت کو یقینی بناتی ہے۔ صحت کی دیکھ بھال کے نظام میں جہاں بیرونی نظاموں (لیبارٹریز، انشورنس، EHR) کے ساتھ انضمام عام ہے، خلل ڈالنے والی تبدیلی اہم چیلنجوں کا باعث بن سکتی ہے۔

مثالوں میں شامل ہیں:

[Route("api/v1/patients")]

یہ پاتھ انتساب API کے بنیادی URL کی وضاحت کرتا ہے اور واضح طور پر ورژن شناخت کنندہ (v1) کو شامل کرتا ہے۔ ورژنز کو راستے میں داخل کرنے سے سروس کو ایک ہی API کے متعدد ورژنز کو بیک وقت سپورٹ کرنے کی اجازت ملتی ہے۔ یہ موجودہ کلائنٹس کو پرانے ورژنز کا استعمال جاری رکھنے کی اجازت دیتا ہے جبکہ مطابقت کو برقرار رکھتے ہوئے نئے ورژن متعارف کرائے جاتے ہیں۔

نئے ورژن بعد میں متعارف کرائے جا سکتے ہیں۔

[Route("api/v2/patients")]

یہ اسی API کے نئے ورژن کی نمائندگی کرتا ہے، ممکنہ طور پر اپ ڈیٹ کردہ فعالیت یا ساخت کے ساتھ۔ روٹنگ کی سطح پر ورژن کو الگ کر کے، ڈیولپرز کلائنٹس کو ہجرت کے لیے وقت دیتے ہوئے اپنے APIs کو محفوظ طریقے سے تیار کر سکتے ہیں۔

یہ نقطہ نظر صحت کی دیکھ بھال کے نظام میں خاص طور پر اہم ہے جہاں بیرونی انضمام کو طویل عرصے تک مستحکم رہنا چاہیے۔

یہ آپ کو محفوظ طریقے سے نئی خصوصیات جاری کرنے، میراثی کلائنٹس کی حمایت کرنے اور ورژن کے درمیان بتدریج منتقلی کو فعال کرنے کی اجازت دیتا ہے۔

2. دوبارہ کوشش کی پالیسی نافذ کریں۔

مائیکرو سروسز کے درمیان نیٹ ورک کالز عارضی مسائل، جیسے ٹائم آؤٹ یا عارضی سروس کی عدم دستیابی کی وجہ سے ناکام ہو سکتی ہیں۔ دوبارہ کوشش کرنے کی پالیسی آپ کو خود بخود ان خرابیوں سے بازیافت کرنے میں مدد کرتی ہے۔

یہاں ایک مثال ہے (پولی کا استعمال کرتے ہوئے):

services.AddHttpClient("api")
    .AddTransientHttpErrorPolicy(p => p.RetryAsync(3));

یہ کوڈ HTTP کلائنٹ کو دوبارہ کوشش کی پالیسی کے ساتھ ترتیب دینے کے لیے پولی، ایک .NET لچکدار اور عارضی غلطی سے نمٹنے والی لائبریری کا استعمال کرتا ہے۔ پولی ڈویلپرز کو ناقابل اعتماد نیٹ ورک کالز کو ہینڈل کرنے کے لیے دوبارہ کوششیں، سرکٹ بریکرز، اور ٹائم آؤٹ جیسی پالیسیوں کی وضاحت کرنے کی اجازت دیتی ہے۔

کہ AddTransientHttpErrorPolicy یہ طریقہ عارضی غلطیوں جیسے نیٹ ورک ٹائم آؤٹ یا سرور کی خرابیوں کے لیے دوبارہ کوشش کرنے کی حکمت عملی کا اطلاق کرتا ہے۔ کہ RetryAsync(3) کنفیگریشن کا مطلب ہے کہ اگر کوئی درخواست کسی عارضی مسئلے کی وجہ سے ناکام ہو جاتی ہے، تو غلطی کو واپس کرنے سے پہلے خود بخود تین بار دوبارہ کوشش کی جائے گی۔

یہ دستی مداخلت کے بغیر عارضی مسائل کو سنبھال کر نظام کے استحکام کو بہتر بناتا ہے۔

یہ کنفیگریشن ناکام ہونے سے پہلے تین بار تک ناکام درخواستوں کی دوبارہ کوشش کرتی ہے۔

آپ ایکسپونینشل بیک آف بھی شامل کر سکتے ہیں۔

.AddTransientHttpErrorPolicy(p =>
    p.WaitAndRetryAsync(3, retryAttempt =>
        TimeSpan.FromSeconds(Math.Pow(2, retryAttempt))));

یہ کنفیگریشن ایکسپونیشنل بیک آف متعارف کروا کر دوبارہ کوشش کرنے کے طریقہ کار کو بہتر بناتی ہے۔ فوری طور پر دوبارہ کوشش کرنے کے بجائے، سسٹم ہر دوبارہ کوشش کے درمیان آہستہ آہستہ طویل انتظار کرتا ہے۔

ایکسپونیشنل بیک آف کا مطلب ہے:

• پہلی دوبارہ کوشش 21 سیکنڈ انتظار کرتی ہے۔

• دوسری دوبارہ کوشش 2² سیکنڈ انتظار کرتی ہے۔

• تیسری دوبارہ کوشش 2³ سیکنڈ انتظار کرتی ہے۔

یہ نقطہ نظر ناکام خدمات پر بوجھ کو کم کرتا ہے اور خدمات کو بار بار درخواستوں سے مغلوب ہونے سے روکتا ہے۔ یہ خاص طور پر تقسیم شدہ نظاموں میں مفید ہے جہاں عارضی غلطیاں کثرت سے ہوتی ہیں اور سروس کو بحال کرنے کے لیے وقت درکار ہوتا ہے۔

یہ وشوسنییتا کو بہتر بنانے، عارضی غلطیوں کو کم کرنے، اور دستی دوبارہ کوششوں سے بچنے میں مدد کرتا ہے۔

3. ان پٹ کی توثیق کو نافذ کریں۔

آنے والے ڈیٹا کی تصدیق کرنا بہت ضروری ہے۔ یہ صحت کی دیکھ بھال کے نظام میں خاص طور پر درست ہے جہاں غلط اعداد و شمار کے سنگین نتائج ہو سکتے ہیں۔

مثالوں میں شامل ہیں:

if (string.IsNullOrEmpty(patient.Name))
    return BadRequest("Name is required");

یہ ایک سادہ دستی توثیق ہے جو اس بات کی تصدیق کرتی ہے کہ درخواست پر کارروائی کرنے سے پہلے نام کی فیلڈ فراہم کی گئی ہے۔ اگر قدر غائب یا خالی ہے، تو فوری طور پر API BadRequest غلط ڈیٹا کو سسٹم میں داخل ہونے سے روکنے کے لیے جواب دیں۔

ڈیٹا تشریحات کا استعمال کرنا ایک بہتر طریقہ ہے۔

public class Patient
{
    public int Id { get; set; }

    [Required]
    public string Name { get; set; }
}

اس مثال میں، ہم ماڈل کی سطح پر توثیق کے اصولوں کو لاگو کرنے کے لیے ڈیٹا تشریحات کا استعمال کرتے ہیں۔ کہ [Required] وصف اس بات کی ضمانت دیتا ہے کہ جب درخواست کی جائے تو نام کی خاصیت فراہم کی جانی چاہیے۔ ASP.NET درخواست کی کارروائی کے دوران ماڈلز کی خود بخود توثیق کرتا ہے اور اگر توثیق ناکام ہو جاتی ہے تو غلطی کا جواب دیتا ہے۔

یہ نقطہ نظر دستی معائنہ کے مقابلے میں زیادہ توسیع پذیر اور برقرار رکھنے کے قابل ہے، خاص طور پر بڑی ایپلی کیشنز کے لیے۔

یہ صاف اور درست ڈیٹا، کم رن ٹائم غلطیاں، اور بہتر API کی دستیابی کو یقینی بناتا ہے۔

4. سرکٹ بریکر پیٹرن کا استعمال کریں

سرکٹ بریکر پیٹرن جھرن کی ناکامیوں کو روکتا ہے جب منحصر خدمات کم یا سست ہوجاتی ہیں۔

مثال کے طور پر، اگر اپوائنٹمنٹ سروس دستیاب نہیں ہے، تو مریض کی خدمات سے بار بار کالیں سسٹم کو مغلوب کر سکتی ہیں۔ سرکٹ بریکر ان کالوں کو عارضی طور پر روک دیتے ہیں۔

یہاں ایک مثال ہے (دوبارہ پولی کا استعمال کرتے ہوئے):

services.AddHttpClient("api")
    .AddTransientHttpErrorPolicy(p =>
        p.CircuitBreakerAsync(5, TimeSpan.FromSeconds(30)));

اس کا مطلب ہے:

• مسلسل 5 ناکامیوں کے بعد سرکٹ کھل جاتا ہے۔

• 30 سیکنڈ تک مزید درخواستیں نہیں بھیجی جائیں گی۔

• اس سے سسٹم کو ٹھیک ہونے کا وقت ملتا ہے۔

یہ نظام کے استحکام کی حفاظت، وسائل کی تھکن کو روکنے اور مجموعی لچک کو بہتر بنانے میں مدد کرتا ہے۔

یہ طرز عمل اس بات کو یقینی بناتے ہیں کہ مائیکرو سروسز پسماندہ مطابقت (ورژننگ)، لچکدار (دوبارہ کوششیں + سرکٹ بریکرز)، اور قابل اعتماد (توثیق) ہیں۔

صحت کی دیکھ بھال کے نظام میں ان نمونوں کا اطلاق ضروری ہے جہاں اپ ٹائم اور ڈیٹا کی سالمیت اہم ہے۔

یہ کوڈ پولی کو ایک سرکٹ بریکر پالیسی ترتیب دینے کے لیے استعمال کرتا ہے تاکہ بیرونی خدمات کو کال کرتے وقت نظام کو بار بار کی غلطیوں سے بچایا جا سکے۔

کہ CircuitBreakerAsync(5, TimeSpan.FromSeconds(30)) کنفیگریشن کا مطلب ہے کہ اگر مسلسل پانچ درخواستیں ناکام ہو جاتی ہیں تو سرکٹ کھل جاتا ہے اور مزید درخواستوں کو 30 سیکنڈ کے لیے روک دیتا ہے۔ اس وقت کے دوران، سسٹم کسی ناکام سروس کالز کی کوشش نہیں کرے گا، لہذا بحالی میں وقت لگے گا۔

بندش کی مدت کے بعد، سرکٹ نیم کھلی حالت میں ہے جہاں محدود تعداد میں درخواستوں کو جانچنے کی اجازت ہے کہ آیا سروس بحال ہو گئی ہے۔ کامیاب ہونے کی صورت میں معمول کا آپریشن دوبارہ شروع ہو جائے گا۔ ورنہ سرکٹ دوبارہ کھل جائے گا۔

یہ پیٹرن جھرن کی غلطیوں کو روکتا ہے، ناکام خدمات پر غیر ضروری بوجھ کو کم کرتا ہے، اور نظام کی مجموعی لچک کو بہتر بناتا ہے۔

یہ مثالیں بتاتی ہیں کہ کس طرح چھوٹے ڈیزائن کے فیصلے (جیسے ورژن بنانا، دوبارہ کوشش کرنا، توثیق، اور غلطی سے نمٹنے) مائیکرو سروسز کی وشوسنییتا اور برقراری کو نمایاں طور پر بہتر بنا سکتے ہیں۔ یہ خاص طور پر صحت کی دیکھ بھال کے نظام میں درست ہے جہاں غلطیاں سنگین نتائج کا باعث بن سکتی ہیں۔

مائیکرو سروسز کب استعمال نہ کریں۔

مائیکرو سروسز طاقتور ہیں، لیکن یہ ایک عالمگیر حل نہیں ہیں۔ بہت سے معاملات میں، مائیکرو سروسز کو بہت جلد اپنانا کسی حقیقی مسئلے کو حل کرنے کے بجائے غیر ضروری پیچیدگیاں پیدا کر سکتا ہے۔

اس فن تعمیر کو منتخب کرنے سے پہلے، یہ سمجھنا ضروری ہے کہ ایک آسان طریقہ، جیسے کہ یک سنگی، کب زیادہ مناسب ہے۔

1. جب درخواست چھوٹی ہو۔

اگر آپ کی ایپلی کیشن میں محدود فعالیت ہے (جیسے کہ مریض کا بنیادی رجسٹریشن سسٹم یا اندرونی ٹولز)، تو اسے متعدد خدمات میں تقسیم کرنے سے غیر ضروری اوور ہیڈ بڑھ جاتا ہے۔

یک سنگی فن تعمیر آپ کو کم سیٹ اپ کے ساتھ تیزی سے ترقی کرنے، مسائل کو زیادہ آسانی سے ڈیبگ کرنے، اور متعدد تعیناتیوں کو منظم کرنے کی ضرورت کو ختم کرنے کی اجازت دیتا ہے۔

ہاں: یہ ایک سادہ میڈیکل پورٹل ہے جو صرف مریض کے اندراج اور طبی تقرری کے تحفظات کی اجازت دیتا ہے، اور ہر فنکشن کے لیے علیحدہ خدمات کی ضرورت نہیں ہے۔

2. جب ٹیم کا سائز محدود ہو۔

جب ٹیم کا سائز محدود ہو تو مائیکرو سروسز مشکل ہو سکتی ہیں۔ متعدد کوڈ بیسز کا انتظام، سروس مواصلات کو سنبھالنا، اور تعیناتی اور نگرانی ترقی کو سست کر سکتی ہے اور چھوٹی ٹیموں کے لیے پیچیدگی کو سنبھالنا مشکل بنا سکتی ہے۔

ہاں: دو یا تین ڈویلپرز کی ایک ٹیم اگر مائیکرو سروسز کو ابتدائی طور پر اپنایا جائے تو فنکشنلٹی بنانے کے بجائے انفراسٹرکچر کا انتظام کرنے میں زیادہ وقت صرف کر سکتا ہے۔

3. جب تعیناتی کی پیچیدگی فوائد سے بڑھ جاتی ہے۔

مائیکرو سروسز آپریشنل پیچیدگی کو متعارف کراتی ہیں، بشمول API گیٹ ویز، سروس کی دریافت، کنٹینر آرکیسٹریشن (مثلاً Kubernetes)، اور سروس وائڈ مانیٹرنگ اور لاگنگ۔

اگر آپ کی درخواست کو آزاد اسکیلنگ یا بار بار تعیناتی کی ضرورت نہیں ہے، تو اس پیچیدگی کا جواز نہیں ہو سکتا۔

ہاں: Monoliths اکثر زیادہ کارآمد ہوتے ہیں جب سسٹم کے تمام اجزاء ایک ساتھ پیمانے اور اپ ڈیٹ ہوتے ہیں۔

4. جب ڈومین کی حدود واضح نہ ہوں۔

مائیکرو سروسز اچھی طرح سے طے شدہ سروس کی حدود پر انحصار کرتی ہیں۔ اگر ڈومین کو واضح طور پر نہیں سمجھا جاتا ہے، تو بہت جلد سروسز میں تقسیم ہو جانے سے سروسز کے درمیان سخت جوڑے، سروسز کے درمیان بار بار تبدیلیاں، اور خراب ڈیزائن کردہ APIs کا باعث بن سکتا ہے۔

ان صورتوں میں، ایک بہتر طریقہ یہ ہے کہ یک سنگی کے ساتھ شروع کیا جائے اور اسے بعد میں ری ایکٹر کیا جائے۔

5. DevOps اور مشاہداتی پختگی کی کمی ہے۔

مائیکرو سروسز کے لیے ایک مضبوط DevOps اپروچ کی ضرورت ہوتی ہے، بشمول CI/CD پائپ لائنز، سنٹرلائزڈ لاگنگ، ڈسٹری بیوٹڈ ٹریسنگ، مانیٹرنگ، اور الرٹنگ۔ اس کے بغیر، ڈیبگنگ کے مسائل بہت مشکل ہو جاتے ہیں۔

مستقبل میں بہتری

صحت کی دیکھ بھال کے نظام تیزی سے تیار ہو رہے ہیں، اور مائیکرو سروسز فن تعمیر نئی صلاحیتوں کو سپورٹ کرنے کے لیے ڈھال سکتے ہیں۔ مستقبل کی بہتری میں شامل ہیں:

1. واقعہ سے چلنے والا فن تعمیر

واقعہ پر مبنی نقطہ نظر کو اپنانا خدمات کو براہ راست درخواستوں کے بجائے واقعات کے ذریعے متضاد طور پر بات چیت کرنے کی اجازت دیتا ہے۔ اس سے اسکیل ایبلٹی، ردعمل، اور غلطی کی رواداری میں بہتری آتی ہے، جس سے متعدد سروسز میں بڑی مقدار میں مریضوں کے ڈیٹا اور ریئل ٹائم اپ ڈیٹس کو سنبھالنا آسان ہوجاتا ہے۔

2. AI پر مبنی تشخیص

AI اور مشین لرننگ کو یکجا کرنے سے مریض کے ڈیٹا کا تجزیہ کرکے، پیٹرن کا پتہ لگا کر، اور پیش گوئی کرنے والی بصیرت فراہم کرکے تشخیصی صلاحیتوں کو بہتر بنایا جا سکتا ہے۔ اس سے طبی فیصلہ سازی کو بہتر بنانے اور ہیلتھ کیئر پورٹل کے اندر ورک فلو کو ہموار کرنے میں مدد ملتی ہے۔

3. FHIR معیار کے ساتھ انضمام

فاسٹ ہیلتھ کیئر انٹرآپریبلٹی ریسورسز (FHIR) کے معیار کے لیے سپورٹ مختلف ہیلتھ کیئر سسٹمز، لیبارٹریز اور تھرڈ پارٹی ایپلی کیشنز کے درمیان بغیر کسی رکاوٹ کے ڈیٹا کے تبادلے کو قابل بناتا ہے۔ معیاری APIs بیرونی پلیٹ فارمز کے ساتھ بہتر انٹرآپریبلٹی، تعمیل اور آسان انضمام کو یقینی بناتے ہیں۔

4. حقیقی وقت کا تجزیہ

ریئل ٹائم تجزیات صحت کی دیکھ بھال فراہم کرنے والوں کو مریضوں کے ڈیٹا، سسٹم کی کارکردگی، اور آپریشنل میٹرکس کی مسلسل نگرانی کرنے کی اجازت دیتا ہے۔ یہ فعال فیصلہ سازی، اسامانیتاوں کا جلد پتہ لگانے، اور دیکھ بھال کے مجموعی معیار کو بہتر بنانے میں مدد کرتا ہے۔

نتیجہ

مائیکرو سروسز پر مبنی REST API کی ترقی قابل توسیع اور محفوظ صحت کی دیکھ بھال کے پورٹلز کی تعمیر کے لیے ایک مضبوط بنیاد فراہم کرتی ہے۔ ایپلی کیشنز کو آزاد خدمات میں تقسیم کرکے، ٹیمیں بہتر اسکیل ایبلٹی، تیز تر تعیناتی، اور بہتر فالٹ آئسولیشن حاصل کر سکتی ہیں۔

تاہم، مائیکرو سروسز کو اپنانا صرف ایک تکنیکی تبدیلی نہیں ہے، بلکہ ایک تعمیراتی اور آپریشنل کوشش ہے۔ ڈویلپرز کو چھوٹی شروعات کرنی چاہیے، واضح سروس کی حدود کی نشاندہی کرنی چاہیے، اور آہستہ آہستہ سسٹم کو تیار کرنا چاہیے۔

آپ کی ایپلیکیشنز بڑھنے کے ساتھ ہی سیکیورٹی کو مضبوط بنانے، مشاہداتی صلاحیت کو بہتر بنانے اور خودکار تعیناتی پر توجہ دیں۔ یہ طرز عمل اس بات کو یقینی بناتا ہے کہ صحت کی دیکھ بھال کے پلیٹ فارم مستحکم، مطابقت پذیر، اور کلاؤڈ مقامی ماحول میں پیمانے کے لیے تیار ہیں۔

اگلے مرحلے میں پہلی مائیکرو سروسز بنانا، کنٹینرز کا استعمال کرتے ہوئے انہیں تعینات کرنا، اور آہستہ آہستہ نظام کو مکمل طور پر تقسیم شدہ صحت کی دیکھ بھال کے پلیٹ فارم میں ڈھالنا ہے۔