El 26 de febrer vam celebrar una reunió d'Apache Ignite GreenSource, on van parlar els col·laboradors del projecte de codi obert. . Un fet important en la vida d'aquesta comunitat va ser la reestructuració del component , que us permet implementar microserveis personalitzats directament en un clúster Ignite. Va parlar d'aquest difícil procés a la trobada , enginyer de programari i col·laborador d'Apache Ignite durant més de dos anys.
Comencem pel que és Apache Ignite en general. Aquesta és una base de dades que és un emmagatzematge de clau/valor distribuït amb suport per a SQL, transaccionalitat i memòria cau. A més, Ignite us permet desplegar serveis personalitzats directament en un clúster Ignite. El desenvolupador té accés a totes les eines que ofereix Ignite: estructures de dades distribuïdes, missatgeria, streaming, càlcul i graella de dades. Per exemple, quan s'utilitza Data Grid, desapareix el problema d'administrar una infraestructura separada per a l'emmagatzematge de dades i, com a conseqüència, els costos generals resultants.
Amb l'API Service Grid, podeu implementar un servei simplement especificant l'esquema de desplegament i, en conseqüència, el propi servei a la configuració.
Normalment, un esquema de desplegament és una indicació del nombre d'instàncies que s'han de desplegar als nodes del clúster. Hi ha dos esquemes de desplegament típics. El primer és Cluster Singleton: en qualsevol moment, es garanteix que una instància d'un servei d'usuari està disponible al clúster. El segon és Node Singleton: es desplega una instància del servei a cada node del clúster.
L'usuari també pot especificar el nombre d'instàncies de servei a tot el clúster i definir un predicat per filtrar els nodes adequats. En aquest escenari, Service Grid calcularà la distribució òptima per desplegar serveis.
A més, hi ha una característica com ara el servei d'afinitat. L'afinitat és una funció que defineix la relació de les claus amb les particions i la relació de les parts amb els nodes de la topologia. Amb la clau, podeu determinar el node principal on s'emmagatzemen les dades. D'aquesta manera, podeu associar el vostre propi servei amb una memòria cau de claus i funcions d'afinitat. Si la funció d'afinitat canvia, es produirà una redistribució automàtica. D'aquesta manera, el servei s'ubicarà sempre a prop de les dades que necessita manipular i, en conseqüència, es redueix la sobrecàrrega d'accés a la informació. Aquest esquema es pot anomenar una mena d'informàtica col·locada.
Ara que hem descobert quina és la bellesa de Service Grid, parlem de la seva història de desenvolupament.
Què va passar abans
La implementació anterior de Service Grid es basava en la memòria cau del sistema replicada transaccional d'Ignite. La paraula "caché" a Ignite fa referència a l'emmagatzematge. És a dir, això no és una cosa temporal, com podríeu pensar. Tot i que la memòria cau es replica i cada node conté tot el conjunt de dades, dins de la memòria cau té una representació particionada. Això es deu a l'optimització de l'emmagatzematge.
Què va passar quan l'usuari va voler desplegar el servei?
- Tots els nodes del clúster es van subscriure per actualitzar les dades de l'emmagatzematge mitjançant el mecanisme de consulta contínua integrat.
- El node iniciador, sota una transacció compromesa de lectura, va fer un registre a la base de dades que contenia la configuració del servei, inclosa la instància serialitzada.
- Quan es va notificar una nova entrada, el coordinador va calcular la distribució en funció de la configuració. L'objecte resultant es va tornar a escriure a la base de dades.
- Si un node formava part de la distribució, el coordinador havia de desplegar-lo.
El que no ens va bé
En algun moment vam arribar a la conclusió: aquesta no és la manera de treballar amb els serveis. Hi havia diversos motius.
Si es va produir algun error durant el desplegament, només es podria esbrinar als registres del node on va passar tot. Només hi va haver un desplegament asíncron, de manera que després de tornar el control a l'usuari des del mètode de desplegament, es va necessitar un temps addicional per iniciar el servei, i durant aquest temps l'usuari no va poder controlar res. Per tal de desenvolupar encara més la quadrícula de serveis, crear noves funcions, atraure nous usuaris i facilitar la vida a tothom, alguna cosa ha de canviar.
A l'hora de dissenyar la nova Service Grid, hem volgut, en primer lloc, oferir una garantia de desplegament síncron: tan bon punt l'usuari tornava el control des de l'API, podia utilitzar immediatament els serveis. També volia donar a l'iniciador la capacitat de gestionar els errors de desplegament.
A més, volia simplificar la implementació, és a dir, allunyar-se de les transaccions i el reequilibri. Malgrat que la memòria cau es replica i no hi ha equilibri, van sorgir problemes durant un gran desplegament amb molts nodes. Quan la topologia canvia, els nodes necessiten intercanviar informació i, amb un gran desplegament, aquestes dades poden pesar molt.
Quan la topologia era inestable, el coordinador havia de recalcular la distribució dels serveis. I, en general, quan heu de treballar amb transaccions en una topologia inestable, això pot provocar errors difícils de predir.
Problemes
Què són els canvis globals sense problemes associats? El primer d'ells va ser un canvi de topologia. Heu d'entendre que en qualsevol moment, fins i tot en el moment del desplegament del servei, un node pot entrar o sortir del clúster. A més, si en el moment del desplegament el node s'uneix al clúster, caldrà transferir de manera coherent tota la informació sobre els serveis al nou node. I parlem no només del que ja s'ha desplegat, sinó també dels desplegaments actuals i futurs.
Aquest és només un dels problemes que es poden recollir en una llista separada:
- Com implementar serveis configurats estàticament a l'inici del node?
- Sortir d'un node del clúster: què fer si el node allotja serveis?
- Què fer si el coordinador ha canviat?
- Què cal fer si el client es torna a connectar al clúster?
- Les sol·licituds d'activació/desactivació s'han de processar i com?
- Què passa si demanessin la destrucció de la memòria cau i hi tenim serveis d'afinitat vinculats?
I això no és tot.
decisió
Com a objectiu, vam triar l'enfocament basat en esdeveniments amb la implementació de la comunicació de processos mitjançant missatges. Ignite ja implementa dos components que permeten als nodes reenviar missatges entre ells: communication-spi i discovery-spi.
Communication-spi permet als nodes comunicar-se directament i reenviar missatges. És molt adequat per enviar grans quantitats de dades. Discovery-spi us permet enviar un missatge a tots els nodes del clúster. A la implementació estàndard, això es fa mitjançant una topologia en anell. També hi ha integració amb Zookeeper, en aquest cas s'utilitza una topologia en estrella. Un altre punt important a destacar és que discovery-spi ofereix garanties que el missatge es lliurarà definitivament en l'ordre correcte a tots els nodes.
Vegem el protocol de desplegament. Totes les sol·licituds dels usuaris per a la implementació i el desplegament s'envien mitjançant discovery-spi. Això dóna el següent garantia:
- La sol·licitud la rebran tots els nodes del clúster. Això permetrà que la sol·licitud continuï amb la tramitació quan canviï el coordinador. Això també vol dir que en un missatge, cada node tindrà totes les metadades necessàries, com ara la configuració del servei i la seva instància serialitzada.
- L'ordre estricte de lliurament de missatges ajuda a resoldre els conflictes de configuració i les sol·licituds en competència.
- Com que l'entrada del node a la topologia també es processa mitjançant discovery-spi, el nou node rebrà totes les dades necessàries per treballar amb serveis.
Quan es rep una sol·licitud, els nodes del clúster la validen i creen tasques de processament. Aquestes tasques es posen a la cua i després es processen en un altre fil per un treballador independent. S'implementa d'aquesta manera perquè el desplegament pot trigar una quantitat significativa de temps i retardar de manera intolerable el costós flux de descobriments.
Totes les sol·licituds de la cua les processa el gestor de desplegament. Té un treballador especial que treu una tasca d'aquesta cua i la inicialitza per començar el desplegament. Després d'això, es produeixen les accions següents:
- Cada node calcula de manera independent la distribució gràcies a una nova funció d'assignació determinista.
- Els nodes generen un missatge amb els resultats del desplegament i l'envien al coordinador.
- El coordinador agrega tots els missatges i genera el resultat de tot el procés de desplegament, que s'envia mitjançant discovery-spi a tots els nodes del clúster.
- Quan es rep el resultat, finalitza el procés de desplegament i, després, la tasca s'elimina de la cua.
Nou disseny basat en esdeveniments: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Si es produeix un error durant el desplegament, el node inclou immediatament aquest error en un missatge que envia al coordinador. Després de l'agregació de missatges, el coordinador tindrà informació sobre tots els errors durant el desplegament i enviarà aquest missatge mitjançant discovery-spi. La informació d'error estarà disponible a qualsevol node del clúster.
Tots els esdeveniments importants de la xarxa de serveis es processen mitjançant aquest algorisme operatiu. Per exemple, canviar la topologia també és un missatge mitjançant discovery-spi. I en general, en comparació amb el que hi havia abans, el protocol va resultar ser bastant lleuger i fiable. Suficient per gestionar qualsevol situació durant el desplegament.
Què passarà després
Ara sobre els plans. Qualsevol canvi important al projecte Ignite es completa com una iniciativa de millora d'Ignite, anomenada IEP. El redisseny de la xarxa de serveis també té un IEP: amb el títol burleu "Canvi d'oli a la xarxa de serveis". Però de fet, no hem canviat l'oli del motor, sinó tot el motor.
Hem dividit les tasques de l'IEP en 2 fases. La primera és una fase important, que consisteix a reelaborar el protocol de desplegament. Ja està inclòs al mestre, podeu provar la nova Service Grid, que apareixerà a la versió 2.8. La segona fase inclou moltes altres tasques:
- Redistribució en calent
- Versions del servei
- Augment de la tolerància a fallades
- Client prim
- Eines de seguiment i càlcul de diverses mètriques
Finalment, us podem assessorar sobre Service Grid per construir sistemes d'alta disponibilitat i tolerants a errors. També et convidem a visitar-nos a и comparteix la teva experiència. La vostra experiència és molt important per a la comunitat; us ajudarà a entendre cap a on avançar, com desenvolupar el component en el futur.
Font: www.habr.com