মনোলিথ থেকে মাইক্রোসার্ভিসেসে রূপান্তর: ইতিহাস এবং অনুশীলন

এই নিবন্ধে, আমি যে প্রকল্পে কাজ করছি তা কীভাবে একটি বৃহৎ মনোলিথ থেকে মাইক্রোসার্ভিসেসের একটি সেটে রূপান্তরিত হয়েছে সে সম্পর্কে কথা বলব।

প্রকল্পটি তার ইতিহাস বেশ দীর্ঘকাল আগে, 2000 এর শুরুতে শুরু হয়েছিল। প্রথম সংস্করণগুলি ভিজ্যুয়াল বেসিক 6-এ লেখা হয়েছিল। সময়ের সাথে সাথে, এটি স্পষ্ট হয়ে ওঠে যে এই ভাষার বিকাশ ভবিষ্যতে সমর্থন করা কঠিন হবে, যেহেতু IDE এবং ভাষা নিজেই খারাপভাবে উন্নত হয়. 2000 এর দশকের শেষে, আরও প্রতিশ্রুতিশীল C#-এ স্যুইচ করার সিদ্ধান্ত নেওয়া হয়েছিল। নতুন সংস্করণটি পুরানোটির সংশোধনের সাথে সমান্তরালভাবে লেখা হয়েছিল, ধীরে ধীরে আরও বেশি কোড লেখা হয়েছে .NET-এ। C#-এ ব্যাকএন্ড প্রাথমিকভাবে একটি পরিষেবা আর্কিটেকচারের উপর দৃষ্টি নিবদ্ধ করা হয়েছিল, কিন্তু বিকাশের সময়, যুক্তি সহ সাধারণ লাইব্রেরিগুলি ব্যবহার করা হয়েছিল এবং পরিষেবাগুলি একক প্রক্রিয়ায় চালু করা হয়েছিল। ফলাফল হল একটি অ্যাপ্লিকেশন যাকে আমরা "পরিষেবা মনোলিথ" বলে অভিহিত করেছি।

এই সংমিশ্রণের কয়েকটি সুবিধার মধ্যে একটি হল একটি বহিরাগত API এর মাধ্যমে একে অপরকে কল করার পরিষেবাগুলির ক্ষমতা। আরও সঠিক পরিষেবা এবং ভবিষ্যতে, মাইক্রোসার্ভিস আর্কিটেকচারে রূপান্তরের জন্য স্পষ্ট পূর্বশর্ত ছিল।

আমরা 2015 সালের দিকে পচন ধরে আমাদের কাজ শুরু করি। আমরা এখনও একটি আদর্শ অবস্থায় পৌঁছতে পারিনি - এখনও একটি বড় প্রকল্পের কিছু অংশ রয়েছে যেগুলিকে খুব কমই মনোলিথ বলা যেতে পারে, তবে সেগুলি মাইক্রোসার্ভিসের মতোও দেখায় না। তবুও, অগ্রগতি উল্লেখযোগ্য।
আমি নিবন্ধে এটি সম্পর্কে কথা বলতে হবে.

সন্তুষ্ট

• স্থাপত্য এবং বিদ্যমান সমাধানের সমস্যা
• মাইক্রোসার্ভিস থেকে প্রত্যাশা
• স্থানান্তর সমস্যা
• কিভাবে মনোলিথ থেকে মাইক্রোসার্ভিসে যেতে হয়
  • প্রথম উপায়
  • দ্বিতীয় উপায়
  • তৃতীয় উপায়
  • চতুর্থ উপায়
• ডাটাবেস নিয়ে কাজ করা
  • বিদ্যমান টেবিল বিভক্ত করা
  • প্রক্রিয়াকরণ বিভাগ
• সোর্স কোড নিয়ে কাজ করা
• অবকাঠামোগত সমস্যা
  • পরিবেশে ম্যানুয়াল ইনস্টলেশন
  • আলাদা লগিং
  • পরীক্ষা এবং ডিবাগিং সম্পর্কিত পরিষেবা

স্থাপত্য এবং বিদ্যমান সমাধানের সমস্যা

প্রাথমিকভাবে, আর্কিটেকচারটি এইরকম ছিল: UI হল একটি পৃথক অ্যাপ্লিকেশন, মনোলিথিক অংশটি ভিজ্যুয়াল বেসিক 6 এ লেখা আছে, .NET অ্যাপ্লিকেশনটি একটি মোটামুটি বড় ডাটাবেসের সাথে কাজ করা সম্পর্কিত পরিষেবাগুলির একটি সেট।

আগের সমাধানের অসুবিধা

ব্যর্থতার একমাত্র কারণ
আমাদের ব্যর্থতার একক পয়েন্ট ছিল: .NET অ্যাপ্লিকেশনটি একটি একক প্রক্রিয়ায় চলেছিল। যদি কোনো মডিউল ব্যর্থ হয়, পুরো অ্যাপ্লিকেশন ব্যর্থ হয়েছে এবং পুনরায় চালু করতে হবে। যেহেতু আমরা বিভিন্ন ব্যবহারকারীর জন্য প্রচুর সংখ্যক প্রক্রিয়া স্বয়ংক্রিয় করে, তাদের মধ্যে একটিতে ব্যর্থতার কারণে, সবাই কিছু সময়ের জন্য কাজ করতে পারেনি। এবং একটি সফ্টওয়্যার ত্রুটির ক্ষেত্রে, এমনকি ব্যাকআপ সাহায্য করেনি।

উন্নতির সারি
এই অপূর্ণতা বরং সাংগঠনিক। আমাদের অ্যাপ্লিকেশনটির অনেক গ্রাহক রয়েছে এবং তারা সবাই যত তাড়াতাড়ি সম্ভব এটিকে উন্নত করতে চায়। পূর্বে, সমান্তরালভাবে এটি করা অসম্ভব ছিল এবং সমস্ত গ্রাহকরা লাইনে দাঁড়িয়েছিলেন। এই প্রক্রিয়াটি ব্যবসার জন্য নেতিবাচক ছিল কারণ তাদের প্রমাণ করতে হয়েছিল যে তাদের কাজটি মূল্যবান। আর এই সারির আয়োজনে সময় ব্যয় করে উন্নয়ন দল। এটি অনেক সময় এবং প্রচেষ্টা নিয়েছে, এবং পণ্যটি শেষ পর্যন্ত যত তাড়াতাড়ি তারা পছন্দ করবে তত দ্রুত পরিবর্তন করতে পারেনি।

সম্পদের সর্বোত্তম ব্যবহার
একটি একক প্রক্রিয়ায় পরিষেবাগুলি হোস্ট করার সময়, আমরা সর্বদা সার্ভার থেকে সার্ভারে কনফিগারেশন সম্পূর্ণরূপে অনুলিপি করি। আমরা সবচেয়ে বেশি লোড করা পরিষেবাগুলিকে আলাদাভাবে স্থাপন করতে চেয়েছিলাম যাতে সম্পদের অপচয় না হয় এবং আমাদের স্থাপনার পরিকল্পনার উপর আরও নমনীয় নিয়ন্ত্রণ লাভ করা যায়।

আধুনিক প্রযুক্তি প্রয়োগ করা কঠিন
সমস্ত ডেভেলপারদের কাছে পরিচিত একটি সমস্যা: প্রকল্পে আধুনিক প্রযুক্তি চালু করার ইচ্ছা আছে, কিন্তু কোন সুযোগ নেই। একটি বৃহৎ একচেটিয়া সমাধানের সাথে, বর্তমান লাইব্রেরির যেকোনো আপডেট, একটি নতুন ট্রানজিশনের কথা উল্লেখ না করে, বরং একটি অ-তুচ্ছ কাজে পরিণত হয়। দলনেতার কাছে প্রমাণ করতে দীর্ঘ সময় লাগে যে এটি নষ্ট স্নায়ুর চেয়ে বেশি বোনাস আনবে।

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

মাইক্রোসার্ভিস থেকে প্রত্যাশা

প্রস্তুত হলে উপাদান ইস্যু. দ্রবণকে পচিয়ে এবং বিভিন্ন প্রক্রিয়া আলাদা করে প্রস্তুত হলে উপাদান সরবরাহ করা।

ছোট পণ্য দল। এটি গুরুত্বপূর্ণ কারণ পুরানো মনোলিথের উপর কাজ করা একটি বড় দল পরিচালনা করা কঠিন ছিল। এই জাতীয় দলকে একটি কঠোর প্রক্রিয়া অনুসারে কাজ করতে বাধ্য করা হয়েছিল, তবে তারা আরও সৃজনশীলতা এবং স্বাধীনতা চেয়েছিল। শুধুমাত্র ছোট দল এটি বহন করতে পারে.

পৃথক প্রক্রিয়ায় পরিষেবাগুলির বিচ্ছিন্নতা। আদর্শভাবে, আমি এটিকে পাত্রে বিচ্ছিন্ন করতে চেয়েছিলাম, কিন্তু .NET ফ্রেমওয়ার্কে লেখা প্রচুর পরিসেবা শুধুমাত্র উইন্ডোজে চলে। .NET Core-এর উপর ভিত্তি করে পরিষেবাগুলি এখন উপস্থিত হচ্ছে, কিন্তু এখনও তাদের মধ্যে কয়েকটি রয়েছে৷

স্থাপনার নমনীয়তা। আমরা পরিষেবাগুলিকে আমাদের যেভাবে প্রয়োজন তা একত্রিত করতে চাই, এবং কোড যেভাবে বাধ্য করে তা নয়৷

নতুন প্রযুক্তির ব্যবহার। এটি যে কোনও প্রোগ্রামারের কাছে আকর্ষণীয়।

স্থানান্তর সমস্যা

অবশ্যই, যদি মাইক্রোসার্ভিসে একটি মনোলিথ ভাঙ্গা সহজ হতো, তাহলে কনফারেন্সে এটি সম্পর্কে কথা বলার এবং নিবন্ধ লেখার দরকার ছিল না। এই প্রক্রিয়াটিতে অনেকগুলি ত্রুটি রয়েছে; আমি প্রধানগুলি বর্ণনা করব যা আমাদের বাধা দিয়েছে।

প্রথম সমস্যা বেশিরভাগ মনোলিথের জন্য সাধারণ: ব্যবসায়িক যুক্তির সমন্বয়। যখন আমরা একটি মনোলিথ লিখি, তখন আমরা আমাদের ক্লাসগুলি পুনরায় ব্যবহার করতে চাই যাতে অপ্রয়োজনীয় কোড না লেখা যায়। এবং মাইক্রোসার্ভিসে যাওয়ার সময়, এটি একটি সমস্যা হয়ে দাঁড়ায়: সমস্ত কোড বেশ শক্তভাবে সংযুক্ত, এবং পরিষেবাগুলি আলাদা করা কঠিন।

কাজ শুরু করার সময়, সংগ্রহস্থলে 500 টিরও বেশি প্রকল্প এবং 700 হাজারেরও বেশি লাইন কোড ছিল। এটি বেশ বড় সিদ্ধান্ত এবং দ্বিতীয় সমস্যা. এটি সহজভাবে নেওয়া এবং মাইক্রোসার্ভিসে ভাগ করা সম্ভব ছিল না।

তৃতীয় সমস্যা - প্রয়োজনীয় পরিকাঠামোর অভাব। আসলে, আমরা ম্যানুয়ালি সার্ভারে সোর্স কোড কপি করছিলাম।

কিভাবে মনোলিথ থেকে মাইক্রোসার্ভিসে যেতে হয়

মাইক্রোসার্ভিসের ব্যবস্থা করা

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

মাইক্রোসার্ভিসগুলিকে বিচ্ছিন্ন করতে আমরা কোন পদ্ধতি ব্যবহার করি?

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

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

হোস্টের সাথে সমাবেশ হল প্রোগ্রাম ক্লাসে কোডের মাত্র এক লাইন। আমরা একটি অক্জিলিয়ারী ক্লাসে টপশেল্ফের সাথে কাজ লুকিয়ে রেখেছিলাম।

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");

       }
    }
}

মাইক্রোসার্ভিস বরাদ্দ করার দ্বিতীয় উপায় হল: নতুন সমস্যা সমাধানের জন্য তাদের তৈরি করুন। যদি একই সময়ে মনোলিথ বৃদ্ধি না পায় তবে এটি ইতিমধ্যেই দুর্দান্ত, যার অর্থ আমরা সঠিক দিকে এগোচ্ছি। নতুন সমস্যা সমাধানের জন্য, আমরা আলাদা পরিষেবা তৈরি করার চেষ্টা করেছি। যদি এমন একটি সুযোগ থাকে, তাহলে আমরা আরও "ক্যাননিকাল" পরিষেবা তৈরি করেছি যা সম্পূর্ণরূপে তাদের নিজস্ব ডেটা মডেল, একটি পৃথক ডাটাবেস পরিচালনা করে।

আমরা, অনেকের মতো, প্রমাণীকরণ এবং অনুমোদন পরিষেবা দিয়ে শুরু করেছি। তারা এই জন্য নিখুঁত. তারা স্বাধীন, একটি নিয়ম হিসাবে, তাদের একটি পৃথক ডেটা মডেল আছে। তারা নিজেরাই মনোলিথের সাথে যোগাযোগ করে না, শুধুমাত্র কিছু সমস্যা সমাধানের জন্য এটি তাদের দিকে ফিরে আসে। এই পরিষেবাগুলি ব্যবহার করে, আপনি একটি নতুন আর্কিটেকচারে রূপান্তর শুরু করতে পারেন, তাদের অবকাঠামো ডিবাগ করতে পারেন, নেটওয়ার্ক লাইব্রেরি সম্পর্কিত কিছু পদ্ধতির চেষ্টা করতে পারেন, ইত্যাদি। আমাদের প্রতিষ্ঠানে এমন কোনো দল নেই যা একটি প্রমাণীকরণ পরিষেবা তৈরি করতে পারেনি।

মাইক্রোসার্ভিস বরাদ্দ করার তৃতীয় উপায়আমরা যেটা ব্যবহার করি সেটা আমাদের কাছে একটু নির্দিষ্ট। এটি UI স্তর থেকে ব্যবসায়িক যুক্তি অপসারণ। আমাদের প্রধান UI অ্যাপ্লিকেশন হল ডেস্কটপ; এটি, ব্যাকএন্ডের মতো, C# এ লেখা হয়। বিকাশকারীরা পর্যায়ক্রমে ভুল করেছে এবং যুক্তির অংশগুলি UI এ স্থানান্তর করেছে যা ব্যাকএন্ডে থাকা উচিত ছিল এবং পুনরায় ব্যবহার করা উচিত।

আপনি যদি UI অংশের কোড থেকে একটি বাস্তব উদাহরণের দিকে তাকান, আপনি দেখতে পাবেন যে এই সমাধানের বেশিরভাগই বাস্তব ব্যবসায়িক যুক্তি ধারণ করে যা অন্যান্য প্রক্রিয়াগুলিতে দরকারী, শুধুমাত্র UI ফর্ম তৈরির জন্য নয়।

আসল UI যুক্তি শুধুমাত্র শেষ কয়েক লাইনে আছে। আমরা এটিকে সার্ভারে স্থানান্তর করেছি যাতে এটি পুনরায় ব্যবহার করা যায়, যার ফলে UI হ্রাস করা যায় এবং সঠিক আর্কিটেকচার অর্জন করা যায়।

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

প্রক্রিয়াকরণ থেকে পরিষেবাগুলিকে আলাদা করা আবদ্ধ প্রেক্ষাপটের ধারণার সাথে অবিচ্ছেদ্যভাবে যুক্ত। এটি ডোমেন চালিত ডিজাইনের একটি ধারণা। এর অর্থ হল ডোমেন মডেলের একটি বিভাগ যেখানে একটি একক ভাষার সমস্ত পদ স্বতন্ত্রভাবে সংজ্ঞায়িত করা হয়েছে। আসুন একটি উদাহরণ হিসাবে বীমা এবং বিলের প্রেক্ষাপটটি দেখি। আমাদের একটি একচেটিয়া অ্যাপ্লিকেশন রয়েছে এবং আমাদের বীমা অ্যাকাউন্টের সাথে কাজ করতে হবে। আমরা আশা করি যে বিকাশকারী অন্য অ্যাসেম্বলিতে একটি বিদ্যমান অ্যাকাউন্ট ক্লাস খুঁজে পাবে, এটি বীমা ক্লাস থেকে উল্লেখ করবে এবং আমাদের কাছে কাজের কোড থাকবে৷ DRY নীতিকে সম্মান করা হবে, বিদ্যমান কোড ব্যবহার করে কাজটি দ্রুত সম্পন্ন করা হবে।

ফলস্বরূপ, এটি দেখা যাচ্ছে যে অ্যাকাউন্ট এবং বীমার প্রসঙ্গ সংযুক্ত। নতুন প্রয়োজনীয়তা আবির্ভূত হওয়ার সাথে সাথে, এই সংযোগটি উন্নয়নে হস্তক্ষেপ করবে, ইতিমধ্যে জটিল ব্যবসায়িক যুক্তির জটিলতা বাড়িয়ে তুলবে। এই সমস্যাটি সমাধান করতে, আপনাকে কোডের প্রসঙ্গগুলির মধ্যে সীমানা খুঁজে বের করতে হবে এবং তাদের লঙ্ঘনগুলি সরাতে হবে। উদাহরণস্বরূপ, বীমা প্রসঙ্গে, এটা খুবই সম্ভব যে একটি 20-সংখ্যার কেন্দ্রীয় ব্যাংক অ্যাকাউন্ট নম্বর এবং অ্যাকাউন্ট খোলার তারিখ যথেষ্ট হবে।

এই আবদ্ধ প্রসঙ্গগুলিকে একে অপরের থেকে আলাদা করতে এবং একচেটিয়া সমাধান থেকে মাইক্রোসার্ভিসগুলিকে আলাদা করার প্রক্রিয়া শুরু করতে, আমরা অ্যাপ্লিকেশনের মধ্যে বাহ্যিক API তৈরি করার মতো একটি পদ্ধতি ব্যবহার করেছি। যদি আমরা জানতাম যে কিছু মডিউল একটি মাইক্রোসার্ভিস হওয়া উচিত, প্রক্রিয়ার মধ্যে কোনওভাবে পরিবর্তিত হওয়া উচিত, তাহলে আমরা অবিলম্বে বহিরাগত কলগুলির মাধ্যমে অন্য সীমিত প্রসঙ্গের সাথে সম্পর্কিত যুক্তিতে কল করেছি। উদাহরণস্বরূপ, REST বা WCF এর মাধ্যমে।

আমরা দৃঢ়ভাবে সিদ্ধান্ত নিয়েছি যে বিতরণকৃত লেনদেনের প্রয়োজন হবে এমন কোড আমরা এড়িয়ে যাব না। আমাদের ক্ষেত্রে, এই নিয়মটি অনুসরণ করা বেশ সহজ বলে প্রমাণিত হয়েছে। আমরা এখনও এমন পরিস্থিতির সম্মুখীন হইনি যেখানে কঠোরভাবে বিতরণ করা লেনদেন সত্যিই প্রয়োজন - মডিউলগুলির মধ্যে চূড়ান্ত সামঞ্জস্য যথেষ্ট যথেষ্ট।

এর একটি নির্দিষ্ট উদাহরণ তাকান. আমাদের কাছে একটি অর্কেস্ট্রেটরের ধারণা রয়েছে - একটি পাইপলাইন যা "অ্যাপ্লিকেশন" এর সত্তাকে প্রক্রিয়া করে। তিনি পালাক্রমে একটি ক্লায়েন্ট, একটি অ্যাকাউন্ট এবং একটি ব্যাংক কার্ড তৈরি করেন। যদি ক্লায়েন্ট এবং অ্যাকাউন্ট সফলভাবে তৈরি করা হয়, কিন্তু কার্ড তৈরি করতে ব্যর্থ হয়, তাহলে অ্যাপ্লিকেশনটি "সফল" স্থিতিতে স্থানান্তরিত হয় না এবং "কার্ড তৈরি হয়নি" অবস্থায় থাকে। ভবিষ্যতে, ব্যাকগ্রাউন্ড অ্যাক্টিভিটি এটিকে তুলে নেবে এবং শেষ করবে। সিস্টেমটি কিছু সময়ের জন্য অসঙ্গতিপূর্ণ অবস্থায় রয়েছে, তবে আমরা সাধারণত এতে সন্তুষ্ট।

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

আসুন একটি মাইক্রোসার্ভিস বরাদ্দের একটি উদাহরণ দেখি। আপনি কিভাবে এটি তুলনামূলকভাবে নিরাপদে উৎপাদনে আনতে পারেন? এই উদাহরণে, আমাদের সিস্টেমের একটি পৃথক অংশ রয়েছে - একটি বেতন পরিষেবা মডিউল, কোড বিভাগগুলির মধ্যে একটি যার আমরা মাইক্রোসার্ভিস তৈরি করতে চাই৷

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

এর পরে, আমরা এই কনফিগারেশনটিকে অপারেশনে ছেড়ে দিই, কিন্তু একটি পাইলট অবস্থায়। আমাদের বেশিরভাগ ব্যবহারকারী এখনও পুরানো ব্যবসা প্রক্রিয়ার সাথে কাজ করে। নতুন ব্যবহারকারীদের জন্য, আমরা মনোলিথিক অ্যাপ্লিকেশনটির একটি নতুন সংস্করণ তৈরি করছি যাতে এই প্রক্রিয়াটি আর নেই৷ মূলত, আমাদের কাছে পাইলট হিসাবে কাজ করা একটি মনোলিথ এবং একটি মাইক্রোসার্ভিসের সমন্বয় রয়েছে।

একজন সফল পাইলটের সাথে, আমরা বুঝতে পারি যে নতুন কনফিগারেশনটি আসলেই কার্যকরী, আমরা সমীকরণ থেকে পুরানো মনোলিথকে সরিয়ে দিতে পারি এবং পুরানো সমাধানের জায়গায় নতুন কনফিগারেশন ছেড়ে দিতে পারি।

মোট, আমরা একটি মনোলিথের উত্স কোড বিভক্ত করার জন্য প্রায় সমস্ত বিদ্যমান পদ্ধতি ব্যবহার করি। এগুলি সবই আমাদের অ্যাপ্লিকেশনের অংশগুলির আকার কমাতে এবং আরও ভাল উত্স কোড তৈরি করে নতুন লাইব্রেরিতে অনুবাদ করার অনুমতি দেয়৷

ডাটাবেস নিয়ে কাজ করা

ডাটাবেসকে সোর্স কোডের চেয়ে খারাপভাবে ভাগ করা যেতে পারে, কারণ এতে শুধুমাত্র বর্তমান স্কিমাই নয়, ঐতিহাসিক তথ্যও রয়েছে।

আমাদের ডাটাবেস, অন্য অনেকের মত, আরেকটি গুরুত্বপূর্ণ ত্রুটি ছিল - এর বিশাল আকার। এই ডাটাবেসটি একটি মনোলিথের জটিল ব্যবসায়িক যুক্তি এবং বিভিন্ন আবদ্ধ প্রসঙ্গের টেবিলের মধ্যে সঞ্চিত সম্পর্ক অনুসারে ডিজাইন করা হয়েছিল।

আমাদের ক্ষেত্রে, সমস্ত সমস্যা (বড় ডাটাবেস, অনেক সংযোগ, কখনও কখনও টেবিলের মধ্যে অস্পষ্ট সীমানা) শীর্ষে একটি সমস্যা দেখা দেয় যা অনেক বড় প্রকল্পে ঘটে: ভাগ করা ডাটাবেস টেমপ্লেটের ব্যবহার। টেবিল থেকে ডেটা ভিউ, রেপ্লিকেশনের মাধ্যমে নেওয়া হয়েছিল এবং অন্যান্য সিস্টেমে পাঠানো হয়েছিল যেখানে এই প্রতিলিপির প্রয়োজন ছিল। ফলস্বরূপ, আমরা টেবিলগুলিকে একটি পৃথক স্কিমাতে সরাতে পারিনি কারণ সেগুলি সক্রিয়ভাবে ব্যবহৃত হয়েছিল।

কোডের সীমিত প্রেক্ষাপটে একই বিভাজন আমাদের বিচ্ছেদ করতে সাহায্য করে। এটি সাধারণত ডাটাবেস স্তরে আমরা কীভাবে ডেটা ভেঙে ফেলি সে সম্পর্কে আমাদের একটি ভাল ধারণা দেয়। আমরা বুঝতে পারি কোন টেবিলটি একটি আবদ্ধ প্রসঙ্গের এবং কোনটি অন্যটির সাথে।

আমরা ডাটাবেস পার্টিশনের দুটি বিশ্বব্যাপী পদ্ধতি ব্যবহার করেছি: বিদ্যমান টেবিলের বিভাজন এবং প্রক্রিয়াকরণের সাথে পার্টিশন।

বিদ্যমান টেবিলগুলিকে বিভক্ত করা একটি ভাল পদ্ধতি যদি ডেটা স্ট্রাকচার ভাল হয়, ব্যবসার প্রয়োজনীয়তা পূরণ করে এবং সবাই এতে খুশি হয়। এই ক্ষেত্রে, আমরা বিদ্যমান টেবিলগুলিকে একটি পৃথক স্কিমাতে আলাদা করতে পারি।

প্রক্রিয়াকরণ সহ একটি বিভাগের প্রয়োজন হয় যখন ব্যবসার মডেল ব্যাপকভাবে পরিবর্তিত হয়, এবং টেবিলগুলি আর আমাদেরকে মোটেও সন্তুষ্ট করে না।

বিদ্যমান টেবিল বিভক্ত করা. আমরা কি আলাদা করব তা নির্ধারণ করতে হবে। এই জ্ঞান ছাড়া, কিছুই কাজ করবে না, এবং এখানে কোডে আবদ্ধ প্রসঙ্গগুলির বিচ্ছেদ আমাদের সাহায্য করবে। একটি নিয়ম হিসাবে, আপনি যদি উত্স কোডে প্রসঙ্গগুলির সীমানা বুঝতে পারেন, তবে বিভাগের জন্য তালিকায় কোন টেবিলগুলি অন্তর্ভুক্ত করা উচিত তা স্পষ্ট হয়ে যায়।

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

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

পরে আমরা এই সংযোগটি সরিয়ে ফেলব, অর্থাৎ, পৃথক টেবিল থেকে একটি মনোলিথিক অ্যাপ্লিকেশন থেকে ডেটা পড়ার বিষয়টিও এপিআইতে স্থানান্তরিত হবে।

এর পরে, আমরা সাধারণ ডাটাবেস থেকে সেই টেবিলগুলি নির্বাচন করব যার সাথে শুধুমাত্র নতুন মাইক্রোসার্ভিস কাজ করে। আমরা টেবিলগুলিকে একটি পৃথক স্কিমাতে বা এমনকি একটি পৃথক শারীরিক ডাটাবেসে স্থানান্তর করতে পারি। মাইক্রোসার্ভিস এবং মনোলিথ ডাটাবেসের মধ্যে এখনও একটি রিডিং সংযোগ রয়েছে, তবে চিন্তার কিছু নেই, এই কনফিগারেশনে এটি দীর্ঘ সময়ের জন্য বেঁচে থাকতে পারে।

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

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

এই স্কিমটি কাজ করার জন্য, আমাদের সম্ভবত একটি ট্রানজিশন পিরিয়ডের প্রয়োজন হবে।

তারপরে দুটি সম্ভাব্য পন্থা রয়েছে।

প্রথম: আমরা নতুন এবং পুরানো ডাটাবেসে সমস্ত ডেটা নকল করি। এই ক্ষেত্রে, আমাদের ডেটা রিডানডেন্সি আছে এবং সিঙ্ক্রোনাইজেশন সমস্যা দেখা দিতে পারে। কিন্তু আমরা দুটি ভিন্ন ক্লায়েন্ট নিতে পারি। একটি নতুন সংস্করণের সাথে কাজ করবে, অন্যটি পুরানোটির সাথে।

দ্বিতীয়: আমরা কিছু ব্যবসার মানদণ্ড অনুযায়ী ডেটা ভাগ করি। উদাহরণস্বরূপ, আমাদের সিস্টেমে 5টি পণ্য ছিল যা পুরানো ডাটাবেসে সংরক্ষিত ছিল। আমরা একটি নতুন ডাটাবেসে নতুন ব্যবসার টাস্কের মধ্যে ষষ্ঠটিকে রাখি। কিন্তু আমাদের একটি এপিআই গেটওয়ের প্রয়োজন হবে যা এই ডেটা সিঙ্ক্রোনাইজ করবে এবং ক্লায়েন্টকে দেখাবে কোথায় এবং কী থেকে পেতে হবে।

উভয় পন্থা কাজ করে, পরিস্থিতির উপর নির্ভর করে চয়ন করুন।

আমরা নিশ্চিত হওয়ার পরে যে সবকিছু কাজ করে, মনোলিথের অংশ যা পুরানো ডাটাবেস কাঠামোর সাথে কাজ করে তা নিষ্ক্রিয় করা যেতে পারে।

শেষ ধাপ হল পুরানো ডেটা স্ট্রাকচার অপসারণ করা।

সংক্ষেপে, আমরা বলতে পারি যে ডাটাবেসের সাথে আমাদের সমস্যা রয়েছে: সোর্স কোডের তুলনায় এটির সাথে কাজ করা কঠিন, এটি ভাগ করা আরও কঠিন, তবে এটি করা যেতে পারে এবং করা উচিত। আমরা এমন কিছু উপায় খুঁজে পেয়েছি যা আমাদের এটিকে বেশ নিরাপদে করতে দেয়, কিন্তু সোর্স কোডের চেয়ে ডেটা দিয়ে ভুল করা এখনও সহজ।

সোর্স কোড নিয়ে কাজ করা

সোর্স কোড ডায়াগ্রামটি এমনই ছিল যখন আমরা একচেটিয়া প্রকল্পের বিশ্লেষণ শুরু করি।

এটিকে মোটামুটিভাবে তিনটি স্তরে ভাগ করা যায়। এটি লঞ্চ করা মডিউল, প্লাগইন, পরিষেবা এবং পৃথক কার্যকলাপের একটি স্তর। প্রকৃতপক্ষে, এগুলি একটি মনোলিথিক সমাধানের মধ্যে এন্ট্রি পয়েন্ট ছিল। তাদের সকলকে একটি সাধারণ স্তর দিয়ে শক্তভাবে সিল করা হয়েছিল। এটি ব্যবসায়িক যুক্তি ছিল যে পরিষেবাগুলি ভাগ করা হয়েছে এবং অনেকগুলি সংযোগ রয়েছে৷ প্রতিটি পরিষেবা এবং প্লাগইন তাদের আকার এবং বিকাশকারীদের বিবেকের উপর নির্ভর করে 10 বা তার বেশি সাধারণ সমাবেশ পর্যন্ত ব্যবহৃত হয়।

আমরা ভাগ্যবান ছিলাম যে পরিকাঠামোর লাইব্রেরিগুলো আলাদাভাবে ব্যবহার করা যেতে পারে।

কখনও কখনও এমন পরিস্থিতি দেখা দেয় যখন কিছু সাধারণ বস্তু আসলে এই স্তরের অন্তর্গত ছিল না, কিন্তু অবকাঠামো লাইব্রেরি ছিল। এই নাম পরিবর্তন করে সমাধান করা হয়েছে.

সবচেয়ে বড় উদ্বেগ ছিল আবদ্ধ প্রসঙ্গ। এটি ঘটেছিল যে একটি সাধারণ সমাবেশে 3-4টি প্রসঙ্গ মিশ্রিত হয়েছিল এবং একই ব্যবসায়িক ফাংশনের মধ্যে একে অপরকে ব্যবহার করেছিল। এটি কোথায় বিভক্ত করা যেতে পারে এবং কোন সীমানা বরাবর, এবং উত্স কোড সমাবেশগুলিতে এই বিভাগটিকে ম্যাপ করার সাথে পরবর্তী কী করতে হবে তা বোঝার প্রয়োজন ছিল৷

আমরা কোড বিভাজন প্রক্রিয়ার জন্য বেশ কিছু নিয়ম প্রণয়ন করেছি।

প্রথম: আমরা আর পরিষেবা, কার্যকলাপ এবং প্লাগইনগুলির মধ্যে ব্যবসায়িক যুক্তি ভাগ করতে চাই না৷ আমরা মাইক্রোসার্ভিসের মধ্যে ব্যবসায়িক যুক্তিকে স্বাধীন করতে চেয়েছিলাম। অন্যদিকে, মাইক্রোসার্ভিসগুলিকে আদর্শভাবে এমন পরিষেবা হিসাবে বিবেচনা করা হয় যা সম্পূর্ণ স্বাধীনভাবে বিদ্যমান। আমি বিশ্বাস করি যে এই পদ্ধতিটি কিছুটা অপচয়মূলক, এবং এটি অর্জন করা কঠিন, কারণ, উদাহরণস্বরূপ, C#-এর পরিষেবাগুলি যে কোনও ক্ষেত্রে একটি স্ট্যান্ডার্ড লাইব্রেরি দ্বারা সংযুক্ত হবে। আমাদের সিস্টেম C# এ লেখা আছে; আমরা এখনও অন্যান্য প্রযুক্তি ব্যবহার করিনি। অতএব, আমরা সিদ্ধান্ত নিয়েছি যে আমরা সাধারণ প্রযুক্তিগত সমাবেশগুলি ব্যবহার করতে পারি। প্রধান জিনিস হল যে তারা ব্যবসায়িক যুক্তির কোন অংশ ধারণ করে না। আপনি যে ORM ব্যবহার করছেন তার উপর যদি আপনার সুবিধার মোড়ক থাকে, তাহলে পরিষেবা থেকে পরিষেবাতে এটি অনুলিপি করা খুবই ব্যয়বহুল।

আমাদের দল ডোমেন-চালিত ডিজাইনের অনুরাগী, তাই পেঁয়াজ স্থাপত্য আমাদের জন্য উপযুক্ত ছিল। আমাদের পরিষেবাগুলির ভিত্তি ডেটা অ্যাক্সেস স্তর নয়, তবে ডোমেন লজিক সহ একটি সমাবেশ, যাতে কেবল ব্যবসায়িক যুক্তি থাকে এবং পরিকাঠামোর সাথে কোনও সংযোগ নেই৷ একই সময়ে, ফ্রেমওয়ার্ক সম্পর্কিত সমস্যাগুলি সমাধান করতে আমরা স্বাধীনভাবে ডোমেন সমাবেশ সংশোধন করতে পারি।

এই পর্যায়ে আমরা আমাদের প্রথম গুরুতর সমস্যা সম্মুখীন. পরিষেবাটিকে একটি ডোমেন সমাবেশে উল্লেখ করতে হয়েছিল, আমরা যুক্তিটিকে স্বাধীন করতে চেয়েছিলাম, এবং DRY নীতি এখানে আমাদের ব্যাপকভাবে বাধা দেয়। ডেভেলপাররা ডুপ্লিকেশন এড়াতে প্রতিবেশী সমাবেশগুলি থেকে ক্লাসগুলি পুনরায় ব্যবহার করতে চেয়েছিল এবং ফলস্বরূপ, ডোমেনগুলি আবার একসাথে সংযুক্ত হতে শুরু করে। আমরা ফলাফলগুলি বিশ্লেষণ করেছি এবং সিদ্ধান্ত নিয়েছি যে সম্ভবত সমস্যাটি সোর্স কোড স্টোরেজ ডিভাইসের ক্ষেত্রেও রয়েছে। আমাদের কাছে সমস্ত সোর্স কোড সম্বলিত একটি বড় সংগ্রহস্থল ছিল। সমগ্র প্রকল্পের সমাধান একটি স্থানীয় মেশিনে একত্র করা খুব কঠিন ছিল। অতএব, প্রকল্পের অংশগুলির জন্য পৃথক ছোট সমাধান তৈরি করা হয়েছিল, এবং কেউ তাদের সাথে কিছু সাধারণ বা ডোমেন সমাবেশ যোগ করতে এবং তাদের পুনরায় ব্যবহার করতে নিষেধ করেনি। একমাত্র টুল যা আমাদের এটি করতে দেয়নি কোড পর্যালোচনা। কিন্তু মাঝে মাঝে তাও ব্যর্থ হয়।

তারপরে আমরা পৃথক সংগ্রহস্থল সহ একটি মডেলে যেতে শুরু করি। ব্যবসায়িক যুক্তি আর পরিষেবা থেকে পরিষেবাতে প্রবাহিত হয় না, ডোমেনগুলি সত্যিই স্বাধীন হয়ে উঠেছে। আবদ্ধ প্রসঙ্গগুলি আরও স্পষ্টভাবে সমর্থিত। আমরা কিভাবে অবকাঠামো লাইব্রেরি পুনরায় ব্যবহার করব? আমরা সেগুলিকে একটি পৃথক সংগ্রহস্থলে আলাদা করেছি, তারপর সেগুলিকে নুগেট প্যাকেজে রেখেছি, যা আমরা আর্টিফ্যাক্টরিতে রেখেছি। কোনো পরিবর্তনের সাথে, সমাবেশ এবং প্রকাশনা স্বয়ংক্রিয়ভাবে ঘটে।

আমাদের পরিষেবাগুলি বহিরাগতগুলির মতোই অভ্যন্তরীণ পরিকাঠামো প্যাকেজগুলিকে উল্লেখ করতে শুরু করেছে৷ আমরা Nuget থেকে বাহ্যিক লাইব্রেরি ডাউনলোড করি। আর্টিফ্যাক্টরির সাথে কাজ করার জন্য, যেখানে আমরা এই প্যাকেজগুলি রেখেছিলাম, আমরা দুটি প্যাকেজ ম্যানেজার ব্যবহার করেছি। ছোট ভান্ডারেও আমরা Nuget ব্যবহার করতাম। একাধিক পরিষেবা সহ সংগ্রহস্থলগুলিতে, আমরা Paket ব্যবহার করি, যা মডিউলগুলির মধ্যে আরও সংস্করণ সামঞ্জস্য প্রদান করে।

এইভাবে, সোর্স কোডে কাজ করে, আর্কিটেকচারে সামান্য পরিবর্তন করে এবং সংগ্রহস্থলগুলিকে আলাদা করে, আমরা আমাদের পরিষেবাগুলিকে আরও স্বাধীন করে তুলি৷

অবকাঠামোগত সমস্যা

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

পরিবেশে ম্যানুয়াল ইনস্টলেশন

প্রাথমিকভাবে, আমরা ম্যানুয়ালি পরিবেশের জন্য সমাধান ইনস্টল করেছি। এই প্রক্রিয়াটি স্বয়ংক্রিয় করতে, আমরা একটি CI/CD পাইপলাইন তৈরি করেছি। আমরা ক্রমাগত বিতরণ প্রক্রিয়া বেছে নিয়েছি কারণ ব্যবসায়িক প্রক্রিয়ার দৃষ্টিকোণ থেকে ক্রমাগত স্থাপনা এখনও আমাদের জন্য গ্রহণযোগ্য নয়। অতএব, অপারেশনের জন্য পাঠানো একটি বোতাম ব্যবহার করে বাহিত হয়, এবং পরীক্ষার জন্য - স্বয়ংক্রিয়ভাবে।

আমরা সোর্স কোড স্টোরেজের জন্য Atlassian, Bitbucket এবং বিল্ডিংয়ের জন্য বাঁশ ব্যবহার করি। আমরা কেকে বিল্ড স্ক্রিপ্ট লিখতে পছন্দ করি কারণ এটি C# এর মতোই। রেডিমেড প্যাকেজগুলি আর্টিফ্যাক্টরিতে আসে এবং অ্যান্সিবল স্বয়ংক্রিয়ভাবে টেস্ট সার্ভারে পৌঁছে যায়, যার পরে সেগুলি অবিলম্বে পরীক্ষা করা যেতে পারে।

আলাদা লগিং

এক সময়ে, মনোলিথের একটি ধারণা ছিল শেয়ার্ড লগিং প্রদান করা। ডিস্কে থাকা পৃথক লগগুলির সাথে কী করতে হবে তাও আমাদের বুঝতে হবে। আমাদের লগ টেক্সট ফাইল লেখা হয়. আমরা একটি আদর্শ ELK স্ট্যাক ব্যবহার করার সিদ্ধান্ত নিয়েছি। আমরা সরবরাহকারীদের মাধ্যমে সরাসরি ELK-কে লিখিনি, কিন্তু সিদ্ধান্ত নিয়েছি যে আমরা পাঠ্য লগগুলি চূড়ান্ত করব এবং তাদের মধ্যে একটি শনাক্তকারী হিসাবে ট্রেস আইডি লিখব, পরিষেবার নাম যোগ করে, যাতে এই লগগুলি পরে পার্স করা যায়।

Filebeat ব্যবহার করে, আমরা সার্ভার থেকে আমাদের লগ সংগ্রহ করার সুযোগ পাই, তারপর সেগুলিকে রূপান্তর করি, UI-তে ক্যোয়ারী তৈরি করতে Kibana ব্যবহার করি এবং পরিষেবাগুলির মধ্যে কলটি কীভাবে হয়েছিল তা দেখতে পাই৷ ট্রেস আইডি এটির সাথে অনেক সাহায্য করে।

পরীক্ষা এবং ডিবাগিং সম্পর্কিত পরিষেবা

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

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

আমরা জনপ্রিয় Specflow লাইব্রেরি ব্যবহার করে একটি স্বয়ংক্রিয় পরীক্ষার প্রক্রিয়া যুক্ত করেছি। Ansible থেকে স্থাপনের পরপরই NUnit ব্যবহার করে পরীক্ষা স্বয়ংক্রিয়ভাবে চলে। যদি টাস্ক কভারেজ সম্পূর্ণ স্বয়ংক্রিয় হয়, তাহলে ম্যানুয়াল পরীক্ষার প্রয়োজন নেই। যদিও কখনও কখনও অতিরিক্ত ম্যানুয়াল পরীক্ষার এখনও প্রয়োজন হয়। কোন নির্দিষ্ট সমস্যার জন্য কোন পরীক্ষা চালানো হবে তা নির্ধারণ করতে আমরা জিরাতে ট্যাগ ব্যবহার করি।

উপরন্তু, লোড পরীক্ষার প্রয়োজনীয়তা বৃদ্ধি পেয়েছে; আগে এটি শুধুমাত্র বিরল ক্ষেত্রেই করা হত। আমরা পরীক্ষা চালানোর জন্য JMeter, সেগুলি সংরক্ষণ করার জন্য InfluxDB এবং প্রক্রিয়া গ্রাফ তৈরি করতে Grafana ব্যবহার করি।

আমরা কি অর্জন করেছি?

প্রথমত, আমরা "মুক্তি" ধারণা থেকে মুক্তি পেয়েছি। যখন এই কলোসাসটি একটি উত্পাদন পরিবেশে স্থাপন করা হয়েছিল, অস্থায়ীভাবে ব্যবসায়িক প্রক্রিয়াগুলিকে ব্যাহত করেছিল তখন দুই মাসের ভয়ঙ্কর রিলিজ চলে গেছে। এখন আমরা গড়ে প্রতি 1,5 দিনে পরিষেবাগুলি স্থাপন করি, সেগুলিকে গোষ্ঠীবদ্ধ করি কারণ সেগুলি অনুমোদনের পরে কার্যকর হয়৷

আমাদের সিস্টেমে কোন মারাত্মক ব্যর্থতা নেই। যদি আমরা একটি বাগ সহ একটি মাইক্রোসার্ভিস প্রকাশ করি, তবে এর সাথে যুক্ত কার্যকারিতা ভেঙে যাবে এবং অন্যান্য সমস্ত কার্যকারিতা প্রভাবিত হবে না। এটি ব্যবহারকারীর অভিজ্ঞতাকে ব্যাপকভাবে উন্নত করে।

আমরা স্থাপনা প্যাটার্ন নিয়ন্ত্রণ করতে পারেন. প্রয়োজনে আপনি বাকি সমাধান থেকে আলাদাভাবে পরিষেবার গোষ্ঠী নির্বাচন করতে পারেন।

উপরন্তু, আমরা উল্লেখযোগ্যভাবে উন্নতির একটি বড় সারি দিয়ে সমস্যা কমিয়েছি। আমাদের এখন আলাদা পণ্য দল আছে যারা কিছু পরিষেবার সাথে স্বাধীনভাবে কাজ করে। স্ক্রাম প্রক্রিয়াটি ইতিমধ্যেই এখানে উপযুক্ত। একটি নির্দিষ্ট দলের একটি পৃথক পণ্য মালিক থাকতে পারে যিনি এটির জন্য কাজগুলি বরাদ্দ করেন৷

সারাংশ

• মাইক্রোসার্ভিসগুলি জটিল সিস্টেমগুলি পচানোর জন্য উপযুক্ত। প্রক্রিয়ায়, আমরা বুঝতে শুরু করি আমাদের সিস্টেমে কী আছে, কী সীমিত প্রসঙ্গ রয়েছে, তাদের সীমানা কোথায় রয়েছে। এটি আপনাকে মডিউলগুলির মধ্যে উন্নতিগুলি সঠিকভাবে বিতরণ করতে এবং কোড বিভ্রান্তি প্রতিরোধ করতে দেয়।
• মাইক্রোসার্ভিসগুলি সাংগঠনিক সুবিধা প্রদান করে। এগুলি প্রায়শই কেবল স্থাপত্য হিসাবে কথা বলা হয়, তবে যে কোনও স্থাপত্য ব্যবসায়ের প্রয়োজনগুলি সমাধান করার জন্য প্রয়োজন, এবং নিজের উপর নয়। অতএব, আমরা বলতে পারি যে ছোট দলগুলির সমস্যা সমাধানের জন্য মাইক্রোসার্ভিসগুলি উপযুক্ত, কারণ স্ক্রাম এখন খুব জনপ্রিয়৷
• বিচ্ছেদ একটি পুনরাবৃত্তিমূলক প্রক্রিয়া। আপনি একটি অ্যাপ্লিকেশন নিতে পারবেন না এবং এটিকে মাইক্রোসার্ভিসে ভাগ করতে পারবেন না। ফলস্বরূপ পণ্য কার্যকরী হওয়ার সম্ভাবনা কম। মাইক্রোসার্ভিসগুলিকে উৎসর্গ করার সময়, বিদ্যমান উত্তরাধিকারকে পুনঃলিখন করা উপকারী, অর্থাৎ, এটিকে আমাদের পছন্দের কোডে পরিণত করা এবং কার্যকারিতা এবং গতির পরিপ্রেক্ষিতে ব্যবসার চাহিদাগুলি আরও ভালভাবে পূরণ করে৷

  একটি ছোট সতর্কতা: মাইক্রোসার্ভিসে যাওয়ার খরচ বেশ তাৎপর্যপূর্ণ। এককভাবে অবকাঠামোগত সমস্যা সমাধানে দীর্ঘ সময় লেগেছে। তাই যদি আপনার কাছে একটি ছোট অ্যাপ্লিকেশন থাকে যার জন্য নির্দিষ্ট স্কেলিং প্রয়োজন হয় না, যদি না আপনার দলের মনোযোগ এবং সময়ের জন্য প্রতিদ্বন্দ্বিতাকারী বিপুল সংখ্যক গ্রাহক না থাকে, তাহলে মাইক্রোসার্ভিসগুলি আপনার আজকের প্রয়োজন হতে পারে না। এটা বেশ ব্যয়বহুল. আপনি যদি মাইক্রোসার্ভিসেস দিয়ে প্রক্রিয়াটি শুরু করেন, তাহলে প্রাথমিকভাবে খরচগুলি বেশি হবে যদি আপনি একটি মনোলিথের বিকাশের সাথে একই প্রকল্প শুরু করেন।

  পুনশ্চ. একটি আরো আবেগপূর্ণ গল্প (এবং ব্যক্তিগতভাবে আপনার জন্য) - অনুযায়ী লিংক.
  এখানে প্রতিবেদনের সম্পূর্ণ সংস্করণ।

উত্স: www.habr.com