Một trong những vấn đề chính trong quá trình phát triển và vận hành tiếp theo của microservice là cấu hình chính xác và hiệu quả của các phiên bản của chúng. Theo ý kiến của tôi, một khuôn khổ mới có thể giúp giải quyết vấn đề này . Nó cho phép bạn giải quyết một số tác vụ cấu hình ứng dụng thông thường một cách khá dễ dàng.
Nếu bạn có nhiều vi dịch vụ và mỗi vi dịch vụ đều có tệp/tệp cấu hình riêng thì khả năng cao xảy ra lỗi ở một trong số chúng là rất khó phát hiện nếu không có kỹ năng phù hợp và hệ thống ghi nhật ký. Nhiệm vụ chính mà khung đặt ra cho chính nó là giảm thiểu các tham số cấu hình phiên bản trùng lặp, từ đó giảm khả năng xảy ra lỗi.
Hãy xem một ví dụ. Giả sử chúng ta có một ứng dụng đơn giản với tệp cấu hình khoai mỡ. Đây có thể là bất kỳ microservice nào ở bất kỳ ngôn ngữ nào. Hãy xem làm thế nào framework có thể được áp dụng cho dịch vụ này.
Nhưng trước tiên, để thuận tiện hơn, hãy tạo một dự án trống trong Idea IDE, sau khi cài đặt plugin microconfig.io trong đó:
Chúng ta thiết lập cấu hình khởi chạy plugin, bạn có thể sử dụng cấu hình mặc định như trong ảnh chụp màn hình ở trên.
Dịch vụ của chúng tôi được gọi là order, sau đó trong một dự án mới, chúng tôi sẽ tạo một cấu trúc tương tự:
Đặt tệp cấu hình vào thư mục có tên dịch vụ - ứng dụng.yaml. Tất cả các vi dịch vụ đều được khởi chạy trong một số loại môi trường, vì vậy, ngoài việc tạo cấu hình cho chính dịch vụ đó, cần phải mô tả chính môi trường đó: để làm được điều này, chúng ta sẽ tạo một thư mục env và thêm một tệp vào đó với tên môi trường làm việc của chúng tôi. Như vậy framework sẽ tạo các file cấu hình cho các dịch vụ trong môi trường dev, vì tham số này được đặt trong cài đặt plugin.
Cấu trúc tập tin dev.yaml nó sẽ khá đơn giản:
mainorder:
components:
- orderKhung hoạt động với các cấu hình được nhóm lại với nhau. Đối với dịch vụ của chúng tôi, hãy chọn tên cho nhóm đơn hàng chính. Khung này tìm thấy từng nhóm ứng dụng như vậy trong tệp môi trường và tạo cấu hình cho tất cả chúng, mà nó tìm thấy trong các thư mục tương ứng.
Trong chính tệp cài đặt dịch vụ gọi món Bây giờ hãy chỉ định một tham số:
spring.application.name: orderBây giờ, hãy chạy plugin và nó sẽ tạo cấu hình cần thiết cho dịch vụ của chúng tôi theo đường dẫn được chỉ định trong thuộc tính:
có thể và không cần cài đặt plugin, chỉ cần tải xuống bản phân phối khung và chạy nó từ dòng lệnh.
Giải pháp này phù hợp để sử dụng trên máy chủ xây dựng.
Điều đáng chú ý là framework này hoàn toàn hiểu được tài sản cú pháp, nghĩa là các tệp thuộc tính thông thường có thể được sử dụng cùng nhau trong khoai mỡ cấu hình.
Hãy thêm một dịch vụ khác thanh toán và làm phức tạp cái hiện có.
В gọi món:
eureka:
instance.preferIpAddress: true
client:
serviceUrl:
defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100В thanh toán:
eureka:
instance.preferIpAddress: true
client:
serviceUrl:
defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9998
spring.application.name: payments
db.url: 192.168.0.100Vấn đề chính với các cấu hình này là sự hiện diện của một lượng lớn bản sao-dán trong cài đặt dịch vụ. Hãy xem khuôn khổ sẽ giúp loại bỏ nó như thế nào. Hãy bắt đầu với điều rõ ràng nhất - sự hiện diện của cấu hình eureka trong phần mô tả của từng microservice. Hãy tạo một thư mục mới với tệp cài đặt và thêm cấu hình mới vào nó:
Và bây giờ hãy thêm dòng vào từng dự án của chúng ta #include eureka.
Khung sẽ tự động tìm cấu hình eureka và sao chép nó vào các tệp cấu hình dịch vụ, trong khi cấu hình eureka riêng sẽ không được tạo vì chúng tôi sẽ không chỉ định nó trong tệp môi trường dev.yaml. Dịch vụ gọi món:
#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100Chúng tôi cũng có thể di chuyển cài đặt cơ sở dữ liệu sang một cấu hình riêng bằng cách thay đổi dòng nhập thành #include eureka, oracle.
Điều đáng chú ý là khung theo dõi từng thay đổi khi tạo lại các tệp cấu hình và đặt nó vào một tệp đặc biệt bên cạnh tệp cấu hình chính. Mục trong nhật ký của nó trông như thế này: “Thuộc tính đã lưu trữ 1 thay đổi thành đặt hàng/diff-application.yaml" Điều này cho phép bạn nhanh chóng phát hiện các thay đổi đối với các tệp cấu hình lớn.
Việc xóa các phần chung của cấu hình cho phép bạn loại bỏ nhiều thao tác sao chép-dán không cần thiết, nhưng không cho phép bạn tạo cấu hình một cách linh hoạt cho các môi trường khác nhau - điểm cuối của các dịch vụ của chúng tôi là duy nhất và được mã hóa cứng, điều này thật tệ. Hãy thử loại bỏ điều này.
Một giải pháp tốt là giữ tất cả các điểm cuối trong một cấu hình mà người khác có thể tham khảo. Với mục đích này, hỗ trợ dành cho trình giữ chỗ đã được đưa vào khung. Đây là cách tập tin cấu hình sẽ thay đổi eureka:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/Bây giờ hãy xem trình giữ chỗ này hoạt động như thế nào. Hệ thống tìm thấy một thành phần có tên thiết bị đầu cuối và tìm kiếm ý nghĩa trong đó eurekaip, sau đó thay thế nó vào cấu hình của chúng tôi. Nhưng còn những môi trường khác nhau thì sao? Để thực hiện việc này, hãy tạo một tệp cài đặt trong thiết bị đầu cuối loại sau ứng dụng.dev.yaml. Khung độc lập, dựa trên phần mở rộng tệp, quyết định cấu hình này thuộc về môi trường nào và tải nó:
Nội dung tệp dev:
eurekaip: 192.89.89.111
dbip: 192.168.0.100Chúng tôi có thể tạo cấu hình tương tự cho các cổng dịch vụ của mình:
server.port: ${ports@order}.Tất cả các cài đặt quan trọng đều ở một nơi, do đó giảm khả năng xảy ra lỗi do các tham số rải rác trong tệp cấu hình.
Khung này cung cấp nhiều trình giữ chỗ được tạo sẵn, ví dụ: bạn có thể lấy tên của thư mục chứa tệp cấu hình và gán nó:
#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}Nhờ đó, không cần chỉ định thêm tên ứng dụng trong cấu hình và nó cũng có thể được đặt trong một mô-đun chung, chẳng hạn như trong cùng một eureka:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/
spring.application.name: ${this@name}Tập tin cấu hình gọi món sẽ được giảm xuống còn một dòng:
#include eureka, oracle
server.port: ${ports@order}Nếu chúng tôi không cần bất kỳ cài đặt nào từ cấu hình gốc, chúng tôi có thể chỉ định cài đặt đó trong cấu hình của mình và nó sẽ được áp dụng trong quá trình tạo. Nghĩa là, nếu vì lý do nào đó mà chúng tôi cần một tên duy nhất cho dịch vụ đặt hàng, chúng tôi sẽ chỉ để lại tham số mùa xuân.application.name.
Giả sử bạn cần thêm cài đặt ghi nhật ký tùy chỉnh vào dịch vụ, ví dụ: cài đặt này được lưu trữ trong một tệp riêng biệt logback.xml. Hãy tạo một nhóm cài đặt riêng cho nó:
Trong cấu hình cơ bản, chúng tôi sẽ cho khung biết nơi đặt tệp cài đặt ghi nhật ký mà chúng tôi cần bằng cách sử dụng trình giữ chỗ @ConfigDir:
microconfig.template.logback.fromFile: ${logback@configDir}/logback.xmlTrong tập tin logback.xml chúng tôi định cấu hình các trình bổ sung tiêu chuẩn, do đó cũng có thể chứa các phần giữ chỗ mà khung sẽ thay đổi trong quá trình tạo cấu hình, ví dụ:
<file>logs/${this@name}.log</file>Bằng cách thêm nhập vào cấu hình dịch vụ đăng lại, chúng tôi sẽ tự động nhận được tính năng ghi nhật ký được định cấu hình cho từng dịch vụ:
#include eureka, oracle, logback
server.port: ${ports@order}Đã đến lúc làm quen chi tiết hơn với tất cả các phần giữ chỗ có sẵn của khung:
${this@env} - trả về tên của môi trường hiện tại.
${…@name} - trả về tên của thành phần.
${…@configDir} — trả về đường dẫn đầy đủ tới thư mục cấu hình của thành phần.
${…@resultDir} — trả về đường dẫn đầy đủ tới thư mục đích của thành phần (các tệp kết quả sẽ được đặt trong thư mục này).
${this@configRoot} — trả về đường dẫn đầy đủ tới thư mục gốc của kho cấu hình.
Hệ thống cũng cho phép bạn lấy các biến môi trường, ví dụ như đường dẫn đến java:
${env@Java_HOME}
Hoặc, vì khung được viết bằng JAVA, chúng ta có thể nhận được các biến hệ thống tương tự như cuộc gọi Hệ thống::getProperty sử dụng cấu trúc như thế này:
${[email được bảo vệ]}
Điều đáng nói là hỗ trợ cho ngôn ngữ mở rộng EL mùa xuân. Các biểu thức sau đây được áp dụng trong cấu hình:
connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} và bạn có thể sử dụng các biến cục bộ trong tệp cấu hình bằng biểu thức #var:
#var feedRoot: ${[email protected]}/feed
folder:
root: ${this@feedRoot}
success: ${this@feedRoot}/archive
error: ${this@feedRoot}/errorDo đó, framework này là một công cụ khá mạnh để tinh chỉnh và cấu hình linh hoạt các microservices. Khung này hoàn thành xuất sắc nhiệm vụ chính của nó - loại bỏ việc sao chép-dán trong cài đặt, hợp nhất cài đặt và do đó giảm thiểu các lỗi có thể xảy ra, đồng thời cho phép bạn dễ dàng kết hợp các cấu hình và thay đổi chúng cho các môi trường khác nhau.
Nếu bạn quan tâm đến framework này, tôi khuyên bạn nên truy cập trang chính thức của nó và làm quen với toàn bộ , hoặc tìm hiểu các nguồn .
Nguồn: www.habr.com