Ya da monoliti olan her mutsuz şirket kendince mutsuzdur.
Dodo IS sisteminin gelişimi, tıpkı Dodo Pizza işletmesi gibi, 2011'de hemen başladı. İş süreçlerinin eksiksiz ve topyekun dijitalleştirilmesi fikrine dayanıyordu ve 2011'de bile birçok soruya ve şüpheciliğe neden oldu. Ancak 9 yıldır, bir monolit ile başlayan kendi gelişimimizle bu yolu izliyoruz.
Bu makale, “Neden mimariyi yeniden yazmak ve bu kadar büyük ölçekli ve uzun vadeli değişiklikler yapmak?” Sorularına bir “cevap” niteliğindedir. önceki makaleye dön . Dodo IS'nin gelişiminin nasıl başladığı, orijinal mimarinin nasıl göründüğü, yeni modüllerin nasıl ortaya çıktığı ve hangi sorunlar nedeniyle büyük ölçekli değişikliklerin yapılması gerektiği ile başlayacağım.
"Dodo IS Nedir?" başlıklı makale dizisi hakkında şunları söyler:
-
Dodo IS'de (2011-2015) erken monolit. (Buradasınız)
-
.
-
İstemci tarafı yolu: temelin üzerindeki cephe (2016-2017). (Devam etmekte...)
-
Gerçek mikro hizmetlerin geçmişi. (2018-2019). (Devam etmekte...)
-
Monolitin testereyle kesilmesi ve mimarinin stabilizasyonu tamamlandı. (Devam etmekte...)
İlk mimari
2011'de Dodo IS mimarisi şöyle görünüyordu:
Mimarideki ilk modül sipariş kabulüdür. İş süreci şuydu:
-
müşteri pizzacıyı arar;
-
yönetici telefonu açar;
-
telefonla sipariş kabul eder;
-
sipariş kabul arayüzünde paralel olarak doldurur: müşteri hakkındaki bilgiler, sipariş detaylarındaki veriler, teslimat adresi dikkate alınır.
Bilgi sisteminin arayüzü şuna benziyordu ...
Ekim 2011'den ilk sürüm:
Birinci sipariş alma modülünün geliştirilmesi için kaynaklar sınırlıydı. Hızlı ve küçük bir ekiple çok şey yapmamız gerekiyordu. Küçük bir ekip, gelecekteki tüm sistemin temelini atan 2 geliştiricidir.
İlk kararları, teknoloji yığınının kaderini belirledi:
-
ASP.NET MVC, C# dilinde arka uç. Geliştiriciler dotnetchiki idi, bu yığın onlara tanıdık ve hoş geldi.
-
Bootstrap ve JQuery'de ön uç: kendi kendine yazılan stiller ve betiklerde kullanıcı arabirimleri.
-
MySQL veritabanı: lisans maliyeti yok, kullanımı kolay.
-
Windows Server'daki sunucular, çünkü .NET o zaman yalnızca Windows altında olabilir (Mono'yu tartışmayacağız).
Fiziksel olarak, tüm bunlar “barındırıcıdaki adak” ile ifade edildi.
Sipariş Alma Uygulama Mimarisi
Sonra herkes mikro hizmetlerden bahsediyordu ve SOA 5 yıl boyunca büyük projelerde kullanıldı, örneğin WCF 2006'da piyasaya sürüldü. Ama sonra güvenilir ve kanıtlanmış bir çözüm seçtiler.
İşte burada.
Asp.Net MVC, bir formdan veya bir istemciden gelen istek üzerine, sunucu işlemeli bir HTML sayfası oluşturan Razor'dur. İstemcide, CSS ve JS komut dosyaları zaten bilgileri görüntüler ve gerekirse JQuery aracılığıyla AJAX isteklerini gerçekleştirir.
Sunucudaki istekler, son HTML sayfasının işlenmesinin ve oluşturulmasının yöntemde gerçekleştiği *Controller sınıflarında son bulur. Denetleyiciler *Services adlı bir mantık katmanına istekte bulunur. Hizmetlerin her biri, işin bazı yönlerine karşılık geliyordu:
-
Örneğin, DepartmentStructureService pizzacılar, departmanlar hakkında bilgi veriyordu. Departman, tek bir franchise sahibi tarafından işletilen bir grup pizzacıdır.
-
ReceivingOrdersService, siparişin bileşimini kabul etti ve hesapladı.
-
Ve SmsService, SMS göndermek için API servislerini arayarak SMS gönderdi.
Servisler veri tabanından işlenen verileri, depolanan iş mantığını. Her hizmetin uygun ada sahip bir veya daha fazla *Havuzu vardı. Zaten veritabanındaki saklı yordamlara yönelik sorgular ve bir haritalayıcı katmanı içeriyorlardı. Depolarda, özellikle raporlama verilerini yayınlayanlarda çok iş mantığı vardı. ORM kullanılmadı, herkes el yazısı sql'ye güvendi.
Etki alanı modelinin bir katmanı ve ortak yardımcı sınıflar da vardı, örneğin siparişi depolayan Order sınıfı. Aynı yerde, katmanda, görüntülenen metni seçilen para birimine göre dönüştürmek için bir yardımcı vardı.
Bütün bunlar böyle bir modelle temsil edilebilir:
Sipariş Yolu
Böyle bir sipariş oluşturmanın basitleştirilmiş bir başlangıç yolunu düşünün.
Başlangıçta, site statikti. Üzerinde fiyatlar ve üstünde - bir telefon numarası ve "Pizza istiyorsanız - numarayı arayın ve sipariş verin" yazısı vardı. Sipariş vermek için basit bir akış uygulamamız gerekiyor:
-
Müşteri fiyatların olduğu statik bir siteyi ziyaret eder, ürünleri seçer ve sitede listelenen numarayı arar.
-
Müşteri, siparişe eklemek istediği ürünleri belirtir.
-
Adresini ve adını verir.
-
Operatör siparişi kabul eder.
-
Sipariş, kabul edilen siparişler arayüzünde görüntülenir.
Her şey menüyü görüntülemekle başlar. Oturum açmış bir kullanıcı-operatör aynı anda yalnızca bir sipariş kabul eder. Bu nedenle, taslak sepeti oturumunda saklanabilir (kullanıcının oturumu hafızada saklanır). Ürünleri ve müşteri bilgilerini içeren bir Sepet nesnesi var.
Müşteri ürünü adlandırır, operatör tıklar + ürünün yanında bulunur ve sunucuya bir istek gönderilir. Ürünle ilgili bilgiler veri tabanından çekilir ve ürünle ilgili bilgiler sepete eklenir.
Dikkat. Evet, burada ürünü veritabanından çekemezsiniz, ancak ön uçtan aktarabilirsiniz. Ancak netlik için, veritabanından tam olarak yolu gösterdim.
Ardından, müşterinin adresini ve adını girin.
"Sipariş Oluştur"a tıkladığınızda:
-
İstek, OrderController.SaveOrder()'a gönderilir.
-
Seanslardan Sepet alıyoruz, ihtiyacımız olan adette ürün var.
-
Sepeti müşteri hakkında bilgilerle tamamlıyoruz ve veritabanına kaydedildiği ReceivingOrderService sınıfının AddOrder yöntemine iletiyoruz.
-
Veritabanında sipariş, siparişin bileşimi, müşteri ile tablolar bulunur ve hepsi birbirine bağlıdır.
-
Sipariş görüntüleme arayüzü gider ve en son siparişleri çıkarır ve görüntüler.
Yeni modüller
Siparişi almak önemli ve gerekliydi. Satacak bir siparişiniz yoksa pizza işi yapamazsınız. Bu nedenle, sistem yaklaşık olarak 2012'den 2015'e kadar işlevsellik kazanmaya başladı. Bu süre zarfında, sistemin diyeceğim birçok farklı bloğu ortaya çıktı. modüller, hizmet veya ürün kavramının aksine.
Bir modül, bazı ortak iş hedefleri tarafından birleştirilen bir dizi işlevdir. Aynı zamanda fiziksel olarak aynı uygulamanın içindedirler.
Modüller sistem blokları olarak adlandırılabilir. Örneğin bu bir raporlama modülü, yönetici arayüzleri, , yetki. Bunların hepsi farklı kullanıcı arayüzleridir, hatta bazılarının farklı görsel stilleri vardır. Aynı zamanda, her şey tek bir uygulama, çalışan bir süreç çerçevesindedir.
Teknik olarak, modüller Alan olarak tasarlandı (böyle bir fikir bile kaldı. ). Ön uç, modeller ve kendi denetleyici sınıfları için ayrı dosyalar vardı. Sonuç olarak, sistem bundan dönüştürüldü ...
...bunun içine:
Tamamen ayrı bir işlevsellik ve kısmen biraz ayrı, daha odaklanmış bir geliştirme nedeniyle bazı modüller ayrı siteler (yürütülebilir proje) tarafından uygulanır. Bu:
-
yer - site dodopizza.ru.
-
Ihracat: 1C için Dodo IS'den rapor yükleme.
-
Kişisel - çalışanın kişisel hesabı. Ayrı olarak geliştirildi ve kendi giriş noktası ve ayrı tasarımı var.
-
fs — barındırma statiği için bir proje. Daha sonra ondan uzaklaştık ve tüm statiği Akamai CDN'ye taşıdık.
Blokların geri kalanı BackOffice uygulamasındaydı.
İsim açıklaması:
-
Kasiyer - Restoran kasiyeri.
-
ShiftManager - "Vardiya Yöneticisi" rolü için arayüzler: pizzacı satışlarıyla ilgili operasyonel istatistikler, ürünleri durdurma listesine koyma, siparişi değiştirme.
-
OfficeManager - "Pizzeria Manager" ve "Franchisee" rolleri için arayüzler. İşte bir pizzacı kurmak, bonus promosyonları, çalışanları almak ve onlarla çalışmak, raporlar için toplanan işlevler.
-
PublicScreens - pizzacılarda asılı olan TV'ler ve tabletler için arabirimler. TV'ler teslimat sırasında menüleri, reklam bilgilerini ve sipariş durumunu görüntüler.
Ortak bir hizmet katmanı, ortak bir Dodo.Core alan sınıfı bloğu ve ortak bir taban kullandılar. Bazen birbirlerine geçişler boyunca yol gösterebilirler. Dodopizza.ru veya personal.dodopizza.ru gibi bireysel siteler dahil olmak üzere genel hizmetlere gitti.
Yeni modüller ortaya çıktığında, önceden oluşturulmuş hizmet kodlarını, saklı yordamları ve veritabanındaki tabloları maksimumda yeniden kullanmaya çalıştık.
Sistemde yapılan modüllerin ölçeğini daha iyi anlamak için, geliştirme planlarıyla birlikte 2012'den bir diyagram:
2015'e gelindiğinde her şey haritadaydı ve daha da fazlası yapım aşamasındaydı.
-
Sipariş kabulü, siparişin operatör tarafından kabul edildiği İletişim Merkezi'nin ayrı bir bloğuna dönüştü.
-
Pizzacılarda menülerin ve bilgilerin asılı olduğu halka açık ekranlar vardı.
-
Mutfakta, yeni bir sipariş geldiğinde "Yeni Pizza" sesli mesajını otomatik olarak çalan ve ayrıca kurye için bir fatura yazdıran bir modül vardır. Bu, mutfaktaki işlemleri büyük ölçüde basitleştirir, çalışanların çok sayıda basit işlemle dikkatini dağıtmamasını sağlar.
-
Teslimat birimi, siparişin daha önce vardiyayı almış olan kuryeye verildiği ayrı bir Teslimat Kontrolü haline geldi. Bordro hesaplamasında çalışma süresi dikkate alınmıştır.
Buna paralel olarak, 2012'den 2015'e kadar 10'dan fazla geliştirici ortaya çıktı, 35 pizzacı açıldı, sistemi Romanya'ya yerleştirdi ve Amerika Birleşik Devletleri'nde satış noktalarının açılması için hazırlandı. Geliştiriciler artık tüm görevlerle ilgilenmediler, ekiplere ayrıldılar. her biri sistemin kendi bölümünde uzmanlaşmıştır.
Sorunları
Mimari nedeniyle dahil (ama sadece değil).
üssünde kaos
Bir taban uygundur. İçinde ve ilişkisel veritabanlarında yerleşik araçlar pahasına tutarlılık elde edilebilir. Özellikle az sayıda tablo ve az veri varsa, onunla çalışmak tanıdık ve kullanışlıdır.
Ancak 4 yılı aşkın bir süredir geliştirilen veritabanında yaklaşık 600 tablo, 1500 saklı yordam olduğu ortaya çıktı ve bunların çoğunda mantık da vardı. Ne yazık ki, saklı yordamlar MySQL ile çalışırken fazla avantaj sağlamaz. Taban tarafından önbelleğe alınmazlar ve içlerinde mantık depolamak, geliştirmeyi ve hata ayıklamayı zorlaştırır. Kodun yeniden kullanımı da zordur.
Birçok tablonun uygun indeksleri yoktu, bir yerlerde, aksine, eklemeyi zorlaştıran çok sayıda dizin vardı. Yaklaşık 20 tabloyu değiştirmek gerekiyordu - sipariş oluşturma işlemi yaklaşık 3-5 saniye sürebiliyordu.
Tablolardaki veriler her zaman en uygun biçimde değildi.. Bir yerlerde denormalizasyon yapmak gerekiyordu. Düzenli olarak alınan verilerin bir kısmı, XML yapısı biçimindeki bir sütundaydı, bu, yürütme süresini artırdı, sorguları uzattı ve geliştirmeyi karmaşık hale getirdi.
Aynı masalara çok üretildi heterojen istekler. Özellikle yukarıda belirtilen tablo gibi popüler tablolar acı çekti. emir veya tablolar pizzacı. Mutfakta operasyonel arayüzleri, analitikleri görüntülemek için kullanıldılar. Başka bir site onlarla iletişime geçti (), herhangi bir zamanda birçok isteğin aniden gelebileceği yer.
Veriler toplanmadı ve taban kullanılarak anında birçok hesaplama yapıldı. Bu, gereksiz hesaplamalar ve ek yük yarattı.
Çoğu zaman kod, bunu yapamadığı zaman veritabanına gitti. Toplu işlemlerin yeterli olmadığı bir yerde, bir yerde, hızlandırmak ve güvenilirliği artırmak için bir isteği kod aracılığıyla birkaç kişiye yaymak gerekecekti.
Kodda uyum ve şaşırtma
İşin kendilerine düşen kısmından sorumlu olması gereken modüller, bunu dürüstçe yapmadılar.. Bazılarında roller için işlevlerin kopyası vardı. Örneğin, ağın kendi şehrinde pazarlama faaliyetinden sorumlu yerel bir pazarlamacının hem "Yönetici" arayüzünü (promosyonlar oluşturmak için) hem de "Ofis Yöneticisi" arayüzünü (promosyonların işletme üzerindeki etkisini görüntülemek için) kullanması gerekiyordu. Tabii ki, her iki modül içinde bonus promosyonlarla çalışan aynı hizmeti kullandı.
Hizmetler (tek bir yekpare büyük proje içindeki sınıflar), verilerini zenginleştirmek için birbirlerini arayabilir.
Verileri depolayan model sınıflarının kendileri ile, koddaki çalışma farklı şekilde gerçekleştirildi. Bir yerlerde, gerekli alanları belirtmenin mümkün olduğu kurucular vardı. Bir yerde bu, kamu malları aracılığıyla yapıldı. Tabii ki, veri tabanından veri almak ve dönüştürmek çeşitliydi.
Mantık ya denetleyicilerde ya da hizmet sınıflarındaydı.
Bunlar küçük sorunlar gibi görünüyor, ancak geliştirmeyi büyük ölçüde yavaşlattı ve kaliteyi düşürerek istikrarsızlığa ve hatalara yol açtı.
Büyük bir geliştirmenin karmaşıklığı
Geliştirmenin kendisinde zorluklar ortaya çıktı. Sistemin farklı bloklarını paralel olarak yapmak gerekiyordu. Her bileşenin ihtiyaçlarını tek bir koda sığdırmak giderek zorlaştı. Tüm bileşenleri aynı anda kabul etmek ve memnun etmek kolay olmadı. Buna, özellikle taban ve ön uç ile ilgili olarak teknolojideki sınırlamalar eklendi. Özellikle müşteri hizmetleri (web sitesi) açısından jQuery'yi üst düzey çerçevelere doğru terk etmek gerekiyordu.
Sistemin bazı bölümlerinde buna daha uygun veri tabanları kullanılabilir.. Örneğin, daha sonra bir sipariş sepetini depolamak için Redis'ten CosmosDB'ye geçme kullanım durumumuz oldu.
Kendi alanlarında yer alan ekipler ve geliştiriciler, hem geliştirme hem de kullanıma sunma açısından hizmetleri için daha fazla özerklik istiyorlardı. Birleştirme çakışmaları, serbest bırakma sorunları. 5 geliştirici için bu sorun önemsizse, o zaman 10 ile ve hatta planlanan büyüme ile her şey daha ciddi hale gelir. Ve ileride bir mobil uygulamanın geliştirilmesi olacaktı (2017'de başladı ve 2018'de ).
Sistemin farklı parçaları, farklı seviyelerde kararlılık gerektiriyordu., ancak sistemin güçlü bağlantısı nedeniyle bunu sağlayamadık. Yönetici panelinde yeni bir işlevin geliştirilmesindeki bir hata, sitedeki bir siparişin kabulünde yer almış olabilir, çünkü kod ortak ve tekrar kullanılabilir, veritabanı ve veriler de aynıdır.
Böyle yekpare-modüler bir mimari çerçevesinde bu hatalardan ve sorunlardan kaçınmak muhtemelen mümkün olacaktır: sorumluluk dağılımı yapın, hem kodu hem de veritabanını yeniden düzenleyin, katmanları birbirinden net bir şekilde ayırın, kaliteyi her gün izleyin. Ancak seçilen mimari çözümler ve sistemin işlevselliğinin hızlı bir şekilde genişletilmesine odaklanma, kararlılık açısından sorunlara yol açtı.
Aklın Gücü blogu, kasaları restoranlara nasıl yerleştirdi?
Pizzacı ağının (ve yükün) büyümesi aynı hızda devam ederse, bir süre sonra düşüşler öyle olur ki sistem yükselmez. 2015'te yüzleşmeye başladığımız sorunları çok iyi gösteriyor, işte böyle bir hikaye.
blogda "”, tüm ağın yılı için gelir verilerini gösteren bir pencere öğesiydi. Widget, bu verileri sağlayan Dodo genel API'sine erişti. Bu istatistik şu anda şu adreste mevcuttur: . Widget her sayfada gösterildi ve her 20 saniyede bir zamanlayıcıda istekte bulundu. İstek api.dodopizza.ru adresine gitti ve şunları istedi:
-
ağdaki pizzacı sayısı;
-
yılın başından bu yana toplam ağ geliri;
-
bugün için gelir.
Gelir istatistikleri talebi doğrudan veri tabanına gitti ve siparişler hakkında veri talep etmeye, verileri anında toplamaya ve miktarı vermeye başladı.
Restoranlardaki kasalar aynı sipariş tablosuna gitti, bugün için alınan sipariş listesini boşalttı ve ona yeni siparişler eklendi. Yazarkasalar isteklerini 5 saniyede bir veya sayfa yenilemede yaptılar.
Diyagram şöyle görünüyordu:
Bir sonbaharda, Fyodor Ovchinnikov blogunda uzun ve popüler bir makale yazdı. Bloga bir çok insan geldi ve her şeyi dikkatlice okumaya başladı. Gelenlerin her biri makaleyi okurken gelir widget'ı düzgün çalıştı ve 20 saniyede bir API'yi istedi.
API, zincirdeki tüm pizzacılar için yılın başından bu yana tüm siparişlerin toplamını hesaplamak üzere bir saklı yordam çağırdı. Toplama, çok popüler olan siparişler tablosuna dayanıyordu. O sırada açık olan tüm restoranların tüm kasaları ona gider. Kasalar yanıt vermeyi kesti, siparişler kabul edilmedi. Ayrıca siteden kabul edilmediler, izleyicide görünmediler, vardiya yöneticisi onları arayüzünde göremedi.
Bu tek hikaye değil. 2015 sonbaharında, her Cuma sistemdeki yük kritik hale geldi. Birkaç kez genel API'yi kapattık ve bir keresinde siteyi bile kapatmak zorunda kaldık çünkü hiçbir şey yardımcı olmadı. Ağır yükler altında kapatma emri olan bir hizmet listesi bile vardı.
Bundan sonra, yüklerle ve sistemin istikrarı için mücadelemiz başlıyor (2015 sonbaharından 2018 sonbaharına kadar). İşte o zaman oldu"". Ayrıca, bazen arızalar da meydana geldi, bazıları çok hassastı, ancak genel istikrarsızlık dönemi artık geçmiş sayılabilir.
Hızlı iş büyümesi
Neden hemen yapılamadı? Sadece aşağıdaki çizelgelere bakın.
Ayrıca 2014-2015'te Romanya'da bir açılış vardı ve Amerika'da bir açılış hazırlanıyordu.
Ağ çok hızlı büyüdü, yeni ülkeler açıldı, yeni pizzacı formatları ortaya çıktı, örneğin yemek alanında bir pizzacı açıldı. Tüm bunlar, özellikle Dodo IS işlevlerinin genişletilmesine büyük önem verilmesini gerektiriyordu. Tüm bu işlevler olmadan, mutfakta takip olmadan, sistemdeki ürün ve kayıpların muhasebeleştirilmesinden, yemek mahkeme salonunda bir siparişin verildiğini göstermeden, “doğru” mimariden ve “doğru” yaklaşımdan bahsetmemiz pek mümkün değildir. şimdi geliştirme.
Mimarinin zamanında revize edilmesinin ve genel olarak teknik sorunların dikkate alınmasının önündeki bir diğer engel de 2014 kriziydi. Bunun gibi şeyler, özellikle Dodo Pizza gibi genç bir işletme için ekiplerin büyüme fırsatlarını olumsuz etkiler.
Yardımcı Olan Hızlı Çözümler
Sorunlar çözüm gerektiriyordu. Geleneksel olarak, çözümler 2 gruba ayrılabilir:
-
Yangını söndüren, küçük bir güvenlik payı sağlayan ve değişmemiz için bize zaman kazandıran hızlı olanlar.
-
Sistemik ve bu nedenle uzun. Bir dizi modülün yeniden yapılandırılması, yekpare bir mimarinin ayrı hizmetlere bölünmesi (çoğu mikro değil, makro hizmetlerdir ve bununla ilgili bir şeyler vardır) ).
Hızlı değişikliklerin kuru listesi aşağıdaki gibidir:
Temel ana ölçeği büyüt
Yüklerle başa çıkmak için yapılan ilk şey elbette sunucunun kapasitesini artırmaktır. Bu, ana veritabanı ve web sunucuları için yapıldı. Ne yazık ki, bu sadece belirli bir sınıra kadar mümkündür, sonra çok pahalı hale gelir.
2014 yılından itibaren Azure'a taşındık, bu konuyu da o dönemde “ yazımızda yazmıştık.". Ancak üs için sunucuda bir dizi artıştan sonra, maliyetle karşı karşıya kaldılar.
Okumak için temel kopyalar
Üs için iki kopya yapıldı:
Çoğaltmayı Oku referans talepleri için. Dizinleri, türü, şehri, caddeyi, pizzacıyı, ürünleri (yavaşça değişen etki alanı) ve küçük bir gecikmenin kabul edilebilir olduğu arayüzlerde okumak için kullanılır. Bu replikalardan 2 adet vardı, ustalarla aynı şekilde bulunabilirliğini sağladık.
Rapor İstekleri için ReadReplica. Bu veritabanının kullanılabilirliği daha düşüktü, ancak tüm raporlar ona gitti. Büyük veri yeniden hesaplamaları için ağır istekleri olmasına izin verin, ancak ana veritabanını ve operasyonel arayüzleri etkilemezler.
Koddaki önbellekler
Kodun hiçbir yerinde (hiçbir şekilde) önbellek yoktu. Bu, yüklenen veritabanına her zaman gerekli olmayan ek isteklere yol açtı. Önbellekler önce hem bellek içinde hem de Redis adlı harici bir önbellek hizmetindeydi. Her şey zamanla geçersiz kılındı, ayarlar kodda belirtildi.
Birden fazla arka uç sunucusu
Artan iş yüklerinin üstesinden gelmek için uygulamanın arka ucunun da ölçeklendirilmesi gerekiyordu. Bir iis sunucusundan bir küme oluşturmak gerekliydi. yeniden planladık bellekten RedisCache'e, bu da çok sayıda sunucuyu tek seferlik basit bir yük dengeleyicinin arkasında oluşturmayı mümkün kıldı. İlk başta, önbelleklerde olduğu gibi aynı Redis kullanıldı, ardından birkaç parçaya bölündü.
Sonuç olarak, mimari daha karmaşık hale geldi ...
… ama gerginliğin bir kısmı ortadan kalktı.
Ve sonra üstlendiğimiz yüklü bileşenleri yeniden yapmak gerekiyordu. Bir sonraki bölümde bunun hakkında konuşacağız.
Kaynak: habr.com