Микросервисы: прой­ден­ный путь и даль­ней­шие це­ли

Otkrytye sistemy. SUBD. - - СОДЕРЖАНИЕ -

Пу­ян Джам­ши­ди, Джеймс Лью­ис, Клаус Паль, На­бор Мен­дон­ча, Сте­фан Тил­ков Микросервисы — но­вая тен­ден­ция в области про­ек­ти­ро­ва­ния, раз­ра­бот­ки и предо­став­ле­ния про­грамм­ных сер­ви­сов, ме­тод по­стро­е­ния ар­хи­тек­ту­ры про­грамм­ных си­стем, уде­ля­ю­щий осо­бое вни­ма­ние ав­то­ном­но­сти мо­ду­лей для по­вы­ше­ния гиб­ко­сти ПО. Как эво­лю­ци­о­ни­ро­ва­ла эта кон­цеп­ция, ка­кие та­ит про­бле­мы и че­го следует ожи­дать от мик­ро­сер­ви­сов в бу­ду­щем?

ет­ся как от­но­ше­ние ко­ли­че­ства успеш­ных за­про­сов к об­ще­му их чис­лу: Устой­чи­вость = Ко­ли­че­ство успеш­ных за­про­сов / Об­щее ко­ли­че­ство за­про­сов × 100%.

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

В кон­тек­сте из­вле­че­ния мик­ро­сер­ви­сов уна­сле­до­ван­ная про­грам­ма за­ви­сит от со­сто­я­ния, ес­ли она спо­соб­на со­хра­нять зна­че­ния пе­ре­мен­ных (то есть со­сто­я­ния) меж­ду вы­зо­ва­ми и ге­не­ри­ро­вать ре­зуль­та­ты, ко­то­рые за­ви­сят не толь­ко от те­ку­щих вход­ных па­ра­мет­ров, но и от ра­нее со­хра­нен­но­го со­сто­я­ния.

При ана­ли­зе мик­ро­сер­ви­сом со­сто­я­ния уна­сле­до­ван­но­го ко­да тре­бу­ет­ся про­ве­рить вклю­че­ние или ис­клю­че­ние опре­де­ле­ний пе­ре­мен­ных со­сто­я­ния (то есть со­сто­я­ние се­ан­са в па­мя­ти).

Про­це­ду­ры и объ­ек­ты с со­хра­не­ни­ем со­сто­я­ния

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

Ча­ще все­го со­сто­я­ния в уна­сле­до­ван­ных про­грам­мах сохраняются в объ­ек­тах (эк­зем­пля­рах класса). Объ­ект мо­жет со­хра­нять со­сто­я­ние, со­зда­вая эк­зем­пляр класса, в ко­то­ром при­сут­ству­ют про­це­ду­ры с со­хра­не­ни­ем со­сто­я­ния или свойства со­сто­я­ния.

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

Ком­по­нен­ты с со­хра­не­ни­ем со­сто­я­ния

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

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

Пе­ре­нос уна­сле­до­ван­но­го про­грамм­но­го ко­да с со­хра­не­ни­ем со­сто­я­ния в мик­ро­сер­вис

Пе­ре­нос уна­сле­до­ван­но­го ко­да в микросервисы мо­жет осу­ществ­лять­ся свер­ху вниз, сни­зу вверх или пу­тем де­ле­ния по­по­лам, в том чис­ле с ре­фак­то­рин­гом уна­сле­до­ван­но­го ко­да и при­ме­не­ни­ем ар­хи­тек­тур­ных ре­ше­ний к нуж­но­му мик­ро­сер­ви­су. Ис­поль­зу­е­мые в дальнейшем шаб­ло­ны сер­вис­ной ар­хи­тек­ту­ры (service-oriented architecture, SOA) ори­ен­ти­ро­ва­ны на сохранение со­сто­я­ния и при­ме­ни­мы к мик­ро­сер­вис­ным ар­хи­тек­ту­рам.

Ша­б­лон Stateful Messaging де­ле­ги­ру­ет дан­ные внут­рен­не­го со­сто­я­ния со­об­ще­ни­ям мик­ро­сер­ви­са — за­про­сам и от­ве­там сер­ви­са. Уна­сле­до­ван­ные про­це­ду­ры с со­хра­не­ни­ем со­сто­я­ния мо­гут быть ре­а­ли­зо­ва­ны без уче­та со­сто­я­ния пу­тем за­ме­ны ло­каль­ных пе­ре­мен­ных со­сто­я­ния до­пол­ни­тель­ны­ми па­ра­мет­ра­ми и возврата зна­че­ний, поз­во­ля­ю­щих опре­де­лять со­сто­я­ние и возв­ра- щать его. За­тем эти до­пол­ни­тель­ные па­ра­мет­ры со­сто­я­ния и воз­вра­ща­е­мые зна­че­ния свя­зы­ва­ют­ся со­от­вет­ствен­но с за­про­са­ми и от­ве­та­ми мик­ро­сер­ви­са. Объ­ек­ты и ком­по­нен­ты с со­хра­не­ни­ем со­сто­я­ния мо­гут быть под­верг­ну­ты ре­фак­то­рин­гу ана­ло­гич­ным об­ра­зом.

Ша­б­лон Partial State Deferral пред­став­ля­ет собой оп­цию мик­ро­сер­ви­са, поз­во­ля­ю­щую со­хра­нять со­сто­я­ние ча­стич­но, с тем что­бы умень­шить рас­ход па­мя­ти.

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

Ша­б­лон Stateful Service со­хра­ня­ет со­сто­я­ние мик­ро­сер­ви­са в на­бо­ре вспо­мо­га­тель­ных сер­ви­сов с со­хра­не­ни­ем со­сто­я­ния, функ­ции ко­то­рых сво­дят­ся к управ­ле­нию ин­фор­ма­ци­ей о со­сто­я­нии. Этот ша­б­лон изо­ли­ру­ет за­да­чу со­хра­не­ния со­сто­я­ния и пе­ре­да­ет ее дру­гим сер­ви­сам, ко­то­рые ока­зы­ва­ют та­кое же нега­тив­ное вли­я­ние на мас­шта­би­ру­е­мость, готовность и устой­чи­вость.

СО­ГЛА­СО­ВАН­НОСТЬ ДАН­НЫХ

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

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

Уна­сле­до­ван­ный про­грамм­ный код за­ча­стую со­дер­жит мно­же­ство опе­ра­ций чте­ния-

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

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

Ре­струк­ту­ри­за­ция уна­сле­до­ван­но­го ко­да с со­гла­со­ван­ны­ми дан­ны­ми

У мик­ро­сер­ви­сов име­ет­ся соб­ствен­ное хра­ни­ли­ще дан­ных — вы­де­лен­ный эк­зем­пляр ба­зы дан­ных, вы­де­лен­ная схе­ма в об­щей ба­зе дан­ных или вы­де­лен­ные таб­ли­цы ба­зы дан­ных. Это поз­во­ля­ет ре­шать во­про­сы со­гла­со­ван­но­сти при син­хро­ни­за­ции дан­ных мик­ро­сер­ви­са с цен­тра­ли­зо­ван­ной ба­зой дан­ных.

Ша­б­лон SOA Service Data Replication реп­ли­ци­ру­ет дан­ные в сер­вис ба­зы дан­ных. Его мож­но без­опас­но при­ме­нять к опе­ра­ци­ям, до­пус­ка­ю­щим толь­ко чте­ние, од­на­ко опе­ра­ции чте­ния-за­пи­си тре­бу­ют до­пол­ни­тель­ных про­ве­рок со­гла­со­ван­но­сти дан­ных.

Об­лач­ные шаб­ло­ны Strict Consistency и Eventual Consistency по­мо­га­ют ре­шать во­про­сы со­гла­со­ван­но­сти в об­лач­ных хра­ни­ли­щах. Ша­б­лон Strict Consistency поз­во­ля­ет счи­ты­вать и за­пи­сы­вать пе­ре­мен­ное чис­ло ре­плик дан­ных. На­при­мер, в си­сте­ме, вклю­ча­ю­щей n ре­плик дан­ных, опе­ра­ции за­пи­си мо­гут обращаться к w ре­пли­кам, а опе­ра­ции чте­ния — к r ре­пли­кам. Для каж­дой опе­ра­ции га­ран­ти­ру­ет­ся от­но­ше­ние n < w + r, а стро­гая со­гла­со­ван­ность обес­пе­чи­ва­ет­ся за счет числа ре­плик чте­ния или за­пи­си, при ко­то­рых каж­дая из опе­ра­ций об­ра­ща­ет­ся по край­ней ме­ре к од­ной ак­ту­аль­ной вер­сии дан­ных.

Ша­б­лон Eventual Consistency при­ме­ня­ет­ся в неустой­чи­вых се­тях или се­тях с огра­ни­чен­ной про­пуск­ной спо­соб­но­стью, а та­к­же при боль­ших объ­е­мах дан­ных, ко­гда невоз­мо­жен од­но­вре­мен­ный до­ступ к несколь­ким ре­пли­кам (рис. 4). Опе­ра­ци­ям чте­ния-за­пи­си до­ступ­на толь­ко од­на ре­пли­ка, что при­во­дит к вре­мен­ной несо­гла­со­ван­но­сти дан­ных ра­ди по­вы­ше­ния уровня го­тов­но­сти и про­из­во­ди­тель­но­сти. В ко­неч­ном ито­ге несо­гла­со­ван­ность устра­ня­ет­ся пу­тем син­хро­ни­за­ции ре­плик дан­ных. Несо­гла­со­ван­ность дан­ных мо­жет со­хра­нять­ся, ес­ли за­пи­си дан­ных в раз­лич­ных ре­пли­ках из­ме­ня­ют­ся од­но­вре­мен­но. В этом слу­чае для раз­ре­ше­ния кон­флик­тов раз­ра­ба­ты­ва­ют­ся определенные пра­ви­ла — на­при­мер, од­на из из­ме­нен­ных вер­сий про­сто от­бра­сы­ва­ет­ся. Та­кие пра­ви­ла до­пу­сти­мы толь­ко в некри­тич­ных к дан­ным си­сте­мах, а в важ­ных кор­по­ра­тив­ных си­сте­мах в этих слу­ча­ях вы­пол­ня­ет­ся от­кат или про­из­во­дят­ся ка­кие-то дру­гие ком­пен­са­ци­он­ные дей­ствия. Луч­шие ре­ше­ния трех ос­нов­ных про­блем пе­ре­но­са уна­сле­до­ван­но­го про­грамм­но­го ко­да в микросервисы преду­смат­ри­ва­ют ите­ра­ци­он­ную раз­ра­бот­ку мик­ро­сер­ви­са, в про­цес­се ко­то­рой ос­нов­ное вни­ма­ние уде­ля­ет­ся:

• устранению за­ви­си­мо­сти уна­сле­до­ван­но­го про­грамм­но­го ко­да от со­сто­я­ния; • реализации муль­ти­а­ренд­но­го функ­ци­о­на­ла;

• ре­ше­нию по­тен­ци­аль­ных но­вых про­блем, свя­зан­ных с несо­гла­со­ван­но­стью дан­ных.

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

ЛИТЕРАТУРА 1.

O. Zimmermann. Microservices Tenets // Computer Science — Research and Development. — 2017. vol. 32, N. 3–4. — P. 301–310. 2.

C. Pautasso et al. Microservices in Practice, Part 1: Reality Check and Service Design // IEEE Software. — 2017. vol. 34, N. 1. — P. 91–98. 3.

I. Gorton. Hyper Scalability — the Changing Face of Software Architecture. Software Architecture for Big Data and the Cloud, Elsevier, 2017. — P. 13–31.

Ан­дрей Фур­да (andreifurda@gmail.com) — лек­тор на­уч­но-ин­же­нер­но­го фа­куль­те­та, Ко­лин Фидж (c.fidge@qut.edu. au) — про­фес­сор на­уч­но-ин­же­нер­но­го фа­куль­те­та Квинсленд­ско­го тех­но­ло­ги­че­ско­го уни­вер­си­те­та; Олаф Цим­мер­манн — про­фес­сор и парт­нер Уни­вер­си­те­та при­клад­ных на­ук Во­сточ­ной Швей­ца­рии в Рап­пер­сви­ле, вхо­дит в ре­дак­ци­он­ный со­вет IEEE Software; Уэйн Кел­ли (w.kelly@qut.edu. au) — стар­ший лек­тор, Али­стер Бар­рос (alistair.barros@qut.edu.au) — про­фес­сор Шко­лы ин­фор­ма­ци­он­ных си­стем Квинсленд­ско­го тех­но­ло­ги­че­ско­го уни­вер­си­те­та.

Рис. 3. Готовность и устой­чи­вость при ис­поль­зо­ва­нии из­бы­точ­ных (не за­ви­ся­щих от со­сто­я­ния) мик­ро­сер­ви­сов

Рис. 4. Ша­б­лон Eventual Consistency. Несо­гла­со­ван­ность устра­ня­ет­ся пу­тем мно­го­этап­ной син­хро­ни­за­ции ре­плик

Newspapers in Russian

Newspapers from Russia

© PressReader. All rights reserved.