Hva er mikrotjenester?

Microservices er en av de nyeste trendene innen programvaredesign der flere uavhengige tjenester kommuniserer seg imellom og har sine egne prosesser og ressurser. Denne tilnærmingen skiller seg fra en typisk klient-server applikasjonsdesign. Den vanlige klientserverapplikasjonen består av en eller flere klienter, en monolitisk back-end som inkluderer alle domenedata og logikk, og en BRANN som gir klienter tilgang til back-end og funksjonalitet.

Mikrotjenester erstatter klassiske monolitiske back-end-servere kvitring

I en mikrotjenestearkitektur erstattes den beskrevne monolitiske backend i stedet av en serie distribuerte tjenester. Denne designen gir bedre ansvarsdeling, enklere vedlikehold, større fleksibilitet i valg av teknologier for hver tjeneste og enklere skalerbarhet og feiltoleranse. Samtidig har komplekse distribuerte systemer sine sett med utfordringer. De har større sjanse for å måtte takle løpsforhold, og de er vanskeligere å feilsøke, ettersom problemer ikke lett blir pekt på en enkelt tjeneste, men i stedet distribueres gjennom mange. Hvis det ikke gjøres et forsøk på å følge de beste fremgangsmåtene mens du bygger et slikt system, kan du bli omringet av branner som du ikke vet hvordan du skal slukke. Spesiell forsiktighet må tas med tjenestenees nyttelastkontrakter, da endringer i en tjeneste kan påvirke alle kundene, og følgelig hele back-endens servicesuite.

Alle disse betraktningene er viktige, men la oss anta at du allerede har tenkt over det. Nå er det du ønsker å finne en måte å bygge en mikrotjeneste på egenhånd. Så la oss dykke rett inn i det.

Hvordan sette opp en mikrotjenestearkitektur

Det er for tiden mange måter du kan sette opp mikrotjenester, og i denne guiden vil vi fokusere på en meglerarkitektur.

En meglerarkitektur

En meglerarkitektur er en av måtene du kan få tjenestene dine til å kommunisere seg imellom kvitring

En meglerarkitektur er en av måtene du kan få tjenestene dine til å kommunisere seg imellom. I den omgir alle tjenester en meldingsserver, megleren og alle er koblet til den. Tjenester sender meldinger til megleren, som da vet hvilke andre tjenester eller tjenester han trenger for å videresende disse meldingene. På denne måten trenger ikke tjenester å beholde informasjon om andre tjenester. I stedet stoler de på at megleren tar seg av alle meldinger, og det gjør at de bare kan isoleres og fokusere på deres spesielle domene. En megler kan også lagre meldinger når mottakerne er nede, slik at avsendere og mottakere ikke blir tvunget til å være oppe samtidig, og dermed muliggjøre enda større isolasjon. Selvfølgelig er det ulemper med denne løsningen, da megleren raskt kan bli en flaskehals siden all kommunikasjon må gå gjennom dem, og det kan også bli et eneste feilpunkt for din backend. Imidlertid er det noen måter å redusere disse problemene på. En måte er å ha flere forekomster av megleren som kjører parallelt, noe som vil gi bedre systemfeiltoleranse. En annen måte ville være å bruke andre arkitekturer . Alternative arkitekturer skiller seg fra arkitekturen vi vil implementere i denne veiledningen ved ikke å bruke megler, eller ved å bruke en annen meglerarkitektur, eller ved å bruke en annen meldingsprotokoll som HTTP.

Kommunikasjon mellom tjenester

I denne guiden skal vi bruke ZeroMQ å håndtere kommunikasjonen mellom tjenestene og megleren.

ZeroMQ gir et protokollabstraksjonslag som håndterer asynkrone meldinger med flere deler over tilfeldige transporter. Fordelene med å bruke ZeroMQ for meldinger mellom tjenester og meglere er utenfor omfanget av denne veiledningen, så vi vil ikke gå over dem akkurat her, men hvis du vil vite mer om dem, sjekk ut følgende Quora-artikkel . Hvis du er interessert i å finne ut andre måter å få tjenestene dine til å snakke med hverandre, foreslår jeg at du tar en titt på Megler mot meglerfri artikkel for å se hva annet kan oppnås.

Bygg Microservices Suite

Denne artikkelen vil lede deg gjennom alle trinnene som trengs for å lage din mikroservicepakke. Systemet vårt vil bestå av en megler og en tjeneste. Vi bruker også et lite klientskript for å teste samtaler til servicesuiten, men husk at klientkoden enkelt kan brukes hvor som helst.

Så, la oss begynne å bygge.

Starter

La oss først sørge for at du har alt du trenger for å drive megleren og tjenesten. Først begynner du med å laste ned og installere Node.js , ZeroMQ og Gå på maskinen din. Hvis du bruker OSX, er det hjemmebryggepakker for hver av dem, og de fleste Linux-distribusjoner har også en pakke for hver av dem, så du bør ikke ha noe problem med dette. Windows-brukere kan bare bruke nedlastingskoblingene som er gitt ovenfor.

Kjører megleren

Etter å ha installert alle nødvendige avhengigheter, la oss få megleren vår i gang. I denne guiden bruker vi en Node.js-implementering av megleren som er en del av ZMQ Service Oriented Suite. Du finner koden og dokumentasjonen på GitHub . For å kjøre megleren må du først klone a Megler bootstrap til maskinen din. Dette depotet er en bootstrap for bruk av meglerbiblioteket ovenfor. Merk at dette trinnet ikke er nødvendig da det originale biblioteket i seg selv kan kjøres, men forskjellen mellom de to er at i bootstrap-depotet kan du endre standardkonfigurasjonene.

Så bruk først følgende Git-kommando for å laste ned prosjektet til maskinen din:

$ git clone [email protected] :dadah/zmq-broker-bootstrap.git

Etter at du har gjort det, flytt til den opprettede katalogen:

$ cd zmq-broker-bootstrap

Installer nå avhengighetene til pakken:

$ npm install

Megleren er nå klar. For å kjøre megleren din, kjør følgende kommando:

$ bin/zss-broker run

Du finner konfigurasjonsfiler for hvert miljø i config/ katalog. Dette er standard utviklingskonfigurasjon:

{ 'broker': { 'backend': 'tcp://127.0.0.1:7776', 'frontend': 'tcp://127.0.0.1:7777' }, 'log': { 'consolePlugin': { 'level': 'debug' } } }

backend parameter definerer ip:port adresse til meglerens back-end og front-end. Back-end-adressen er der megleren mottar forespørsler fra og svarer på tjenestene, og front-end-adressen er der den mottar og sender til tjenesteklientene. Du kan også angi loggningsnivå ved å endre log.consolePlugin.level. Mulige verdier er trace, debug, info, warn og error, og de bestemmer mengden loggingsinformasjonsmeglerprosess som skal sendes ut.

Kjører tjenesten

Etter at megleren din er oppe, er det på tide å utvikle din første Rubin mikroservice. Start med å åpne et nytt konsollvindu. Opprett deretter en katalog der tjenestene dine blir lagret, og gå deretter til den katalogen. I denne guiden bruker vi Ruby-klient og service av ZMQ SOA Suite . Det er en bootstrap “Hello world” -tjenesten tilgjengelig, så la oss bruke den til å få vår første mikroservice i gang.

Gå til tjenestekatalogen din og klone bootstrap-depotet:

$ git clone [email protected] :dadah/zmq-service-suite-ruby-bootstrap.git

Gå til den nylig opprettede katalogen:

$ cd zmq-service-suite-ruby-bootstrap

Installer nå alle avhengigheter:

$ bundle install

For å starte tjenesten, kjør følgende kommando:

$ bin/zss-service run

Flott. Du har din første tjeneste i gang.

Hvis du går til konsollvinduet der du lot megleren kjøre, kan du se følgende utdata:

2015-12-15 16:45:05 | INFO | BROKER - Async Broker is waiting for messages... 2015-12-15 16:45:14 | DEBUG | BACKEND - received from: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: 76f50741-913a-43b9-94b0-36d8f7bd75b1 2015-12-15 16:45:14 | DEBUG | BACKEND - routing from: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: 76f50741-913a-43b9-94b0-36d8f7bd75b1 to SMI.UP request... 2015-12-15 16:45:14 | INFO | SMI - SMI register for sid: HELLO-WORD instance: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b! 2015-12-15 16:45:14 | DEBUG | BACKEND - reply to: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: 76f50741-913a-43b9-94b0-36d8f7bd75b1 with status: 200 2015-12-15 16:45:15 | DEBUG | BACKEND - received from: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: 3b3a0416-73fa-4fd2-9306-dad18bc0502a 2015-12-15 16:45:15 | DEBUG | BACKEND - routing from: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: 3b3a0416-73fa-4fd2-9306-dad18bc0502a to SMI.HEARTBEAT request... 2015-12-15 16:45:15 | DEBUG | BACKEND - reply to: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: 3b3a0416-73fa-4fd2-9306-dad18bc0502a with status: 200 2015-12-15 16:45:16 | DEBUG | BACKEND - received from: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: b3044c24-c823-4394-8204-1e872f30e909 2015-12-15 16:45:16 | DEBUG | BACKEND - routing from: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: b3044c24-c823-4394-8204-1e872f30e909 to SMI.HEARTBEAT request... 2015-12-15 16:45:16 | DEBUG | BACKEND - reply to: hello-word#aaa65374-8585-410a-a41d-c8a5b024553b rid: b3044c24-c823-4394-8204-1e872f30e909 with status: 200

Denne loggen betyr at megleren har erkjent eksistensen av en ny tjeneste og mottar hjerteslagmeldinger fra den. Hvert sekund sender tjenesten en hjerteslagmelding til megleren, slik at den vet at forekomsten av tjenesten er oppe.

Forbruker fra tjenesten

Så nå har vi en tjeneste som kjører, hvordan bruker vi den?

I bootstrap-depotet er det en dummy-klient du kan bruke til å teste “Hello World” -tjenesten. Bare åpne et nytt konsollvindu eller en ny fane, og gå til servicekatalogen din. Når du er der, kjør følgende kommando:

$ bin/zss-client

Du bør se noe slikt:

15-49-15 16:49:54 | INFO | ZSS::CLIENT - Request 90a88081-3485-45b6-91b3-b0609d64592a sent to HELLO-WORD:*#HELLO/WORLD with 1.0s timeout 15-49-15 16:49:54 | INFO | ZSS::CLIENT - Received response to 90a88081-3485-45b6-91b3-b0609d64592a with status 200 'Hello World'

Hvis du går til konsollvinduet der tjenesten din kjører, bør du se dette:

Started hello-word daemon... 15-45-15 16:45:14 | INFO | ZSS::SERVICE - Starting SID: 'HELLO-WORD' ID: 'hello-word#aaa65374-8585-410a-a41d-c8a5b024553b' Env: 'development' Broker: 'tcp://127.0.0.1:7776' 15-49-15 16:49:54 | INFO | ZSS::SERVICE - Handle request for HELLO-WORD:*#HELLO/WORLD 15-49-15 16:49:54 | INFO | ZSS::SERVICE - Reply with status: 200

God. Du har nettopp lansert og brukt 'Hello World' -mikrotjenesten. Dette er imidlertid ikke det vi har tenkt oss å gjøre. Vi ønsker å bygge våre tjenester. La oss komme til det, da.

Bygg din tjeneste

Først, la oss stoppe 'Hello World' -tjenesten. Gå til konsollvinduet til tjenesten og trykk Ctrl+C for å stoppe tjenesten. Deretter må vi gjøre tjenesten “Hello World” om til “Person” -tjenesten.

Kodestruktur

La oss starte med å se på kodetreet til prosjektet. Det ser slik ut:

• bin katalogen er der du lagrer skriptene som starter tjenesten din.
• config katalog lagrer alle konfigurasjonsfilene.
  • boot.rb filen er der du kan legge til alle tjenesteavhengighetene dine. Hvis du åpner den, kan du legge merke til at det allerede er mange avhengigheter oppført der. Hvis du trenger å legge til flere, er det her du bør gjøre det.
  • application.yml filen lagrer alle applikasjonsinnstillingene dine. Vi tar en titt på denne filen senere.
  • I config/initializers katalogen kan du legge til initialiseringsskriptene. Du kan for eksempel legge til innstillinger for ActiveRecord- eller Redis-tilkoblinger her. Skriptene du legger til i denne katalogen, kjøres ved oppstart av tjenesten.
• I db/migrate katalogen kan du lagre ActiveRecord- eller Sequel-migrasjonene dine hvis du har noen. Hvis du ikke gjør det, kan du slette denne katalogen helt.
• lib katalogen er der den viktigste applikasjonskoden din ligger.
  • settings.rb filen laster ganske enkelt inn application.yml filen og gjør den tilgjengelig i hele tjenestens omfang, slik at du får tilgang til konfigurasjonene dine hvor som helst. For eksempel Settings.broker.backend returnerer megler-backend-adressen du definerte i YML-filen ovenfor.
  • Fil service_register.rb er der du registrerer tjenestene og tjenestene dine. Vi vil forklare det senere.
  • hello_world_service.rb filen definerer sluttpunktene for 'Hello World' -tjenesten.
  • lib/daos katalogen er der du lagrer ActiveModel-objektene dine hvis du bruker ActiveRecord, eller andre datatilgangsobjekter du eventuelt kan opprette, for eksempel dine Sequel-modeller.
  • lib/dtos katalogen lagrer dataoverføringsobjektene dine. Disse objektene er de som til slutt sendes tilbake til tjenestens klienter.
  • lib/repositories katalog lagrer lagringsplassene dine. Repositories er objekter som gir tjenester tilgang til data og er de eneste objektene som har lov til å håndtere DAO. Så hvis en tjeneste vil ha en gruppe “Hello World” -forekomster, vil den be depotet om dem. Datalageret bruker i sin tur de aktuelle DAOene til å hente relevante data fra databasen. Dataene blir deretter kartlagt i en passende “HelloWorld” DTO- eller “HelloWorld” DTO-samling som returneres til tjenesten.
  • lib/repositories/mappers katalogen er der du lagrer kartleggere. Kart er objekter som konverterer DAO til DTO, og omvendt.

application.yml fil fra config katalog ser slik ut:

defaults: &defaults broker: backend: tcp://127.0.0.1:7776 frontend: tcp://127.0.0.1:7777 logging: console: level: info development: <<: *defaults test: <<: *defaults production: <<: *defaults

Denne innstillingen angir ganske enkelt meglerens back- og front-end-adresse og loggningsnivå.

Hvis alt dette høres forvirrende så langt, ikke bekymre deg, da det blir tydeligere når vi går videre.

“Person” -tjeneste

Så, la oss fortsette med vår 'Person' -tjeneste. La oss starte med å konfigurere databasetilkoblingen. Åpne filen config/initializers/active_record.rb og unkommentere den eneste linjen der. Deretter legger du til følgende oppføring i utviklingskonfigurasjonen i application.yml slik at det ser slik ut:

defaults: &defaults broker: backend: tcp://127.0.0.1:7776 frontend: tcp://127.0.0.1:7777 logging: console: level: info database: adapter: postgresql database: zss-tutorial-development

Nå som du har lagt til databasekonfigurasjonen, må du opprette databasen. For øyeblikket er det ingen måte å gjøre dette automatisk med mindre du bruker en standard PostgreSQL-database, i så fall kan du bare kjøre:

$ rake db:create

Hvis du foretrekker en annen database, må du legge til passende perle i gemfilen og deretter installere prosjektet.

Neste er migrasjonen. For det er det bare å lage filen db/migrate kalt 000_creates_persons.rb:

$ touch db/migrate/000_creates_persons_table.rb

Åpne filen og opprett migreringen som med en vanlig Rails-migrering:

class CreatesPersons

Kjør den deretter:

$ rake db:migrate == 0 CreatesPersons: migrating ================================================ -- create_table(:persons) DEPRECATION WARNING: `#timestamp` was called without specifying an option for `null`. In Rails 5, this behavior will change to `null: false`. You should manually specify `null: true` to prevent the behavior of your existing migrations from changing. (called from block in change at /Users/francisco/Code/microservices-tutorial/db/migrate/000_creates_persons.rb:6) -> 0.0012s == 0 CreatesPersons: migrated (0.0013s) =======================================

Nå som vi har laget bordet vårt, la oss lage en modell for det. Opprett filen lib/daos/person.rb:

$ touch lib/daos/person.rb

Rediger det slik:

module DAO class Person

Der er modellen din. Nå må du lage en DTO-modell for en “Person” slik at du kan returnere den til klienten. Opprett filen lib/dtos/person.rb:

$ touch lib/dtos/person.rb

Rediger det slik:

module DTO class Person

Deretter må du lage en kartlegger for å konvertere “Person” DAO til en “Person” DTO. Opprett filen lib/repositories/mappers/person.rb, og rediger den slik:

module Mapper class Person

Her, Mapper::Base krever at du implementerer self.to_dao og self.to_dto. Hvis du ikke ønsker å gjøre det, kan du implementere self.map i stedet og overstyr Mapper::Base.map som kaller to_dao eller to_dto, avhengig av om attributtet den mottar er en DAO eller en DTO.

Nå har du en DAO for å få tilgang til databasen din, en DTO for å sende den til klienten, og en Mapper for å konvertere den ene til den andre. Du kan nå bruke disse tre klassene i et depot for å lage logikken som gjør det mulig å få personer fra databasen og returnere en tilsvarende samling DTOer.

La oss opprette depotet da. Opprett filen lib/repositories/person.rb:

$ touch lib/dtos/person.rb

Rediger det slik:

module Repository class Person

Dette depotet har bare forekomstmetoden get som ganske enkelt får alle personer fra databasen og kartlegger dem i en samling person-DTO-er - ganske enkelt. La oss bringe alt sammen nå. Alt som er igjen nå er å opprette tjenesten og endepunktet som kaller dette depotet. For å gjøre det, la oss lage filen lib/person_service.rb:

$ touch lib/person_service.rb

Rediger det slik:

class PersonService

“Person” -tjenesten initialiserer depotet i initialisereren. Alle offentlige instansemetoder for 'Person' -tjenesten har nyttelast og overskrifter som du kan utelate hvis du ikke trenger dem. Begge er Hashie::Mash forekomster og de lagrer variablene som sendes til endepunktet, enten som attributter eller overskrifter, og svarene deres etterligner HTTP-svar da hvert svar har en statuskode som klienter kan bruke til å finne ut resultatet av forespørsler sendt til tjenesten, sammen med tjenestens svar nyttelast. Svarkodene er de samme som du forventer av en HTTP-server. For eksempel vil en vellykket forespørsel returnere en 200 statuskode, sammen med svarets nyttelast. Hvis det oppstår noen tjenestefeil, vil statuskoden være 500, og hvis det er noe galt med parametrene som sendes til serveren, vil statuskoden være 400. Tjenesten kan svare med de fleste HTTP-statuskoder sammen med nyttelasten. Så hvis du for eksempel vil at tjenesten din skal fortelle kundene når de ikke har tilgang til et bestemt sluttpunkt, kan du gjøre det ved å svare med en 403-kode. Du kan se et annet eksempel på svarkoder hvis du ser tilbake på tjenestekoden vår ovenfor. I get endepunkt, vi returnerer statuskode 404 sammen med den valgfrie meldingen 'Ingen personer her' når ingen mennesker blir funnet, akkurat som en HTTP-server ville returnert en 404 hvis det ikke er noen ressurser tilgjengelig. Hvis depotet faktisk returnerer folk, serialiserer tjenesten DTO-ene og returnerer dem til klienten. Hver DTO har en standard serializer som returnerer et JSON-objekt med nøklene og tilsvarende verdier definert som enten attr_reader eller attr_accessible i DTO-definisjonen. Du kan selvfølgelig overstyre serialisereren ved å definere serialiseringsmetoden din i DTO-klassene.

Nå som vi har definert en tjeneste, må vi registrere den. Dette er det siste trinnet. Åpne filen lib/service_register.rb og erstatte alle forekomster av “HelloWorld” med “Person”, slik at filen endelig ser slik ut:

module ZSS class ServiceRegister def self.get_service config = Hashie::Mash.new( backend: Settings.broker.backend ) service = ZSS::Service.new(:person, config) personInstance = PersonService.new service.add_route(personInstance, :get) return service end end end

Som du sikkert la merke til, er det en liten endring i add_route anrop. Vi fjernet strengen “HELLO / WORLD”. Det er fordi strengen bare er nødvendig hvis serviceverbet ikke samsvarer med metoden som implementerer den. I vårt tilfelle, når vi ringer personstjenesten med GET-verbet, er metoden som skal kalles get, slik at vi kan utelate strengen.

ServiceRegister klasse er der du må definere metoden self.get_service. Denne metoden initialiserer tjenesten og kobler den til meglerens backend. Den samsvarer deretter ruter på den tjenesten med metoder i en eller flere tjenestedefinisjoner. I følgende tilfelle oppretter den for eksempel tjenesten og binder den til megleren:

config = Hashie::Mash.new( backend: Settings.broker.backend ) service = ZSS::Service.new(:person, config)

Deretter starter den en servicehandler:

personInstance = PersonService.new

Deretter er servicehandleren bundet til tjenesten:

service.add_route(personInstance, :get)

Til slutt må den returnere tjenesteinstansen.

return service

Nå er det bare et siste skritt før vi kan starte vår 'Person' -tjeneste; vi trenger å lage et kjørbart skript for det. Vi har allerede fått en til 'HelloService'. Så åpne filen bin/zss-service, erstatt “hallo-ord” med “person”, og lagre filen. Gå tilbake til konsollen og løp:

$ bin/zss-service run Starting person: PID: ./log LOGS: ./log Started person daemon... 15-29-15 19:29:54 | INFO | ZSS::SERVICE - Starting SID: 'PERSON' ID: 'person#d3ca7e1f-e229-4502-ac2d-0c01d8c285f8' Env: 'development' Broker: 'tcp://127.0.0.1:7776'

Det er det. Du har nettopp startet “Person” -tjenesten for første gang. La oss nå teste det. Åpne bin/zss-client fil, endre sid variabel til “person” og endre klientsamtalen fra hello_world() til get(). Når det er gjort, kjører du klienten i et nytt vindu:

$ bin/zss-client /Users/francisco/.rvm/gems/ruby-2.1.2/gems/zss-0.3.4/lib/zss/client.rb:41:in `new': No people here (ZSS::Error) from /Users/francisco/.rvm/gems/ruby-2.1.2/gems/zss-0.3.4/lib/zss/client.rb:41:in `call' from /Users/francisco/.rvm/gems/ruby-2.1.2/gems/zss-0.3.4/lib/zss/client.rb:55:in `method_missing' from bin/zss-client:12:in `'

Som du kan se, har du tatt en ZSS::Error. Dette er fordi vi reiser en feil når ingen mennesker blir funnet av tjenesten, og vi har ingen personer ennå i tjenestens database.

La oss håndtere denne feilen da. Åpne zss-client og rediger det slik:

begin client = ZSS::Client.new(sid, config) p client.get() rescue ZSS::Client => e if e.code == 404 p e.message else raise e end end

Nå skriver vi ut feilmeldingen når feilkoden er 404, mens vi hever feilen hvis den er en annen. La oss se det i aksjon ved å kjøre klienten vår igjen:

$ bin/zss-client 'No people here'

Utmerket. La oss nå legge til noen mennesker på bordet vårt og se om de returneres av tjenesten til klienten vår. For å gjøre dette, bare åpne en tjenestekonsoll:

$ rake service:console

Legg til noen personer:

$ rake service:console [1] pry(main)> DAO::Person.create name: 'John' => # [2] pry(main)> DAO::Person.create name: 'Mary' => # [3] pry(main)> DAO::Person.create name: 'Francis' => # [4] pry(main)> exit

Kjør klienten din igjen.

$ bin/zss-client [{'id'=>1, 'name'=>'John'}, {'id'=>2, 'name'=>'Mary'}, {'id'=>3, 'name'=>'Francis'}]

Der har du det.

Avsluttende hensyn

Når du går gjennom koden i denne håndboken, kan du tro at det er mange trinn som var unødvendige, for eksempel å opprette depoter eller DTO-er, og du vil ha rett. Alt du trenger for å ha en fungerende 'Person' -tjeneste vil være din serviceklasse og din DAO, som du kan ringe direkte fra serviceklassen. Det er likevel god praksis å følge mønsteret som er beskrevet i denne artikkelen, da det lar deg holde tjenestelogikken atskilt fra datalagringsmanipulasjonen. Tjenester bør bare være fokusert på deres logikk, og arkiver bør håndtere alle interaksjoner med datalagring. DTO-er bestemmer tjenestens nyttelast og serialisering, og DAO er bare opptatt av å få data fra lagring. Konvensjonene og teknikkene som er beskrevet i denne guiden er kjent som depotmønsteret, som du kan sjekke ut på bildet nedenfor.

Jeg vil avslutte med å be alle som syntes dette var nyttig, om å bidra til SOA-servicesuite , ved å utvide og forbedre den på noen måte. Alle gafler og trekkforespørsler er velkomne.

Jeg håper dette vil hjelpe deg med å komme i gang med mikrotjenester. Hvis du vil sjekke servicekoden, a komplett versjon er tilgjengelig på GitHub .