Ми­гра­ция уна­сле­до­ван­ных кор­по­ра­тив­ных при­ло­же­ний на микросервисы

Otkrytye sistemy. SUBD. - - МИКРОСЕРВИСЫ - Ан­дрей Фур­да, Ко­лин Фидж, Олаф Цим­мер­манн, Уэйн Кел­ли, Али­стер Бар­рос

Пе­ре­ход на микросервисы — мно­го­обе­ща­ю­щая тех­но­ло­гия по­ша­го­вой мо­дер­ни­за­ции уна­сле­до­ван­ных мо­но­лит­ных кор­по­ра­тив­ных при­ло­же­ний, поз­во­ля­ю­щая ис­поль­зо­вать пре­иму­ще­ства об­лач­ных сред. В этой ста­тье рас­смат­ри­ва­ют­ся три про­бле­мы пе­ре­хо­да на микросервисы — муль­ти­а­ренд­но­сти, со­хра­не­ния ин­фор­ма­ции те­ку­ще­го со­сто­я­ния и со­гла­со­ван­но­сти дан­ных. Клю­че­вые сло­ва: микросервисы, уна­сле­до­ван­ные си­сте­мы Keywords: мicroservices, legacy systems

Мо­дер­ни­за­ция уна­сле­до­ван­ных кор­по­ра­тив­ных си­стем — во­прос, с ко­то­рым стал­ки­ва­ют­ся мно­гие ор­га­ни­за­ции, пла­ни­ру­ю­щие ис­поль­зо­вать но­вые об­лач­ные тех­но­ло­гии для обес­пе­че­ния высокого уровня мас­шта­би­ру­е­мо­сти и го­тов­но­сти. Ес­ли ис­ход­ный код уна­сле­до­ван­ной си­сте­мы до­сту­пен и до­пус­ка­ет вне­се­ние из­ме­не­ний, то микросервисы становятся мно­го­обе­ща­ю­щим решением, при ко­то­ром цен­тра­ли­зо­ван­ные сер­ви­сы за­ме­ня­ют­ся несколь­ки­ми неза­ви­си­мы­ми [1, 2] (рис. 1). Микросервисы поз­во­ля­ют про­во­дить по­ша­го­вую мо­дер­ни­за­цию, что спо­соб­ству­ет со­зда­нию си­стем с вы­со­ким уров­нем мас­шта­би­ру­е­мо­сти и го­тов­но­сти [3] (за счет из­бы­точ­но­сти эк­зем­пля­ров сер­ви­сов) и ве­дет к со­кра­ще­нию за­трат. При­ме­не­ние мик­ро­сер­ви­сов от­кры­ва­ет воз­мож­ность раз­би­вать про­цесс мо­дер­ни­за­ции на неболь­шие эта­пы, что за­ча­стую ока­зы­ва­ет­ся пред­по­чти­тель­нее од­но­мо­мент­но­го вне­се­ния круп­но­мас­штаб­ных из­ме­не­ний.

МУЛЬТИАРЕНДНОСТЬ

Муль­ти­а­ренд­ное приложение, пред­ла­га­е­мое в ка­че­стве сер­ви­са, поз­во­ля­ет удо­вле­тво­рить по­треб­но­сти сра­зу несколь­ких групп поль­зо­ва­те­лей, ор­га­ни­за­ций или по- драз­де­ле­ний. При ис­поль­зо­ва­нии муль­ти­а­ренд­ной модели на уровне при­ло­же­ния каж­дый из его эк­зем­пля­ров об­слу­жи­ва­ет сра­зу несколь­ко кли­ен­тов. Эк­зем­пля­ры кон­фи­гу­ри­ру­ют­ся с уче­том по­треб­но­стей арен­да­то­ров. При сов­мест­ном ис­поль­зо­ва­нии эк­зем­пля­ров при­ло­же­ния дан­ные арен­да­то­ров долж­ны быть от­де­ле­ны друг от дру­га и до­ступ­ны толь­ко их вла­дель­цам (рис. 2). По­ми­мо раз­де­ле­ния кли­ент­ских дан­ных, муль­ти­а­ренд­ная среда долж­на обес­пе­чи­вать рав­но­мер­ное рас­пре­де­ле­ние вы­чис­ли­тель­ных ре­сур­сов меж­ду арен­да­то­ра­ми. В этом слу­чае воз­рас­та­ние спро­са на ре­сур­сы со сто­ро­ны од­но­го арен­да­то­ра не от­ра­жа­ет­ся нега­тив­ным об­ра­зом на всех осталь­ных.

Уна­сле­до­ван­ные кор­по­ра­тив­ные при­ло­же­ния за­ча­стую работают в од­но­аренд­ном ре­жи­ме, осо­бен­но­сти со­вре­мен­ных об­лач­ных муль­ти­а­ренд­ных сред при раз­ра­бот­ке та­ких при­ло­же­ний не учи­ты­ва­лись, и они, как пра­ви­ло, не под­дер­жи­ва­ют мно­же­ствен­ную арен­ду. Уна­сле­до­ван­ные од­но­аренд­ные при­ло­же­ния име­ют до­ступ к хра­ни­ли­щу дан­ных толь­ко од­ной ор­га­ни­за­ции. Важ­но, что­бы пе­ре­ход от од­но­аренд­но­го уна­сле­до­ван­но­го ко­да к мик­ро­сер­ви­сам про­из­во­дил­ся с уче­том мно­же­ствен­ной арен­ды — муль­ти­а­ренд­ные эк­зем­пля­ры мик­ро­сер­ви­сов мо­гут сов­мест­но ис­поль­зо­вать­ся несколь­ки­ми кли­ен­та­ми, а на­строй­ка их кон­фи­гу­ра­ции вы­пол­ня­ет­ся с уче­том ин­ди­ви­ду­аль­ных по­треб­но­стей и стро­го­го раз­де­ле­ния кли­ент­ских дан­ных.

Для изо­ля­ции дан­ных, по­сту­па­ю­щих че­рез кли­ент­ские вход­ные ка­на­лы, про­грамм­ный код дол­жен по­ме­чать их при­сво­ен­ным кли­ен­ту иден­ти­фи­ка­то­ром, и этот кли­ент­ский тег необ­хо­ди­мо со­хра­нять в неиз­мен­ном ви­де, по­ка дан­ные не до­стиг­нут кли­ент­ско­го вы­ход­но­го ка­на­ла.

Про­це­ду­ры, об­ра­ба­ты­ва­ю­щие вход­ные дан­ные с ин­фор­ма­ци­ей о кли­ен­те (на­при­мер, за­про­сы сер­ви­са, ввод че­рез поль­зо­ва­тель­ский ин­тер­фейс, опе­ра­ции чте­ния из ба­зы дан­ных), долж­ны из­вле­кать кли­ент­ский иден­ти­фи­ка­тор из ис­пол­ня­е­мой сре­ды и при­сва­и­вать его вход­но­му ка­на­лу. На­при­мер, ес­ли за раз­ме­ще­ние муль­ти­а­ренд­но­го мик­ро­сер­ви­са от­ве­ча­ет Google App Engine, иден­ти­фи­ка­тор арен­да­то­ра из­вле­ка­ет­ся из до­ме­на Google Apps.

Ана­ло­гич­ным об­ра­зом про­це­ду­ры, об­ра­ба­ты­ва­ю­щие выходные дан­ные с ин­фор­ма­ци­ей о кли­ен­те (на­при­мер, от­ве­ты сер­ви­са, вы­вод че­рез поль­зо­ва­тель­ский ин­тер­фейс и опе­ра­ции за­пи­си в ба­зу дан­ных), из­вле­ка­ют кли­ент­ский иден­ти­фи­ка­тор и при­сва­и­ва­ют его вы­ход­но­му ка­на­лу. Windows Azure, к при­ме­ру, перед об­ра­ще­ни­ем к API хра­ни­ли­ща тре­бу­ет опре­де­ле­ния кли­ент­ско­го кон­тек­ста.

Та­ким об­ра­зом, муль­ти­а­ренд­ный про­грамм­ный код из­вле­ка­ет иден­ти­фи­ка­тор кли­ен­та (кли­ент­ский кон­текст) перед

по­лу­че­ни­ем дан­ных из вход­но­го ка­на­ла, опре­де­ля­ет кли­ент­ский кон­текст для всех биз­нес-объектов, со­дер­жа­щих ин­фор­ма­цию о кли­ен­те, и фор­ми­ру­ет кли­ент­ский кон­текст для дан­ных, от­прав­ля­е­мых в выходные ка­на­лы.

СОХРАНЕНИЕ СО­СТО­Я­НИЯ

Система с со­хра­не­ни­ем ин­фор­ма­ции о со­сто­я­нии вы­да­ет ре­зуль­та­ты, ко­то­рые за­ви­сят от преды­ду­щих вза­и­мо­дей­ствий. Счи­та­ет­ся, на­при­мер, что приложение элек­трон­ной ком­мер­ции со­хра­ня­ет со­сто­я­ние, ес­ли оно за­по­ми­на­ет дан­ные о преды­ду­щих про­да­жах и ви­зи­тах по­ку­па­те­лей в элек­трон­ный магазин.

Во мно­гих слу­ча­ях микросервисы, не за­ви­ся­щие от со­сто­я­ния, пред­став­ля­ют собой иде­аль­ный ва­ри­ант, по­то­му что ис­поль­зу­ют пре­иму­ще­ства об­ла­ков: спо­соб­ность адап­ти­ро­вать­ся по тре­бо­ва­нию, сба­лан­си­ро­ван­ность на­груз­ки, вы­со­кую готовность и устой­чи­вость, до­сти­га­е­мые за счет из­бы­точ­но­сти. Микросервисы, за­ви­ся­щие от со­сто­я­ния, тре­бу­ют бо­лее слож­ной ло­ги­ки для под­держ­ки со­сто­я­ния, об­ла­да­ют мень­шей мас­шта­би­ру­е­мо­стью и не мо­гут по­хва­стать­ся вы­со­ким уров­нем го­тов­но­сти и устой­чи­во­сти. Ин­фор­ма­ция о со­сто­я­нии долж­на по­сто­ян­но при­сут­ство­вать, син­хро­ни­зи­ро­вать­ся в кон­фи­гу­ра­ци­ях с горячим ре­зер­ви­ро­ва­ни­ем и вос­ста­нав­ли­вать­ся при воз­ник­но­ве­нии сбо­ев.

Да­же при от­сут­ствии сбо­ев сохранение со­сто­я­ния при­во­дит к сход­ству се­ан­сов, что, в свою оче­редь, мо­жет со­про­вож­дать­ся сни­же­ни­ем про­пуск­ной способности и ро­стом за­дер­жек из-за ожи­да­ния эк­зем­пля­ров с опре­де­лен­ным со­сто­я­ни­ем. С дру­гой сто­ро­ны, для мик­ро­сер­ви­сов, не за­ви­ся­щих от со­сто­я­ния, ха­рак­тер­но умень­ше­ние сред­не­го вре­ме­ни от­кли­ка за счет рас­пре­де­ле­ния на­груз­ки меж­ду до­ступ­ны­ми мик­ро­сер­ви­са­ми, а та­к­же от­сут­ствие необ­хо­ди­мо­сти ис­поль­зо­ва­ния слож­но­го управ­ле­ния со­сто­я­ни­я­ми и тех­но­ло­гий син­хро­ни­за­ции со­сто­я­ния.

В ти­пич­ной ар­хи­тек­ту­ре мик­ро­сер­ви­сов (рис. 3) за­про­сы кли­ен­тов сер­ви­са ад­ре­су­ют­ся ба­лан­си­ров­щи­ку на­груз­ки, ко­то­рый пе­ре­на­прав­ля­ет их до­ступ­ным эк­зем­п­ля- рам мик­ро­сер­ви­са. Готовность си­сте­мы определяется сле­ду­ю­щим об­ра­зом:

Готовность = MTBF / (MTBF + MTTR), где MTBF (mean time between failures) — сред­ний про­ме­жу­ток вре­ме­ни меж­ду от­ка­за­ми, а MTTR (mean time to repair) — сред­нее вре­мя вос­ста­нов­ле­ния. Пред­по­ло­жим, что все эк­зем­пля­ры мик­ро­сер­ви­сов име­ют оди­на­ко­вый па­ра­метр MTBF, то­гда готовность си­сте­мы воз­рас­та­ет при сни­же­нии MTTR. Это­го мож­но до­стичь за счет предо­став­ле­ния ба­лан­си­ров­щи­ку на­груз­ки воз­мож­но­сти оста­нав­ли­вать пе­ре­ад­ре­са­цию вхо­дя­щих кли­ент­ских за­про­сов сбой­ным эк­зем­пля­рам мик­ро­сер­ви­са и на­прав­лять их нор­маль­но функ­ци­о­ни­ру­ю­щим эк­зем­пля­рам. Ба­лан­си­ров­щик на­груз­ки спо­со­бен немедленно на­прав­лять за­про­сы уже раз­вер­ну­тым из­бы­точ­ным мик­ро­сер­ви­сам толь­ко в том слу­чае, ес­ли они не за­ви­сят от со­сто­я­ния.

Микросервисы, не за­ви­ся­щие от со­сто­я­ния, поз­во­ля­ют до­бить­ся бо­лее высокого уровня устой­чи­во­сти си­сте­мы за счет из­бы­точ­но­сти. Устой­чи­вость си­сте­мы опре­де­ля-

Newspapers in Russian

Newspapers from Russia

© PressReader. All rights reserved.