વિતરિત એપ્લિકેશનોના બિલ્ડીંગ બ્લોક્સ. પ્રથમ અભિગમ

છેલ્લામાં લેખ અમે પ્રતિક્રિયાશીલ આર્કિટેક્ચરના સૈદ્ધાંતિક પાયાની તપાસ કરી. ડેટા ફ્લો, રિએક્ટિવ એર્લાંગ/એલિક્સિર સિસ્ટમ્સ અમલમાં મૂકવાની રીતો અને તેમાં મેસેજિંગ પેટર્ન વિશે વાત કરવાનો આ સમય છે:

• વિનંતી-પ્રતિભાવ
• વિનંતી-ચંક્ડ પ્રતિભાવ
• વિનંતી સાથે પ્રતિસાદ
• પ્રકાશિત-સબ્સ્ક્રાઇબ કરો
• ઊંધું પ્રકાશિત-સબ્સ્ક્રાઇબ કરો
• કાર્ય વિતરણ

SOA, MSA અને મેસેજિંગ

SOA, MSA એ સિસ્ટમ આર્કિટેક્ચર છે જે બિલ્ડિંગ સિસ્ટમ્સ માટેના નિયમોને વ્યાખ્યાયિત કરે છે, જ્યારે મેસેજિંગ તેમના અમલીકરણ માટે આદિમ પૂરા પાડે છે.

હું આ અથવા તે સિસ્ટમ આર્કિટેક્ચરનો પ્રચાર કરવા માંગતો નથી. હું ચોક્કસ પ્રોજેક્ટ અને વ્યવસાય માટે સૌથી અસરકારક અને ઉપયોગી પદ્ધતિઓનો ઉપયોગ કરવા માટે છું. અમે ગમે તે દાખલો પસંદ કરીએ, યુનિક્સ-વે પર નજર રાખીને સિસ્ટમ બ્લોક્સ બનાવવાનું વધુ સારું છે: ન્યૂનતમ કનેક્ટિવિટીવાળા ઘટકો, વ્યક્તિગત સંસ્થાઓ માટે જવાબદાર. API પદ્ધતિઓ એકમો સાથે સૌથી સરળ શક્ય ક્રિયાઓ કરે છે.

નામ સૂચવે છે તેમ મેસેજિંગ એ મેસેજ બ્રોકર છે. તેનો મુખ્ય હેતુ સંદેશાઓ પ્રાપ્ત કરવાનો અને મોકલવાનો છે. તે માહિતી મોકલવા માટેના ઈન્ટરફેસ, સિસ્ટમમાં માહિતી પ્રસારિત કરવા માટે લોજિકલ ચેનલોની રચના, રૂટીંગ અને સંતુલન તેમજ સિસ્ટમ સ્તરે ફોલ્ટ હેન્ડલિંગ માટે જવાબદાર છે.
અમે જે મેસેજિંગ વિકસાવી રહ્યા છીએ તે rabbitmq સાથે સ્પર્ધા કરવાનો કે બદલવાનો પ્રયાસ નથી કરી રહ્યો. તેની મુખ્ય લાક્ષણિકતાઓ:

• વિતરણ.
  એક્સચેન્જ પોઈન્ટ તમામ ક્લસ્ટર નોડ્સ પર બનાવી શકાય છે, જે કોડનો ઉપયોગ કરે છે તેની શક્ય તેટલી નજીક.
• સાદગી.
  બોઈલરપ્લેટ કોડને ઘટાડવા અને ઉપયોગમાં સરળતા પર ધ્યાન કેન્દ્રિત કરો.
• વધુ સારું પ્રદર્શન.
  અમે rabbitmq ની કાર્યક્ષમતાને પુનરાવર્તિત કરવાનો પ્રયાસ કરી રહ્યા નથી, પરંતુ માત્ર આર્કિટેક્ચરલ અને ટ્રાન્સપોર્ટ લેયરને હાઈલાઈટ કરીએ છીએ, જેને અમે OTPમાં શક્ય તેટલી સરળ રીતે ફિટ કરીએ છીએ, ખર્ચમાં ઘટાડો કરીએ છીએ.
• સુગમતા.
  દરેક સેવા ઘણા વિનિમય નમૂનાઓને જોડી શકે છે.
• ડિઝાઇન દ્વારા સ્થિતિસ્થાપકતા.
• માપનીયતા.
  એપ્લિકેશન સાથે મેસેજિંગ વધે છે. જેમ જેમ લોડ વધે છે, તમે વિનિમય પોઈન્ટને વ્યક્તિગત મશીનો પર ખસેડી શકો છો.

ટીકા. કોડ ઓર્ગેનાઈઝેશનના સંદર્ભમાં, મેટા-પ્રોજેક્ટ્સ જટિલ એર્લાંગ/એલિક્સિર સિસ્ટમ્સ માટે યોગ્ય છે. બધા પ્રોજેક્ટ કોડ એક રીપોઝીટરીમાં સ્થિત છે - એક છત્ર પ્રોજેક્ટ. તે જ સમયે, માઇક્રોસર્વિસિસ મહત્તમ રીતે અલગ કરવામાં આવે છે અને સરળ કામગીરી કરે છે જે અલગ એન્ટિટી માટે જવાબદાર હોય છે. આ અભિગમ સાથે, સમગ્ર સિસ્ટમના API ને જાળવવાનું સરળ છે, તેમાં ફેરફારો કરવા માટે સરળ છે, તે એકમ અને એકીકરણ પરીક્ષણો લખવા માટે અનુકૂળ છે.

સિસ્ટમના ઘટકો સીધા અથવા બ્રોકર દ્વારા ક્રિયાપ્રતિક્રિયા કરે છે. મેસેજિંગ પરિપ્રેક્ષ્યમાં, દરેક સેવાના જીવનના ઘણા તબક્કાઓ છે:

• સેવાની શરૂઆત.
  આ તબક્કે, સેવાને એક્ઝિક્યુટ કરતી પ્રક્રિયા અને નિર્ભરતાઓ રૂપરેખાંકિત અને લોન્ચ કરવામાં આવે છે.
• વિનિમય બિંદુ બનાવવું.
  સેવા નોડ રૂપરેખાંકનમાં ઉલ્લેખિત સ્થિર વિનિમય બિંદુનો ઉપયોગ કરી શકે છે અથવા ગતિશીલ રીતે વિનિમય બિંદુઓ બનાવી શકે છે.
• સેવા નોંધણી.
  સેવાને વિનંતીઓ પૂરી પાડવા માટે, તે એક્સચેન્જ પોઈન્ટ પર નોંધાયેલ હોવું આવશ્યક છે.
• સામાન્ય કામગીરી.
  સેવા ઉપયોગી કાર્ય ઉત્પન્ન કરે છે.
• બંધ કરો.
  ત્યાં 2 પ્રકારના શટડાઉન શક્ય છે: સામાન્ય અને કટોકટી. સામાન્ય કામગીરી દરમિયાન, સેવા વિનિમય બિંદુથી ડિસ્કનેક્ટ થઈ જાય છે અને અટકી જાય છે. કટોકટીની પરિસ્થિતિઓમાં, મેસેજિંગ ફેલઓવર સ્ક્રિપ્ટોમાંથી એકને એક્ઝિક્યુટ કરે છે.

તે એકદમ જટિલ લાગે છે, પરંતુ કોડ એટલો ડરામણો નથી. ટિપ્પણીઓ સાથેના કોડ ઉદાહરણો થોડા સમય પછી નમૂનાઓના વિશ્લેષણમાં આપવામાં આવશે.

એક્સચેન્જો

એક્સચેન્જ પોઈન્ટ એ એક મેસેજિંગ પ્રક્રિયા છે જે મેસેજિંગ ટેમ્પલેટમાં ઘટકો સાથે ક્રિયાપ્રતિક્રિયાના તર્કને અમલમાં મૂકે છે. નીચે પ્રસ્તુત તમામ ઉદાહરણોમાં, ઘટકો વિનિમય બિંદુઓ દ્વારા ક્રિયાપ્રતિક્રિયા કરે છે, જેનું સંયોજન મેસેજિંગ બનાવે છે.

સંદેશ વિનિમય પેટર્ન (MEPs)

વૈશ્વિક સ્તરે, વિનિમય પેટર્નને બે-માર્ગી અને વન-વેમાં વિભાજિત કરી શકાય છે. પહેલાનો અર્થ આવનારા સંદેશનો પ્રતિભાવ સૂચવે છે, બાદમાં નથી. ક્લાયંટ-સર્વર આર્કિટેક્ચરમાં દ્વિ-માર્ગી પેટર્નનું ઉત્તમ ઉદાહરણ વિનંતી-પ્રતિસાદ પેટર્ન છે. ચાલો નમૂના અને તેના ફેરફારો જોઈએ.

વિનંતી-પ્રતિસાદ અથવા RPC

જ્યારે અમને બીજી પ્રક્રિયામાંથી પ્રતિસાદ પ્રાપ્ત કરવાની જરૂર હોય ત્યારે RPC નો ઉપયોગ થાય છે. આ પ્રક્રિયા સમાન નોડ પર ચાલી રહી હોઈ શકે છે અથવા અલગ ખંડ પર સ્થિત હોઈ શકે છે. નીચે મેસેજિંગ દ્વારા ક્લાયંટ અને સર્વર વચ્ચેની ક્રિયાપ્રતિક્રિયાનો આકૃતિ છે.

મેસેજિંગ સંપૂર્ણપણે અસુમેળ હોવાથી, ક્લાયંટ માટે એક્સચેન્જને 2 તબક્કામાં વિભાજિત કરવામાં આવે છે:

1. વિનંતી સબમિટ કરો

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

   એક્સચેન્જ - વિનિમય બિંદુનું અનન્ય નામ
   ResponseMatchingTag - પ્રતિભાવની પ્રક્રિયા માટે સ્થાનિક લેબલ. ઉદાહરણ તરીકે, વિવિધ વપરાશકર્તાઓને લગતી ઘણી સમાન વિનંતીઓ મોકલવાના કિસ્સામાં.
   વિનંતીની વ્યાખ્યા - વિનંતી શરીર
   હેન્ડલરપ્રોસેસ - હેન્ડલરનું PID. આ પ્રક્રિયા સર્વર તરફથી પ્રતિસાદ પ્રાપ્ત કરશે.

2. પ્રતિભાવ પર પ્રક્રિયા કરી રહ્યું છે

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

   રિસ્પોન્સપેલોડ - સર્વર પ્રતિસાદ.

સર્વર માટે, પ્રક્રિયામાં 2 તબક્કાઓ પણ શામેલ છે:

1. વિનિમય બિંદુ શરૂ કરી રહ્યા છીએ
2. પ્રાપ્ત વિનંતીઓ પર પ્રક્રિયા

ચાલો આ નમૂનાને કોડ સાથે સમજાવીએ. ચાલો કહીએ કે આપણે એક સરળ સેવા અમલમાં મૂકવાની જરૂર છે જે એક ચોક્કસ સમય પદ્ધતિ પ્રદાન કરે છે.

સર્વર કોડ

ચાલો api.hrl માં સર્વિસ API ને વ્યાખ્યાયિત કરીએ:

%% =====================================================
%%  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(#'$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 MB ના 1 સંદેશાઓ 1 GB ના એક સંદેશ કરતાં વધુ સારા છે.

એર્લાંગ ક્લસ્ટરમાં, અમને એક વધારાનો લાભ મળે છે - એક્સચેન્જ પોઈન્ટ અને નેટવર્ક પરનો ભાર ઘટાડવો, કારણ કે એક્સચેન્જ પોઈન્ટને બાયપાસ કરીને પ્રતિભાવો તરત જ પ્રાપ્તકર્તાને મોકલવામાં આવે છે.

વિનંતી સાથે પ્રતિસાદ

સંવાદ સિસ્ટમો બનાવવા માટે 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