Добры дзень, калегі.
Сёння на ваш суд прапануецца пераклад артыкула Тугберка Угурлу (Tugberk Ugurlu), які ўзяўся ў параўнальна невялікім аб'ёме выкласці прынцыпы праектавання сучасных софтверных сістэм. Вось што аўтар паведамляе пра сябе ў сухой рэштцы:
Паколькі рашуча немагчыма ахапіць у хабраартыку такую каласальную тэму, як архітэктурныя патэрны + патэрны праектавання па стане на 2019 год, рэкамендуем не толькі сам тэкст спадара Уруглу, але і шматлікія спасылкі, якія ён у ім ласкава расставіў. Калі вам спадабаецца - апублікуем і больш вузкаспецыяльны тэкст аб праектаванні размеркаваных сістэм.
здымак з сайта Unsplash
Калі вам ніколі не даводзілася сутыкацца з такімі выклікамі, як праектаванне софтвернай сістэмы з нуля, то, прыступаючы да такой працы, часам нават не зразумела, з чаго пачаць. Я лічу, што спачатку патрабуецца акрэсліць межы, каб больш-менш упэўнена ўяўляць, што менавіта вы збіраецеся спраектаваць, а затым - закатаць рукавы і працаваць, не выходзячы за гэтыя межы. У якасці адпраўной кропкі можна ўзяць які-небудзь прадукт ці сэрвіс (у ідэале - такі, што вам вельмі падабаецца) і разабрацца ў яго рэалізацыі. Магчыма, вы ўразіцеся, наколькі проста выглядае дадзены прадукт, і якая велізарная складанасць у ім насамрэч утоена. Не забывайце: , і гэта нармальна.
Думаю, найлепшая рада, якую я магу даць тым, хто прыступае да праектавання сістэмы, такі: не дапушчайце ніякіх дапушчэнняў! З самага пачатку трэба канкрэтызаваць факты, вядомыя аб гэтай сістэме, і звязаныя з ёю чаканні. Вось некалькі добрых пытанняў, адказы на якія дапамогуць вам прыступіць да праектавання:
- Якая праблема, якую мы спрабуем вырашыць?
- Якая пікавая колькасць карыстальнікаў, якія будуць узаемадзейнічаць з нашай сістэмай?
- Якія патэрны запісы і счытванні дадзеных у нас будуць выкарыстоўвацца?
- Якія чаканыя выпадкі адмоў, як мы збіраемся з імі спраўляцца?
- Якія чаканні прад'яўляюцца да ўзгодненасці і даступнасці сістэмы?
- Ці даводзіцца ўлічваць пры працы якія-небудзь патрабаванні, звязаныя са знешняй праверкай і рэгламентацыяй?
- Якія разнавіднасці канфідэнцыйных дадзеных мы збіраемся захоўваць?
Гэта ўсяго некалькі пытанняў, якія спатрэбіліся пры працы як мне, так і тым камандам, у якіх мне давялося ўдзельнічаць за гады прафесійнай дзейнасці. Калі вам вядомы адказы на гэтыя пытанні (і на любыя іншыя, рэлевантныя ў тым кантэксце, у якім вам даводзіцца працаваць), то можна паступова паглыбляцца ў тэхнічныя дэталі задачы.
Задаем зыходны ўзровень
Што я разумею тут пад "зыходным узроўнем" (baseline)? Уласна, у нашы часы большасць праблем у софтвернай індустрыі "можна" вырашыць пры дапамозе ўжо наяўных метадаў і тэхналогій. Адпаведна, арыентуючыся ў гэтым ландшафце, вы атрымліваеце пэўную фору, сутыкаючыся з задачамі, якія камусьці даводзілася вырашаць да вас. Не забываем, што праграмы пішуцца для рашэння праблем бізнэсу і карыстачоў, таму мы імкнемся вырашыць задачу самым прамалінейным і простым (з пункта гледжання карыстача) спосабам. Чаму аб гэтым неабходна памятаць? Можа быць, вам у вашай сістэме каардынат падабаецца падшукваць для ўсіх задач унікальныя рашэнні, бо вы лічыце, "які ж я праграміст, калі паўсюль прытрымліваюся патэрнаў"? На самой справе, мастацтва тут заключаецца ў прыняцці рашэнняў аб тым, дзе і што рабіць. Зразумела, любому з нас час ад часу даводзіцца сутыкацца з унікальнымі праблемамі, кожная з якіх - сапраўдны выклік. Аднак, калі наш зыходны ўзровень дакладна акрэслены, то мы ведаем, на што марнаваць сілы: на пошук гатовых варыянтаў рашэння пастаўленай перад намі задачы, альбо на яе далейшае вывучэнне і глыбейшае разуменне.
Думаю, мне атрымалася вас пераканаць, што, калі адмысловец упэўнена разбіраецца ў тым, які архітэктурны складнік некаторых выдатных софтверных сістэм, то гэтыя веды будуць незаменныя для авалодання мастацтвам архітэктара і напрацоўкі самавітага базісу ў гэтай сферы.
Добра, дык з чаго ж пачаць? У ёсць рэпазітар на GitHub пад назвай , па матэрыялах якога вы зможаце навучыцца праектаванню буйнамаштабных сістэм, а таксама падрыхтавацца да сумоўяў на гэтую тэму. У рэпазітары ёсць раздзел з прыкладамі , дзе, у прыватнасці, разгледжана, як падыходзяць да дызайну сваіх сістэм , напрыклад, Twitter, Uber, г.д.
Аднак, перш чым пераходзіць да гэтага матэрыялу, давайце падрабязней разбярэмся з найболей важнымі архітэктурнымі выклікамі, з якімі прыходзіцца сутыкацца на практыку. Гэта важна, паколькі даводзіцца канкрэтызаваць Мноства аспектаў непадатлівай і шматграннай праблемы, а затым вырашаць яе ў рамках рэгламентацыі, якая дзейнічае ў дадзенай сістэме. , былы супрацоўнік Facebook, запісаў , дзе падзяліўся ўласным вопытам па аглядзе сотняў суіскальнікаў. Прытым, што відэа выразна датычыцца праектавання вялікіх сістэм і крытэрыяў паспяховасці, важных пры пошуку кандыдата на такую пазіцыю, яно ўсё ж паслужыць вычарпальным рэсурсам аб тым, якія рэчы найбольш важныя пры праектаванні сістэм. Таксама прапаную гэтага відэа.
Напрацоўвайце веды аб захоўванні і выманні дадзеных
Як правіла, ваша рашэнне аб тым, як вы будзеце доўгачасова захоўваць і выдаваць вашыя дадзеныя, крытычна адбіваецца на прадукцыйнасці сістэмы. Такім чынам, вы павінны першым чынам разумець чаканыя характарыстыкі запісу і счытванні дадзеных у вашай сістэме. Затым трэба ўмець ацэньваць гэтыя паказчыкі і рабіць выбар, зыходзячы са зробленых адзнак. Аднак, эфектыўна спраўляцца з гэтай працай вы зможаце толькі ў выпадку, калі разбіраецеся ў наяўных патэрнах захоўвання дадзеных. У прынцыпе, гэта мае на ўвазе упэўненыя веды, звязаныя з .
Базы дадзеных можна лічыць структурамі дадзеных, якім уласціва выключная маштабаванасць і даўгавечнасць. Таму веданне структур дадзеных павінна вельмі спатрэбіцца вам і пры выбары той ці іншай базы дадзеных. Напрыклад, - гэта сервер структур дадзеных, які падтрымлівае розныя віды значэнняў. Ён дазваляе працаваць з такімі структурамі дадзеных як спісы і мноства, счытваць дадзеныя пры дапамозе агульнавядомых алгарытмаў, напрыклад, , арганізуючы такую працу ў даўгавечным і высокадаступным стылі.
здымак з сайта Unsplash
Калі вы ў дастатковай ступені зарыентуйцеся ў розных патэрнах захоўвання дадзеных - пераходзіце да вывучэння ўзгодненасці і даступнасці дадзеных. Перш за ўсё вам спатрэбіцца засвоіць хоць бы ў агульных рысах, а затым адшліфаваць гэтыя веды, падрабязней разгледзеўшы ўстояныя патэрны и . Такім чынам вы напрацуеце кругагляд у гэтай галіне і зразумееце, што счытванне і запіс дадзеных - гэта на самай справе дзве вельмі розныя праблемы, і з кожнай з іх спалучаныя свае асаблівыя выклікі. Узброіўшыся некалькімі патэрнамі забеспячэння ўзгодненасці і даступнасці, вы зможаце значна нарасціць прадукцыйнасць сістэмы, пры гэтым гарантаваўшы бесперабойную падачу дадзеных у вашыя прыкладанні.
Нарэшце, завяршаючы размову аб пытаннях захоўвання дадзеных, варта згадаць і пра кэшаванне. Ці павінна яно выконвацца адначасова на кліенце і на серверы? Якія дадзеныя будуць знаходзіцца ў вас у кэшы? І чаму? Як вы арганізуеце інваліднасць кэша? Ці будзе яна рабіцца рэгулярна, праз пэўныя прамежкі часу? Калі так - то як часта? Прапрацоўку гэтых тэм рэкамендую пачаць са вышэйзгаданага буквара па праектаванні сістэм.
Камунікацыйныя патэрны
Сістэмы складаюцца з розных кампанентаў; гэта могуць быць як розныя працэсы, якія працуюць усярэдзіне аднаго і таго ж фізічнага вузла, так і розныя машыны, якія дзейнічаюць у розных частках вашай сеткі. Некаторыя з гэтых рэсурсаў у межах вашай сеткі могуць быць прыватнымі, але іншыя павінны быць публічнымі і адкрытымі для спажыўцоў, якія звяртаюцца да іх звонку.
Неабходна забяспечыць камунікацыю гэтых рэсурсаў адзін з адным, а таксама абмен інфармацыяй паміж усёй сістэмай і навакольным светам. У кантэксце праектавання сістэм тут мы, зноў жа, сутыкаемся з наборам новых унікальных выклікаў. Разбіраемся, чым могуць быць карысныя , і якія р.
здымак з сайта Unsplash
Пры арганізацыі камунікацыі з навакольным светам заўсёды вельмі важная , да забеспячэння якой таксама трэба падыходзіць з усёй сур'ёзнасцю і займацца ёю актыўна.
Размеркаванне злучэнняў
Не ўпэўнены, што вынясенне гэтай тэмы ў самастойную частку ўсім здасца апраўданым. Тым не менш, разгорнута выкладу тут гэтую канцэпцыю, прычым, лічу, што матэрыял гэтай часткі дакладней за ўсё апісваецца менавіта тэрмінам "размеркаванне злучэнняў" (connection distribution).
Сістэмы фармуюцца шляхам правільнага злучэння мноства кампанентаў, і іх камунікацыя сябар з сябрам часцяком арганізуецца на базе ўстояных пратаколаў, напрыклад, TCP і UDP. Аднак, гэтых пратаколаў як такіх часта недастаткова для задавальнення ўсіх патрэб сучасных сістэм, якія часта эксплуатуюцца пад высокай нагрузкай, а таксама моцна залежаць ад патрэб карыстальнікаў. Часта бывае неабходна адшукваць спосабы размеркавання злучэнняў, каб спраўляцца з такімі высокімі нагрузкамі ў сістэме.
У аснове такога размеркавання ляжыць добра вядомая (DNS). Такая сістэма дазваляе пераўтварыць даменнае імя, напрыклад, узважаны цыклічны алгарытм (weighted round robin) і метады на аснове затрымак, якія дапамагаюць размяркоўваць нагрузку.
прынцыпова важная, і практычна любая буйная сістэма ў Інтэрнэце, з якой нам сёння даводзіцца мець справу, размешчана за адным ці некалькімі балансавальнікамі нагрузкі. Балансавальнікі нагрузкі дапамагаюць размяркоўваць кліенцкія запыты па мностве даступных інстансаў. Балансавальнікі нагрузкі бываюць як апаратнымі, так і праграмнымі, аднак, на практыцы часцей даводзіцца мець справу з праграмнымі, напрыклад з и . канцэптуальна таксама вельмі падобныя на балансавальнікі нагрузкі, хоць, паміж першымі і другімі ёсць шэраг . Гэтыя адрозненні абавязкова трэба ўлічваць, праектуючы сістэму з улікам вашых запатрабаванняў.
Таксама варта ведаць аб (CDN). CDN – гэта глабальная размеркаваная сетка проксі-сервераў, якая дастаўляе інфармацыю з тых вузлоў, якія геаграфічна размешчаны бліжэй да канкрэтнага карыстача. Сеткі CDN пераважней выкарыстоўваць, калі вы працуеце са статычнымі файламі, напісанымі на JavaScript, CSS і HTML. Акрамя таго, сёння распаўсюджаны такія хмарныя сэрвісы, у якіх прадастаўляюцца дыспетчары трафіку, напрыклад, , якія забяспечваюць вам глабальнае размеркаванне і зніжаныя затрымкі пры працы з дынамічным кантэнтам. Аднак, такія сэрвісы звычайна карысныя ў тых выпадках, калі даводзіцца працаваць з вэб-сэрвісамі без захавання стану.
Пагаворым аб бізнэс-логіцы. Структураванне бізнес-логікі, патокаў задач і кампанентаў
Такім чынам, мы паспелі абгаварыць разнастайныя інфраструктурныя аспекты сістэмы. Хутчэй за ўсё, карыстач нават не задумваецца пра ўсе гэтыя элементы вашай сістэмы і, сапраўды кажучы, зусім з іх нагоды не парыцца. Карыстальніка цікавіць, якое ўзаемадзейнічаць з вашай сістэмай, чаго можна дабіцца, паступіўшы вось так, а таксама якім чынам сістэма выконвае карыстацкія каманды, што і як робіць з карыстацкімі дадзенымі.
Як зразумела з назвы дадзенага артыкула, я збіраўся распавесці ў ім аб софтвернай архітэктуры і праектаванні сістэм. Адпаведна, я не планаваў асвятляць патэрны праектавання ПЗ, якія апісваюць, як ствараюцца праграмныя кампаненты. Аднак, чым больш я пра гэта разважаю, тым больш мне здаецца, што мяжа паміж патэрнамі праектавання ПЗ і архітэктурнымі патэрнамі вельмі размытая, і дзве гэтыя канцэпцыі цесна злучаны. Возьмем, напрыклад, (event sourcing). Варта вам узяць на ўзбраенне гэты архітэктурны патэрн - і ён паўплывае практычна на ўсе аспекты вашай сістэмы: доўгачасовае захоўванне дадзеных, узровень узгодненасці, прыняты ў вашай сістэме, абрысы кампанентаў у ёй, і г.д., і да т.п. Таму я вырашыў згадаць некаторыя архітэктурныя патэрны, якія непасрэдна тычацца бізнес-логікі. Няхай нават у гэтым артыкуле давядзецца абмежавацца простым спісам, рэкамендую вам пазнаёміцца з ім і абдумаць ідэі, звязаныя з гэтымі патэрнамі. Вось калі ласка:
- канцэпцыі , у прыватнасці, ,
Калабаратыўныя падыходы
Вельмі малаверагодна, што вы апынецеся на праекце тым удзельнікам, хто аднаасобна адказвае за працэс праектавання сістэмы. Наадварот, хутчэй за ўсё, вам давядзецца ўзаемадзейнічаць з калегамі, якія працуюць як у рамках вашай задачы, так і за яе межамі. У дадзеным выпадку можа запатрабавацца ацэньваць абраныя тэхналагічныя рашэнні разам з калегамі, вычляняць бізнэс-патрэбы і разумець, як лепш распаралельваць задачы.
здымак з сайта Unsplash
У першую чаргу запатрабуецца выпрацаваць дакладнае і агульнапрызнанае ўяўленне пра тое, якая тая бізнэс-мэта, якую вы спрабуеце дасягнуць, і з якімі рухомымі элементамі пры гэтым прыйдзецца мець справу. Прыёмы групавога мадэлявання, у прыватнасці, (event storming) дапамагаюць значна паскорыць гэты працэс і павялічваюць вашы шанцы на поспех. Гэтай працай можна заняцца да таго ці пасля таго, як вы акрэсліце , А затым паглыбляць яго па меры паспявання прадукта. Абапіраючыся на той узровень узгодненасці, што будзе дасягнуты тут, вы таксама можаце сфармуляваць для таго абмежаванага кантэксту, у якім працуеце. Калі спатрэбіцца расказваць пра архітэктуру вашай сістэмы, для гэтага вам можа спатрэбіцца. , прапанаваная , асабліва калі патрабуецца зразумець, наколькі вам давядзецца паглыбляцца ў дэталі праблемы, візуалізуючы рэчы, якія вы хочаце паведаміць.
Верагодна, у гэтай тэме знойдзецца і іншая спелая тэхналогія, не менш карысная, чым прадметна-арыентаванае праектаванне. Аднак, мы так ці інакш вяртаемся да разумення прадметнай вобласці, таму веды і досвед у сферы павінны вам спатрэбіцца.
Крыніца: habr.com