JavaRush /Blog Java /Random-VI /Hướng dẫn về Java Microservices. Phần 2: Triển khai và th...

Hướng dẫn về Java Microservices. Phần 2: Triển khai và thử nghiệm

Xuất bản trong nhóm
Dịch và điều chỉnh các vi dịch vụ Java: Hướng dẫn thực hành . Liên kết đến phần đầu tiên của hướng dẫn . Hướng dẫn về Java Microservices.  Phần 2: Triển khai và thử nghiệm - 1Bất kỳ chương trình Java phía máy chủ nào và do đó bất kỳ vi dịch vụ nào cũng chỉ là một tệp có phần mở rộng .jar hoặc .war. Có một điều tuyệt vời về hệ sinh thái Java, hay đúng hơn là JVM: bạn chỉ cần viết mã Java một lần và nó có thể chạy trên hầu hết mọi hệ điều hành, miễn là bạn chưa biên dịch mã của mình bằng phiên bản Java mới hơn phiên bản Java hiện tại của bạn. phiên bản JVM mục tiêu. Điều này rất quan trọng để hiểu, đặc biệt là khi nói đến các chủ đề như Docker, Kubernetes hoặc (trống cuộn!) Đám mây. Tại sao? Hãy xem xét các kịch bản triển khai khác nhau.

Ví dụ triển khai microservice Java tối giản

Hãy tiếp tục với ví dụ về ngân hàng. Vì vậy, chúng tôi có một tệp monobank.jar (nguyên khối) và Riskengine.jar mới được trích xuất (microservice kiểm tra rủi ro đầu tiên). Cũng giả sử rằng cả hai ứng dụng, giống như mọi ứng dụng khác trên thế giới, đều cần tệp .properties. Trong trường hợp của chúng tôi, nó sẽ chỉ chứa URL cơ sở dữ liệu và thông tin xác thực. Việc triển khai tối thiểu có thể bao gồm hai thư mục trông giống như thế này: Đầu tiên:

-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

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...
Thứ hai:

-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

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...
Điều này để lại câu hỏi mở: các tệp .properties và .jar sẽ đến máy chủ như thế nào? Thật không may, có thể có nhiều câu trả lời.

Cách sử dụng Công cụ xây dựng, SSH và Ansible để triển khai các vi dịch vụ Java

Lời khuyên nhàm chán nhưng không kém phần xuất sắc về cách triển khai các dịch vụ vi mô Java... Trên thực tế, chính xác là cách mà các quản trị viên hệ thống đã triển khai bất kỳ chương trình máy chủ Java nào trong các công ty trong hơn 20 năm qua. Đây là sự pha trộn:
  • công cụ xây dựng yêu thích của bạn (Maven, Gradle)
  • SSH/SCP cũ tốt để sao chép .jars vào máy chủ
  • Tập lệnh Bash để quản lý tập lệnh triển khai và máy chủ
  • hoặc thậm chí tốt hơn: một số tập lệnh Ansible.
Tất nhiên, điều này không phù hợp với những nhà đổi mới cần một đám mây “dễ thở”, các máy chủ có tính năng cân bằng tải tự động, v.v. Đây là trường học cũ thực sự nhàm chán. Tuy nhiên nó hoạt động!

Cách sử dụng Docker để triển khai các vi dịch vụ Java

Hãy quay trở lại với sự đau đớn ngọt ngào của sự lựa chọn. Một vài năm trước, Docker đã xuất hiện và kéo theo đó là việc container hóa. Nếu bạn chưa từng làm việc với nó thì đây là mô tả ngắn gọn dành cho người dùng cuối và nhà phát triển:
  • Một thùng chứa (đơn giản hóa) tương tự như máy ảo cũ nhưng “nhẹ hơn”. Nếu bạn không rõ “dễ dàng hơn” nghĩa là gì trong ngữ cảnh này, vui lòng xem câu trả lời này trên Stackoverflow .
  • Container đảm bảo tính di động của chính nó. Đó là, nó hoạt động ở bất cứ đâu. Nghe có vẻ quen thuộc phải không?
Hướng dẫn về Java Microservices.  Phần 2: Triển khai và thử nghiệm - 2Thật buồn cười khi xét đến tính di động và khả năng tương thích ngược của JVM, tính năng này dường như không phải là một lợi thế. Bạn có thể chỉ cần tải xuống JVM.zip trên bất kỳ Raspberry Pi nào (hoặc thậm chí cả điện thoại di động), giải nén nó và chạy bất kỳ tệp .jar nào. Tình hình thay đổi trong các ngôn ngữ như PHP hoặc Python, trong đó phiên bản không tương thích hoặc cài đặt triển khai phức tạp hơn. Hoặc nếu ứng dụng Java của bạn phụ thuộc vào nhiều dịch vụ được cài đặt khác (với số phiên bản chính xác): ví dụ: cơ sở dữ liệu Postgres hoặc kho lưu trữ giá trị khóa Redis. Vì vậy, ưu điểm chính của Docker cho các dịch vụ vi mô Java, hay chính xác hơn là dành cho các ứng dụng Java, là: khả năng thiết lập môi trường tích hợp hoặc thử nghiệm đồng nhất bằng cách sử dụng các công cụ như Testcontainers . Sự phát triển phức tạp dễ cài đặt hơn. Hãy sử dụng phần mềm diễn đàn Discourse . Bạn có thể cài đặt nó bằng một hình ảnh Docker duy nhất và hình ảnh đó chứa mọi thứ bạn cần, từ phần mềm Discourse được viết bằng Ruby, đến cơ sở dữ liệu Postgres, Redis, cho đến bồn rửa bát. Nếu quá trình triển khai của bạn tương tự hoặc bạn muốn chạy một cơ sở dữ liệu Oracle nhỏ gọn, hãy thử Docker. Vì vậy, để tóm tắt, thay vì chỉ nhìn vào tệp .jar, bây giờ bạn:
  • gói tệp jar của bạn vào hình ảnh Docker
  • Đẩy hình ảnh này vào sổ đăng ký Docker riêng
  • kéo và chạy hình ảnh này trên nền tảng mục tiêu của bạn
  • hoặc sao chép hình ảnh Docker trực tiếp vào hệ thống sản xuất của bạn và chạy nó.

Cách sử dụng Docker Swarm hoặc Kubernetes để triển khai các vi dịch vụ Java

Giả sử bạn quyết định dùng thử Docker. Mỗi khi bạn triển khai một vi dịch vụ Java, bạn sẽ tạo một hình ảnh Docker gói tệp .jar của mình. Giả sử bạn có một vài dịch vụ vi mô Java này và bạn muốn triển khai các dịch vụ này trên một số máy (trong một cụm). Câu hỏi đặt ra: làm thế nào để quản lý cụm này? Chạy vùng chứa Docker, kiểm tra hiệu suất, triển khai bản cập nhật, mở rộng quy mô hệ thống (brrr)? Hai câu trả lời khả dĩ cho câu hỏi này là Docker Swarm và Kubernetes. Đi sâu vào chi tiết về cả hai tùy chọn sẽ khiến hướng dẫn vốn đã dài này trở nên quá dài, nhưng chúng tôi nghĩ điều quan trọng cần đề cập là cả hai tùy chọn cuối cùng đều dựa vào việc bạn ghi các tệp YAML (xem câu chuyện thụt lề Yaml ) để quản lý cụm của bạn. Nếu bạn muốn biết điều này gợi lên cảm giác gì trong thực tế, chỉ cần nhập một truy vấn tương tự vào tìm kiếm Twitter. Vì vậy, quy trình triển khai cho các vi dịch vụ Java của bạn bây giờ trông giống như thế này:
  • Định cấu hình và quản lý Docker Swarm/Kubernetes
  • Tất cả các bước cho Docker (xem ở trên)
  • Viết và thực thi YAML cho đến khi mắt bạn chảy máu cho đến khi mọi thứ hoạt động.

Cách kiểm tra vi dịch vụ Java

Giả sử bạn quyết định triển khai vi dịch vụ trong sản xuất. Bây giờ làm cách nào để kiểm tra việc tích hợp n-microservices trong quá trình phát triển? Làm cách nào bạn có thể biết liệu toàn bộ quy trình làm việc có đang hoạt động hay không chứ không chỉ một phần của quy trình đó? Trong thực tế, bạn có thể sử dụng một trong ba phương pháp:
  1. Chỉ cần thực hiện một chút công việc (nếu đang sử dụng các khung như Spring Boot), bạn có thể kết hợp tất cả các vi dịch vụ của mình vào một lớp trình khởi chạy và tải tất cả các vi dịch vụ bằng một lớp Wrapper.java duy nhất - tùy thuộc vào việc bạn có đủ bộ nhớ trên máy hay không chạy chúng tất cả các dịch vụ vi mô của bạn.
  2. Bạn có thể sao chép cài đặt Docker Swarm hoặc Kubernetes cục bộ.
  3. Đừng chạy thử nghiệm tích hợp cục bộ nữa. Thay vào đó, hãy triển khai môi trường DEV/TEST chuyên dụng. Đây là điều mà khá nhiều nhóm thực sự làm khi họ gặp khó khăn trong việc thiết lập microservice cục bộ.
Ngoài ra, ngoài các vi dịch vụ Java, có thể bạn cũng sẽ cần một trình trung chuyển tin nhắn đang chạy (chẳng hạn như ActiveMQ hoặc RabbitMQ) hoặc có thể là một máy chủ email hoặc bất kỳ thành phần nhắn tin nào khác mà các vi dịch vụ Java của bạn cần liên lạc với nhau. Điều này dẫn đến việc đánh giá thấp đáng kể mức độ phức tạp ở phía DevOps. Hãy xem Thư viện kiểm tra microservice, chúng có thể giảm bớt nỗi đau này. Trong mọi trường hợp, sự phức tạp này đưa chúng ta đến những vấn đề chung của microservice mà chúng ta sẽ nói đến ngay bây giờ. Trong phần cuối cùng , chúng tôi sẽ đề cập đến các câu hỏi chung về vi dịch vụ Java.
Bình luận
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION