36-წუთიანი მოგზაურობა სისტემური დონის ფორმებში — მონოლითიდან მიკროსერვისებამდე, BFF, API გეითვეები, event-driven, სერვერლესი და როგორ გადავიდეთ უსაფრთხოდ. გულწრფელები ვიქნებით იმაზე, თუ სად იმარჯვებს ჩუმად უფრო მარტივი ვარიანტი.
ერთი პროცესის შიგნით ცუდი საზღვარი ნელი რეფაქტორინგია. ქსელის გაღმა იგივე ცუდი საზღვარი იქცევა ხელახალი მცდელობების ქარიშხლად, ჩავარდნილ დეპლოიდ და ღამის ორ საათზე მიღებულ გაფრთხილებად. არქიტექტურული სტილი უბრალოდ ისაა, სად გაავლებთ დეპლოიმენტისა და ინტეგრაციის ხაზებს — და რა ჯდება ეს ხაზები, როცა ისინი ქსელს კვეთს.
იგივე ოთხი საზრუნავი. მარცხნივ გამოძახება ვერ ჩავარდება; მარჯვნივ კი ყოველი ხაზი ის რამაა, რაც შეიძლება გაფუჭდეს.
მარტივი ოპერაციები, ერთი დეპლოი, მარტივი ლოკალური გარემო, ტრანზაქციები უფასოა. პროდუქტების უმეტესობამ აქ უნდა დაიწყოს.
დამოუკიდებელი მასშტაბირება და დეპლოები, გუნდის ავტონომია, ხარვეზების იზოლაცია — თუ საზღვრები ნამდვილია.
განაწილებული ყველაფერს უმატებს ქსელურ ჩავარდნას, ნაწილობრივ ჩავარდნას, მონაცემთა თანმიმდევრულობასა და დაკვირვებადობის ღირებულებას.
ნუ გადაიხდით განაწილებულობის გადასახადს, სანამ დაკავშირებულობის ტკივილი — და არა რეზიუმეს შური — არ გაიძულებთ.
ეს სამი ტომი არაა — ეს სამი წერტილია ერთ ხაზზე, სადაც დეპლოის სიმარტივეს დამოუკიდებლობაზე ცვლით. 2026 წლის გულწრფელი სიმართლე: მიკროსერვისები ზედმეტად ხშირად გამოიყენება. გუნდების უმეტესობა მათ იმ ტკივილამდე წლებით ადრე მიმართავს, რომელიც მათ გაამართლებდა — და მთელი ამ ხნის განმავლობაში გადასახადს იხდის.
შუა ვარიანტი ის არის, რომელსაც გუნდების უმეტესობა გამოტოვებს — და რომელიც სინამდვილეში სჭირდება.
// "microservices", but they share a database async function checkout(cart) { await http.post("orders-svc/create", cart) await http.post("billing-svc/charge", cart) // network hop await http.post("inventory-svc/reserve", cart) // network hop } // deploy one → must deploy all. Slower AND fragile.
// modules with enforced boundaries, one process async function checkout(cart) { await orders.create(cart) // in-process, can't half-fail await billing.charge(cart) // one DB transaction await inventory.reserve(cart) } // split a module into a service later, when it earns it.
გაჭერით შემოსაზღვრული კონტექსტების (DDD) გასწვრივ — ენა და მფლობელობა, რომლებიც ერთად იცვლება. ქსელური საზღვარი, რომელიც ნამდვილ ნაკერს მიჰყვება, იაფია; ის კი, რომელიც ტრანზაქციას ჭრის — ტანჯვაა.
ვების ცხრილს, მობილურის სიასა და პარტნიორის ინტეგრაციას ერთი და იმავე მონაცემების სრულიად სხვადასხვა ფორმა სჭირდება. BFF არის თხელი ბექენდი, რომელსაც თითოეული კლიენტის გუნდი ფლობს: ის ქვედა დონის სერვისებს ესაუბრება და აბრუნებს ზუსტად იმას, რაც ამ კლიენტს სჭირდება — ზედმეტი მონაცემების წამოღებისა და თორმეტი მისვლა-მოსვლის გარეშე.
თითოეულ კლიენტს თავისი BFF აქვს; BFF-ები კი ერთსა და იმავე ქვედა დონის სერვისებს იზიარებენ.
როგორც პირადი შემსყიდველი თითოეული მომხმარებლისთვის — საწყობი ერთია, მაგრამ თითოეული ერთი ადამიანისთვის აწყობილი ჩანთით ბრუნდება. UI-ის მხარეს ნათესავი იდეაა მიკროფრონტენდები; ძლიერია და თანაბრად ზედმეტად გამოყენებული — ერთ გუნდს ისინი იშვიათად სჭირდება.
კლიენტებმა თქვენი სერვისების რუკა არ უნდა იცოდნენ. API გეითვეი ერთადერთი შესასვლელი წერტილია, რომელიც განივკვეთ საქმეებს ითავსებს — მარშრუტიზაცია, ავთენტიფიკაცია, სიხშირის ლიმიტები, TLS — რომ ეს თითოეულმა სერვისმა ცალკე არ აკეთოს. მის უკან სერვისები ერთმანეთს ორნაირად ესაუბრებიან და ეს არჩევანი განსაზღვრავს, როგორ ვრცელდება ჩავარდნა.
ავთენტიფიკაცია და მარშრუტიზაცია ერთხელ, კიდეზე ხდება — სერვისები კი თავიანთ საქმეზე რჩებიან ფოკუსირებული.
აირჩიეთ საოპერაციო მოდელით: თვითჰოსტინგი კონტროლისთვის, მართული სერვისი ნაკლები ოპერაციებისთვის, სრული სასიცოცხლო ციკლი დიდი API პროგრამებისთვის.
აირჩიეთ, როცა გინდათ პორტაბელურობა და ღრმა კონფიგურირებადობა.
აირჩიეთ, როცა უკვე სერვერლესზე ხართ AWS-ში.
აირჩიეთ, როცა API-ები პროდუქტია, რომელსაც გარე დეველოპერებს ყიდით.
აირჩიეთ გამოძახების ფორმის მიხედვით: ვინ მოიხმარს მას, რამდენად მჭიდროა შეყოვნების ბიუჯეტი და შეუძლია თუ არა გამომძახებელს ლოდინი.
აირჩიეთ საჯარო API-ებისა და ფართო წვდომისთვის.
აირჩიეთ შიდა, მაღალი გამტარუნარიანობის სერვის-მეშისთვის.
აირჩიეთ მდიდარი, კლიენტზე მართული ფრონტენდებისა და BFF-ებისთვის.
აირჩიეთ, როცა გამომძახებელს პასუხი ახლავე არ სჭირდება.
მოვლენებით მართულ სტილში სერვისი აცხადებს ფაქტს — OrderPlaced — და მიდის. ვისაც აინტერესებს, ის რეაგირებს. პროდიუსერებმა კონსიუმერები არ იციან, ამიტომ ახალ რეაქციებს წყაროსთან შეხების გარეშე ამატებთ. სწორედ ეს განცალკევებაა მთელი მიმზიდველობა — და საბოლოო თანმიმდევრულობა კი მთელი ფასი.
Pub/sub: შეკვეთები ერთხელ აქვეყნებს; სამი კონსიუმერი რეაგირებს. მეოთხის დამატება ზემოთ არავის ეხება.
// the log of facts IS the truth const events = [ { type: "OrderPlaced", items: 3 }, { type: "OrderPaid", amount: 90 }, { type: "ItemRefunded", amount: 30 }, ] // current state = fold over events const balance = events.reduce(apply, 0) // → 60
CQRS: ჩაწერა მოვლენებს ამატებს; წაკითხვა კი ამ ლოგზე აგებული პროექციებიდან მოდის.
სერვერლესი საშუალებას გაძლევთ ფუნქცია გაუშვათ და არა მთელი ფლოტი: პლატფორმა მას საჭიროებისამებრ უშვებს და უქმად დგომისას ნულამდე ამცირებს. და როცა საბოლოოდ მონოლითის მოდერნიზაციას გადაწყვეტთ, მას ერთი შემზარავი ნახტომით არ გადაწერთ — ნელ-ნელა შეახრჩობთ, თითო მარშრუტს ერთდროულად.
პიკებიანი ან დაბალი ტრაფიკი, დამაკავშირებელი/cron დავალებები, მოვლენების დამმუშავებლები, ვებჰუკები, მსუბუქი API-ები კიდეზე.
სტაბილურად მაღალი ტრაფიკი (მუდმივად ჩართულ სერვერზე იაფია), გრძელი დავალებები, ულტრადაბალი შეყოვნება, მძიმე მდგომარეობიანი დატვირთვები.
ცივი გაშვებები, ტაიმაუტები და ვენდორზე მიბმა. ფუნქციები პატარა შეინახეთ, ბიზნეს-ლოგიკა კი პროვაიდერისგან დამოუკიდებელი.
აირჩიეთ, როცა AWS-ში ცხოვრობთ და მოვლენების მდიდარი წყაროები გჭირდებათ.
აირჩიეთ, როცა თქვენი მონაცემები და სტეკი უკვე GCP-ზეა.
აირჩიეთ გლობალური, დაბალშეყოვნებიანი კიდის ლოგიკისა და მსუბუქი API-ებისთვის.
ფასადი როუტებს ძველიდან ახალზე თითო ნაჭრად ინაცვლებს — ერთბაშად გადაწერის გარეშე.
"საუკეთესო" არქიტექტურა არ არსებობს — არსებობს მხოლოდ ყველაზე იაფი, რომელიც დღევანდელ რეალურ შეზღუდვებს აკმაყოფილებს. განმეორებადი შეცდომაა განაწილებული სირთულის ვალით ყიდვა და პროცენტის სამუდამოდ გადახდა.
ხუთი სწრაფი კითხვა მონოლითებზე, BFF-ებზე, გეითვეებზე, მოვლენებსა და მიგრაციაზე — მყისიერი პასუხი, ავტორიზაციის გარეშე.
ნავიგაცია ← → ღილაკებით ან სქროლით · უკან ბიბლიოთეკაში