Isang Gabay sa Java Microservices. Bahagi 2: Deployment at Pagsubok

Pagsasalin at pag-aangkop ng Java Microservices: A Practical Guide . Link sa unang bahagi ng gabay . Anumang server-side na Java program, at samakatuwid ang anumang microservice, ay isang file lamang na may extension na .jar o .war. May isang magandang bagay tungkol sa Java ecosystem, o sa halip ang JVM: kailangan mo lang magsulat ng Java code nang isang beses at maaari itong tumakbo sa halos anumang operating system, hangga't hindi mo pa naipon ang iyong code gamit ang isang mas bagong bersyon ng Java kaysa sa iyong target na bersyon ng JVM . Mahalaga itong maunawaan, lalo na pagdating sa mga paksa tulad ng Docker, Kubernetes, o (drum roll!) The Cloud. Bakit? Tingnan natin ang iba't ibang mga senaryo sa pag-deploy.

Halimbawa ng Minimalistic na Java Microservice Deployment

Ipagpatuloy natin ang halimbawa ng bangko. Kaya mayroon kaming monobank.jar file (monolith) at ang aming bagong na-extract na riskengine.jar (ang unang microservice sa pagsuri ng panganib). Ipagpalagay din natin na ang parehong application, tulad ng bawat iba pang application sa mundo, ay nangangailangan ng .properties file. Sa aming kaso, maglalaman lamang ito ng URL ng database at mga kredensyal. Ang isang minimal na deployment ay maaaring binubuo ng dalawang direktoryo na mukhang ganito: Una:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 monobank-384.jar

ubuntu@somemachine:/var/www/www.monobank.com/java$ java -jar monobank-384.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Pangalawa:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 risk-engine-1.jar

ubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Iiwan nitong bukas ang tanong: paano mapupunta sa server ang mga .properties at .jar file? Sa kasamaang palad, maaaring maraming mga sagot.

Paano Gumamit ng Mga Build Tool, SSH, at Ansible para I-deploy ang Java Microservices

Nakakainip, ngunit hindi gaanong mahusay na payo sa kung paano mag-deploy ng mga microservice ng Java... Sa totoo lang, eksakto ang paraan ng pag-deploy ng mga system administrator ng anumang programa ng Java server sa mga kumpanya sa nakalipas na 20 taon. Ito ang halo:

• ang iyong paboritong tool sa pagbuo (Maven, Gradle)
• magandang lumang SSH/SCP para sa pagkopya ng .jars sa mga server
• Bash script para pamahalaan ang mga deployment script at server
• o mas mabuti pa: ilang Ansible script.

Siyempre, hindi ito angkop para sa mga innovator na nangangailangan ng "paghinga" na ulap, mga server na may awtomatikong pagbabalanse ng pag-load, at iba pa. Ang boring talaga nitong old school. Gayunpaman ito ay gumagana!

Paano Gamitin ang Docker para I-deploy ang Java Microservices

Bumalik tayo sa matamis na paghihirap ng pagpili. Ilang taon na ang nakalilipas, dumating si Docker sa eksena, at kasama nito ang containerization. Kung hindi mo pa ito nagawa, narito ang isang maikling paglalarawan na naglalayon sa mga end user at developer:

• Ang isang lalagyan (pinasimple) ay katulad ng magandang lumang virtual machine, ngunit "mas magaan". Kung hindi ka malinaw kung ano ang ibig sabihin ng "mas madali" sa kontekstong ito, pakitingnan ang sagot na ito sa Stackoverflow .
• Ginagarantiyahan ng lalagyan ang sarili nitong portable. Ibig sabihin, gumagana ito kahit saan. Parang pamilyar, hindi ba?

Nakakatuwa na dahil sa portability at backward compatibility ng JVM, mukhang hindi ganoong kalamangan ang feature na ito. Maaari mong i-download lang ang JVM.zip sa anumang Raspberry Pi (o kahit na mobile phone), i-extract ito at patakbuhin ang anumang .jar file. Ang sitwasyon ay nagbabago sa mga wika tulad ng PHP o Python, kung saan ang mga hindi pagkakatugma ng bersyon o mga setting ng deployment ay mas kumplikado. O kung ang iyong Java application ay nakasalalay sa maraming iba pang naka-install na serbisyo (na may tamang mga numero ng bersyon): halimbawa, isang Postgres database, o isang Redis key value store. Kaya, ang pangunahing bentahe ng Docker para sa mga microservice ng Java, o mas tiyak para sa mga aplikasyon ng Java, ay ito: ang kakayahang mag-set up ng homogenized na pagsubok o mga integrasyon na kapaligiran gamit ang mga tool tulad ng Testcontainers . Ang mga kumplikadong pag-unlad ay mas madaling i-install. Kunin ang Discourse forum software . Maaari mo itong i-install gamit ang isang larawan ng Docker, at naglalaman ang larawang iyon ng lahat ng kailangan mo, mula sa Discourse software na nakasulat sa Ruby, hanggang sa database ng Postgres, hanggang Redis, hanggang sa lababo sa kusina. Kung magkapareho ang iyong mga deployment o gusto mong magpatakbo ng isang magandang maliit na database ng Oracle, subukan ang Docker. Kaya't bilang buod, sa halip na tumingin lamang sa .jar file, ikaw ngayon:

• i-bundle ang iyong jar file sa isang imahe ng Docker
• itulak ang larawang ito sa isang pribadong pagpapatala ng Docker
• hilahin at patakbuhin ang larawang ito sa iyong target na platform
• o direktang kopyahin ang imahe ng Docker sa iyong production system at patakbuhin ito.

Paano Gamitin ang Docker Swarm o Kubernetes para I-deploy ang Java Microservices

Sabihin nating nagpasya kang subukan ang Docker. Sa tuwing magde-deploy ka ng Java microservice, gagawa ka ng Docker na imahe na nag-bundle ng iyong .jar file. Sabihin nating mayroon kang isang pares ng mga Java microservice na ito, at gusto mong i-deploy ang mga serbisyong ito sa ilang mga makina (sa isang cluster). Ang tanong ay lumitaw: paano pamahalaan ang kumpol na ito? Magpatakbo ng mga container ng Docker, suriin ang pagganap, mag-deploy ng mga update, sukatin ang system (brrr)? Dalawang posibleng sagot sa tanong na ito ay ang Docker Swarm at Kubernetes. Ang pagdedetalye tungkol sa parehong mga opsyon ay gagawing masyadong mahaba ang mahabang tutorial na ito, ngunit sa tingin namin ay mahalagang banggitin na ang parehong mga opsyon sa huli ay umaasa sa iyong pagsusulat ng mga YAML file (tingnan ang Yaml indentation stories ) upang pamahalaan ang iyong cluster. Kung gusto mong malaman kung anong mga damdamin ang dulot nito sa pagsasanay, mag-type lang ng katulad na query sa paghahanap sa Twitter. Kaya't ang proseso ng pag-deploy para sa iyong mga Java microservice ay mukhang ganito na ngayon:

• Pag-configure at pamamahala ng Docker Swarm/Kubernetes
• Lahat ng mga hakbang para sa Docker (tingnan sa itaas)
• Sumulat at isagawa ang YAML hanggang sa dumugo ang iyong mga mata hanggang sa gumana ang lahat.

Paano Subukan ang Java Microservices

Sabihin nating nagpasya kang magpatupad ng mga microservice sa produksyon. Paano natin masusubok ang pagsasama ng n-microservices sa panahon ng pag-unlad ngayon? Paano mo makikita kung gumagana ang buong workflow, at hindi lang mga bahagi nito? Sa pagsasagawa, maaari mong gamitin ang isa sa tatlong paraan:

1. Sa kaunting trabaho (kung gumagamit ka ng mga frameworks tulad ng Spring Boot), maaari mong pagsamahin ang lahat ng iyong microservice sa isang launch class at i-load ang lahat ng microservices gamit ang isang Wrapper.java class - depende sa kung mayroon kang sapat na memorya sa iyong machine upang patakbuhin ang lahat ng iyong mga microservice.
2. Maaari mong kopyahin nang lokal ang mga setting ng Docker Swarm o Kubernetes.
3. Huwag na lang magpatakbo ng mga pagsubok sa pagsasama nang lokal. Sa halip, mag-deploy ng nakalaang DEV/TEST environment. Ito ay isang bagay na talagang ginagawa ng ilang mga koponan kapag sila ay sumuko sa sakit ng mga lokal na microservice setup.

Bukod pa rito, bilang karagdagan sa iyong mga Java microservice, malamang na kailangan mo rin ng tumatakbong message broker (tulad ng ActiveMQ o RabbitMQ) o marahil ng isang email server o anumang iba pang bahagi ng pagmemensahe na kailangan ng iyong Java microservice na makipag-ugnayan sa isa't isa. Ito ay humahantong sa isang makabuluhang pagmamaliit ng pagiging kumplikado sa panig ng DevOps. Tingnan ang Microservice Testing Libraries, maaari nilang maibsan ang sakit na ito. Sa anumang kaso, dinadala tayo ng pagiging kumplikadong ito sa mga pangkalahatang problema ng mga microservice, na pag-uusapan natin ngayon. Sa huling bahagi , tatalakayin namin ang mga pangkalahatang tanong tungkol sa mga microservice ng Java.