Habr dünyayı değiştiriyor. Bir yılı aşkın süredir blog yazıyoruz. Yaklaşık altı ay önce Khabrovsk sakinlerinden oldukça mantıklı geri bildirimler aldık: “Dodo, her yerde kendi sisteminin olduğunu söylüyorsun. Bu nasıl bir sistem? Peki pizza zincirinin buna neden ihtiyacı var?”
Oturduk düşündük ve haklı olduğunuzu anladık. Her şeyi parmaklarımızla anlatmaya çalışıyoruz ama yırtık pırtık çıkıyor ve hiçbir yerde sistemin tam açıklaması yok. Böylece bilgi toplama, yazar arama ve Dodo IS hakkında bir dizi makale yazma konusunda uzun bir yolculuk başladı. Hadi gidelim!
Teşekkür: Geri bildiriminizi bizimle paylaştığınız için teşekkür ederiz. Onun sayesinde nihayet sistemi tanımladık, bir teknoradar derledik ve yakında süreçlerimizin geniş bir tanımını yayınlayacağız. Sen olmasaydın 5 yıl daha böyle otururduk.
"Dodo IS Nedir?" başlıklı makale dizisi hakkında şunları söyler:
- Dodo IS'deki erken monolit (2011-2015). (Devam etmekte...)
- Arka ofis yolu: ayrı üsler ve veri yolu. (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...)
Başka bir şey öğrenmekle ilgileniyorsanız, yorumlara yazın.
Yazarın kronolojik açıklamasına ilişkin görüşü
Yeni çalışanlarla düzenli olarak “Sistem Mimarisi” konulu toplantılar yapıyorum. Buna "Dodo IS Mimarisine Giriş" adını veriyoruz ve yeni geliştiriciler için katılım sürecinin bir parçası. Mimarimiz hakkında, onun özellikleri hakkında şu ya da bu şekilde konuşarak, açıklamaya belirli bir tarihsel yaklaşım geliştirdim.
Geleneksel olarak, bir sistemi, bir hedefe ulaşmak için birbirleriyle etkileşime giren bir dizi bileşen (teknik veya daha üst düzey) ve iş modülleri olarak görüyoruz. Ve böyle bir görüş tasarım açısından haklı olsa da, tanımlama ve anlama açısından tamamen uygun değildir. Birkaç sebep var:
- Gerçek, kağıt üzerinde görünenden farklıdır. Her şey planlandığı gibi gitmiyor. Ve her şeyin gerçekte nasıl ortaya çıktığı ve çalıştığıyla ilgileniyoruz.
- Bilginin tutarlı sunumu. Aslında kronolojik olarak başlangıçtan şimdiki duruma gidebilirsiniz.
- Basitten karmaşığa. Evrensel değil ama bizim durumumuzda öyle. Mimarlık daha basit yaklaşımlardan daha karmaşık yaklaşımlara doğru ilerledi. Çoğu zaman, komplikasyon nedeniyle, uygulama hızı ve kararlılığı sorunlarının yanı sıra işlevsel olmayan gereksinimler listesinden düzinelerce başka özellik ( Karmaşıklığın diğer gereksinimlerle karşılaştırılması hakkında çok iyi konuşuldu).
2011'de Dodo IS mimarisi şöyle görünüyordu:
2020 yılına gelindiğinde ise durum biraz daha karmaşık hale geldi ve şu şekilde oldu:
Bu evrim nasıl gerçekleşti? Sistemin farklı bölümlerine neden ihtiyaç duyulur? Hangi mimari kararlar alındı ve neden? Bu makale dizisinde bunu öğrenelim.
2016'nın ilk sorunları: Hizmetler neden monolitten çıksın?
Serinin ilk yazıları monolitten ilk ayrılan hizmetler hakkında olacak. Sizi bağlam içine oturtmak için, 2016'nın başında sistemde ne gibi sorunlar yaşadığımızı, hizmetlerin ayrılığıyla uğraşmak zorunda kaldığımızı anlatacağım.
O dönemde Dodo IS'te bulunan tüm uygulamaların kayıtlarını yazdığı tek bir MySql veritabanı. Sonuçlar şunlardı:
- Ağır yük (isteklerin %85'i okunuyor).
- Taban büyüyordu. Bu nedenle maliyet ve destek sorun haline geldi.
- Tek başarısızlık noktası. Veritabanına yazan bir uygulama aniden bunu daha aktif bir şekilde yapmaya başlarsa, diğer uygulamalar da bu etkiyi hissetti.
- Depolama ve sorgularda verimsizlik. Çoğunlukla veriler, bazı senaryolar için uygun olan ancak diğerleri için uygun olmayan bir yapıda depolanıyordu. Dizinler bazı işlemleri hızlandırır ancak bazılarını yavaşlatabilir.
- Sorunların bir kısmı aceleyle oluşturulan önbellekler ve veritabanlarına okuma kopyaları ile çözüldü (bu ayrı bir makalede ele alınacak), ancak bunlar yalnızca zaman kazanmamıza izin verdi ve sorunu temelden çözmedi.
Sorun monolitin kendisinin varlığıydı. Sonuçlar şunlardı:
- Benzersiz ve nadir sürümler.
- Zorluk, çok sayıda insanın ortaklaşa geliştirilmesinde yatmaktadır.
- Yeni teknolojileri, yeni çerçeveleri ve kütüphaneleri tanıtamama.
Taban ve monolitle ilgili sorunlar, örneğin 2018'in başlarındaki kazalar bağlamında birçok kez anlatıldı (, и ), bu yüzden fazla üzerinde durmayacağım. Hizmetleri geliştirirken daha fazla esneklik sağlamak istediğimizi söylememe izin verin. Her şeyden önce bu, tüm sistemde en çok yüklü ve kök olanlarla ilgiliydi - Kimlik Doğrulama ve İzleyici.
Arka Ofis Yolu: Ayrı Üsler ve Otobüs
Bölümde Gezinme
Monolitin şeması 2016
İşte 2016 Dodo IS monolitinin ana blokları ve hemen altında ana görevlerinin bir dökümü.
Teslimat kasa masası. Kuryelerin muhasebesini yapmak, kuryelere sipariş vermek.
İletişim merkezi. Operatör aracılığıyla siparişleri kabul etmek.
yer. Web sitelerimiz (dodopizza.ru, dodopizza.co.uk, dodopizza.by, vb.).
auth. Arka ofis için yetkilendirme ve kimlik doğrulama hizmeti.
Трекер. Mutfak sipariş takibi. Sipariş hazırlarken hazırlık durumlarını işaretleme hizmeti.
Restoran kasa. Bir restoranda sipariş almak, kasiyer arayüzleri.
Ihracat. Muhasebe için raporları 1C'ye yükleme.
Uyarılar ve faturalar. Mutfakta sesli komutlar (örneğin, "Yeni pizza geldi") + kuryeler için faturaların yazdırılması.
Vardiya müdürü. Vardiya yöneticisinin çalışmasına yönelik arayüzler: sipariş listesi, verimlilik çizelgeleri, çalışanların vardiyalara getirilmesi.
Ofis Yöneticisi. Franchise sahiplerinin ve yöneticilerin çalışmalarına yönelik arayüzler: çalışanların kabulü, pizzacının çalışmaları hakkında raporlar.
Restoran panosu. Pizzacılardaki menülerin TV'lerde görüntülenmesi.
Admin Paneli. Belirli bir pizzacının ayarları: menü, fiyatlar, muhasebe, promosyon kodları, promosyonlar, site için bannerlar vb.
Çalışan Kişisel Hesabı. Çalışanların çalışma programları, çalışanlar hakkında bilgiler.
Mutfak Motivasyon Panosu. Mutfakta asılı olan ve pizza üreticilerinin hızını gösteren ayrı bir ekran.
Yakın İletişim. Sms ve e-posta gönderme.
DosyaDepolama. Statik dosyaların alınması ve verilmesi için kendi hizmeti.
Sorunları çözmeye yönelik ilk girişimler bize yardımcı oldu, ancak bunlar yalnızca geçici bir soluklanmaydı. Bunlar sistem çözümü haline gelmedi, dolayısıyla üslerle ilgili bir şeyler yapılması gerektiği açıktı. Örneğin, genel veritabanını daha özel birkaç veri tabanına bölün.
Monoliti boşaltmaya başlıyoruz: Auth ve Tracker'ın ayrılması
Daha sonra veritabanından diğerlerinden daha fazla yazan ve okuyan ana hizmetler:
- Yetki. Arka ofis için yetkilendirme ve kimlik doğrulama hizmeti.
- Takipçi. Mutfak sipariş takibi. Sipariş hazırlarken hazırlık durumlarını işaretleme hizmeti.
Auth ne yapar?
Kimlik doğrulama, kullanıcıların arka ofise giriş yapmasını sağlayan bir hizmettir (istemci tarafında ayrı bir bağımsız giriş vardır). Ayrıca doğru erişim haklarının mevcut olduğundan ve bu hakların son girişten bu yana değişmediğinden emin olmak için talepte de buna atıfta bulunulmaktadır. Cihazlar pizzacılara onun üzerinden giriyor.
Örneğin salonda asılı olan televizyonda tamamlanan siparişlerin durumunu gösteren bir ekran açmak istiyoruz. Daha sonra auth.dodopizza.ru'yu açıyoruz, “Cihaz olarak giriş yap” seçeneğini seçiyoruz, vardiya yöneticisinin bilgisayarındaki özel bir sayfaya girilebilen, cihazın (cihazın) türünü belirten bir kod beliriyor. TV, pizzacının istenen arayüzüne gidecek ve orada siparişleri hazır olan müşterilerin adlarını görüntülemeye başlayacak.
Yükler nereden geliyor?
Oturum açan her arka ofis kullanıcısı, her istek için veritabanına, kullanıcı tablosuna gider, bir sql sorgusu aracılığıyla kullanıcıyı oradan çeker ve bu sayfaya gerekli erişim ve haklara sahip olup olmadığını kontrol eder.
Cihazların her biri, rolünü ve erişimlerini kontrol ederek aynı işlemi yalnızca cihaz tablosuyla yapar. Ana veritabanına yapılan çok sayıda istek, bu işlemlerde yüklenmesine ve genel veritabanı kaynaklarının israfına yol açar.
Kimlik Doğrulaması Kaldırılıyor
Auth'un yalıtılmış bir alanı vardır; yani kullanıcılar, oturum açma bilgileri veya cihazlarla ilgili veriler hizmete girer (şu anda gelecekte) ve orada kalır. Birisinin bunlara ihtiyacı varsa, veri almak için bu hizmete gidecektir.
OLDU. İş akışı başlangıçta şu şekildeydi:
Nasıl çalıştığını biraz açıklamak isterim:
- Arka uca (burada Asp.Net MVC) harici bir istek gelir ve beraberinde Redis(1)'den oturum verilerini almak için kullanılan bir oturum çerezi gelir. Ya erişimlerle ilgili bilgileri içerir ve ardından denetleyiciye erişim açıktır (3,4) ya da değildir.
- Erişim yoksa yetkilendirme prosedürünü uygulamanız gerekir. Burada basitlik açısından aynı öznitelikteki yolun bir parçası olarak gösterilir, ancak bu giriş sayfasına bir geçiştir. Olumlu bir senaryo durumunda doğru şekilde doldurulmuş bir oturum alıp Backoffice Controller'a gideceğiz.
- Veri varsa, kullanıcı veritabanındaki alaka düzeyini kontrol etmeniz gerekir. Rolü değişti mi, artık sayfaya girmesine izin verilmemeli mi? Bu durumda oturumu (1) aldıktan sonra doğrudan veritabanına gitmeniz ve kimlik doğrulama mantık katmanını (2) kullanarak kullanıcının erişimini kontrol etmeniz gerekir. Ardından giriş sayfasına gidin veya denetleyiciye gidin. Bu basit bir sistemdir ancak tamamen standart değildir.
- Tüm prosedürler tamamlanırsa kontrolörler ve yöntemlerdeki mantığın daha da ilerisine atlarız.
Kullanıcı verileri diğer tüm verilerden ayrılır, ayrı bir üyelik tablosunda saklanır, AuthService mantık katmanındaki işlevler pekala API yöntemleri haline gelebilir. Etki alanının sınırları oldukça açık bir şekilde tanımlanmıştır: kullanıcılar, rolleri, erişim verileri, erişimin verilmesi ve iptali. Her şey ayrı bir hizmete taşınabilecek gibi görünüyor.
OLDU. Yaptıkları da buydu:
Bu yaklaşımın bir takım sorunları vardır. Örneğin, bir işlemin içindeki bir yöntemi çağırmak, http aracılığıyla harici bir hizmeti çağırmakla aynı şey değildir. Operasyonun gecikmesi, güvenilirliği, desteklenebilirliği ve şeffaflığı tamamen farklıdır. Andrey Morevsky raporunda tam olarak bu sorunlar hakkında daha ayrıntılı olarak konuştu .
Kimlik doğrulama hizmeti ve onunla birlikte cihaz hizmeti, arka ofis için, yani üretimde kullanılan hizmetler ve arayüzler için kullanılır. İstemci hizmetlerine (web sitesi veya mobil uygulama gibi) yönelik kimlik doğrulama, Kimlik Doğrulama kullanılmadan ayrı olarak gerçekleşir. Ayrılık yaklaşık bir yıl sürdü ve şimdi yine bu konu üzerinde çalışıyoruz ve sistemi yeni kimlik doğrulama hizmetlerine (standart protokollerle) aktarıyoruz.
Ayrılık neden bu kadar uzun sürdü?
Yol boyunca bizi yavaşlatan birçok sorun vardı:
- Ülke veritabanlarından kullanıcılar, cihazlar ve kimlik doğrulama verilerini tek bir veri tabanına aktarmak istedik. Bunu yapmak için, tüm tabloları ve kullanımı int tanımlayıcıdan global UUId tanımlayıcıya aktarmamız gerekti (yakın zamanda bu kodu yeniden düzenledik) ve açık kaynaklı proje ). Kullanıcı verilerinin saklanmasının (bu kişisel bir bilgi olduğundan) sınırlamaları vardır ve bazı ülkeler için bunların ayrı olarak saklanması gerekir. Ancak global bir kullanıcı kimliği olmalıdır.
- Veritabanındaki birçok tablo, işlemi gerçekleştiren kullanıcıya ilişkin denetim bilgilerine sahiptir. Bu, tutarlılığı sağlamak için ek bir mekanizma gerektiriyordu.
- API hizmetlerinin oluşturulmasından sonra uzun ve kademeli bir şekilde başka bir sisteme geçiş süreci yaşandı. Anahtarların kullanıcılar için sorunsuz bir şekilde gerçekleşmesi ve manuel çalışma gerektirmesi gerekiyordu.
Bir pizzacıya bir cihazı kaydetme şeması:
Kimlik Doğrulama ve Cihazlar hizmetinin ayrılmasından sonraki genel mimari:
Dikkat. 2020 yılı için Auth'un OAuth 2.0 yetkilendirme standardını temel alan yeni bir sürümü üzerinde çalışıyoruz. Bu standart oldukça karmaşıktır ancak uçtan uca kimlik doğrulama hizmeti geliştirmek için kullanışlıdır. Makalede "» biz Alexey Chernyaev, standart hakkında olabildiğince basit ve net bir şekilde konuşmaya çalıştık, böylece onu incelerken zaman kazanacaksınız.
Tracker ne işe yarar?
Şimdi yüklenen hizmetlerin ikincisi hakkında. İzleyici ikili bir rol üstlenir:
- Bir yandan görevi mutfaktaki çalışanlara şu anda hangi siparişlerin devam ettiğini, hangi ürünlerin şimdi hazırlanması gerektiğini göstermektir.
- Öte yandan mutfaktaki tüm süreçleri dijitalleştirin.
Bir siparişte yeni bir ürün (örneğin pizza) göründüğünde, bu ürün "Rolling" takip istasyonuna gider. Bu istasyonda, gerekli büyüklükte bir çörek alıp yuvarlayan bir pizza üreticisi var, ardından takip tabletine görevini tamamladığını işaretliyor ve açılan hamur tabanını bir sonraki istasyona - "Doldurma" aktarıyor. .
Orada, bir sonraki pizzacı pizzanın üzerine koyar ve tablet üzerinde görevini tamamladığını işaretleyerek pizzayı fırına koyar (bu da tablet üzerinde işaretlenmesi gereken ayrı bir istasyondur). Böyle bir sistem Dodo'da ve Dodo IS'in en başından beri mevcuttu. Tüm operasyonları tam olarak takip etmenize ve dijitalleştirmenize olanak tanır. Ayrıca takipçi, belirli bir ürünün nasıl hazırlanacağını önerir, her ürün tipini kendi üretim şemasına göre gerçekleştirir, ürün için en uygun pişirme süresini saklar ve ürün üzerindeki tüm işlemleri takip eder.
Raskatka izleme istasyonundaki tablet ekranı böyle görünüyor.
Yükler nereden geliyor?
Her pizzacıda takip cihazı bulunan yaklaşık beş tablet bulunur. 2016'da 100'den fazla pizzacımız vardı (şu anda 600'ün üzerinde). Tabletlerin her biri, her 10 saniyede bir arka uca istekte bulunur ve sipariş tablosundan (müşteri ve adresle bağlantı), sipariş kompozisyonundan (ürünle bağlantı ve miktar göstergesi) ve motivasyon tablosundan (takip eder) veri toplar. basma zamanı). Bir pizza üreticisi takipçideki bir ürüne tıkladığında tüm bu tablolardaki kayıtlar güncellenir. Sipariş tablosu geneldir; aynı anda bir siparişi kabul ederken eklemeleri, sistemin diğer bölümlerinden güncellemeleri ve örneğin bir pizzacıda asılı olan ve müşterilere hazır siparişleri gösteren bir TV'de çok sayıda okumayı içerir.
Yüklerle mücadele döneminde, her şey ve herkes önbelleğe alındığında ve veritabanının eşzamansız bir kopyasına aktarıldığında, izleyici ile yapılan bu işlemler ana veritabanına gitmeye devam etti. Burada herhangi bir gecikme olmaması gerekiyor, verilerin güncel olması gerekiyor, senkronizasyonun bozulması kabul edilemez.
Ayrıca üzerlerinde kendi tablo ve indekslerimizin bulunmaması, kullanımımıza özel daha spesifik sorgular yazmamıza olanak vermedi. Örneğin, bir takipçinin siparişler tablosunda bir pizzacıya ilişkin bir dizine sahip olması etkili olabilir. Pizzacı siparişlerini her zaman takip veritabanından alıyoruz. Aynı zamanda bir siparişi kabul etmek için hangi pizzacıya ait olduğu o kadar önemli değil, daha önemli olan bu siparişi hangi müşterinin verdiğidir. Bu, istemcide bir indeks olması gerektiği anlamına gelir. Takipçinin, basılı makbuzun kimliğini veya siparişle ilişkili bonus promosyonlarını sipariş tablosunda saklaması da gerekli değildir. Takip hizmetimiz bu bilgilerle ilgilenmiyor. Ortak bir monolitik veritabanında tablolar yalnızca tüm kullanıcılar arasında bir uzlaşma olabilir. Bu orijinal sorunlardan biriydi.
OLDU. Başlangıçta mimari şöyleydi:
Ayrı süreçlere ayrıldıktan sonra bile kod tabanının çoğu, farklı hizmetlerde ortak kaldı. Denetleyicilerin altındaki her şey birleştirildi ve tek bir depoda barındırıldı. Ortak hizmet yöntemleri, depolar ve ortak tabloları içeren ortak bir veritabanı kullanıldı.
İzleyiciyi Boşaltma
İzleyicinin temel sorunu, verilerin farklı veritabanları arasında senkronize edilmesinin gerekmesidir. Bu aynı zamanda Auth hizmetinin bölünmesinden temel farkıdır; sıra ve durumu değişebilir ve çeşitli hizmetlerde görüntülenmelidir.
Restoran Ödeme bölümünde siparişleri kabul ediyoruz (bu bir hizmettir), veritabanında "Kabul Edildi" durumunda saklanır. Bundan sonra durumunu birkaç kez daha değiştireceği izleyiciye gitmesi gerekir: "Mutfak" tan "Paketlenmiş" e. Bu durumda siparişle birlikte Kasiyer veya Vardiya Yöneticisi arayüzünden bazı dış etkiler meydana gelebilir. Sipariş durumlarını tabloda açıklamalarıyla birlikte vereceğim:
Sipariş durumu değişiklik şeması şuna benzer:
Durumlar farklı sistemler arasında değişir. Ve burada izleyici, verilerin kilitlendiği son sistem değildir. Böyle bir durumda ayırmaya yönelik birkaç olası yaklaşımı gördük:
- Tüm sipariş eylemlerini tek bir hizmette yoğunlaştırıyoruz. Bizim durumumuzda bu seçenek, siparişi işlemek için çok fazla hizmet gerektiriyor. Eğer orada dursaydık ikinci bir monolitle karşı karşıya kalacaktık. Sorunları çözemezdik.
- Bir sistem diğerine çağrı yapar. İkinci seçenek daha ilginç. Ancak bununla birlikte çağrı zincirleri mümkündür (), bileşenlerin bağlantısı daha yüksektir ve yönetimi daha zordur.
- Etkinlikler düzenliyoruz ve bu etkinlikler aracılığıyla her hizmet birbiriyle alışveriş yapıyor. Sonuç olarak, tüm hizmetlerin birbirleriyle etkinlik alışverişinde bulunmaya başladığı üçüncü seçenek seçildi.
Üçüncü seçeneği seçmemiz, tracker'ın kendi veri tabanına sahip olacağı ve sıralamadaki her değişiklikte bununla ilgili bir olay göndereceği, diğer servislerin abone olacağı ve ana veri tabanına dahil edileceği anlamına geliyordu. Bunu yapmak için servisler arasında mesajların iletilmesini sağlayacak bir servise ihtiyacımız vardı.
O zamana kadar zaten RabbitMQ'yu yığında bulunduruyorduk, dolayısıyla onu bir mesaj aracısı olarak kullanma konusundaki son kararımızdı. Diyagram, bir siparişin Restoran Kasiyerinden Takipçiye geçişini gösterir; burada siparişin durumunu değiştirir ve Yöneticinin Siparişler arayüzündeki görünümünü değiştirir. WAS:
Yolu adım adım sıralayın
Sipariş yolu, sipariş kaynağı hizmetlerinden birinde başlar. İşte Restoran Kasiyeri:
- Sipariş, Ödeme bölümünde tamamen hazırdır ve takipçiye gönderme zamanı gelmiştir. İzleyicinin abone olduğu etkinlik atılır.
- Siparişi kabul eden takipçi, bunu kendi veritabanına kaydederek “Sipariş Takipçi Tarafından Kabul Edildi” olayı yaparak RMQ'ya gönderir.
- Birçok işleyici zaten özel olay veriyoluna abone oldu. Bizim için monolitik veritabanıyla senkronize olan önemli.
- İşleyici olayı alır, kendisi için önemli olan verileri seçer: bizim durumumuzda bu, "İzleyici Tarafından Kabul Edildi" sipariş durumudur ve ana veritabanındaki sipariş varlığını günceller.
Birisinin özellikle monolitik siparişler tablosundan bir siparişe ihtiyacı varsa, onu oradan da okuyabilir. Örneğin, Vardiya Yöneticisindeki Siparişler arayüzünün ihtiyacı olan şey budur:
Diğer tüm hizmetler, kendileri için kullanmak üzere izleyiciden etkinlik siparişi vermek üzere abone olabilir.
Bir sipariş bir süre sonra üretime alınırsa, önce veritabanındaki (Tracker veritabanı) durumu değişir ve ardından hemen "OrderInWork" olayı oluşturulur. Aynı zamanda yekpare bir veritabanında senkronize edildiği ve diğer hizmetlere iletildiği RMQ'ya da girer. Bu yolda çeşitli sorunlar olabilir; bunlar hakkında daha fazla ayrıntı Zhenya Peshkov'un raporunda bulunabilir. .
Auth ve Tracker'daki değişikliklerden sonra son mimari
Özetlemek: Başlangıçta Dodo IS sisteminin dokuz yıllık geçmişini tek bir makalede toplama fikri aklıma geldi. Hızlı ve basit bir şekilde evrimin aşamalarından bahsetmek istedim. Ancak materyali incelemek için oturduğumda her şeyin göründüğünden çok daha karmaşık ve ilginç olduğunu fark ettim.
Bu tür materyallerin yararları (veya eksikliği) üzerine düşünerek, olayların tam kapsamlı kayıtları, ayrıntılı geriye dönük değerlendirmeler ve kişinin geçmiş kararlarının analizi olmadan sürekli gelişimin imkansız olduğu sonucuna vardım.
Umarım yolculuğumuz hakkında bilgi almayı faydalı ve ilginç bulmuşsunuzdur. Şimdi bir sonraki makalede Dodo IS sisteminin hangi bölümünü anlatacağıma dair bir seçimle karşı karşıyayım: yorumlara yazın veya oy verin.
Ankete sadece kayıtlı kullanıcılar katılabilir. Lütfen.
Bir sonraki makalede Dodo IS'in hangi bölümünü öğrenmek istersiniz?
-
%24,1Dodo IS'deki ilk monolit (2011-2015)14
-
%24,1İlk problemler ve çözümleri (2015-2016)14
-
%20,7Müşteri kısmının yolu: tabanın üstündeki cephe (2016-2017)12
-
%36,2Gerçek mikro hizmetlerin tarihi (2018-2019)21
-
%44,8Monolitin kesilmesi ve mimarinin stabilizasyonu tamamlandı26
-
%29,3Sistemin geliştirilmesine yönelik diğer planlar hakkında17
-
%19,0Dodo IS11 hakkında hiçbir şey bilmek istemiyorum
58 kullanıcı oy kullandı. 6 kişi çekimser kaldı.
Kaynak: habr.com