Dünya bir yerdə dayanmır. Tərəqqi yeni texnoloji problemlər yaradır. Dəyişən tələblərə uyğun olaraq informasiya sistemlərinin arxitekturası inkişaf etməlidir. Bu gün biz hadisələrə əsaslanan memarlıq, paralellik, paralellik, asinxroniya və bütün bunlarla Erlanqda necə dinc yaşaya biləcəyiniz haqqında danışacağıq.
Giriş
Layihələndirilən sistemin ölçüsündən və ona olan tələblərdən asılı olaraq, biz tərtibatçılar sistemdə məlumat mübadiləsi üsulunu seçirik. Əksər hallarda xidmətlərin qarşılıqlı əlaqəsini təşkil etmək üçün iş variantı broker ilə sxem ola bilər, məsələn, RabbitMQ və ya kafka əsasında. Amma bəzən hadisələrin axını, SLA və sistem üzərində nəzarət səviyyəsi elə olur ki, hazır mesajlaşma bizə uyğun gəlmir. Əlbəttə ki, siz, məsələn, ZeroMQ və ya nanomsg istifadə edərək, nəqliyyat təbəqəsi və klasterin formalaşması üçün məsuliyyət götürməklə sistemi bir az çətinləşdirə bilərsiniz. Lakin sistem kifayət qədər ötürmə qabiliyyətinə və standart Erlanq klasterinin imkanlarına malikdirsə, o zaman əlavə qurumun tətbiqi məsələsi ətraflı öyrənilmə və iqtisadi əsaslandırma tələb edir.
Reaktiv paylanmış proqramların mövzusu olduqca genişdir. Məqalənin formatında saxlamaq üçün bugünkü müzakirəmizin mövzusu yalnız Erlang/Elixir üzərində qurulmuş homojen mühitlər olacaq. Erlang/OTP ekosistemi sizə ən az səylə reaktiv arxitektura həyata keçirməyə imkan verir. Amma istənilən halda bizə mesajlaşma təbəqəsi lazım olacaq.
Nəzəri əsas
Dizayn məqsədləri və məhdudiyyətləri müəyyən etməklə başlayır. Əsas məqsəd inkişaf naminə inkişaf sahəsində deyil. Biz təhlükəsiz və miqyaslana bilən alət əldə etməliyik ki, onun əsasında biz müxtəlif səviyyəli müasir proqramlar yarada və ən əsası inkişaf etdirə bilək: kiçik auditoriyaya xidmət edən tək server proqramlarından başlayaraq, sonradan 50-yə qədər klasterə çevrilə bilər. -60 qovşaq, klaster federasiyaları ilə bitən. Beləliklə, əsas məqsəd son sistemin inkişafı və sahiblik xərclərini azaltmaqla mənfəəti maksimuma çatdırmaqdır.
Son sistem üçün 4 əsas tələbi qeyd edək:
- Сhadisə yönümlü.
Sistem hadisələrin axınından keçməyə və lazımi hərəkətləri yerinə yetirməyə həmişə hazırdır; - Мmiqyaslılıq.
Fərdi bloklar həm şaquli, həm də üfüqi olaraq ölçülə bilər. Bütün sistem sonsuz üfüqi artım qabiliyyətinə malik olmalıdır; - Оsəhvlərə dözümlülük.
Bütün səviyyələr və bütün xidmətlər nasazlıqlardan avtomatik bərpa oluna bilməlidir; - Гzəmanətli cavab müddəti.
Vaxt dəyərlidir və istifadəçilər çox gözləməməlidirlər.
Köhnə nağılı xatırlayırsınız: "Bala biləcək kiçik mühərrik"? Layihələndirilən sistemin prototip mərhələsindən uğurla çıxması və mütərəqqi olması üçün onun təməli minimum tələblərə cavab verməlidir. SMOG.
İnfrastruktur aləti və bütün xidmətlər üçün əsas kimi mesajlaşmaya daha bir məqam əlavə olunur: proqramçılar üçün istifadə rahatlığı.
Hadisə yönümlü
Tətbiqin tək serverdən klasterə çevrilməsi üçün onun arxitekturası boş birləşməni dəstəkləməlidir. Asinxron model bu tələbə cavab verir. Burada göndərici və alıcı mesajın məlumat yükünə diqqət yetirir və sistem daxilində ötürülmə və marşrutlaşdırmadan narahat olmayın.
Ölçeklenebilirlik
Ölçeklenebilirlik və sistemin səmərəliliyi bir-birinin yanındadır. Tətbiq komponentləri bütün mövcud resurslardan istifadə etməyi bacarmalıdır. Tutumdan nə qədər səmərəli istifadə edə bilsək və emal üsullarımız nə qədər optimal olarsa, avadanlıqlara bir o qədər az pul xərcləyirik.
Tək maşın daxilində Erlanq yüksək rəqabət mühiti yaradır. Paralellik və paralellik arasındakı tarazlıq Erlang VM-də mövcud olan əməliyyat sistemi iplərinin sayını və bu iplərdən istifadə edən planlaşdırıcıların sayını seçməklə müəyyən edilə bilər.
Erlanq prosesləri vəziyyəti paylaşmır və bloklanmayan rejimdə işləyir. Bu, ənənəvi bloklama əsaslı tətbiqlərə nisbətən nisbətən aşağı gecikmə və daha yüksək ötürmə qabiliyyətini təmin edir. Erlang'ın planlaşdırıcısı CPU və IO-nun ədalətli bölüşdürülməsini təmin edir və bloklamanın olmaması tətbiqin hətta pik yüklənmələr və ya uğursuzluqlar zamanı cavab verməyə imkan verir.
Klaster səviyyəsində utilizasiya problemi də mövcuddur. Klasterdəki bütün maşınların bərabər yüklənməsi və şəbəkənin həddindən artıq yüklənməməsi vacibdir. Gəlin bir vəziyyəti təsəvvür edək: istifadəçi trafiki daxil olan balanslaşdırıcılara (haproxy, nginx və s.) düşür, onlar emal sorğularını mövcud backendlər dəsti arasında mümkün qədər bərabər paylayır. Tətbiq infrastrukturu daxilində tələb olunan interfeysi həyata keçirən xidmət yalnız son mildir və ilkin sorğuya cavab vermək üçün bir sıra digər xidmətlərə müraciət etməli olacaq. Daxili sorğular həmçinin marşrutlaşdırma və balanslaşdırma tələb edir.
Məlumat axınlarını effektiv idarə etmək üçün mesajlaşma tərtibatçılara marşrutlaşdırma və yük balansını idarə etmək üçün interfeys təqdim etməlidir. Bunun sayəsində tərtibatçılar mikroservis nümunələrindən (aqreqator, proxy, zəncir, filial və s.) istifadə edərək həm standart problemləri, həm də nadir hallarda yaranan problemləri həll edə biləcəklər.
Biznes nöqteyi-nəzərindən miqyaslılıq risklərin idarə edilməsi alətlərindən biridir. Əsas odur ki, avadanlıqdan optimal şəkildə istifadə etməklə müştəri istəklərini təmin edək:
- Tərəqqi nəticəsində avadanlıqların gücü artdıqda. Qüsursuz proqram təminatı səbəbindən boş qalmayacaq. Erlang şaquli olaraq yaxşı tərəzi edir və həmişə bütün CPU nüvələrindən və mövcud yaddaşdan istifadə edə biləcək;
- Bulud mühitlərində biz cari və ya proqnozlaşdırılan yükdən asılı olaraq avadanlıqların miqdarını idarə edə və SLA-ya zəmanət verə bilərik.
xətaya dözümlülük
Gəlin iki aksioma nəzər salaq: “Uğursuzluqlar qəbuledilməzdir” və “Uğursuzluqlar həmişə olacaq”. Biznes üçün proqram təminatının uğursuzluğu pul itkisi, daha pisi isə reputasiya itkisi deməkdir. Mümkün itkilər və nasazlığa dözümlü proqram təminatının işlənib hazırlanması xərcləri arasında tarazlıq quraraq, tez-tez bir kompromis tapmaq olar.
Qısa müddətdə xətaya dözümlülüyü özündə birləşdirən arxitektura hazır klasterləşdirmə həllərinin alınmasına pula qənaət edir. Onlar bahadır və onların da səhvləri var.
Uzunmüddətli perspektivdə qüsurlara dözümlü arxitektura inkişafın bütün mərhələlərində özünü dəfələrlə ödəyir.
Kod bazası daxilində mesajlaşma inkişaf mərhələsində sistem daxilində komponentlərin qarşılıqlı əlaqəsini ətraflı şəkildə işləməyə imkan verir. Bu, uğursuzluqlara cavab vermək və onları idarə etmək tapşırığını asanlaşdırır, çünki bütün kritik komponentlər nasazlıqları idarə edir və nəticədə yaranan sistem dizaynla nasazlıqdan sonra avtomatik olaraq normal vəziyyətə qayıtmağı bilir.
Cavabdehlik
Uğursuzluqlardan asılı olmayaraq, proqram sorğulara cavab verməli və SLA-ya cavab verməlidir. Reallıq budur ki, insanlar gözləmək istəmirlər, ona görə də müəssisələr buna uyğunlaşmalıdırlar. Getdikcə daha çox tətbiqin yüksək həssaslığa malik olacağı gözlənilir.
Cavab verən proqramlar real vaxt rejimində işləyir. Erlang VM yumşaq real vaxt rejimində işləyir. Birja ticarəti, tibb və sənaye avadanlıqlarına nəzarət kimi bəzi sahələr üçün çətin real vaxt rejimi vacibdir.
Cavab verən sistemlər UX-ni təkmilləşdirir və biznesə fayda verir.
İlkin xülasə
Bu məqaləni planlaşdırarkən, mesajlaşma brokerinin yaradılması və onun əsasında mürəkkəb sistemlərin qurulması təcrübəmi bölüşmək istədim. Ancaq nəzəri və motivasiya hissəsi olduqca geniş oldu.
Məqalənin ikinci hissəsində mübadilə nöqtələrinin həyata keçirilməsinin nüansları, mesajlaşma nümunələri və onların tətbiqi haqqında danışacağam.
Üçüncü hissədə xidmətlərin təşkili, marşrutlaşdırma və balanslaşdırmanın ümumi məsələlərini nəzərdən keçirəcəyik. Sistemlərin miqyaslılığının və nasazlıqlara qarşı dözümlülüyün praktik tərəfi haqqında danışaq.
Birinci hissənin sonu.
foto .
Mənbə: www.habr.com