Fahim Shariar Shoumik

Backend Engineer | Golang Specialist | Distributed Systems Architect

Dhaka, Bangladesh
Fahim Shariar Shoumik

About

Tech entrepreneur and backend specialist with 10+ years of experience building scalable systems using Golang, gRPC, and Docker-based microservices. Proven leadership in startups and developer platforms. Passionate about API-first design, plugin-based extensibility, and headless CMS architectures. Currently building Apito.io, an API development platform. Past projects include FHIR-compliant EHR systems, DevOps consulting, and open-source tooling.

Back to Blog

মাইক্রোসার্ভিস আর্কিটেক্টচার – পর্ব ১

MicroservicesArchitectureBengali

কি ?

মাইক্রোসার্ভিস আর্কিটেক্টচার হল এক ধরনের সফটওয়্যার ডেভেলপমেন্ট মেথড ।  মাইক্রোসার্ভিসে, পুরো সার্ভিসকে অথবা একটা বড় অ্যাপ্লিকেশনকে অনেক গুলো ছোট ছোট সার্ভিসে ভাগ করা হয় যেখানে প্রত্যেক সার্ভিস একটা নির্দিষ্ট কাজ করে । এটা অনেকটা ইউনিক্স(Unix) স্ট্যান্ডার্ডের মত । এর আগে হয়ত SOA সম্বন্ধে অনেক যায়গায় শুনে থাকতে পারেন , এটা অনেকটা সার্ভিস ওরিয়েন্টেড আর্কিটেকচারের মতই। প্রত্যেকটা সার্ভিস কাজ অনুযায়ী ভাগ করার পরে সার্ভিস গুলো কিভাবে একে অপরের সাথে যোগাযোগ করবে এটা সাধারণত অ্যাপলিকেশনের ধরনের উপরে নির্ভর করে সাধারণত সেটা হয় RestFUL API, RPC নয়তো Message BUS এর মাধ্যমে ।

মাইক্রোসার্ভিস আর্কিটেক্টচার

মাইক্রোসার্ভিস আর্কিটেক্টচার

কেন ?

মাইক্রোসার্ভিসের প্রথম সুবিধাটা হল স্কেলিং (Scaling) অর্থাৎ যখন আপনার অ্যাপ্লিকেশান অনেকগুলো লোড নেওয়া শুরু করবে তখন লোড নিতে নিতে হয়ত কোন একসময় আপনার অ্যাপ্লিকেশান ক্রাশ ও করতে পারে । আপনি হয়ত এটার হাত থেকে বাঁচার জন্য সার্ভারের CPU Core আরও বাড়াবেন , নয়তবা আরও Extra Ram ইন্সটল করবেন । এই পধতি টাও ঠিক আছে কিন্তু এটাতে অনেক অসুবিধা আছে , এটাকে সাধারণত Vertical Scaling বলে ।

Vertical Scaling এর প্রধান অসুবিধা হল যেহুতু পুরো অ্যাপ্লিকেশানটা একটা বড় সার্ভারে আছে তাই Single Point of Failure হতে পারে অর্থাৎ যদি মেশিনে কিছু অসুবিধা হয় তাহলে পুরো অ্যাপ্লিকেশানটাই কাজ করবে না আর এক না এক সময় কিছু ঘাটতি কারণে(Costing) হয়ত অত বড় সার্ভার চালানো সম্ভব হবে না ।

তাহলে চিন্তা করুন আপনার অ্যাপ্লিকেশানটা পুরোটাই এক সাথে না থেকে যদি প্রত্যেকটা অংশ চাহিদা অনুসারে অনেক অংশে ভাগ ভাগ করা থাকত,  বিভিন্ন মেশিনে কিন্তু সবগুলো মিলিয়ে কাজ করত একটা বড় অ্যাপ্লিকেশান এর মত । এখান থেকেই মাইক্রোসার্ভিসের জন্ম । অর্থাৎ আপনার অ্যাপ্লিকেশানটা পুরোটাই একসাথে না থেকে প্রত্যেকটা অংশ চাহিদা অনুসারে অনেক অংশে ভাগ ভাগ করা থাকবে এবং সবগুলো একে অপরের সাথে যোগাযোগ করবে এবং শেষে একটা হয়ে ফলাফল দেবে !

অনেক অংশে ভাগ ভাগ করার কারণে Single Point of Failure হবার সম্ভাবনা নেই । এবং চাহিদা মত আপনি বিভিন্ন সার্ভিসকে বিভিন্ন ক্ষমতা দিতে পারেন , উদাহরন স্বরূপ আপনার একটা বড় ই-কমার্স ওয়েবসাইট আছে , আপনি সেটাকে বিভিন্ন মাইক্রোসার্ভিসের ভাগ করেছেন অর্থাৎ ধরুন,

  1. একটা সার্ভিস সব প্রোডাক্ট ক্রেতাদেরকে দেখায় ,
  2. একটা সার্ভিস তারা কি কি পছন্দ করছে সেটার হিস্ট্রি রাখছে ,
  3. একটা সার্ভিস তাদের সার্চ অনুসারে ফলাফল দেখাচ্ছে ,
  4. একটা সার্ভিস অর্ডার নেওয়ার কাজ করছে এবং
  5. একটা সার্ভিস তাদের লেনদেনের হিসাব রাখছে ।

এখন আপনি লক্ষ্য করলেন যে এসব সার্ভিসের মধ্যে ১ ও ৩ সার্ভিস বেশি ব্যাবহার হচ্ছে , তাহলে আপনার শুধু ওইগুলো সার্ভিসকেই বেশি ক্ষমতা অর্থাৎ  (CPU & RAM) দেওয়া উচিত । এখন আপনি সেটা করতে পারবেন । অবং এ অবস্থায় একটা সার্ভিস বিভিন্ন লোকেশানে চালু করা যেতে পারে যদি দেখেন যে ওই লোকেশান থেকে আপনার গ্রাহক বেশি আসছে । আমাদের দেশে এখনো এলাকা ভিত্তিতে কোন ডাটা সেন্টের নেই তাই এলাকা ভিত্তিতে সার্ভিস চালু করার কোন উপায় নেই কিন্তু বিদেশে বড় বড় কোম্পানিগুলো এই কাজই করে । যখন তারা দেখে যে নিউইয়র্ক এর থেকে লসআঞ্জালেসে তাঁদের গ্রাহক বেশি তখন তারা একটা সার্ভিসের অনেক গুলো মেশিন ওই জিওগ্রাফিক লোকেশানে চালু করে যাতে সার্ভিসগুলো ওখানকার লোড সামলাতে পারে । একটা সার্ভিসের বিভিন্ন মেশিন কোনটা কখন ব্যবহার হবে সেই কাজটি যেই সার্ভিস করে থাকে তাকে বলে  Load Balancer । Load Balancer এর সম্বন্ধে আমরা বিস্তারিত পরের পর্বে  আলোচনা করব ।

Reference

https://smartbear.com/learn/api-design/what-are-microservices/
https://www.nginx.com/blog/introduction-to-microservices/
https://auth0.com/blog/introduction-to-microservices-part-4-dependencies/
https://dzone.com/articles/do-you-need-a-microservices-architecture