Cyflwyniad
Digwyddodd felly bod yn rhaid i mi ddod yn gyfarwydd â'r dechnoleg hon yn fy man gwaith presennol. Dechreuaf gydag ychydig o gefndir. Yn y cyfarfod nesaf, dywedwyd wrth ein tîm bod angen i ni greu integreiddio gyda system hysbys. Trwy integreiddio golygwyd y byddai'r system adnabyddus hon yn anfon ceisiadau atom trwy HTTP i bwynt terfyn penodol, a byddem, yn rhyfedd ddigon, yn anfon ymatebion yn ôl ar ffurf neges SEBON. Mae popeth yn ymddangos yn syml ac yn ddibwys. O hyn mae'n dilyn bod angen i chi ...
Gorchwyl
Creu 3 gwasanaeth. Y cyntaf ohonynt yw'r Gwasanaeth Diweddaru Cronfa Ddata. Mae'r gwasanaeth hwn, pan fydd data newydd yn cyrraedd o system trydydd parti, yn diweddaru'r data yn y gronfa ddata ac yn cynhyrchu ffeil mewn fformat CSV i'w drosglwyddo i'r system nesaf. Gelwir pwynt terfynol yr ail wasanaeth - Gwasanaeth Trafnidiaeth FTP, sy'n derbyn y ffeil a drosglwyddwyd, yn ei ddilysu, ac yn ei roi mewn storfa ffeiliau trwy FTP. Mae'r trydydd gwasanaeth, y gwasanaeth trosglwyddo data defnyddwyr, yn gweithio'n anghydamserol â'r ddau gyntaf. Mae'n derbyn cais gan system allanol trydydd parti i dderbyn y ffeil a drafodwyd uchod, yn cymryd y ffeil ymateb parod, yn ei haddasu (yn diweddaru'r meysydd id, disgrifiad, linkToFile) ac yn anfon yr ymateb ar ffurf neges SEBON. Hynny yw, mae'r darlun cyffredinol fel a ganlyn: mae'r ddau wasanaeth cyntaf yn dechrau eu gwaith dim ond pan fydd y data ar gyfer diweddaru wedi cyrraedd. Mae'r trydydd gwasanaeth yn gweithio'n gyson oherwydd bod llawer o ddefnyddwyr gwybodaeth, tua 1000 o geisiadau am ddata y funud. Mae gwasanaethau ar gael yn gyson ac mae eu hachosion wedi'u lleoli mewn gwahanol amgylcheddau, megis prawf, demo, cyn-gynhyrchu a chynnyrch. Isod mae diagram o sut mae'r gwasanaethau hyn yn gweithio. Gadewch imi egluro ar unwaith bod rhai manylion wedi'u symleiddio er mwyn osgoi cymhlethdod diangen.
Dyfnhau Technegol
Wrth gynllunio ateb i'r broblem, fe wnaethom benderfynu yn gyntaf wneud ceisiadau yn Java gan ddefnyddio fframwaith y Gwanwyn, Nginx balancer, cronfa ddata Postgres a phethau technegol eraill ac nid mor dechnegol. Gan fod yr amser i ddatblygu datrysiad technegol wedi caniatáu inni ystyried dulliau eraill o ddatrys y broblem hon, syrthiodd ein golwg ar dechnoleg Apache NIFI, sy'n ffasiynol mewn rhai cylchoedd. Fe ddywedaf ar unwaith fod y dechnoleg hon wedi caniatáu inni sylwi ar y 3 gwasanaeth hyn. Bydd yr erthygl hon yn disgrifio datblygiad gwasanaeth cludo ffeiliau a gwasanaeth trosglwyddo data i'r defnyddiwr, ond os yw'r erthygl yn ddefnyddiol, byddaf yn ysgrifennu am y gwasanaeth ar gyfer diweddaru data yn y gronfa ddata.
Beth ydyn nhw
Mae NIFI yn bensaernïaeth ddosbarthedig ar gyfer llwytho a phrosesu data yn gyfochrog yn gyflym, nifer fawr o ategion ar gyfer ffynonellau a thrawsnewidiadau, fersiynau ffurfwedd a llawer mwy. Bonws braf yw ei fod yn hawdd iawn i'w ddefnyddio. Gellir cynrychioli prosesau dibwys fel getFile, sendHttpRequest ac eraill fel sgwariau. Mae pob sgwâr yn cynrychioli proses, y gellir gweld ei rhyngweithiad yn y ffigur isod. Mae dogfennaeth fanylach ar ryngweithiadau sefydlu prosesau wedi'i hysgrifennu
Ganed y syniad i ysgrifennu erthygl ar ôl chwiliad hir a strwythuro'r wybodaeth a dderbyniwyd yn rhywbeth ymwybodol, yn ogystal â'r awydd i wneud bywyd ychydig yn haws i ddatblygwyr y dyfodol.
Enghraifft
Ystyrir enghraifft o sut mae sgwariau'n rhyngweithio â'i gilydd. Mae'r cynllun cyffredinol yn eithaf syml: Rydym yn derbyn cais HTTP (Mewn theori, gyda ffeil yng nghorff y cais. Er mwyn dangos galluoedd NIFI, yn yr enghraifft hon mae'r cais yn cychwyn y broses o dderbyn ffeil o'r storfa ffeiliau leol ), yna byddwn yn anfon ymateb yn ôl bod y cais wedi'i dderbyn, ochr yn ochr â'r broses o dderbyn ffeil gan FH ac yna'r broses o'i symud trwy FTP i FH. Mae'n werth egluro bod prosesau'n rhyngweithio â'i gilydd trwy'r llifFile fel y'i gelwir. Dyma'r endid sylfaenol yn NIFI sy'n storio priodoleddau a chynnwys. Cynnwys yw'r data sy'n cael ei gynrychioli gan y ffeil ffrwd. Hynny yw, yn fras, os ydych chi'n derbyn ffeil o un sgwâr a'i drosglwyddo i un arall, y cynnwys fydd eich ffeil.
Fel y gwelwch, mae'r llun hwn yn dangos y broses gyffredinol. HandleHttpRequest - yn derbyn ceisiadau, ReplaceText - yn cynhyrchu corff ymateb, HandleHttpResponse - yn anfon ymateb. FetchFile - yn derbyn ffeil o storfa ffeil, yn ei throsglwyddo i'r sgwâr PutSftp - yn rhoi'r ffeil hon ar FTP, yn y cyfeiriad penodedig. Nawr mwy am y broses hon.
Yn yr achos hwn, y cais yw dechrau popeth. Gadewch i ni edrych ar ei baramedrau cyfluniad.
Mae popeth yma yn eithaf dibwys ac eithrio StandardHttpContextMap - mae hwn yn fath o wasanaeth sy'n caniatáu ichi anfon a derbyn ceisiadau. Yn fwy manwl a hyd yn oed gydag enghreifftiau, gallwch weld -
Nesaf, gadewch i ni edrych ar baramedrau cyfluniad ReplaceText y sgwâr. Mae'n werth talu sylw i ReplacementValue - dyma beth fydd yn cael ei ddychwelyd i'r defnyddiwr ar ffurf ymateb. Mewn gosodiadau gallwch addasu lefel y logio, gallwch weld y logiau {lle wnaethoch chi ddadbacio nifi}/nifi-1.9.2/logs, mae yna hefyd baramedrau methiant/llwyddiant - yn seiliedig ar y paramedrau hyn gallwch reoli'r broses gyfan . Hynny yw, yn achos prosesu testun llwyddiannus, bydd y broses o anfon ymateb at y defnyddiwr yn cael ei alw, ac mewn achos arall byddwn yn syml yn cofnodi'r broses aflwyddiannus.
Nid oes unrhyw beth arbennig o ddiddorol yn yr eiddo HandleHttpResponse ac eithrio'r statws pan fydd ymateb yn cael ei greu'n llwyddiannus.
Rydym wedi datrys y cais a'r ymateb - gadewch i ni symud ymlaen i dderbyn y ffeil a'i gosod ar y gweinydd FTP. FetchFile - yn derbyn ffeil ar y llwybr a nodir yn y gosodiadau ac yn ei drosglwyddo i'r broses nesaf.
Ac yna mae sgwâr PutSftp - yn gosod y ffeil yn y storfa ffeiliau. Gallwn weld y paramedrau cyfluniad isod.
Mae'n werth talu sylw i'r ffaith bod pob sgwâr yn broses ar wahân y mae'n rhaid ei lansio. Fe wnaethom edrych ar yr enghraifft symlaf nad oes angen unrhyw addasu cymhleth. Nesaf, byddwn yn edrych ar y broses ychydig yn fwy cymhleth, lle byddwn yn ysgrifennu ychydig ar y rhigolau.
Enghraifft fwy cymhleth
Roedd y gwasanaeth trosglwyddo data i'r defnyddiwr ychydig yn fwy cymhleth oherwydd y broses o addasu'r neges SEBON. Dangosir y broses gyffredinol yn y ffigur isod.
Yma nid yw'r syniad hefyd yn arbennig o gymhleth: cawsom gais gan y defnyddiwr ei fod angen data, anfonodd ymateb ei fod wedi derbyn neges, cychwynnodd y broses o dderbyn y ffeil ymateb, yna ei olygu gyda rhesymeg benodol, ac yna trosglwyddo'r ffeil i'r defnyddiwr ar ffurf neges SEBON i'r gweinydd.
Dwi’n meddwl nad oes angen disgrifio eto’r sgwariau hynny a welsom uchod – gadewch i ni symud yn syth at y rhai newydd. Os oes angen i chi olygu unrhyw ffeil ac nad yw sgwariau arferol o fath ReplaceText yn addas, bydd yn rhaid i chi ysgrifennu eich sgript eich hun. Gellir gwneud hyn gan ddefnyddio sgwâr ExecuteGroogyScript. Cyflwynir ei osodiadau isod.
Mae dau opsiwn ar gyfer llwytho'r sgript i'r sgwâr hwn. Y cyntaf yw trwy lawrlwytho ffeil gyda sgript. Yr ail yw trwy fewnosod sgript i scriptBody. Hyd y gwn i, mae'r sgwâr executeScript yn cynnal sawl iaith - mae un ohonyn nhw'n groovy. Byddaf yn siomi datblygwyr java - ni allwch ysgrifennu sgriptiau yn java mewn sgwariau o'r fath. I'r rhai sydd wir eisiau, mae angen i chi greu eich sgwâr arfer eich hun a'i ychwanegu at y system NIFI. Mae dawns eithaf hir gyda thambwrîn yn cyd-fynd â'r llawdriniaeth gyfan hon, na fyddwn yn delio â hi yn yr erthygl hon. Dewisais yr iaith groovy. Isod mae sgript prawf sy'n diweddaru'r id yn raddol mewn neges SEBON. Mae'n bwysig nodi. Rydych chi'n cymryd y ffeil o flowFile ac yn ei diweddaru, peidiwch ag anghofio bod angen i chi ei rhoi yn ôl yno, ei diweddaru. Mae'n werth nodi hefyd nad yw pob llyfrgell wedi'i chynnwys. Efallai y bydd yn rhaid i chi fewnforio un o'r libs o hyd. Anfantais arall yw bod y sgript yn y sgwâr hwn yn eithaf anodd ei dadfygio. Mae yna ffordd i gysylltu â'r NIFI JVM a dechrau'r broses difa chwilod. Yn bersonol, lansiais gais lleol ac efelychu derbyn ffeil o'r sesiwn. Fe wnes i ddadfygio yn lleol hefyd. Mae gwallau sy'n ymddangos wrth lwytho sgript yn eithaf hawdd i Google ac yn cael eu hysgrifennu gan NIFI ei hun i'r log.
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)
}
Mewn gwirionedd, dyma lle mae addasu'r sgwâr yn dod i ben. Nesaf, trosglwyddir y ffeil wedi'i diweddaru i'r sgwâr, sy'n gyfrifol am anfon y ffeil i'r gweinydd. Isod mae'r gosodiadau ar gyfer y sgwâr hwn.
Rydym yn disgrifio'r dull y bydd neges SEBON yn cael ei throsglwyddo. Rydym yn ysgrifennu ble. Nesaf mae angen i chi nodi mai SEBON yw hwn.
Ychwanegwch sawl priodwedd fel gwesteiwr a gweithredu (sebonAction). Rydym yn arbed ac yn gwirio. Gallwch weld mwy o fanylion ar sut i anfon ceisiadau SEBON
Gwnaethom edrych ar sawl opsiwn ar gyfer defnyddio prosesau NIFI. Sut maen nhw'n rhyngweithio a beth yw eu gwir fudd? Mae'r enghreifftiau a ystyriwyd yn rhai prawf ac maent ychydig yn wahanol i'r hyn sy'n digwydd mewn ymladd. Rwy'n gobeithio y bydd yr erthygl hon ychydig yn ddefnyddiol i ddatblygwyr. Diolch am eich sylw. Os oes gennych unrhyw gwestiynau, ysgrifennwch. Byddaf yn ceisio ateb.
Ffynhonnell: hab.com