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

Otkrytye sistemy. SUBD. - - МИКРОСЕРВИСЫ - Пу­ян Джам­ши­ди, Джеймс Лью­ис, Клаус Паль, На­бор Мен­дон­ча, Сте­фан Тил­ков

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

Каж­дый мо­дуль-мик­ро­сер­вис ре­а­ли­зу­ет­ся и ра­бо­та­ет как ма­лая пол­но­стью неза­ви­си­мая система [1], предо­став­ля­ю­щая до­ступ к сво­ей внут­рен­ней ло­ги­ке и дан­ным с по­мо­щью определенного се­те­во­го ин­тер­фей­са [2]. Это спо­соб­ству­ет по­вы­ше­нию гиб­ко­сти ПО, по­сколь­ку каж­дый мик­ро­сер­вис яв­ля­ет­ся неза­ви­си­мой еди­ни­цей в плане раз­ра­бот­ки, раз­вер­ты­ва­ния, экс­плу­а­та­ции, управ­ле­ния вер­си­я­ми и мас­шта­би­ро­ва­ния.

Бу­дучи неза­ви­си­мы­ми сер­ви­са­ми с чет­ки­ми гра­ни­ца­ми, микросервисы по­хо­жи на тра­ди­ци­он­ную сер­вис­ную ар­хи­тек­ту­ру (service-oriented architecture, SOA) [3]. Мож­но да­же ска­зать, что микросервисы — это под­вид SOA. Но в то вре­мя как SOA силь­но по­ла­га­ет­ся на спе­ци­аль­ные сред­ства (сер­вис­ную ши­ну пред­при­я­тия и иное «тя­же­ло­вес­ное» свя­зу­ю­щее ПО), микросервисы ис­поль­зу­ют ис­клю­чи­тель­но ма­ло­ре­сур­со­ем­кие тех­но­ло­гии.

Кро­ме то­го, SOA обыч­но ас­со­ци­и­ру­ют с про­то­ко­ла­ми веб-сер­ви­сов, фор­ма­та­ми вро­де SOAP, WSDL и се­мей­ством стан­дар­тов WS-*. Микросервисы же обыч­но по­ла­га­ют­ся на REST, HTTP и дру­гие ме­нее ре­сур­со­ем­кие фор­ма­ты, ко­то­рые при­ня­то счи­тать «на­тив­ны­ми» для веб-раз­ра­бот­ки. На­ко­нец, SOA обыч­но при­ме­ня­ют как ин­те­гра­ци­он­ное ре­ше­ние, то­гда как микросервисы пре­иму­ще­ствен­но ис­поль­зу­ют­ся для «сбор­ки» ин­ди­ви­ду­аль­ных при­ло­же­ний.

ПРЕ­ИМУ­ЩЕ­СТВА МИК­РО­СЕР­ВИ­СОВ

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

Ар­хи­тек­ту­ры мик­ро­сер­ви­сов мо­гут раз­ли­чать­ся, но все они со­зда­ют­ся, что­бы уско­рить вы­пуск — то есть обес­пе­чить мак­си­маль­но быст­рое пре­вра­ще­ние пер­во­на­чаль­ной идеи в функ­цию, вы­пол­ня­ю­щу­ю­ся в ра­бо­чей сре­де. Во мно­гих ор­га­ни­за­ци­ях в ИТ се­год­ня ви­дят средство улуч­ше­ния способности адап­ти­ро­вать­ся к ры­ноч­ным из­ме­не­ни­ям, а уже не центр за­трат, ко­то­рые луч­ше огра­ни­чи­вать. Для це­лей по­вы­ше­ния адап­тив­но­сти микросервисы обыч­но упа­ко­вы­ва­ют и раз­вер­ты­ва­ют в об­ла­ке с по­мо­щью об­лег­чен­ных кон­тей­нер­ных тех­но­ло­гий, по­ла­га­ясь на прак­ти­ки Devops и пол­но­стью ав- то­ма­ти­зи­ро­ван­ные ме­ха­низ­мы ин­те­гра­ции и вы­пус­ка ПО. Та­ким об­ра­зом обес­пе­чи­ва­ет­ся быст­ро­та раз­вер­ты­ва­ния мик­ро­сер­ви­сов в раз­лич­ных сре­дах вы­пол­не­ния — на­при­мер, в сре­де те­сти­ро­ва­ния, под­го­тов­ки (staging) и пред­ва­ри­тель­но­го вы­пус­ка (canary release) по про­из­воль­ным гра­фи­кам при ми­ни­му­ме цен­тра­ли­зо­ван­но­го управ­ле­ния.

Что ка­са­ет­ся тер­ми­на «мас­шта­би­ру­е­мость», то он неод­но­зна­чен. Он мо­жет озна­чать мас­шта­би­ру­е­мость си­сте­мы в пе­ри­од вы­пол­не­ния — на­при­мер, спо­соб­ность адап­ти­ро­вать­ся по ра­зум­ной цене к из­ме­не­нию числа поль­зо­ва­те­лей. Он та­к­же мо­жет от­но­сить­ся к воз­мож­но­сти па­рал­лель­ной раз­ра­бот­ки си­сте­мы мно­ги­ми раз­ра­бот­чи­ка­ми.

В ар­хи­тек­ту­рах мик­ро­сер­ви­сов мас­шта­би­ру­е­мой еди­ни­цей яв­ля­ет­ся ин­ди­ви­ду­аль­ный мик­ро­сер­вис. В пе­ри­од вы­пол­не­ния каж­дый из них мо­жет мас­шта­би­ро­вать­ся по-раз­но­му в за­ви­си­мо­сти от кон­крет­ных требований. Но мик­ро­сер­вис — это та­к­же еди­ни­ца раз­ра­бот­ки и раз­вер­ты­ва­ния. То есть каж­дый сер­вис мо­жет раз­ра­ба­ты­вать, раз­вер­ты­вать и экс­плу­а­ти­ро­вать от­дель­ная ко­ман­да, что поз­во­ля­ет внед­рять нов­ше­ства в па­рал­лель­ном ре­жи­ме.

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

ки и вы­пол­не­ния. Дру­ги­ми сло­ва­ми, груп­па раз­ра­бот­чи­ков име­ет воз­мож­ность изо­ли­ро­ван­но при­ни­мать ре­ше­ние по каждому сер­ви­су: вы­бор язы­ка про­грам­ми­ро­ва­ния, фрейм­вор­ков, СУБД и т. п. Тем са­мым обес­пе­чи­ва­ет­ся оп­ти­маль­ный под­ход с уче­том то­го, что каж­дая груп­па де­ла­ет луч­ший вы­бор для сво­ей зоны ответственности.

ЭВОЛЮЦИЯ МИК­РО­СЕР­ВИ­СОВ

Тер­мин «микросервисы» впер­вые об­суж­дал­ся на се­ми­на­ре по ар­хи­тек­ту­ре ПО, про­хо­див­шем в 2011 го­ду [2], а до это­го ана­ло­гич­ные идеи уже вы­дви­га­лись вид­ны­ми участ­ни­ка­ми от­рас­ли. На­при­мер, в Amazon опи­сы­ва­ли при­ме­ня­е­мую в ком­па­нии ар­хи­тек­ту­ру как «ин­кап­су­ли­ру­ю­щую дан­ные и биз­нес-ло­ги­ку для их обработки с до­сту­пом толь­ко че­рез за­до­ку­мен­ти­ро­ван­ный сер­вис­ный ин­тер­фейс», а в Netflix рас­суж­да­ли о «сла­бо­свя­зан­ной сер­вис­ной ар­хи­тек­ту­ре с огра­ни­чен­ны­ми кон­тек­ста­ми». Сре­ди дру­гих опи­са­ний, упо­ми­нав­ших­ся в от­рас­ли, — «мел­ко­дис­перс­ная SOA» и «пра­виль­но ре­а­ли­зо­ван­ная SOA».

Дру­ги­ми сло­ва­ми, кор­ни мик­ро­сер­ви­сов — в сер­вис­ной ар­хи­тек­ту­ре, ко­то­рая не вполне устра­и­ва­ла ры­нок, о чем сви­де­тель­ству­ет мас­со­вый пе­ре­ход от SOAP к REST, ме­нее ре­сур­со­ем­ко­му и бо­лее про­сто­му про­то­ко­лу вы­зо­ва сер­ви­сов.

В по­яв­ле­нии мик­ро­сер­ви­сов сыг­ра­ли роль несколь­ко важ­ных кон­цеп­ций раз­ра­бот­ки ПО, осо­бен­но про­блем­но-ори­ен­ти­ро­ван­ное про­ек­ти­ро­ва­ние — раз­ра­бот­ка на ос­но­ве мо­де­лей и прин­ци­пов огра­ни­чен­ных кон­тек­стов и непре­рыв­ной ин­те­гра­ции. Боль­шое вли- яние та­к­же ока­за­ли ме­то­ды про­ек­ти­ро­ва­ния с рас­че­том на от­ка­зы, изо­ля­ции дан­ных, ав­то­ма­ти­за­ции ин­фра­струк­ту­ры, мас­штаб­ной agile-раз­ра­бот­ки, фор­ми­ро­ва­ния крос­с­функ­ци­о­наль­ных ко­манд и ответственности за весь жиз­нен­ный цикл про­дук­та. Эти ме­то­ды ис­поль­зу­ют­ся для ре­ше­ния мно­гих за­дач, свя­зан­ных с раз­ра­бот­кой рас­пре­де­лен­ных веб-при­ло­же­ний (Facebook, Spotify и т. д.), а та­к­же ор­га­ни­за­ци­он­ных про­блем, с ко­то­ры­ми стал­ки­ва­ют­ся круп­ные ком­па­нии.

Рас­смот­рим эво­лю­цию мик­ро­сер­ви­сов с тех­ни­че­ской и ар­хи­тек­тур­ной то­чек зре­ния.

Тех­но­ло­гии

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

На рис. 1 по­ка­за­на хро­но­ло­гия по­яв­ле­ния де­ся­ти «волн» раз­ви­тия про­грамм­ных тех­но­ло­гий и со­от­вет­ству­ю­щих ин­стру­мен­тов, ко­то­рые по­вли­я­ли на раз­ви­тие, раз­вер­ты­ва­ние и экс­плу­а­та­цию мик­ро­сер­вис­ных при­ло­же­ний на про­тя­же­нии по­след­не­го де­ся­ти­ле­тия.

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

Тре­тья вол­на — тех­но­ло­гии мо­ни­то­рин­га (Graphite, Sensa), обес­пе­чи­ва­ю­щие мо­ни­то­ринг и ана­лиз по­ве­де­ния мик­ро­сер­вис­ных ре­сур­сов с раз­ной сте­пе­нью де­та­ли­за­ции в пе­ри­од вы­пол­не­ния. Чет­вер­тая — тех­но­ло­гии ор­кест­ров­ки (Mesos, Kubernetes), ко­то­рые ав­то­ма­ти­зи­ру­ют за­да­чи ре­зер­ви­ро­ва­ния и управ­ле­ния кон­тей­не­ра­ми, аб­стра­ги­руя низ­ко­уров­не­вую фи­зи­че­скую или вир­ту­аль­ную ин­фра­струк­ту­ру и тем са­мым упро­щая раз­ра­бот­ку. Пя­тая вол­на — биб­лио­те­ки функ­ций свя­зи, обес­пе­чи­ва­ю­щие устой­чи­вость к от­ка­зам и за­держ­ке (Finagle, Hystrix); они поз­во­ля­ют сер­ви­сам об­ме­ни­вать­ся дан­ны­ми бо­лее эф­фек­тив­но и на­деж­но.

Сле­ду­ю­щие пять волн по­яви­лись как ре­ак­ция на рас­ту­щую по­пу­ляр­ность мик­ро­сер­ви­сов. В ше­стую вол­ну вхо­дят тех­но­ло­гии непре­рыв­но­го вы­пус­ка (Ansible, Drone), ре­а­ли­зу­ю­щие ин­те­гра­ци­он­ные ре­ше­ния для ав­то­ма­ти­за­ции про­це­дур Devops, ши­ро­ко ис­поль­зу­е­мых в сре­дах раз­ра­бот­ки мик­ро­сер­ви­сов. Седь­мая вол­на — тех­но­ло­гии «ха­ос-ин­жи­ни­рин­га» (Simian Army, Chaos Toolkit), ко­то­рые ав­то­ма­ти­зи­ру­ют выполнение об­ще­си­стем­ных те­стов на­деж­но­сти и без­опас­но­сти, в том чис­ле вне­се­ние неиправ­но­стей и ими­та­цию атак (attack injection).

Вось­мая вол­на — тех­но­ло­гии по­сред­ни­ков (Prana, Envoy), ко­то­рые ин­кап­су­ли­ру­ют функ­ции свя­зи — на­при­мер, об­на­ру­же­ние сер­ви­сов, ком­му­ни­ка­ци­он­ные биб­лио­те­ки для кон­крет­ных про­то­ко­лов и сред­ства обес­пе­че­ния от­ка­зо­устой­чи­во­сти, — что­бы аб­стра­ги­ро­вать их для раз­ра­бот­чи­ков. Де­вя­тая вол­на — это тех­но­ло­гии «бес­сер­вер­ных» вы­чис­ле­ний (AWS Lambda, Openwhisk), ко­то­рые ре­а­ли­зу­ют об­лач­ную мо­дель функ­ции в ви­де сер­ви­са. Она дает поль­зо­ва­те­лям воз­мож­ность раз­ра­ба­ты­вать, раз­вер­ты­вать и за­пус­кать в ра­бо­чем ре­жи­ме раз­лич­ные мел­кие функ­ции без слож­но­стей, свя­зан­ных с со­зда­ни­ем и управ­ле­ни­ем ин­фра­струк­тур­ны­ми ре­сур­са­ми, необ­хо­ди­мы­ми для вы­пол­не­ния этих функ­ций (в част­но­сти, не нуж­но при­ни­мать мер, свя­зан­ных с неод­но­род­но­стью тра­фи­ка). И на­ко­нец, де­ся­тая вол­на — это тех­но­ло­гии сер­вис­ной mesh-се­ти (Linkerd, Istio), раз­ви­ва­ю­щие идеи по­сред­ни­ков (sidecar) и предо­став­ля­ю­щие пол­но­стью ин­те­гри­ро­ван­ные сред­ства мо­ни­то­рин­га меж­сер­вис­ных ком­му­ни­ка­ций и сре­ду управ­ле­ния.

По­дав­ля­ю­щее боль­шин­ство ин­стру­мен­тов, пред­став­лен­ных на рис. 1, раз­ра­бо­та­но участ­ни­ка­ми рын­ка. Един­ствен­ное ис­клю­че­ние — Mesos, система, ро­див­ша­я­ся из про­то­ти­па, со­здан­но­го ис­сле­до­ва­те­ля­ми в Ка­ли­фор­ний­ском уни­вер­си­те­те Берк­ли. При этом боль­шин­ство ин­стру­мен­тов раз­ра­ба­ты­ва­ет­ся в от­кры­тых ко­дах.

Ар­хи­тек­тур­ная точ­ка зре­ния

Вли­я­ние пе­ре­чис­лен­ных тех­но­ло­ги­че­ских волн мож­но про­сле­дить по то­му, как ме­ня­лась ар­хи­тек­ту­ра мик­ро­сер­вис­ных при­ло­же­ний. На рис. 2 по­ка­за­ны че­ты­ре по­ко­ле­ния мик­ро­сер­вис­ных ар­хи­тек­тур.

В эпо­ху пер­во­го по­ко­ле­ния (рис. 2, а) ин­ди­ви­ду­аль­ные сер­ви­сы упа­ко­вы­ва­лись с по­мо­щью об­лег­чен­ных кон­тей­нер­ных тех­но­ло­гий, та­ких как LXC. Раз­вер­ты­ва­ние и управ­ле­ние в пе­ри­од вы­пол­не­ния осу­ществ­ля­лись си­сте­мой ор­кест­ров­ки кон­тей­не­ров, на­при­мер Mesos. Каж­дый сер­вис отве­чал за от­сле­жи­ва­ние ме­сто­на­хож­де­ния дру­гих сер­ви­сов, ко­то­рые вы­зы­ва­лись с по­мо­щью спе­ци­аль­ных ком­му­ни­ка­ци­он­ных про­то­ко­лов. Ме­ха­низ­мы обработки от­ка­зов, на­при­мер по­втор­ной по­пыт­ки и сни­же­ния ско­ро­сти со­еди­не­ния, ре­а­ли­зо­вы­ва­лись непо­сред­ствен­но в ис­ход­ном ко­де сер­ви­сов. С ро­стом числа сер­ви­сов в каж­дом при­ло­же­нии и по­треб­но­сти мно­го­крат­но раз­вер­ты­вать сер­ви­сы в раз­лич­ных сре­дах вы­пол­не­ния воз­ник­ли слож­но­сти с об­на­ру­же­ни­ем нуж­ных эк­зем­пля­ров сер­ви­са для вы­зо­ва. А по­сколь­ку но­вые сер­ви­сы ре­а­ли­зо­ва­лись на дру­гих язы­ках про­грам­ми­ро­ва­ния, ста­ло все слож­нее по­втор­но ис­поль­зо­вать су- ще­ству­ю­щий код, об­на­ру­жи­вать ошиб­ки и обрабатывать от­ка­зы.

Для ре­ше­ния этих про­блем в ар­хи­тек­ту­рах вто­ро­го по­ко­ле­ния (рис. 2, б) по­яви­лись сер­ви­сы об­на­ру­же­ния и мно­го­крат­но ис­поль­зу­е­мые биб­лио­те­ки от­ка­зо­устой­чи­вой свя­зи. Сер­ви­сы ре­ги­стри­ро­ва­ли предо­став­ля­е­мые функ­ции в еди­ной служ­бе об­на­ру­же­ния, на­при­мер Consul. За­тем кли­ент­ские сер­ви­сы мог­ли ди­на­ми­че­ски об­на­ру­жи­вать эти функ­ции и обращаться к ним, не ука­зы­вая местонахождение са­мих вы­зы­ва­е­мых сер­ви­сов. В про­цес­се вы­зо­ва все функ­ции, ка­са­ю­щи­е­ся про­то­ко­лов и обработки от­ка­зов, воз­ла­га­лись на со­от­вет­ству­ю­щую ком­му­ни­ка­ци­он­ную биб­лио­те­ку, на­при­мер Finagle. Эта стра­те­гия не толь­ко упро­ща­ла ре­а­ли­за­цию и те­сти­ро­ва­ние сер­ви­сов, но и поз­во­ля­ла мно­го­крат­но ис­поль­зо­вать шаб­ло­ны ком­му­ни­ка­ци­он­но­го ко­да в раз­лич­ных сер­ви­сах.

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

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

Ко­гда sidecar ис­поль­зу­ют­ся в ка­че­стве се­те­вых по­сред­ни­ков, их удоб­но при­ме­нять для мо­ни­то­рин­га всех вза­и­мо­дей­ствий мик­ро­сер­ви­сов при­ло­же­ния. Имен­но эта идея лег­ла в ос­но­ву тех­но­ло­гий сер­вис­ных mesh­се­тей на­по­до­бие Linkerd. Со­от­вет­ству­ю­щие сред­ства рас­ши­ря­ют кон­цеп­цию пол­но­цен­ных по­сред­ни­ков, предо­став­ляя бо­лее ин­те­гри­ро­ван­ное ре­ше­ние для меж­сер­вис­ных ком­му­ни­ка­ций. Опе­ра­то­ры при­ло­же­ния мо­гут ве­сти мо­ни­то­ринг в ди­на­ми­ке и управ­лять по­ве­де­ни­ем мно­же­ства рас­пре­де­лен­ных sidecar с по­мо­щью цен­тра­ли­зо­ван­но­го слоя управ­ле­ния. Та­ким об­ра­зом опе­ра­то­ры мо­гут бо­лее де­таль­но кон­тро­ли­ро­вать раз­лич­ные па­ра­мет­ры меж­сер­вис­ных ком­му­ни­ка­ций, вклю­чая об­на­ру­же­ние, ба­лан­си­ров­ку на­груз­ки, от­ка­зо­устой­чи­вость, марш­ру­ти­за­цию со­об­ще­ний и безопасность.

Чет­вер­тое по­ко­ле­ние (рис. 2, в) пе­ре­но­сит ми­к­ро­сер­вис­ные при­ло­же­ния в но­вую сфе­ру. Идея в том, что­бы ис­поль­зо­вать со­вре­мен­ные тех­но­ло­гии Faas (function as a service) и бес­сер­вер­ных вы­чис­ле­ний на­по­до­бие AWS Lambda с це­лью еще боль­ше упро­стить раз­ра­бот­ку и вы­пуск мик­ро­сер­ви­сов. В рам­ках бес­сер­вер­ной арх­тек­ту­ры ми­к­ро­сер­вис­ные при­ло­же­ния по сути пре­вра­ща­ют­ся в на­бор «эфе­мер­ных» функ­ций,

Рис. 1. Хро­но­ло­гия раз­ви­тия тех­но­ло­гий мик­ро­сер­ви­сов

Newspapers in Russian

Newspapers from Russia

© PressReader. All rights reserved.