26 лютага мы праводзілі мітап Apache Ignite GreenSource, дзе выступалі кантрыб'ютары open source праекту. . Важнай падзеяй у жыцці гэтай супольнасці стала перабудова кампанента , Які дазваляе разгарнуць карыстацкія мікрасэрвісы прама ў кластары Ignite. Пра гэты няпросты працэс на мітапе распавёў , праграмны інжынер і ўжо больш за два гады кантрыб'ютар Apache Ignite.
Пачнём з таго, што такое Apache Ignite наогул. Гэта база дадзеных, якая ўяўляе сабой размеркаванае Key/Value сховішча з падтрымкай SQL, транзакцыйнасці і кэшавання. Акрамя таго, Ignite дазваляе разгарнуць прыстасаваныя сэрвісы прама ў кластары Ignite. Распрацоўніку становяцца даступныя ўсе прылады, якія падае Ignite - размеркаваныя структуры дадзеных, Messaging, Streaming, Compute і Data Grid. Напрыклад, пры выкарыстанні Data Grid знікае праблема з адміністраваннем асобнай інфраструктуры пад сховішча дадзеных і, як следства, якія вынікаюць з гэтага накладныя выдаткі.
Выкарыстоўваючы API Service Grid, можна задэплоіць сэрвіс, проста паказаўшы ў канфігурацыі схему дэплою і, адпаведна, сам сэрвіс.
Звычайна схема дэплою - гэта ўказанне колькасці інстансаў, якое павінна быць разгорнута на вузлах кластара. Ёсць дзве тыповыя схемы дэплою. Першая - гэта Cluster Singleton: у любы момант часу ў кластары гарантавана будзе даступны адзін асобнік карыстацкага сэрвісу. Другая — Node Singleton: на кожным вузле кластара разгорнута па адным асобніку сэрвісу.
Таксама карыстач можа паказаць колькасць інстансаў сэрвісу ва ўсім кластары і вызначыць прэдыкат для фільтрацыі падыходных вузлоў. Пры такім сцэнары Service Grid сам разлічыць аптымальнае размеркаванне для разгортвання сэрвісаў.
Акрамя таго, існуе такая фіча як Affinity Service. Affinity - гэта функцыя, якая вызначае сувязь ключоў з партыцыямі і сувязь партый з вузламі ў тапалогіі. Па ключы можна вызначыць primary-вузел, на якім захоўваюцца дадзеныя. Такім чынам можна асацыяваць ваш уласны сэрвіс з ключом і кэшам affinity-функцыі. У выпадку змены affinity-функцыі адбудзецца аўтаматычны рэдэплой. Так сэрвіс будзе заўсёды размешчаны побач з дадзенымі, якімі ён павінен маніпуляваць, і, адпаведна, зменшыць накладныя выдаткі на доступ да інфармацыі. Такую схему можна назваць свайго роду калацыраванымі вылічэннямі.
Цяпер, калі мы разабралі, у чым хараство Service Grid, раскажам аб яго гісторыі развіцця.
Што было раней
Мінулая рэалізацыя Service Grid грунтавалася на транзакцыйным рэплікаваным сістэмным кэшы Ignite. Пад словам "кэш" у Ignite маецца на ўвазе сховішча. То бок, гэта не нешта часовае, як можна падумаць. Нягледзячы на тое, што кэш які рэплікуецца і кожная нода ўтрымоўвае ўвесь набор дадзеных, усярэдзіне кэш мае партыцыянаванае ўяўленне. Гэта звязана з аптымізацыяй сховішчаў.
Што адбывалася, калі карыстач жадаў задэплоіць сэрвіс?
- Усе вузлы ў кластары падпісваліся на абнаўленне даных у сховішча з дапамогай убудаванага механізму Continuous Query.
- Нода-ініцыятар пад read-committed транзакцыяй рабіла ў базу запіс, якая ўтрымоўвала канфігурацыю сэрвісу, у тым ліку серыялізаваны інстанс.
- Пры атрыманні апавяшчэння аб новым запісе каардынатар разлічваў размеркаванне зыходзячы з канфігурацыі. Атрыманы аб'ект запісваўся назад у базу.
- Калі вузел уваходзіў у размеркаванне, каардынатар павінен быў яго задэплоіць.
Што нас не задавальняла
У нейкі момант мы дашлі да высновы: так працаваць з сэрвісамі нельга. Прычын было некалькі.
Калі падчас дэплою адбывалася нейкая памылка, то пра яе можна было даведацца толькі з логаў таго вузла, дзе ўсё адбылося. Існаваў толькі асінхронны дэплой, так што пасля вяртання карыстачу кіравання ад метаду дэплою трэба было некаторы дадатковы час для старту сэрвісу - і тым часам карыстач нічым кіраваць не мог. Каб развіваць Service Grid далей, пілаваць новыя фічы, прыцягваць новых карыстальнікаў і рабіць усім жыццё прасцей, трэба нешта мяняць.
Пры праектаванні новага Service Grid мы ў першую чаргу жадалі падаць гарантыю сінхроннага дэплою: як толькі карыстачу вярнулася кіраванне ад API, ён адразу можа карыстацца сэрвісамі. Таксама хацелася даць ініцыятару магчымасць апрацоўваць памылкі дэплою.
Акрамя таго, хацелася аблегчыць рэалізацыю, а менавіта адысці ад транзакцый і рэбалансіроўкі. Нягледзячы на тое, што кэш рэпліцыруемы і балансавання няма, падчас вялікага дэплойменту з мноствам нод узнікалі праблемы. Пры змене тапалогіі нодам неабходна абменьвацца інфармацыяй, і пры вялікім дэплойменце гэтыя дадзеныя могуць важыць вельмі шмат.
Калі тапалогія была нестабільная, каардынатару патрабавалася пералічваць размеркаванне сэрвісаў. Ды і ў цэлым, калі даводзіцца працаваць з транзакцыямі на нестабільнай тапалогіі, гэта можа прывесці да складана-прагназуемым памылкам.
Праблемы
Якія ж глабальныя перамены без спадарожных праблем? Першай з іх стала змена тапалогіі. Трэба разумець, што ў любы момант, нават у момант дэплою сэрвісу, вузел можа ўвайсці ў кластар ці выйсці з яго. Больш таго, калі ў момант дэплою вузел увойдзе ў кластар, запатрабуецца кансістэнтна перадаць усю інфармацыю аб сэрвісах у новы вузел. І гаворка ідзе не толькі аб тым, што ўжо было разгорнута, але і аб бягучых і будучых дэплоях.
Гэта толькі адна з праблем, якія можна сабраць у асобны спіс:
- Як задэплоіць статычна сканфігураваныя сэрвісы пры старце вузла?
- Вынахад вузла з кластара – што рабіць калі вузел хосціў сэрвісы?
- Што рабіць, калі змяніўся каардынатар?
- Што рабіць, калі кліент перападключыўся да кластара?
- Ці трэба апрацаваць запыты актывацыі / дэактывацыі і як?
- А што, калі выклікалі дэстрай кэша, а ў нас завязаныя на яго афініці-сэрвісы?
І гэта далёка не ўсё.
рашэнне
У якасці мэтавага мы абралі падыход Event Driven з рэалізацыяй камунікацыі працэсаў з дапамогай паведамленняў. У Ignite ужо рэалізавана два кампаненты, якія дазваляюць вузлам перасылаць паведамленні паміж сабой, – communication-spi і discovery-spi.
Communication-spi дазваляе нодам наўпрост мець зносіны і перасылаць паведамленні. Ён добра падыходзіць для перасылкі вялікага аб'ёму дадзеных. Discovery-spi дазваляе адправіць паведамленне ўсім вузлам у кластары. У стандартнай рэалізацыі гэта робіцца па тапалогіі "кольца". Таксама ёсць інтэграцыя з Zookeeper, у гэтым выпадку выкарыстоўваецца тапалогія "зорка". Яшчэ варта адзначыць важны момант: discovery-spi дае гарантыі таго, што паведамленне сапраўды будзе дастаўлена ў правільным парадку ўсім вузлам.
Разгледзім пратакол дэплою. Усе карыстацкія запыты на дэплой і раздэплой дасылаюцца па discovery-spi. Гэта дае наступныя гарантыі:
- Запыт будзе атрыманы ўсімі вузламі ў кластары. Гэта дазволіць прадоўжыць апрацоўку запыту пры змене каардынатара. Таксама гэта значыць, што за адно паведамленне ў кожнага вузла з'явяцца ўсе неабходныя метададзеныя, такія як канфігурацыя сэрвісу і яго серыялізаваны інстанс.
- Строгі парадак дастаўкі паведамленняў дазваляе дазваляць канфлікты канфігурацый і канкуруючых запытаў.
- Бо ўваход вузла ў тапалогію апрацоўваецца таксама па discovery-spi, на новы вузел патрапяць усе неабходныя для працы з сэрвісамі дадзеныя.
Пры атрыманні запыту вузлы ў кластары валідзіруюць яго і фарміруюць задачы на апрацоўку. Гэтыя задачы складаюцца ў чаргу і затым апрацоўваюцца ў іншым струмені асобным воркерам. Гэта рэалізавана такім чынам, таму што дэплой можа займаць значны час і затрымліваць дарагі discovery-струмень недапушчальна.
Усе запыты з чаргі апрацоўваюцца дэплоймент-мэнэджэрам. У яго ёсць спецыяльны воркер, які выцягвае задачу з гэтай чаргі і ініцыялізуе яе, каб пачаць разгортванне. Пасля гэтага адбываюцца наступныя дзеянні:
- Кожны вузел самастойна разлічвае размеркаванне дзякуючы новай дэтэрмінаваных assignment-функцыі.
- Вузлы фармуюць паведамленне з вынікамі дэплою і адпраўляюць яго каардынатару.
- Каардынатар агрэгуе ўсе паведамленні і фармуе вынік усяго працэсу дэплою, які адпраўляецца па discovery-spi усім вузлам у кластары.
- Пры атрыманні выніку працэс дэплою завяршаецца, пасля чаго задача выдаляецца з чаргі.
Новы event-driven дызайн: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Калі ў момант разгортвання адбылася памылка, вузел адразу ж уключае гэтую памылку ў паведамленне, якое накіроўвае каардынатару. Пасля агрэгацыі паведамленняў каардынатар будзе мець інфармацыю аб усіх памылках падчас дэплою і адправіць гэтае паведамленне па discovery-spi. Інфармацыя пра памылкі будзе даступная на любым вузле ў кластары.
Па гэтым алгарытме працы апрацоўваюцца ўсе важныя падзеі ў Service Grid. Напрыклад, змена тапалогіі - гэта таксама паведамленне па discovery-spi. І ў цэлым, калі параўноўваць з тым, што было, пратакол атрымаўся дастаткова легкаважным і надзейным. Настолькі, каб апрацаваць любую сітуацыю падчас дэплою.
Што будзе далей
Зараз аб планах. Любая буйная дапрацоўка ў праекце Ignite выконваецца як ініцыятыва паляпшэння Ignite, так званага IEP. У рэдызайна Service Grid таксама ёсць IEP са сцёбнай назвай «Замена алею ў Сэрвіс Грыдзе». Але па факце мы памянялі не алей у рухавіку, а рухавік цалкам.
Задачы ў IEP мы падзялілі на 2 фазы. Першая - буйная фаза, якая заключаецца ў пераробцы пратакола дэплоя. Яна ўжо ўліта ў майстар, можна паспрабаваць новы Service Grid, які з'явіцца ў версіі 2.8. Другая фаза складаецца з мноства іншых задач:
- Гарачы рэдэплой
- Версіянаванне сэрвісаў
- Падвышэнне адмоваўстойлівасці
- Тонкі кліент
- Інструменты маніторынгу і падліку розных метрык
Напрыканцы можам параіць вам Service Grid для пабудовы адмоваўстойлівых сістэм высокай даступнасці. А таксама запрашаем да нас у и падзяліцца сваім досведам. Ваш досвед рэальна важны для супольнасці, ён дапаможа зразумець, куды рухацца далей, як у будучыні развіваць кампанент.
Крыніца: habr.com