Service Discovery ও Service Mesh: যোগাযোগ ও policy

এই পাঠে যা শিখবেন

• Service discovery ও traffic proxy আলাদা করা
• Control plane ও data plane-এর responsibility বোঝা
• mTLS-এর সঙ্গে application authorization বজায় রাখা

সমস্যা দিয়ে শুরু

Laravel order service inventory service-কে call করে। দশ team নিজেদের timeout, certificate ও retry configuration আলাদা লিখছে। Central traffic policy দরকার, তাই service mesh বিবেচনা করা হলো। Mesh যোগ করলেই duplicate payment, wrong tenant access বা database transaction নিজে ঠিক হয় না। প্রথমে repeated infrastructure concern কোনটি এবং existing platform capability যথেষ্ট কি না দেখুন; ছোট monolith-এ mesh অপ্রয়োজনীয় operational burden হতে পারে।

সহজ করে বুঝি

Service discovery service name থেকে eligible endpoints খুঁজে দেয়। Mesh data plane proxy traffic-এর পথে routing, transport security এবং telemetry policy কার্যকর করতে পারে। Control plane proxy-কে configuration ও identity material সরবরাহ করে। Sidecar mode-এ app-এর পাশে proxy থাকে; সব mesh architecture sidecar-ভিত্তিক নয়। mTLS দুই workload-এর transport identity verify করে, end-user invoice দেখার permission নয়।

পরিচিত একটি উপমা

একটি courier network-এর branch directory discovery-এর মতো। Local dispatch desk actual parcel চালায়—data plane। Head office route rule ও identity policy পাঠায়—control plane। Uniform badge থাকলেই parcel-এর private content পড়ার অনুমতি হয় না।

নকশাটি দেখুন

flowchart TD
 C[Mesh control plane] -.-> P1[Workload proxy A]
 C -.-> P2[Workload proxy B]
 A[Laravel order app] --> P1
 P1 -->|mTLS transport| P2
 P2 --> B[Inventory app]
 D[Service discovery] -.-> C
 B --> R[Resource authorization]

Discovery endpoint state control configuration-এ পৌঁছায়। Control plane proxies-কে routes, certificates এবং policies দেয়। Request app থেকে local proxy, encrypted peer path পেরিয়ে destination app-এ যায়। Destination business authorization করে। Control plane unavailable হলে existing data-plane behavior product/config অনুযায়ী চলতে পারে, কিন্তু update ও certificate lifecycle প্রভাবিত হয়; universal behavior ধরে নেবেন না।

PHP ও Laravel-এ প্রয়োগ

Laravel inventory client fragment; inventory service name cluster DNS/discovery-তে resolvable এবং network mesh-এর আওতায়। Timeout application deadline-এর অংশ, proxy policy-এর সঙ্গে মিলতে হবে। Mutation নয় বলে GET example। mTLS থাকলেও incoming service identity এবং user/tenant policy server যাচাই করবে; user-controlled headers বিশ্বাস করবে না।

use Illuminate\Support\Facades\Http;
$response = Http::connectTimeout(1)->timeout(3)
    ->acceptJson()
    ->get(config('services.inventory.base_url').'/availability', [
        'product_id' => $productId,
    ]);
$response->throw();
$availability = $response->json();

সুবিধা, সীমাবদ্ধতা ও trade-off

Mesh consistent transport policy, traffic splitting ও telemetry সহজ করতে পারে। বিনিময়ে proxy CPU/memory, extra hop, config complexity এবং upgrade responsibility যোগ হয়। App এবং proxy উভয় retry করলে amplification হয়। Central policy ভুলে অনেক service একসঙ্গে আক্রান্ত হতে পারে; staged rollout ও validation দরকার। Built-in platform discovery/mTLS sufficient হলে mesh ছাড়া simpler design ভালো হতে পারে।

সাধারণ ভুল

• mTLS-কে tenant/resource authorization-এর বিকল্প ধরা।
• App, gateway ও mesh-এ অজান্তে retry multiply করা।
• সব traffic intercept হচ্ছে যাচাই না করে coverage দাবি করা।

আরও একটু গভীরে

Traffic bypass, external egress এবং non-HTTP protocol coverage review করুন। Permissive migration mode strict authentication enforce নাও করতে পারে; actual policy verify করুন। Workload identity credential rotation ও expired certificate recovery পরীক্ষা করুন। Mesh access logs sensitive URL/header রাখতে পারে। Control-plane blast radius সীমিত করতে namespace/config scope ব্যবহার করুন। Observability দিয়ে proxy latency এবং application latency আলাদা দেখতে হবে।

মনে রাখুন

Mesh network concern standardize করে; data correctness, user permission ও retry budget application-level design-এর অংশই থাকে।

নিজে চেষ্টা করুন

এক order-to-inventory call-এর discovery, proxy, mTLS এবং policy path আঁকুন। App তিন attempt এবং proxy তিন attempt করলে worst-case কাজ হিসাব করুন। Certificate expiry ও control-plane outage staging test-এর expected behavior লিখুন।

নিজের বোঝা যাচাই করুন

1. Discovery ও mesh এক?

না। Discovery endpoint খুঁজে দেয়; mesh traffic path-এ policy enforce করতে পারে। দুটো সম্পর্কিত হলেও responsibility আলাদা।

2. Control plane request বহন করে?

সাধারণ model-এ configuration দেয়; actual traffic data-plane proxies বহন করে। Product architecture দেখে নিশ্চিত করুন।

3. সব mesh sidecar?

না। Sidecar একটি deployment pattern; ambient বা অন্য data-plane architecture-ও আছে। Version-specific docs দেখুন।

4. mTLS invoice permission দেয়?

না। Workload identity ও encryption user/resource authorization নয়। Destination application policy বজায় থাকবে।

5. Mesh নেওয়ার আগে কী মাপব?

Repeated concern, operational capacity, latency/resource overhead এবং simpler platform alternative। Tool trend requirement নয়।

আরও পড়ুন

• Istio traffic management
• Istio security
• Laravel HTTP client