{"id":32632,"date":"2019-10-31T21:48:08","date_gmt":"2019-10-31T18:48:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo\/"},"modified":"2019-10-31T21:48:08","modified_gmt":"2019-10-31T18:48:08","slug":"ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","title":{"rendered":"Ikke kun behandling: Hvordan vi gjorde Kafka Streams til en distribueret database, og hvad der kom ud af det","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hello, Habr!<\/p>\n

Vi minder om, at i takt med bogen om Kafka<\/a><\/noindex> har vi udgivet et mindst lige s\u00e5 interessant v\u00e6rk om biblioteket Kafka Streams API<\/a><\/noindex>. <\/p>\n

\"Ikke
\n
\nMens samfundet netop er ved at udforske gr\u00e6nserne for mulighederne med dette kraftfulde v\u00e6rkt\u00f8j, er der for nylig udgivet en artikel, som vi gerne vil introducere jer for. P\u00e5 egen erfaring beskriver forfatteren, hvordan man kan skabe et distribueret datalager med Kafka Streams. God l\u00e6sning!
\n<\/a><\/noindex>
\nBiblioteket Apache Kafka Streams<\/a><\/noindex> bruges over hele verden i erhvervslivet til distribueret streambehandling oven p\u00e5 Apache Kafka. En af de undervurderede aspekter ved dette framework er, at det tillader opbevaring af lokal tilstand genereret ud fra streambehandling.<\/p>\n

I denne artikel vil jeg fort\u00e6lle, hvordan vi i vores virksomhed har haft fordel af denne mulighed i udviklingen af et produkt til sikkerhed i skyapplikationer. Ved hj\u00e6lp af Kafka Streams har vi skabt mikrotjenester med delt tilstand, som hver is\u00e6r fungerer som en redundant og h\u00f8jt tilg\u00e6ngelig kilde til p\u00e5lidelig information om tilstanden af objekterne i systemet. For os er dette et skridt fremad hvad ang\u00e5r p\u00e5lidelighed samt vedligeholdelsesvenlighed.<\/p>\n

Hvis du er interesseret i en alternativ tilgang, der g\u00f8r det muligt at anvende en central database til at underst\u00f8tte den formelle tilstand af dine objekter - l\u00e6s videre, det vil v\u00e6re interessant\u2026 <\/p>\n

Hvorfor vi mente, det var tid til at \u00e6ndre vores tilgang til arbejde med delt tilstand <\/b><\/p>\n

Vi havde brug for at opretholde tilstanden af forskellige objekter baseret p\u00e5 rapporter fra agenter (for eksempel: var hjemmesiden blevet angrebet?). Inden vi skiftede til Kafka Streams stolede vi ofte p\u00e5 at administrere tilstanden med en central database (+ service API). Denne tilgang har sine ulemper: i datadrevne situationer<\/a><\/noindex> bliver opretholdelse af konsistens og synkronisering en reel udfordring. Databasen kan blive flaskehals eller ende i kapl\u00f8b<\/a><\/noindex> og lide under uforudsigelighed.<\/p>\n

\"Ikke
\n
\nIllustration 1: typisk scenario med opdeling af tilstand, der blev m\u00f8dt f\u00f8r skiftet til
\nKafka og Kafka Streams: agenterne rapporterer deres opfattelser via API, den opdaterede tilstand beregnes gennem den centrale database. <\/i><\/p>\n

Bliv bekendt med Kafka Streams \u2013 det er nu blevet nemt at skabe mikrotjenester med delt tilstand. <\/b><\/p>\n

For about a year now, we have thoroughly reviewed our scenarios for working with shared state to tackle various issues. We immediately decided to try Kafka Streams\u2014it's well-known for its scalability, high availability, and fault tolerance, as well as its rich streaming functionality (including transformations, with state preservation). This was exactly what we needed, not to mention how mature and reliable the messaging system in Kafka has become.<\/p>\n

Each of the stateful microservices we created was based on an instance of Kafka Streams with a rather simple topology. It consisted of 1) a source 2) a processor with a persistent key-value store 3) a sink:<\/p>\n

\"Ikke
\n
\nIllustration 2: the default topology of our streaming instances for stateful microservices. Note: there is also a store here that contains metadata about scheduling. <\/i><\/p>\n

With this new approach, agents compose messages submitted to the initial topic, while consumers\u2014say, a mail notification service\u2014receive the computed shared state through the sink (output topic).<\/p>\n

\"Ikke
\n
\nIllustration 3: a new example of a task stream for a scenario with shared microservices: 1) an agent generates a message that goes to the initial Kafka topic; 2) the stateful microservice (using Kafka Streams) processes it and writes the computed state to the final Kafka topic; after which 3) consumers accept the new state.<\/i><\/p>\n

Hey, this built-in key-value store is actually very useful!<\/b><\/p>\n

As mentioned above, our stateful topology contains a key-value store. We found several use cases for it, two of which are described below.<\/p>\n

Option #1: using the key-value store in computations<\/b><\/i><\/p>\n

Vores f\u00f8rste n\u00f8gle-v\u00e6rdi-lager indeholdt hj\u00e6lpeoplysninger, som vi havde brug for til vores beregninger. For eksempel blev den delte tilstand i nogle tilf\u00e6lde bestemt ud fra princippet om \"flertallets stemme\". I lageret kunne vi holde alle de seneste rapporter fra agenter om tilstanden af et bestemt objekt. Derefter, n\u00e5r vi modtog en ny rapport fra en hvilken som helst agent, kunne vi gemme den, hente rapporterne fra alle de andre agenter om tilstanden af det samme objekt og gentage beregningen.
\nNedenfor i illustration 4 vises, hvordan vi \u00e5bnede adgangen til n\u00f8gle-v\u00e6rdi-lageret for den behandlende metode af processoren, s\u00e5 vi derefter kunne behandle en ny besked.<\/p>\n

\"Ikke
\n
\nIllustration 4: \u00c5bning af adgangen til n\u00f8gle-v\u00e6rdi-lageret for den behandlende metode af processoren (herefter skal der implementeres en metode i hvert scenarie, der arbejder med delt tilstand doProcess<\/code>)<\/i><\/p>\n

Mulighed #2: Oprettelse af CRUD API over Kafka Streams<\/b><\/i><\/p>\n

Efter at have etableret vores grundl\u00e6ggende opgaveflow begyndte vi at pr\u00f8ve at skrive et RESTful CRUD API til vores mikrotjenester med delt tilstand. Vi \u00f8nskede at kunne hente tilstanden af nogle eller alle objekter samt oprette eller slette tilstanden af et objekt (det er nyttigt til server-side support).<\/p>\n

For at underst\u00f8tte alle API'er til at hente tilstand, hver gang vi havde brug for at rekonstruere tilstanden under behandlingen, gemte vi den i det indbyggede n\u00f8gle-v\u00e6rdi-lager i lang tid. I s\u00e5 fald bliver det ganske enkelt at implementere et s\u00e5dant API ved hj\u00e6lp af en enkelt instans af Kafka Streams, som vist i den f\u00f8lgende kode:<\/p>\n

\"Ikke
\n
\nIllustration 5: Brug af det indbyggede n\u00f8gle-v\u00e6rdi-lager til at hente den forudberegnede tilstand af objektet <\/i><\/p>\n

Opdatering af objektets tilstand via API er heller ikke sv\u00e6rt at implementere. Grundl\u00e6ggende kr\u00e6ver det kun at oprette en Kafka-producent, og med denne lave en skrivning, der indeholder den nye tilstand. Dette sikrer, at alle beskeder genereret gennem API'en behandles p\u00e5 samme m\u00e5de som dem, der kommer fra andre producenter (f.eks. agenter).<\/p>\n

\"Ikke
\n
\nIllustration 6: Objektets tilstand kan angives ved hj\u00e6lp af en Kafka-producent <\/i><\/p>\n

En lille komplikation: Kafka har mange partitioner<\/b><\/p>\n

Dern\u00e6st \u00f8nskede vi at fordele belastningen relateret til behandlingen og forbedre tilg\u00e6ngeligheden ved at give hver scenarie et cluster af mikrotjenester med delt tilstand. Ops\u00e6tningen var lettere end forventet: efter at vi konfigurerede alle instanser til at arbejde med den samme app-ID (og de samme opstartservere), blev stort set alt andet udf\u00f8rt automatisk. Vi angav ogs\u00e5, at hvert oprindeligt emne skulle best\u00e5 af flere partitioner, s\u00e5 hver instans kunne tildeles et delm\u00e6ngde af disse partitioner.<\/p>\n

Jeg vil ogs\u00e5 n\u00e6vne, at det er almindeligt her at tage backup af tilstandsopbevaringen, s\u00e5 man f.eks. nemt kan overf\u00f8re denne backup til en anden instans i tilf\u00e6lde af gendannelse efter en fejl. For hver tilstandsopbevaring i Kafka Streams oprettes der et replikerbart emne med en \u00e6ndringslog (hvor lokale opdateringer registreres). P\u00e5 den m\u00e5de sikrer Kafka altid tilstandsopbevaringen. Derfor kan tilstandsopbevaringen i Kafka Streams hurtigt gendannes p\u00e5 en anden instans i tilf\u00e6lde af en fejl i en specifik instans, hvor de relevante partitioner overf\u00f8res. Vores tests viste, at dette kan g\u00f8res p\u00e5 f\u00e5 sekunder, selv n\u00e5r der er millioner af poster i opbevaringen.<\/p>\n

At g\u00e5 fra en mikrotjeneste med delt tilstand til et cluster af mikrotjenester g\u00f8r det ikke s\u00e5 trivielt at implementere Get State API. I den nye situation indeholder tilstandsopbevaringen i hver mikrotjeneste kun en del af det samlede billede (de objekter, hvis n\u00f8gler blev vist p\u00e5 en bestemt partition). Vi m\u00e5tte afg\u00f8re, hvilken instans der havde tilstanden af det objekt, vi havde brug for, og dette gjorde vi baseret p\u00e5 metadata fra str\u00f8mmene, som vist nedenfor:<\/p>\n

\"Ikke
\n
\nIllustration 7: ved hj\u00e6lp af metadatastr\u00f8mme bestemmer vi, hvilken instans vi skal anmode om tilstanden af det \u00f8nskede objekt; en lignende tilgang blev anvendt med GET ALL API<\/i><\/p>\n

Hovedelementer<\/b><\/p>\n

Tilstandsopbevaringer i Kafka Streams kan de facto fungere som en distribueret database, <\/p>\n