Tag: মাইক্রোসার্ভিস

28Aug

মাইক্রোসার্ভিস কেন ? কখন ? কিভাবে ? | পর্ব ২

মাইক্রোসার্ভিস আর্কিটেকচার, শুনে অনেক ভাল লাগলেও আগে জানতে হবে কখন কেন এবং কোথায় এটার ব্যবহার  ।  না  বুঝে এই আর্কিটেকচার  গ্রহণ করলে লাভের থেকে ক্ষতি হবে বেশি । শুধু মানুষের কাছ থেকে শুনে , অনেকে করছে বলে আমাদের কেও করতে হবে ব্যাপারটা এরকম করা যাবে না । অনেক প্রোজেক্ট আছে যেসব মনলিথ থাকলেই ভাল মাইক্রোতে যাবার দরকার পরে না , গেলে অনেক কাজ করতে হয় যেটা ওই প্রোজেক্টের জন্য অনেক OverKill । তাই আগে জানা উচিত কেন অমি এই আর্কিটেকচার অবলম্বন করব ও কখন ?

প্রথমে, প্রয়জনিতা বুজুন 

আগে চিন্তা করেনিন যে আপনি যে প্রোজেক্টটা বানাবেন অথবা আপনার এখন যে প্রোজেক্ট আছে যার জন্য মাইক্রোসার্ভিসের কথা ভাবছেন সেটা এই আর্কিটেকচার অবলম্বনে কতটা সুফল আসতে পারে , আমার কি পরে কোন সুবিধা হবে ? আর আমার বিদ্যমান টিম কি নতুন এই আর্কিটেকচারের সাথে খাপ খাওয়াতে পারবে ?

তবে নীচের দিক গুলো যদি কোন প্রোজেক্ট এ থাকে তাহলে মাইক্রোসার্ভিস ব্যবহার করলে প্রবর্তিতে অনেক সুবিধা পাওয়া জেতে পারে ! যেমন,

  • অ্যাপ্লিকেশানের গ্রাহক অনেক বেশি যারা কিনা প্রতিদিন অ্যাপটা ব্যবহার করে ।
  • অ্যাপ যদি কোন সামাজিক যোগাযোগের ওয়েবসাইট মত হয় ।
  • যদি অ্যাপটি বিগ ডাটার সাথে সম্পর্ক থাকে আর গবেষণার এক পর্যায়ে ডাটা বাড়লে আপনাকে অতিতিক্ত CPU & RAM সংযোগ করতে হতে পারে।
  • যদি অ্যাপটির ডেভ্লপমেন্ত আর রিলিস চক্রে যদি Agile Development Stategy  মানা হয়, সোজা ভাষায় বললে, যদি আপনি চান যে, আপনার প্রোজেক্টের ছোট ছোট পরিবর্তনও দ্রুত আপনার গ্রাহকদের কাছে পৌঁছাক এবং তাঁদের চাহিদা মোতাবেক আপনি আপনার সার্ভিস ও সারভারের ক্ষমতা বাড়াতে কমাতে চান ।
  •  আরও অনেক  ……

আগে মনলিথ তারপর মাইক্রো

একটা প্রোজেক্টের শুরু থেকেই মাইক্রোসার্ভিস আর্কিটেকচার অবলম্বন করার কথা চিন্তা করা ঠিক না । তবে টিমে দক্ষ মেম্বার থাকলে করা যেতে পারে, মাইক্রোসার্ভিস অবলম্বনের কি কি জটিলতার আসতে পারে তা সঠিক না জেনে মাইক্রোসার্ভিসে যাওয়ার জন্য আমি নিজেই পরামর্শ দিব না !

যদিও প্রোজেক্টের শুরুতে এটা বলা খুব কঠিন যে কি কি সার্ভিস লাগতে পারে, কিন্তু যদি প্রোজেক্টে একের পরে এক প্ররিবরতন আসে তাহলে যেগুলো পরিবর্তন হচ্ছে না সেগুলো এক একটা সার্ভিসের আওতায় নেও যেতে পারে , তবে এখানে খেয়াল রাখতে হবে যে প্রত্যেক সার্ভিস জেন স্বাধীন কাজ করতে পারে , যদি একটা সার্ভিস আর একটা সার্ভিসের উপড়ে নির্ভর হয়ে পরে তাহলে API Gateway প্যাটার্ন ফলো করতে হবে, েসব নিয়ে পরের পর্বে আশাকরি আলোচনা করব ।

তবে আগে মনলিথ তারপরে মাইক্রোতে যাওয়া উচিত। অর্থাৎ আপনি প্রোজেক্ট আগে পুরোটাই সব সার্ভিস একসাথে করে ফেলা উচিত, যেমনটা সাধারণত আমারা করি ভিবিন্ন ফ্রেমওয়ার্ক ব্যবহার করে । এর পরেই মোটামটি যেগুলো আলাদা ভাবে কাজ করতে সক্ষম বা অতিরিক্ত সংযোগ অ্যাপে সেগুলো মাইক্রোতে নিয়ে যাওয়া উচিত, যেমন যদি একটা ই-কমার্স অ্যাপের কথা চিন্তা করি তাহলে, Search, Recomendation Engine, Order, Operation সব আলাদা আলাদা মাইক্রোসার্ভিসে ভাগ করা উচিত ।

 

সময় হলে এর পরের পর্বে মাইক্রোসার্ভিস প্যাটার্ন ও অ্যান্টি-প্যাটার্ন নিয়ে লিখব ……

25Jun

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

কি ?

মাইক্রোসার্ভিস আর্কিটেক্টচার হল এক ধরনের সফটওয়্যার ডেভেলপমেন্ট মেথড ।  মাইক্রোসার্ভিসে, পুরো সার্ভিসকে অথবা একটা বড় অ্যাপ্লিকেশনকে অনেক গুলো ছোট ছোট সার্ভিসে ভাগ করা হয় যেখানে প্রত্যেক সার্ভিস একটা নির্দিষ্ট কাজ করে । এটা অনেকটা ইউনিক্স(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

© Copyright 2017 shoumik.me, All Rights Reserved