বিতরণকৃত অ্যাপ্লিকেশনের বিল্ডিং ব্লক। প্রথম পদ্ধতি

শেষে প্রবন্ধ আমরা প্রতিক্রিয়াশীল স্থাপত্যের তাত্ত্বিক ভিত্তি বিশ্লেষণ করেছি। ডেটা প্রবাহ, প্রতিক্রিয়াশীল এরলাং/এলিক্সির সিস্টেমগুলি বাস্তবায়নের উপায় এবং সেগুলিতে বার্তা পাঠানোর ধরণগুলি সম্পর্কে কথা বলার সময় এসেছে:

• অনুরোধ প্রতিক্রিয়া
• অনুরোধ-খণ্ডিত প্রতিক্রিয়া
• অনুরোধের সাথে প্রতিক্রিয়া
• সাবস্ক্রাইব প্রকাশ
• উল্টে পাবলিশ সাবস্ক্রাইব করুন
• টাস্ক ডিস্ট্রিবিউশন

SOA, MSA এবং মেসেজিং

SOA, MSA হল সিস্টেম আর্কিটেকচার যা বিল্ডিং সিস্টেমের নিয়মগুলি সংজ্ঞায়িত করে, যখন মেসেজিং তাদের বাস্তবায়নের জন্য আদিম প্রদান করে।

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

বার্তাপ্রেরণ - নাম থেকে বোঝা যায় - একটি বার্তা দালাল। এর মূল উদ্দেশ্য বার্তা গ্রহণ এবং প্রেরণ করা। এটি তথ্য প্রেরণের জন্য ইন্টারফেসের জন্য দায়ী, সিস্টেমের মধ্যে তথ্য প্রেরণের জন্য যৌক্তিক চ্যানেল গঠন, রাউটিং এবং ভারসাম্য, সেইসাথে সিস্টেম স্তরে ব্যর্থতা পরিচালনার জন্য দায়ী।
উন্নত মেসেজিং rabbitmq-এর সাথে প্রতিদ্বন্দ্বিতা বা প্রতিস্থাপন করার চেষ্টা করে না। এর প্রধান বৈশিষ্ট্য:

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

লক্ষ করুন। কোড সংগঠনের ক্ষেত্রে, মেটা-প্রকল্পগুলি জটিল Erlang/Elixir সিস্টেমের জন্য উপযুক্ত। সমস্ত প্রকল্প কোড একটি সংগ্রহস্থল - একটি ছাতা প্রকল্প. একই সময়ে, মাইক্রোসার্ভিসগুলিকে যতটা সম্ভব বিচ্ছিন্ন করা হয় এবং একটি পৃথক সত্তার জন্য দায়ী সহজ ক্রিয়াকলাপগুলি সম্পাদন করে। এই পদ্ধতির সাহায্যে, পুরো সিস্টেমের API বজায় রাখা সহজ, পরিবর্তন করা সহজ, ইউনিট এবং ইন্টিগ্রেশন পরীক্ষা লিখতে সুবিধাজনক।

সিস্টেম উপাদান সরাসরি বা একটি ব্রোকার মাধ্যমে যোগাযোগ. বার্তা প্রেরণের অবস্থান থেকে, প্রতিটি পরিষেবার বিভিন্ন জীবন পর্যায় রয়েছে:

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

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

এক্সচেঞ্জ

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

বার্তা বিনিময় নিদর্শন (MEPs)

বিশ্বব্যাপী, বিনিময় নিদর্শনগুলিকে দ্বি-তরফা এবং একতরফাতে ভাগ করা যায়। প্রাক্তনটি আগত বার্তার প্রতিক্রিয়া বোঝায়, পরেরটি তা করে না। ক্লায়েন্ট-সার্ভার আর্কিটেকচারে দ্বি-মুখী প্যাটার্নের একটি ক্লাসিক উদাহরণ হল অনুরোধ-প্রতিক্রিয়া প্যাটার্ন। টেমপ্লেট এবং এর পরিবর্তনগুলি বিবেচনা করুন।

অনুরোধ-প্রতিক্রিয়া বা RPC

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

যেহেতু মেসেজিং সম্পূর্ণ অ্যাসিঙ্ক্রোনাস, তাই ক্লায়েন্টের বিনিময় 2টি পর্যায়ে বিভক্ত:

1. অনুরোধ জমা দিন

   messaging:request(Exchange, ResponseMatchingTag, RequestDefinition, HandlerProcess).

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

2. প্রতিক্রিয়া প্রক্রিয়াকরণ

   handle_info(#'$msg'{exchange = EXCHANGE, tag = ResponseMatchingTag,message = ResponsePayload}, State)

   রেসপন্সপেলোড - সার্ভার প্রতিক্রিয়া।

সার্ভারের জন্য, প্রক্রিয়াটি 2টি পর্যায় নিয়ে গঠিত:

1. এক্সচেঞ্জ পয়েন্ট আরম্ভ
2. ইনকামিং অনুরোধ প্রক্রিয়াকরণ

কোড দিয়ে এই টেমপ্লেটটি ব্যাখ্যা করা যাক। ধরা যাক যে আমাদের একটি সাধারণ পরিষেবা বাস্তবায়ন করতে হবে যা একটি একক সুনির্দিষ্ট সময় পদ্ধতি প্রদান করে।

সার্ভার কোড

সার্ভিস API সংজ্ঞাটি api.hrl এ সরানো যাক:

%% =====================================================
%%  entities
%% =====================================================
-record(time, {
  unixtime :: non_neg_integer(),
  datetime :: binary()
}).

-record(time_error, {
  code :: non_neg_integer(),
  error :: term()
}).

%% =====================================================
%%  methods
%% =====================================================
-record(time_req, {
  opts :: term()
}).
-record(time_resp, {
  result :: #time{} | #time_error{}
}).

time_controller.erl-এ পরিষেবা নিয়ন্ত্রক সংজ্ঞায়িত করুন

%% В примере показан только значимый код. Вставив его в шаблон gen_server можно получить рабочий сервис.

%% инициализация gen_server
init(Args) ->
  %% подключение к точке обмена
  messaging:monitor_exchange(req_resp, ?EXCHANGE, default, self())
  {ok, #{}}.

%% обработка события потери связи с точкой обмена. Это же событие приходит, если точка обмена еще не запустилась.
handle_info(#exchange_die{exchange = ?EXCHANGE}, State) ->
  erlang:send(self(), monitor_exchange),
  {noreply, State};

%% обработка API
handle_info(#time_req{opts = _Opts}, State) ->
  messaging:response_once(Client, #time_resp{
result = #time{ unixtime = time_utils:unixtime(now()), datetime = time_utils:iso8601_fmt(now())}
  });
  {noreply, State};

%% завершение работы gen_server
terminate(_Reason, _State) ->
  messaging:demonitor_exchange(req_resp, ?EXCHANGE, default, self()),
  ok.

ক্লায়েন্ট কোড

একটি পরিষেবাতে একটি অনুরোধ পাঠাতে, আপনি ক্লায়েন্টের যেকোনো জায়গায় মেসেজিং অনুরোধ API কল করতে পারেন:

case messaging:request(?EXCHANGE, tag, #time_req{opts = #{}}, self()) of
    ok -> ok;
    _ -> %% repeat or fail logic
end

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

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time{unixtime = Utime}}}, State) ->
  ?debugVal(Utime),
  {noreply, State};

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time_error{code = ErrorCode}}}, State) ->
  ?debugVal({error, ErrorCode}),
  {noreply, State};

অনুরোধ-খণ্ডিত প্রতিক্রিয়া

বড় বার্তা পাঠানো এড়াতে ভাল. সমগ্র সিস্টেমের প্রতিক্রিয়াশীলতা এবং স্থিতিশীল অপারেশন এর উপর নির্ভর করে। যদি একটি প্রশ্নের উত্তর অনেক মেমরি নেয়, তাহলে বিভক্ত করা বাধ্যতামূলক।

এখানে এই ধরনের কয়েকটি উদাহরণ রয়েছে:

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

আমি এই ধরনের প্রতিক্রিয়া একটি লোকোমোটিভ কল. যাই হোক না কেন, 1024 1MB বার্তা একটি একক 1GB বার্তার চেয়ে ভাল৷

Erlang ক্লাস্টারে, আমরা একটি অতিরিক্ত সুবিধা পাই - বিনিময় পয়েন্ট এবং নেটওয়ার্কের লোড হ্রাস করা, যেহেতু উত্তরগুলি অবিলম্বে প্রাপকের কাছে পাঠানো হয়, বিনিময় পয়েন্টকে বাইপাস করে।

অনুরোধের সাথে প্রতিক্রিয়া

কথোপকথন সিস্টেম তৈরির জন্য এটি RPC প্যাটার্নের একটি বিরল পরিবর্তন।

প্রকাশ-সাবস্ক্রাইব করুন (ডেটা ডিস্ট্রিবিউশন ট্রি)

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

এই প্যাটার্ন ব্যবহার করার ক্লাসিক উদাহরণ হল রাষ্ট্রের বন্টন: কম্পিউটার গেমে গেম ওয়ার্ল্ড, এক্সচেঞ্জে বাজারের ডেটা, ডেটা ফিডে দরকারী তথ্য।

গ্রাহক কোড বিবেচনা করুন:

init(_Args) ->
  %% подписываемся на обменник, ключ = key
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {ok, #{}}.

handle_info(#exchange_die{exchange = ?SUBSCRIPTION}, State) ->
  %% если точка обмена недоступна, то пытаемся переподключиться
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {noreply, State};

%% обрабатываем пришедшие сообщения
handle_info(#'$msg'{exchange = ?SUBSCRIPTION, message = Msg}, State) ->
  ?debugVal(Msg),
  {noreply, State};

%% при остановке потребителя - отключаемся от точки обмена
terminate(_Reason, _State) ->
  messaging:unsubscribe(?SUBSCRIPTION, key, tag, self()),
  ok.

উত্সটি যে কোনও সুবিধাজনক জায়গায় বার্তাটির প্রকাশ ফাংশনকে কল করতে পারে:

messaging:publish_message(Exchange, Key, Message).

বিনিময় - বিনিময় পয়েন্টের নাম,
চাবি - রাউটিং কী
বার্তা - পেলোড

উল্টে পাবলিশ সাবস্ক্রাইব করুন

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

টাস্ক ডিস্ট্রিবিউশন প্যাটার্ন

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

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

মেসেজিং সারি এবং প্রক্রিয়াকরণ অগ্রাধিকার পরিচালনা করে। প্রসেসররা আসার সাথে সাথে কাজগুলি গ্রহণ করে। টাস্ক সফলভাবে সম্পূর্ণ বা ব্যর্থ হতে পারে:

• messaging:ack(Tack) - বার্তাটির সফল প্রক্রিয়াকরণের ক্ষেত্রে কল করা হয়
• messaging:nack(Tack) - সমস্ত জরুরী পরিস্থিতিতে কল করা হয়। টাস্ক ফিরে আসার পরে, মেসেজিং এটি অন্য হ্যান্ডলারের কাছে প্রেরণ করবে।

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

প্রাথমিক সারসংক্ষেপ

আমরা ডিস্ট্রিবিউটেড সিস্টেমের মৌলিক বিল্ডিং ব্লকগুলি ভেঙে দিয়েছি এবং Erlang/Elixir-এ তাদের ব্যবহার সম্পর্কে একটি প্রাথমিক ধারণা অর্জন করেছি।

মৌলিক টেমপ্লেটগুলিকে একত্রিত করে, উদীয়মান সমস্যাগুলি সমাধানের জন্য জটিল দৃষ্টান্তগুলি তৈরি করা যেতে পারে।

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

দ্বিতীয় অংশের শেষ।

ফটোগ্রাফি মারিয়াস ক্রিস্টেনসেন
চিত্রগুলি websequencediagrams.com এর সৌজন্যে

উত্স: www.habr.com