Хабр әлемді өзгертеді. Бір жылдан астам уақыт бойы блог жүргізіп келеміз. Шамамен алты ай бұрын біз Хабровиттерден толық логикалық пікір алдық: «Додо, сіз барлық жерде сіздің жеке жүйеңіз бар деп айтасыз. Ал бұл жүйе қандай? Ал пицца желісі не үшін қажет?
Отырдық, ойланып, сенің дұрыс екеніңді түсіндік. Біз барлығын саусақпен түсіндіруге тырысамыз, бірақ ол жыртылған бөліктерде шығады және еш жерде жүйенің толық сипаттамасы жоқ. Осылайша Dodo IS туралы ақпарат жинау, авторларды іздеу және бірқатар мақалалар жазудың ұзақ сапары басталды. Барайық!
Алғыс: Пікіріңізді бізбен бөліскеніңізге рахмет. Оның арқасында біз жүйені сипаттадық, технорадар құрастырдық және жақын арада біздің процестеріміздің үлкен сипаттамасын шығарамыз. Сен болмасаң тағы 5 жыл осылай отыратын едік.
«Dodo IS дегеніміз не?» Мақалалар топтамасы. туралы айтып береді:
- Dodo IS-тегі ерте монолит (2011-2015). (Орындалуда...)
- Бэк-офис жолы: бөлек базалар мен автобус. (Сен мындасың)
- Клиент бөлігінің жолы: базаның үстіндегі қасбет (2016-2017). (Орындалуда...)
- Шынайы микросервистердің тарихы. (2018-2019). (Орындалуда...)
- Монолитті аралау және сәулетті тұрақтандыру аяқталды. (Орындалуда...)
Егер сізді тағы бір нәрсе білгіңіз келсе - түсініктемелерде жазыңыз.
Автордан хронологиялық сипаттама туралы пікір
«Жүйелік архитектура» тақырыбына жаңадан келген қызметкерлерге кездесуді жиі өткізіп тұрамын. Біз оны «Dodo IS архитектурасына кіріспе» деп атаймыз және бұл жаңа әзірлеушілер үшін жұмысқа кірісу процесінің бөлігі болып табылады. Біздің сәулет өнері туралы, оның ерекшеліктері туралы бір немесе басқа түрде айта отырып, мен суреттеуге белгілі бір тарихи көзқарасты тудым.
Дәстүрлі түрде жүйеге қандай да бір мақсатқа жету үшін бір-бірімен әрекеттесетін компоненттердің (техникалық немесе жоғары деңгейлі), бизнес модульдердің жиынтығы ретінде қарастырамыз. Ал егер мұндай көзқарас дизайн үшін ақталған болса, онда ол сипаттау мен түсіну үшін өте қолайлы емес. Мұнда бірнеше себептер бар:
- Шындық қағаздағыдан бөлек. Барлығы ойдағыдай бола бермейді. Бізді оның іс жүзінде қалай болғаны және жұмыс істейтіні қызықтырады.
- Ақпаратты дәйекті ұсыну. Шын мәнінде, сіз басынан бастап қазіргі күйге дейін хронологиялық жолмен жүре аласыз.
- Қарапайымнан күрделіге. Әмбебап емес, бірақ біздің жағдайда солай. Архитектура қарапайым әдістерден күрделіге көшті. Көбінесе, орындау жылдамдығы мен тұрақтылығының проблемалары, сондай-ақ функционалды емес талаптар тізімінен ондаған басқа қасиеттердің асқынуы арқылы жиі кездеседі ( күрделілікті басқа талаптарға қарсы қою туралы жақсы айтылды).
2011 жылы Dodo IS архитектурасы келесідей болды:
2020 жылға қарай ол біршама күрделене түсті және келесідей болды:
Бұл эволюция қалай болды? Жүйенің әртүрлі бөліктері не үшін қажет? Қандай архитектуралық шешімдер қабылданды және неліктен? Осы мақалалар топтамасынан білейік.
2016 жылдың бірінші проблемалары: неге қызметтер монолиттен шығуы керек?
Сериядағы алғашқы мақалалар монолиттен бірінші болып бөлінген қызметтер туралы болмақ. Сізді контекстке келтіру үшін мен сізге 2016 жылдың басында жүйеде қандай проблемалар болғанын, қызметтерді бөлумен айналысуға тура келгенін айтамын.
Бір MySql дерекқоры, сол кезде Dodo IS жүйесінде болған барлық қолданбалар өз жазбаларын жазды. Оның салдары болды:
- Ауыр жүктеме (сұраулардың 85% оқылады).
- База өсті. Осыған байланысты шығындар мен қолдау мәселесі болды.
- Бір сәтсіздік нүктесі. Егер дерекқорға жазатын бір қолданба кенеттен оны белсендірек істей бастаса, басқа қолданбалар оны өздері сезді.
- Сақтау мен сұраудың тиімсіздігі. Көбінесе деректер кейбір сценарийлер үшін ыңғайлы, бірақ басқалары үшін емес, кейбір құрылымда сақталады. Индекстер кейбір операцияларды жылдамдатады, бірақ басқаларды баяулатуы мүмкін.
- Кейбір мәселелер асығыс жасалған кэштер мен негіздерге оқу-көшірмелері арқылы жойылды (бұл жеке мақала болады), бірақ олар тек уақытты ұтуға мүмкіндік берді және мәселені түбегейлі шешпеді.
Мәселе монолиттің өзінде болды. Оның салдары болды:
- Бірыңғай және сирек шығарылымдар.
- Көптеген адамдардың бірлескен дамуының қиындығы.
- Жаңа технологияларды, жаңа фреймворктарды және кітапханаларды енгізе алмау.
Негізге және монолитке қатысты мәселелер бірнеше рет сипатталған, мысалы, 2018 жылдың басындағы апаттар контекстінде (, и ), сондықтан мен көп тоқталмаймын. Біз қызметтерді дамыту кезінде көбірек икемділік бергіміз келгенін айтайын. Ең алдымен, бұл бүкіл жүйеде ең жүктелген және түбірлі болғандарға қатысты - Auth және Tracker.
Бэк-офис жолы: бөлек базалар мен автобус
Тарауды шарлау
Монолит схемасы 2016 ж
Міне, 2016 жылғы Dodo IS монолитінің негізгі блоктары, ал төменде олардың негізгі міндеттерінің қысқаша мазмұны берілген.
Жеткізу кассасы. Курьерлерді есепке алу, курьерлерге бұйрықтар беру.
Байланыс орталығы. Оператор арқылы тапсырыстарды қабылдау.
Сайт. Біздің веб-сайттар (dodopizza.ru, dodopizza.co.uk, dodopizza.by және т.б.).
Шындық. Бэк-офиске авторизация және аутентификация қызметі.
Tracker. Ас үйде трекерге тапсырыс беріңіз. Тапсырысты дайындау кезінде әзірлік күйлерін белгілеу қызметі.
Мейрамхананың кассасы. Мейрамханада тапсырыстарды қабылдау, кассир интерфейстері.
экспорт. Бухгалтерлік есеп үшін 1С-те есептерді жүктеу.
Ескертулер мен шот-фактуралар. Ас үйдегі дауыстық командалар (мысалы, «Жаңа пицца келді») + курьерлер үшін шот-фактураларды басып шығару.
Ауысым менеджері. Ауысым бастығының жұмысына арналған интерфейстер: тапсырыстар тізімі, өнімділік диаграммалары, қызметкерлерді ауысымға жеткізу.
Офис-менеджер. Франчайзилер мен менеджерлердің жұмысына арналған интерфейстер: қызметкерлерді қабылдау, пиццерияның жұмысы туралы есептер.
Мейрамхана тақтасы. Пиццериялардағы теледидарлардағы мәзірді көрсету.
админ. Белгілі бір пиццерияға арналған параметрлер: мәзір, бағалар, бухгалтерлік есеп, жарнамалық кодтар, акциялар, сайтқа арналған баннерлер және т.б.
Қызметкердің жеке кабинеті. Қызметкерлердің жұмыс кестесі, қызметкерлер туралы ақпарат.
Ас үйге арналған мотивациялық тақта. Ас үйде ілулі тұрған және пицца жасаушылардың жылдамдығын көрсететін бөлек экран.
қарым-қатынас. SMS және электрондық поштаны жіберу.
FileStorage. Статикалық файлдарды қабылдау және шығару үшін меншікті қызмет.
Мәселелерді шешудің алғашқы әрекеттері бізге көмектесті, бірақ олар уақытша тынығу болды. Олар жүйелік шешімдерге айналмады, сондықтан базалармен бірдеңе істеу керек екені анық болды. Мысалы, жалпы мәліметтер базасын тағы бірнеше мамандандырылғанға бөліңіз.
Біз монолитті түсіре бастаймыз: аутентификация мен трекерді бөлу
Дерекқордан басқаларға қарағанда көбірек жазылған және оқитын негізгі қызметтер:
- Автор. Бэк-офиске авторизация және аутентификация қызметі.
- Трекер. Ас үйде трекерге тапсырыс беріңіз. Тапсырысты дайындау кезінде әзірлік күйлерін белгілеу қызметі.
Auth не істейді?
Auth – пайдаланушылар бэк-офиске кіретін қызмет (клиент жағында жеке тәуелсіз кіру жолы бар). Сондай-ақ ол сұрауда қажетті қол жеткізу құқықтарының бар екеніне және бұл құқықтардың соңғы кіруден бері өзгермегеніне көз жеткізу үшін шақырылады. Ол арқылы құрылғылар пиццерияға кіреді.
Мысалы, залда ілулі тұрған теледидардан дайын тапсырыстардың күйлері жазылған дисплей ашқымыз келеді. Содан кейін біз auth.dodopizza.ru сайтын ашамыз, «Құрылғы ретінде кіру» тармағын таңдаймыз, құрылғының (құрылғының) түрін көрсететін ауысым менеджерінің компьютеріндегі арнайы бетке енгізуге болатын код пайда болады. Теледидардың өзі пиццериясының қалаған интерфейсіне ауысады және тапсырыстары сол жерде дайын тұтынушылардың атын көрсете бастайды.
Жүктер қайдан келеді?
Жүйеге кірген әрбір бэк-офис пайдаланушысы әрбір сұрау үшін дерекқорға, пайдаланушы кестесіне барады, пайдаланушыны sql сұрауы арқылы сол жерден шығарып, оның осы бетке қажетті рұқсаты мен құқықтары бар-жоғын тексереді.
Құрылғылардың әрқайсысы оның рөлін және кіру мүмкіндіктерін тексере отырып, тек құрылғы кестесімен бірдей әрекет жасайды. Негізгі дерекқорға сұраныстардың көп болуы оның жүктелуіне және осы операцияларға жалпы дерекқор ресурстарының ысырап болуына әкеледі.
Аутентификацияны түсіру
Auth оқшауланған доменге ие, яғни пайдаланушылар, логиндер немесе құрылғылар туралы деректер қызметке кіреді (қазіргі болашақта) және сол жерде қалады. Егер олар біреуге қажет болса, ол деректер үшін осы қызметке барады.
ОЛ БОЛДЫ. Жұмыс барысы бастапқыда былай болды:
Мен оның қалай жұмыс істейтінін аздап түсіндіргім келеді:
- Сыртқы сұрау серверге (Asp.Net MVC сол жерде) келеді, өзімен бірге Redis(1) сеанс деректерін алу үшін пайдаланылатын сеанс кукиін әкеледі. Ол рұқсаттар туралы ақпаратты қамтиды, содан кейін контроллерге қол жеткізу ашық (3,4) немесе жоқ.
- Егер рұқсат болмаса, авторизация процедурасынан өту керек. Мұнда қарапайымдылық үшін ол сол атрибуттағы жолдың бөлігі ретінде көрсетіледі, дегенмен бұл кіру бетіне өту. Оң сценарий болған жағдайда, біз дұрыс толтырылған сеансты аламыз және Backoffice Controller-ге барамыз.
- Деректер бар болса, оны пайдаланушы дерекқорында сәйкестігін тексеру керек. Оның рөлі өзгерді ме, енді оны парақшаға кіргізбеу керек пе? Бұл жағдайда (1) сеансты алғаннан кейін дерекқорға тікелей өту керек және аутентификация логикалық қабаты (2) арқылы пайдаланушының кіру мүмкіндігін тексеру керек. Әрі қарай, кіру бетіне өтіңіз немесе контроллерге өтіңіз. Бұл қарапайым жүйе, бірақ толығымен стандартты емес.
- Егер барлық процедуралар орындалса, біз контроллерлер мен әдістердегі логиканы әрі қарай өткізіп жібереміз.
Пайдаланушы деректері барлық басқа деректерден бөлінген, олар бөлек мүшелік кестеде сақталады, AuthService логикалық қабатының функциялары API әдістеріне айналуы мүмкін. Доменнің шекаралары өте анық анықталған: пайдаланушылар, олардың рөлдері, қол жеткізу деректері, рұқсатты беру және қайтарып алу. Барлығын бөлек қызметке ауыстыруға болатын сияқты.
БОЛДЫ. Олар осылай істеді:
Бұл тәсілдің бірқатар проблемалары бар. Мысалы, процестің ішіндегі әдісті шақыру http арқылы сыртқы қызметті шақырумен бірдей емес. Операцияның кешігуі, сенімділігі, қолдау мүмкіндігі және ашықтығы мүлдем басқа. Андрей Моревский өз баяндамасында дәл осы мәселелер туралы толығырақ айтып берді .
Аутентификация қызметі және онымен бірге құрылғы қызметі бэк-офис үшін, яғни өндірісте қолданылатын қызметтер мен интерфейстер үшін пайдаланылады. Клиенттік қызметтерді (веб-сайт немесе мобильді қолданба сияқты) аутентификация аутентификацияны пайдаланбай бөлек орындалады. Бөлу шамамен бір жылға созылды, енді біз жүйені аутентификацияның жаңа қызметтеріне (стандартты хаттамалармен) ауыстыра отырып, осы тақырыппен қайтадан жұмыс істеп жатырмыз.
Неліктен ажырасу ұзаққа созылды?
Жолда бізді баяулататын көптеген мәселелер болды:
- Біз ел дерекқорларынан пайдаланушылар, құрылғылар және аутентификация туралы деректерді бір дерекқорға тасымалдағымыз келді. Ол үшін барлық кестелер мен пайдалануды int идентификаторынан ғаламдық UUId идентификаторына тасымалдауға тура келді (жақында біз бұл кодты қайта өңдедік. және ашық бастапқы жоба ). Пайдаланушы деректерін сақтаудың (бұл жеке ақпарат болғандықтан) шектеулері бар және кейбір елдер үшін оны бөлек сақтау қажет. Бірақ ғаламдық пайдаланушы идентификаторы болуы керек.
- Дерекқордағы көптеген кестелерде операцияны орындаған пайдаланушы туралы аудит ақпараты бар. Бұл жүйелілікті қамтамасыз ету үшін қосымша механизмді қажет етті.
- api-қызметтері құрылғаннан кейін басқа жүйеге өтудің ұзақ және біртіндеп кезеңі болды. Ауыстыру пайдаланушылар үшін біркелкі болуы және қолмен жұмыс істеуі қажет болды.
Пиццерияда құрылғыны тіркеу схемасы:
Auth and Devices қызметін шығарып алғаннан кейінгі жалпы архитектура:
ескерту. 2020 жылға біз OAuth 2.0 авторизация стандартына негізделген Auth бағдарламасының жаңа нұсқасымен жұмыс істеп жатырмыз. Бұл стандарт өте күрделі, бірақ түпкілікті аутентификация қызметін әзірлеу үшін пайдалы. мақаласында «» біз Алексей Черняев стандартты оқуға уақытыңызды үнемдеу үшін мүмкіндігінше қарапайым және анық айтуға тырыстық.
Tracker не істейді?
Енді жүктелген қызметтердің екіншісі туралы. Трекер қос рөл атқарады:
- Бір жағынан, оның міндеті асханадағы қызметкерлерге қазіргі уақытта қандай тапсырыстар жұмыс істеп жатқанын, қазір қандай өнімдерді пісіру керек екенін көрсету.
- Екінші жағынан, ас үйдегі барлық процестерді цифрландыру.
Жаңа өнім (мысалы, пицца) тапсырыста пайда болғанда, ол «Rolling» трекер станциясына өтеді. Бұл станцияда пицца жасаушы бар, ол қажетті мөлшердегі тоқашты алып, оны жайып тастайды, содан кейін ол тапсырманы орындағанын трекер планшетінде белгілейді және жайылған қамыр негізін келесі станцияға береді - «Толтыру» .
Онда келесі пицца жасаушы пиццаны толтырады, содан кейін планшетте өзінің тапсырмасын орындағанын және пиццаны пешке қоятынын белгілейді (бұл да планшетте белгіленетін жеке станция). Мұндай жүйе Додода ең басынан бастап және Додо IS өмір сүрген кезден бастап болды. Ол барлық транзакцияларды толығымен қадағалауға және цифрландыруға мүмкіндік береді. Сонымен қатар, трекер белгілі бір өнімді қалай дайындау керектігін ұсынады, өнімнің әр түрін оның өндіру схемаларына сәйкес бағыттайды, өнімді дайындаудың оңтайлы уақытын сақтайды және өнімдегі барлық операцияларды бақылайды.
«Раскатка» трекерінің станциясында планшеттің экраны осылай көрінеді.
Жүктер қайдан келеді?
Пиццериялардың әрқайсысында трекері бар шамамен бес таблетка бар. 2016 жылы бізде 100-ден астам пиццерия болды (қазір 600-ден астам). Планшеттердің әрқайсысы 10 секунд сайын серверге сұраныс жасайды және тапсырыс кестесінен (клиентпен және мекен-жаймен байланыс), тапсырыс құрамынан (өніммен байланыс және санының көрсеткіші), мотивацияны есепке алу кестесінен (таблицадан) деректерді алып тастайды. онда басу уақыты бақыланады). Пицца жасаушы трекердегі өнімді басқанда, осы кестелердің барлығындағы жазбалар жаңартылады. Тапсырыс кестесі жалпы болып табылады, ол сондай-ақ тапсырысты қабылдау кезінде кірістірулерді, жүйенің басқа бөліктерінен жаңартуларды және көптеген көрсеткіштерді қамтиды, мысалы, пиццерияда ілулі тұрған теледидарда және тұтынушыларға дайын тапсырыстарды көрсетеді.
Жүктемелермен күресу кезеңінде, барлығы және барлығы кэштелген және дерекқордың асинхронды көшірмесіне ауыстырылған кезде, трекермен бұл әрекеттер негізгі дерекқорға өтуді жалғастырды. Бұл жерде кідіріс болмауы керек, деректер жаңартылған болуы керек, синхрондалмаған болуы мүмкін емес.
Сондай-ақ, жеке кестелер мен олардағы индекстердің болмауы оларды пайдалану үшін бейімделген нақтырақ сұрауларды жазуға мүмкіндік бермеді. Мысалы, трекер үшін тапсырыс үстелінде пиццерия индексі болуы тиімді болуы мүмкін. Біз әрқашан пиццерияға тапсырыстарды трекер дерекқорынан алып тастаймыз. Сонымен қатар, тапсырысты алу үшін оның қай пиццерияға түсетіні маңызды емес, бұл тапсырысты қай клиент жасағаны маңыздырақ. Және бұл жерде клиенттің индексі қажет дегенді білдіреді. Сондай-ақ трекерге басып шығарылған түбіртектің идентификаторын немесе тапсырыспен байланысты бонустық жарнамаларды тапсырыс кестесінде сақтау қажет емес. Бұл ақпарат біздің трекер қызметімізді қызықтырмайды. Жалпы монолитті дерекқорда кестелер тек барлық пайдаланушылар арасындағы компромисс болуы мүмкін. Бұл бастапқы мәселелердің бірі болды.
ОЛ БОЛДЫ. Бастапқыда сәулет келесідей болды:
Жеке процестерге бөлінгеннен кейін де, кодтық базаның көпшілігі әртүрлі қызметтер үшін ортақ болып қала берді. Контроллерлердің астындағылардың бәрі жалғыз болды және бір репозиторийде өмір сүрді. Біз қызмет көрсетудің жалпы әдістерін, репозиторийлерді, ортақ кестелер орналасқан ортақ базаны қолдандық.
Трекерді түсіру
Трекердің негізгі мәселесі - деректер әртүрлі дерекқорлар арасында синхрондалу керек. Бұл сонымен қатар оның Auth қызметін бөлуден басты айырмашылығы, тәртіп пен оның күйі өзгеруі мүмкін және әртүрлі қызметтерде көрсетілуі керек.
Біз тапсырыстарды мейрамхана кассасында қабылдаймыз (бұл қызмет), ол дерекқорда «Қабылданды» күйінде сақталады. Осыдан кейін ол трекерге өтуі керек, онда ол өзінің күйін тағы бірнеше рет өзгертеді: «Ас үйден» «Қаптамаға» дейін. Бұл жағдайда тапсырыспен Кассир немесе Shift Manager интерфейсінің кейбір сыртқы әсерлері болуы мүмкін. Мен тапсырыс күйлерін кестеде олардың сипаттамасымен беремін:
Тапсырыс күйін өзгерту схемасы келесідей көрінеді:
Күйлер әртүрлі жүйелер арасында өзгереді. Және бұл жерде трекер деректер құлыпталған соңғы жүйе емес. Біз мұндай жағдайда бөлудің бірнеше ықтимал тәсілдерін көрдік:
- Біз барлық тапсырыс әрекеттерін бір қызметке шоғырландырамыз. Біздің жағдайда бұл опция тапсырыспен жұмыс істеу үшін тым көп қызметті қажет етеді. Осыған тоқталсақ, екінші монолитті алар едік. Біз мәселені шешпейтін едік.
- Бір жүйе екіншісіне қоңырау шалады. Екінші нұсқа қызықтырақ. Бірақ онымен қоңыраулар тізбегі мүмкін (), құрамдастардың қосылуы жоғары, оны басқару қиынырақ.
- Біз іс-шаралар ұйымдастырамыз және әрбір қызмет осы іс-шаралар арқылы басқалармен байланысады. Нәтижесінде үшінші нұсқа таңдалды, оған сәйкес барлық қызметтер бір-бірімен оқиғаларды алмастыра бастайды.
Үшінші нұсқаны таңдағанымыз трекердің жеке деректер базасы болатынын және әрбір ретті өзгерту үшін ол осы туралы оқиғаны жіберетінін, басқа қызметтер жазылатын және негізгі дерекқорға қосылатынын білдірді. Ол үшін бізге қызметтер арасындағы хабарламаларды жеткізуді қамтамасыз ететін қандай да бір қызмет қажет болды.
Осы уақытқа дейін бізде RabbitMQ стекте болды, сондықтан оны хабарлама брокері ретінде пайдалану туралы соңғы шешім қабылданды. Диаграмма тапсырыстың мейрамхана кассирінен бақылаушы арқылы ауысуын көрсетеді, онда ол оның күйін өзгертеді және Менеджер тапсырыстары интерфейсінде көрсетіледі. БОЛУ:
Қадамдық жолға тапсырыс беріңіз
Тапсырыс жолы тапсырыс көзі қызметтерінің бірінен басталады. Міне, мейрамхананың кассирі:
- Тапсырыс кассада толығымен дайын және оны трекерге жіберу уақыты келді. Трекер жазылған оқиға лақтырылады.
- Трекер тапсырысты қабылдай отырып, оны өзінің дерекқорында сақтайды, «Тапсырысты бақылаушы қабылдады» оқиғасын жасайды және оны RMQ-ге жібереді.
- Тапсырыс үшін оқиға автобусына жазылған бірнеше өңдеушілер бар. Біз үшін монолитті негізбен синхрондауды жасайтын маңызды.
- Өңдеуші оқиғаны алады, одан ол үшін маңызды деректерді таңдайды: біздің жағдайда бұл «Трекер қабылдаған» тапсырыс күйі және негізгі дерекқордағы оның тапсырыс нысанын жаңартады.
Егер біреуге монолитті тапсырыстар кестесінен тапсырыс қажет болса, олар оны сол жерден де оқи алады. Мысалы, Shift Manager ішіндегі Тапсырыстар интерфейсіне мыналар қажет:
Барлық басқа қызметтер өздері үшін пайдалану үшін трекерден оқиғаларға тапсырыс беруге жазыла алады.
Егер біраз уақыттан кейін тапсырыс өндіріске қабылданса, оның күйі алдымен дерекқорында (Tracker дерекқоры) өзгереді, содан кейін «OrderInWork» оқиғасы бірден жасалады. Ол сонымен қатар монолитті дерекқорда синхрондалатын және басқа қызметтерге жеткізілетін RMQ-ға түседі. Бұл жолда әртүрлі мәселелер болуы мүмкін, олар туралы толығырақ Женя Пешковтың баяндамасынан табуға болады .
Auth және Tracker өзгерістерінен кейінгі соңғы архитектура
Қорытындылай келе: Бастапқыда менде Dodo IS жүйесінің тоғыз жылдық тарихын бір мақалаға жинақтау идеясы болды. Мен эволюция кезеңдері туралы тез және қарапайым айтқым келді. Дегенмен, материалды зерделеуге отырып, мен бәрі көрінгеннен әлдеқайда күрделі және қызықты екенін түсіндім.
Мұндай материалдың пайдасы (немесе жоқтығы) туралы ой жүгірте отырып, мен оқиғалардың толыққанды хроникасы, егжей-тегжейлі ретроспективалары және өткен шешімдерін талдаусыз үздіксіз даму мүмкін емес деген қорытындыға келдім.
Біздің жолымызды білу сізге пайдалы және қызықты болды деп үміттенемін. Енді мен келесі мақалада Dodo IS жүйесінің қай бөлігін сипаттау керектігін таңдау алдында тұрмын: түсініктемелерде жазыңыз немесе дауыс беріңіз.
Сауалнамаға тек тіркелген пайдаланушылар қатыса алады. , өтінемін.
Келесі мақалада Dodo IS бағдарламасының қай бөлігі туралы білгіңіз келеді?
-
24,1%Додо АЖ-дағы ерте монолит (2011-2015)14
-
24,1%Алғашқы мәселелер және оларды шешу жолдары (2015-2016 ж.)14
-
20,7%Клиенттік жол: негіз үстінен қасбет (2016-2017)12
-
36,2%Шынайы микросервистердің тарихы (2018-2019)21
-
44,8%Монолитті толық кесу және архитектураны тұрақтандыру26
-
29,3%Жүйені дамытудың алдағы жоспарлары туралы17
-
19,0%Мен Dodo IS11 туралы ештеңе білгім келмейді
58 пайдаланушы дауыс берді. 6 пайдаланушы қалыс қалды.
Ақпарат көзі: www.habr.com