Esittely
Kävi niin, että nykyisessä työpaikassani minun piti tutustua tähän tekniikkaan. Aloitan pienellä taustalla. Seuraavassa kokouksessa tiimillemme kerrottiin, että meidän on luotava integraatio tunnettu järjestelmä. Integroinnilla tarkoitettiin, että tämä tunnettu järjestelmä lähettäisi meille pyyntöjä HTTP:n kautta tiettyyn päätepisteeseen, ja me, kummallista kyllä, lähetimme vastaukset takaisin SOAP-sanoman muodossa. Kaikki näyttää yksinkertaiselta ja triviaalilta. Tästä seuraa, että tarvitset...
Tehtävä
Luo 3 palvelua. Ensimmäinen niistä on tietokannan päivityspalvelu. Tämä palvelu päivittää kolmannen osapuolen järjestelmästä uuden tiedon saapuessa tietokannassa olevat tiedot ja luo CSV-muodossa tiedoston siirtääkseen ne seuraavaan järjestelmään. Toisen palvelun päätepiste on nimeltään FTP-kuljetuspalvelu, joka vastaanottaa siirretyn tiedoston, vahvistaa sen ja tallentaa sen tiedostovarastoon FTP:n kautta. Kolmas palvelu, kuluttajatiedonsiirtopalvelu, toimii asynkronisesti kahden ensimmäisen kanssa. Se vastaanottaa kolmannen osapuolen ulkoiselta järjestelmältä pyynnön vastaanottaa yllä kuvattu tiedosto, ottaa valmiin vastaustiedoston, muuttaa sitä (päivittää tunnuksen, kuvauksen, linkToFile-kentät) ja lähettää vastauksen SOAP-viestin muodossa. Eli kokonaiskuva on seuraava: kaksi ensimmäistä palvelua aloittavat toimintansa vasta kun päivitettävät tiedot ovat saapuneet. Kolmas palvelu toimii jatkuvasti, koska tiedonkuluttajia on paljon, noin 1000 datapyyntöä minuutissa. Palvelut ovat jatkuvasti saatavilla ja niiden esiintymät sijaitsevat eri ympäristöissä, kuten testi-, demo-, esituotanto- ja prod-ympäristöissä. Alla on kaavio näiden palvelujen toiminnasta. Haluan selventää heti, että joitain yksityiskohtia on yksinkertaistettu tarpeettoman monimutkaisuuden välttämiseksi.
Tekninen syventäminen
Ongelmaan ratkaisua suunnitellessa päätimme ensin tehdä Java-sovelluksia käyttäen Spring-kehystä, Nginx balanceria, Postgres-tietokantaa ja muita teknisiä ja ei niin teknisiä asioita. Koska teknisen ratkaisun kehittämisen aika antoi meille mahdollisuuden harkita muita lähestymistapoja tämän ongelman ratkaisemiseksi, katseemme osui Apache NIFI -teknologiaan, joka on muodissa tietyissä piireissä. Sanon heti, että tämä tekniikka antoi meille mahdollisuuden huomata nämä 3 palvelua. Tässä artikkelissa kuvataan tiedostonsiirtopalvelun ja tiedonsiirtopalvelun kehitystä kuluttajalle, mutta jos artikkelista on hyötyä, kirjoitan tietokannan tietojen päivityspalvelusta.
Mikä tämä on
NIFI on hajautettu arkkitehtuuri nopeaan rinnakkaislataukseen ja tietojen käsittelyyn, suuri määrä laajennuksia lähteille ja muunnoksille, kokoonpanojen versioinnista ja paljon muuta. Mukava bonus on, että se on erittäin helppokäyttöinen. Triviaalit prosessit, kuten getFile, sendHttpRequest ja muut, voidaan esittää neliöinä. Jokainen neliö edustaa prosessia, jonka vuorovaikutus näkyy alla olevasta kuvasta. Prosessin asetusvuorovaikutuksista on kirjoitettu yksityiskohtaisempi dokumentaatio , niille, jotka puhuvat venäjää - . Dokumentaatio kuvaa täydellisesti NIFI:n purkamisen ja suorittamisen sekä prosessien, joka tunnetaan myös neliöinä, luomisen.
Ajatus artikkelin kirjoittamisesta syntyi pitkän etsinnän ja vastaanotetun tiedon jäsentämisen jälkeen joksikin tietoiseksi, sekä halusta helpottaa hieman tulevien kehittäjien elämää.
Esimerkki
Esimerkki siitä, kuinka neliöt ovat vuorovaikutuksessa toistensa kanssa, tarkastellaan. Yleinen kaava on melko yksinkertainen: Saamme HTTP-pyynnön (Teoriassa tiedosto pyynnön rungossa. NIFI:n ominaisuuksien osoittamiseksi tässä esimerkissä pyyntö käynnistää tiedoston vastaanottamisen paikallisesta tiedostomuistista ), sitten lähetämme takaisin vastauksen, että pyyntö on vastaanotettu, samanaikaisesti tiedoston vastaanottaminen FH:lta ja sen jälkeen prosessi FTP:n kautta FH:lle. On syytä selventää, että prosessit ovat vuorovaikutuksessa keskenään niin sanotun flowFilen kautta. Tämä on NIFI:n peruskokonaisuus, joka tallentaa attribuutteja ja sisältöä. Sisältö on dataa, jota stream-tiedosto edustaa. Toisin sanoen karkeasti sanottuna, jos vastaanotat tiedoston yhdestä ruudusta ja siirrät sen toiseen, sisältö on tiedostosi.
Kuten näet, tämä kuva näyttää yleisen prosessin. HandleHttpRequest - hyväksyy pyynnöt, ReplaceText - luo vastauksen rungon, HandleHttpResponse - lähettää vastauksen. FetchFile - vastaanottaa tiedoston tiedostovarastosta, siirtää sen neliöön PutSftp - laittaa tämän tiedoston FTP:lle määritettyyn osoitteeseen. Nyt lisää tästä prosessista.
Tässä tapauksessa pyyntö on kaiken alku. Katsotaanpa sen konfigurointiparametreja.
Kaikki täällä on melko triviaalia paitsi StandardHttpContextMap - tämä on eräänlainen palvelu, jonka avulla voit lähettää ja vastaanottaa pyyntöjä. Yksityiskohtaisemmin ja jopa esimerkkien avulla voit nähdä -
Seuraavaksi tarkastellaan neliön ReplaceText-määritysparametreja. On syytä kiinnittää huomiota ReplacementValueeseen - tämä palautetaan käyttäjälle vastauksen muodossa. Asetuksissa voit säätää kirjaamisen tasoa, näet lokit {missä purit nifi-paketin}/nifi-1.9.2/logs, on myös epäonnistumis-/onnistumisparametreja - näiden parametrien perusteella voit säätää prosessia kokonaisuutena . Toisin sanoen onnistuneen tekstinkäsittelyn tapauksessa kutsutaan prosessi, jossa lähetetään vastaus käyttäjälle, ja toisessa tapauksessa kirjaamme epäonnistuneen prosessin vain lokiin.
HandleHttpResponse-ominaisuuksissa ei ole mitään erityisen mielenkiintoista paitsi tila, kun vastaus on luotu onnistuneesti.
Olemme selvittäneet pyynnön ja vastauksen - siirrytään tiedoston vastaanottamiseen ja sen sijoittamiseen FTP-palvelimelle. FetchFile - vastaanottaa tiedoston asetuksissa määritetyllä polulla ja välittää sen seuraavalle prosessille.
Ja sitten PutSftp-neliö - sijoittaa tiedoston tiedostomuistiin. Näemme kokoonpanoparametrit alla.
On syytä kiinnittää huomiota siihen, että jokainen neliö on erillinen prosessi, joka on käynnistettävä. Tarkastelimme yksinkertaisinta esimerkkiä, joka ei vaadi monimutkaista räätälöintiä. Seuraavaksi tarkastelemme prosessia hieman monimutkaisempaa, jossa kirjoitamme hieman uriin.
Monimutkaisempi esimerkki
Tiedonsiirtopalvelu kuluttajalle osoittautui hieman monimutkaisemmaksi SOAP-sanoman muokkausprosessin vuoksi. Yleinen prosessi on esitetty alla olevassa kuvassa.
Tässäkään idea ei ole erityisen monimutkainen: saimme kuluttajalta pyynnön, että hän tarvitsee tietoja, lähetimme vastauksen, että hän oli vastaanottanut viestin, aloitimme vastaustiedoston vastaanottoprosessin, sitten muokkasimme sitä tietyllä logiikalla ja sitten siirsi tiedoston kuluttajalle SOAP-viestinä palvelimelle.
Mielestäni ei ole tarvetta kuvailla uudelleen niitä neliöitä, jotka näimme yllä - siirrytään suoraan uusiin. Jos joudut muokkaamaan mitä tahansa tiedostoa ja tavalliset ReplaceText-tyyppiset neliöt eivät sovellu, sinun on kirjoitettava oma käsikirjoituksesi. Tämä voidaan tehdä käyttämällä ExecuteGroogyScript-ruutua. Sen asetukset on esitetty alla.
Skriptin lataamiseen tähän neliöön on kaksi vaihtoehtoa. Ensimmäinen on lataamalla tiedosto komentosarjalla. Toinen on lisäämällä komentosarja scriptBodyyn. Sikäli kuin tiedän, executeScript-ruutu tukee useita kieliä - yksi niistä on groovy. Tulen pettymään java-kehittäjille - et voi kirjoittaa skriptejä Java-kielellä sellaisiin neliöihin. Niille, jotka todella haluavat, sinun on luotava oma mukautettu neliö ja lisättävä se NIFI-järjestelmään. Koko tähän operaatioon liittyy melko pitkä tanssi tamburiinilla, jota emme käsittele tässä artikkelissa. Valitsin kielen kielen. Alla on testiskripti, joka yksinkertaisesti päivittää tunnuksen asteittain SOAP-viestissä. On tärkeää huomata. Otat tiedoston flowFilesta ja päivität sen, älä unohda, että sinun täytyy laittaa se takaisin sinne päivitettynä. On myös syytä huomata, että kaikkia kirjastoja ei ole mukana. Saattaa käydä niin, että joudut silti tuomaan jonkin libistä. Toinen haittapuoli on, että tämän neliön käsikirjoitusta on melko vaikea korjata. On olemassa tapa muodostaa yhteys NIFI JVM:ään ja aloittaa virheenkorjausprosessi. Itse käynnistin paikallisen sovelluksen ja simuloin tiedoston vastaanottamista istunnosta. Tein myös virheenkorjauksen paikallisesti. Skriptiä ladattaessa ilmenevät virheet ovat melko helppoja Googlelle, ja NIFI kirjoittaa ne itse lokiin.
import org.apache.commons.io.IOUtils
import groovy.xml.XmlUtil
import java.nio.charset.*
import groovy.xml.StreamingMarkupBuilder
def flowFile = session.get()
if (!flowFile) return
try {
flowFile = session.write(flowFile, { inputStream, outputStream ->
String result = IOUtils.toString(inputStream, "UTF-8");
def recordIn = new XmlSlurper().parseText(result)
def element = recordIn.depthFirst().find {
it.name() == 'id'
}
def newId = Integer.parseInt(element.toString()) + 1
def recordOut = new XmlSlurper().parseText(result)
recordOut.Body.ClientMessage.RequestMessage.RequestContent.content.MessagePrimaryContent.ResponseBody.id = newId
def res = new StreamingMarkupBuilder().bind { mkp.yield recordOut }.toString()
outputStream.write(res.getBytes(StandardCharsets.UTF_8))
} as StreamCallback)
session.transfer(flowFile, REL_SUCCESS)
}
catch(Exception e) {
log.error("Error during processing of validate.groovy", e)
session.transfer(flowFile, REL_FAILURE)
}Itse asiassa tähän neliön mukauttaminen päättyy. Seuraavaksi päivitetty tiedosto siirretään neliöön, joka vastaa tiedoston lähettämisestä palvelimelle. Alla on tämän neliön asetukset.
Kuvaamme menetelmän, jolla SOAP-viesti lähetetään. Kirjoitamme missä. Seuraavaksi sinun on ilmoitettava, että tämä on SOAP.
Lisää useita ominaisuuksia, kuten isäntä ja toiminta (soapAction). Tallennamme ja tarkistamme. Voit nähdä lisätietoja SOAP-pyyntöjen lähettämisestä
Tarkastelimme useita vaihtoehtoja NIFI-prosessien käyttämiseen. Miten ne ovat vuorovaikutuksessa ja mikä on niiden todellinen hyöty? Käsitellyt esimerkit ovat testiesimerkkejä ja hieman erilaisia kuin taistelussa todellisuudessa tapahtuu. Toivottavasti tästä artikkelista on hieman hyötyä kehittäjille. Kiitos huomiostasi. Jos sinulla on kysyttävää, kirjoita. Yritän vastata.
Lähde: will.com