คำแนะนำเกี่ยวกับ Java Microservices ส่วนที่ 2: การปรับใช้และการทดสอบ

การแปลและการปรับJava Microservices: A Practical Guide ลิงก์ไปยังส่วนแรกของคำแนะนำ โปรแกรม Java ฝั่งเซิร์ฟเวอร์ใดๆ และไมโครเซอร์วิสใดๆ ก็ตาม เป็นเพียงไฟล์ที่มีนามสกุล .jar หรือ .war มีสิ่งหนึ่งที่ดีเกี่ยวกับระบบนิเวศ Java หรือ JVM: คุณเพียงแค่ต้องเขียนโค้ด Java เพียงครั้งเดียวและสามารถทำงานได้บนระบบปฏิบัติการเกือบทุกระบบ ตราบใดที่คุณยังไม่ได้คอมไพล์โค้ดของคุณด้วย Java เวอร์ชันใหม่กว่าของคุณ เป้าหมายเวอร์ชัน JVM นี่เป็นสิ่งสำคัญที่ต้องทำความเข้าใจ โดยเฉพาะอย่างยิ่งเมื่อพูดถึงหัวข้อต่างๆ เช่น Docker, Kubernetes หรือ (drum roll!) The Cloud ทำไม มาดูสถานการณ์การใช้งานที่แตกต่างกัน

ตัวอย่างการปรับใช้ Java Microservice แบบเรียบง่าย

มาดูตัวอย่างธนาคารกันต่อ ดังนั้นเราจึงมีไฟล์ monobank.jar (monolith) และ Riskengine.jar ที่แตกออกมาใหม่ของเรา (ไมโครเซอร์วิสการตรวจสอบความเสี่ยงครั้งแรก) สมมติว่าทั้งสองแอปพลิเคชันเหมือนกับแอปพลิเคชันอื่นๆ ในโลก ต้องมีไฟล์ .properties ในกรณีของเรา จะมีเพียง URL ฐานข้อมูลและข้อมูลประจำตัวเท่านั้น การปรับใช้ขั้นต่ำอาจประกอบด้วยสองไดเร็กทอรีที่มีลักษณะดังนี้: อันดับแรก:

-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

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

ที่สอง:

-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

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

นี่เป็นการเปิดคำถาม: ไฟล์ .properties และ .jar จะเข้าถึงเซิร์ฟเวอร์ได้อย่างไร น่าเสียดายที่อาจมีคำตอบมากมาย

วิธีใช้เครื่องมือ Build, SSH และ Ansible เพื่อปรับใช้ Java Microservices

น่าเบื่อ แต่ไม่มีคำแนะนำที่ยอดเยี่ยมไม่น้อยไปกว่าวิธีการปรับใช้ไมโครเซอร์วิส Java... จริงๆ แล้ว เป็นวิธีที่ผู้ดูแลระบบปรับใช้โปรแกรมเซิร์ฟเวอร์ Java ในบริษัทต่างๆ ตลอด 20 ปีที่ผ่านมา นี่คือส่วนผสม:

• เครื่องมือสร้างที่คุณชื่นชอบ (Maven, Gradle)
• SSH/SCP เก่าที่ดีสำหรับการคัดลอก .jars ไปยังเซิร์ฟเวอร์
• สคริปต์ทุบตีเพื่อจัดการสคริปต์การปรับใช้และเซิร์ฟเวอร์
• หรือดียิ่งขึ้น: สคริปต์ Ansible บางตัว

แน่นอนว่าสิ่งนี้ไม่เหมาะสำหรับนักสร้างสรรค์ที่ต้องการระบบคลาวด์แบบ "หายใจ" เซิร์ฟเวอร์ที่มีการปรับสมดุลโหลดอัตโนมัติ และอื่นๆ นี่มันโรงเรียนเก่าที่น่าเบื่อจริงๆ อย่างไรก็ตามมันใช้งานได้!

วิธีใช้ Docker เพื่อปรับใช้ Java Microservices

กลับไปสู่ความเจ็บปวดอันแสนหวานที่คุณเลือก เมื่อสองสามปีที่แล้ว Docker เข้ามามีบทบาทและด้วยการใช้คอนเทนเนอร์ หากคุณไม่เคยใช้งานมาก่อน ต่อไปนี้เป็นคำอธิบายสั้นๆ ที่มุ่งเป้าไปที่ผู้ใช้และนักพัฒนา:

• คอนเทนเนอร์ (แบบง่าย) คล้ายกับเครื่องเสมือนรุ่นเก่าที่ดี แต่ "เบากว่า" หากคุณไม่ชัดเจนว่า "ง่ายกว่า" หมายถึงอะไรในบริบทนี้ โปรดดู คำตอบ นี้ใน Stackoverflow
• คอนเทนเนอร์รับประกันความสามารถในการพกพาของตัวเอง นั่นคือมันทำงานได้ทุกที่ ฟังดูคุ้นเคยใช่ไหมล่ะ?

เป็นเรื่องตลกที่ความสามารถในการพกพาของ JVM และความเข้ากันได้แบบย้อนหลัง ฟีเจอร์นี้ดูเหมือนจะไม่มีข้อได้เปรียบเช่นนี้ คุณสามารถดาวน์โหลด JVM.zip บน Raspberry Pi (หรือแม้แต่โทรศัพท์มือถือ) แตกไฟล์และรันไฟล์ .jar ใดก็ได้ สถานการณ์เปลี่ยนไปในภาษาต่างๆ เช่น PHP หรือ Python ซึ่งเวอร์ชันที่เข้ากันไม่ได้หรือการตั้งค่าการใช้งานมีความซับซ้อนมากขึ้น หรือหากแอปพลิเคชัน Java ของคุณขึ้นอยู่กับบริการที่ติดตั้งอื่นๆ จำนวนมาก (ด้วยหมายเลขเวอร์ชันที่ถูกต้อง): ตัวอย่างเช่น ฐานข้อมูล Postgres หรือที่เก็บค่าคีย์ Redis ดังนั้นข้อ ได้เปรียบหลักของ Docker สำหรับไมโครเซอร์วิส Java หรือที่แม่นยำยิ่งขึ้นสำหรับแอปพลิเคชัน Java คือ: ความสามารถในการตั้งค่าการทดสอบที่เป็นเนื้อเดียวกันหรือสภาพแวดล้อมการรวมโดยใช้เครื่องมือเช่นTestcontainers การพัฒนาที่ซับซ้อนนั้นง่ายต่อการติดตั้ง ใช้ ซอฟต์แวร์ฟอรั่มวาทกรรม คุณสามารถติดตั้งด้วยอิมเมจ Docker เดียว และอิมเมจนั้นมีทุกสิ่งที่คุณต้องการ ตั้งแต่ซอฟต์แวร์ Discourse ที่เขียนด้วย Ruby ไปจนถึงฐานข้อมูล Postgres ไปจนถึง Redis ไปจนถึงอ่างล้างจาน หากการปรับใช้ของคุณคล้ายกันหรือคุณต้องการเรียกใช้ฐานข้อมูล Oracle เล็กๆ น้อยๆ ให้ลองใช้ Docker สรุป แทนที่จะดูไฟล์ .jar ตอนนี้คุณ:

• รวมไฟล์ jar ของคุณเข้ากับอิมเมจ Docker
• พุชอิมเมจนี้ไปที่รีจิสตรี Docker ส่วนตัว
• ดึงและเรียกใช้ภาพนี้บนแพลตฟอร์มเป้าหมายของคุณ
• หรือคัดลอกอิมเมจ Docker ไปยังระบบที่ใช้งานจริงของคุณโดยตรงแล้วรัน

วิธีใช้ Docker Swarm หรือ Kubernetes เพื่อปรับใช้ Java Microservices

สมมติว่าคุณตัดสินใจลองใช้ Docker ทุกครั้งที่คุณปรับใช้ไมโครเซอร์วิส Java คุณจะสร้างอิมเมจ Docker ที่รวมไฟล์ .jar ของคุณ สมมติว่าคุณมีไมโครเซอร์วิส Java สองสามรายการ และคุณต้องการปรับใช้บริการเหล่านี้บนเครื่องหลายเครื่อง (ในคลัสเตอร์) คำถามเกิดขึ้น: จะจัดการคลัสเตอร์นี้อย่างไร? รันคอนเทนเนอร์ Docker ตรวจสอบประสิทธิภาพ ปรับใช้การอัปเดต ปรับขนาดระบบ (brrr) หรือไม่ สองคำตอบที่เป็นไปได้สำหรับคำถามนี้คือ Docker Swarm และ Kubernetes การลงรายละเอียดเกี่ยวกับตัวเลือกทั้งสองอาจทำให้บทช่วยสอนที่ยาวอยู่แล้วนี้ยาวเกินไป แต่เราคิดว่าสิ่งสำคัญที่ต้องพูดถึงคือท้ายที่สุดแล้วทั้งสองตัวเลือกต้องพึ่งพาคุณในการเขียนไฟล์ YAML (ดูเรื่องราวการเยื้องของ Yaml ) เพื่อจัดการคลัสเตอร์ของคุณ หากคุณต้องการทราบว่าความรู้สึกนี้กระตุ้นในทางปฏิบัติอย่างไร เพียงพิมพ์ข้อความค้นหาที่คล้ายกันลงในการค้นหาของ Twitter ดังนั้นกระบวนการปรับใช้สำหรับไมโครเซอร์วิส Java ของคุณตอนนี้จะมีลักษณะดังนี้:

• การกำหนดค่าและการจัดการ Docker Swarm/Kubernetes
• ขั้นตอนทั้งหมดสำหรับ Docker (ดูด้านบน)
• เขียนและดำเนินการ YAML จนกระทั่งตาของคุณมีเลือดออกจนกว่าทุกอย่างจะทำงาน

วิธีทดสอบ Java Microservices

สมมติว่าคุณตัดสินใจที่จะใช้ไมโครเซอร์วิสในการผลิต เราจะทดสอบการรวม n-microservices ในระหว่างการพัฒนาได้อย่างไร คุณจะดูได้อย่างไรว่าเวิร์กโฟลว์ทั้งหมดใช้งานได้ และไม่ใช่แค่บางส่วนเท่านั้น ในทางปฏิบัติ คุณสามารถใช้วิธีใดวิธีหนึ่งจากสามวิธี:

1. ด้วยการทำงานเพียงเล็กน้อย (หากคุณใช้เฟรมเวิร์ก เช่น Spring Boot) คุณสามารถรวมไมโครเซอร์วิสทั้งหมดของคุณไว้ในคลาสตัวเรียกใช้งานเดียว และโหลดไมโครเซอร์วิสทั้งหมดโดยใช้คลาส Wrapper.java เดียว ขึ้นอยู่กับว่าคุณมีหน่วยความจำเพียงพอในเครื่องของคุณหรือไม่ เรียกใช้ไมโครเซอร์วิสทั้งหมดของคุณ
2. คุณสามารถคัดลอกการตั้งค่า Docker Swarm หรือ Kubernetes ในเครื่องได้
3. อย่าเพิ่งทำการทดสอบการรวมระบบในเครื่องอีกต่อไป ให้ปรับใช้สภาพแวดล้อม DEV/TEST เฉพาะแทน นี่คือสิ่งที่ไม่กี่ทีมทำจริงเมื่อพวกเขายอมจำนนต่อความเจ็บปวดจากการตั้งค่าไมโครเซอร์วิสในพื้นที่

นอกจากนี้ นอกเหนือจากไมโครเซอร์วิส Java ของคุณแล้ว คุณยังอาจจำเป็นต้องมีตัวรับส่งข้อความที่ทำงานอยู่ (เช่น ActiveMQ หรือ RabbitMQ) หรือบางทีอาจเป็นเซิร์ฟเวอร์อีเมลหรือส่วนประกอบการส่งข้อความอื่น ๆ ที่ไมโครเซอร์วิส Java ของคุณจำเป็นต้องสื่อสารระหว่างกัน สิ่งนี้นำไปสู่การประเมินความซับซ้อนในด้าน DevOps ต่ำเกินไปอย่างมีนัยสำคัญ ลองดูที่ Microservice Testing Libraries ซึ่งสามารถบรรเทาความเจ็บปวดนี้ได้ ไม่ว่าในกรณีใด ความซับซ้อนนี้จะนำเราไปสู่ปัญหาทั่วไปของไมโครเซอร์วิส ซึ่งเราจะพูดถึงในตอนนี้ ในส่วนสุดท้ายเราจะกล่าวถึงคำถามทั่วไปเกี่ยวกับไมโครเซอร์วิส Java