ปัญหาหลักประการหนึ่งในการพัฒนาและการดำเนินงานไมโครเซอร์วิสในภายหลังคือการกำหนดค่าอินสแตนซ์ที่มีความสามารถและแม่นยำ ในความคิดของฉัน กรอบการทำงานใหม่สามารถช่วยในเรื่องนี้ได้ . ช่วยให้คุณสามารถแก้ไขงานการกำหนดค่าแอปพลิเคชันตามปกติบางอย่างได้อย่างสวยงาม
หากคุณมีไมโครเซอร์วิสจำนวนมาก และแต่ละไมโครเซอร์วิสมาพร้อมกับไฟล์/ไฟล์การกำหนดค่าของตัวเอง ก็มีโอกาสสูงที่จะเกิดข้อผิดพลาดในไมโครเซอร์วิสตัวใดตัวหนึ่ง ซึ่งอาจเป็นเรื่องยากมากที่จะตรวจพบหากไม่มีทักษะที่เหมาะสมและระบบการบันทึก งานหลักที่เฟรมเวิร์กกำหนดไว้สำหรับตัวเองคือการลดพารามิเตอร์การกำหนดค่าอินสแตนซ์ที่ซ้ำกัน ซึ่งช่วยลดโอกาสที่จะเพิ่มข้อผิดพลาด
ลองดูตัวอย่าง สมมติว่าเรามีแอปพลิเคชันธรรมดาพร้อมไฟล์กำหนดค่า มันแกว. นี่อาจเป็นไมโครเซอร์วิสในภาษาใดก็ได้ มาดูกันว่าสามารถนำกรอบงานไปใช้กับบริการนี้ได้อย่างไร
แต่ก่อนอื่น เพื่อความสะดวกยิ่งขึ้น มาสร้างโปรเจ็กต์ว่างใน Idea IDE หลังจากติดตั้งปลั๊กอิน microconfig.io ลงไปแล้ว:
เราตั้งค่าการกำหนดค่าการเปิดใช้งานปลั๊กอิน คุณสามารถใช้การกำหนดค่าเริ่มต้นได้ดังในภาพหน้าจอด้านบน
บริการของเราเรียกว่า Order จากนั้นเราจะสร้างโครงสร้างที่คล้ายกันในโครงการใหม่:
วางไฟล์กำหนดค่าไว้ในโฟลเดอร์ที่มีชื่อบริการ - application.yaml. ไมโครเซอร์วิสทั้งหมดเปิดตัวในสภาพแวดล้อมบางประเภท ดังนั้น นอกเหนือจากการสร้างการกำหนดค่าสำหรับบริการแล้ว ยังจำเป็นต้องอธิบายสภาพแวดล้อมด้วย: สำหรับสิ่งนี้ เราจะสร้างโฟลเดอร์ สภาพแวดล้อม และเพิ่มไฟล์ลงไปพร้อมกับชื่อสภาพแวดล้อมการทำงานของเรา ดังนั้นเฟรมเวิร์กจะสร้างไฟล์การกำหนดค่าสำหรับบริการในสภาพแวดล้อม devเนื่องจากพารามิเตอร์นี้ถูกตั้งค่าไว้ในการตั้งค่าปลั๊กอิน
โครงสร้างไฟล์ dev.yaml มันจะค่อนข้างง่าย:
mainorder:
components:
- orderเฟรมเวิร์กทำงานร่วมกับการกำหนดค่าที่จัดกลุ่มไว้ด้วยกัน สำหรับบริการของเรา ให้เลือกชื่อกลุ่ม คำสั่งซื้อหลัก. เฟรมเวิร์กจะค้นหากลุ่มแอปพลิเคชันแต่ละกลุ่มในไฟล์สภาพแวดล้อม และสร้างการกำหนดค่าสำหรับแอปพลิเคชันทั้งหมด ซึ่งจะพบในโฟลเดอร์ที่เกี่ยวข้อง
ในไฟล์การตั้งค่าบริการนั้นเอง ใบสั่ง ตอนนี้เราระบุเพียงพารามิเตอร์เดียวเท่านั้น:
spring.application.name: orderตอนนี้มาเรียกใช้ปลั๊กอินกัน และมันจะสร้างการกำหนดค่าที่จำเป็นสำหรับบริการของเราตามเส้นทางที่ระบุในคุณสมบัติ:
หนึ่งสามารถ และโดยไม่ต้องติดตั้งปลั๊กอิน เพียงดาวน์โหลดการกระจายเฟรมเวิร์กและรันจากบรรทัดคำสั่ง
โซลูชันนี้เหมาะสำหรับใช้บนบิลด์เซิร์ฟเวอร์
เป็นที่น่าสังเกตว่ากรอบการทำงานเข้าใจได้อย่างสมบูรณ์แบบ คุณสมบัติ ไวยากรณ์นั่นคือไฟล์คุณสมบัติทั่วไปที่สามารถใช้ร่วมกันได้ มันแกว การกำหนดค่า
มาเพิ่มอีกบริการครับ การชำระเงิน และทำให้สิ่งที่มีอยู่ซับซ้อนขึ้น
В ใบสั่ง:
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В การชำระเงิน:
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.100ปัญหาหลักของการกำหนดค่าเหล่านี้คือการมีสำเนาวางจำนวนมากในการตั้งค่าบริการ มาดูกันว่า Framework จะช่วยกำจัดมันได้อย่างไร เริ่มจากสิ่งที่ชัดเจนที่สุด - การมีอยู่ของการกำหนดค่า eureka ในคำอธิบายของไมโครเซอร์วิสแต่ละรายการ มาสร้างไดเร็กทอรีใหม่ด้วยไฟล์การตั้งค่าและเพิ่มการกำหนดค่าใหม่ลงไป:
และตอนนี้เรามาเพิ่มบรรทัดให้กับแต่ละโครงการของเรา #รวมยูเรก้า.
เฟรมเวิร์กจะค้นหาการกำหนดค่ายูเรก้าโดยอัตโนมัติและคัดลอกไปยังไฟล์การกำหนดค่าบริการ ในขณะที่การกำหนดค่ายูเรก้าแยกต่างหากจะไม่ถูกสร้างขึ้น เนื่องจากเราจะไม่ระบุในไฟล์สภาพแวดล้อม dev.yaml. บริการ ใบสั่ง:
#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100นอกจากนี้เรายังสามารถย้ายการตั้งค่าฐานข้อมูลไปเป็นการกำหนดค่าแยกต่างหากโดยเปลี่ยนบรรทัดนำเข้าเป็น #รวมยูเรก้าออราเคิล.
เป็นที่น่าสังเกตว่าเฟรมเวิร์กจะติดตามการเปลี่ยนแปลงแต่ละครั้งเมื่อสร้างไฟล์คอนฟิกูเรชันใหม่และวางไว้ในไฟล์พิเศษถัดจากไฟล์คอนฟิกูเรชันหลัก รายการในบันทึกมีลักษณะดังนี้: “จัดเก็บคุณสมบัติ 1 รายการเปลี่ยนเป็น สั่งซื้อ/diff-application.yaml" สิ่งนี้ช่วยให้คุณตรวจจับการเปลี่ยนแปลงในไฟล์การกำหนดค่าขนาดใหญ่ได้อย่างรวดเร็ว
การลบส่วนทั่วไปของการกำหนดค่าออกทำให้คุณสามารถกำจัดการคัดลอกและวางที่ไม่จำเป็นออกไปได้มากมาย แต่ไม่อนุญาตให้คุณสร้างการกำหนดค่าสำหรับสภาพแวดล้อมที่แตกต่างกันได้อย่างยืดหยุ่น - จุดสิ้นสุดของบริการของเรามีเอกลักษณ์เฉพาะตัวและมีฮาร์ดโค้ด ซึ่งถือเป็นเรื่องไม่ดี ลองเอาสิ่งนี้ออกดู
วิธีแก้ปัญหาที่ดีคือเก็บปลายทางทั้งหมดไว้ในการกำหนดค่าเดียวที่ผู้อื่นสามารถอ้างอิงได้ เพื่อจุดประสงค์นี้ จึงมีการแนะนำการสนับสนุนสำหรับตัวยึดตำแหน่งในกรอบงาน ไฟล์การกำหนดค่าจะเปลี่ยนแปลงดังนี้ eureka:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/ตอนนี้เรามาดูกันว่าตัวยึดตำแหน่งนี้ทำงานอย่างไร ระบบค้นหาส่วนประกอบที่ชื่อ ปลายทาง และมองหาความหมายในนั้น ยูเรไคปแล้วแทนที่มันลงในการกำหนดค่าของเรา แต่แล้วสภาพแวดล้อมที่แตกต่างกันล่ะ? หากต้องการทำสิ่งนี้ ให้สร้างไฟล์การตั้งค่าใน ปลายทาง ประเภทต่อไปนี้ application.dev.yaml. เฟรมเวิร์กอย่างอิสระ ขึ้นอยู่กับนามสกุลไฟล์ ตัดสินใจว่าการกำหนดค่านี้อยู่ในสภาพแวดล้อมใดและโหลด:
เนื้อหาไฟล์ Dev:
eurekaip: 192.89.89.111
dbip: 192.168.0.100เราสามารถสร้างการกำหนดค่าเดียวกันสำหรับพอร์ตบริการของเรา:
server.port: ${ports@order}.การตั้งค่าที่สำคัญทั้งหมดรวมอยู่ในที่เดียว จึงช่วยลดโอกาสที่จะเกิดข้อผิดพลาดเนื่องจากพารามิเตอร์กระจัดกระจายในไฟล์การกำหนดค่า
เฟรมเวิร์กมีตัวยึดตำแหน่งสำเร็จรูปจำนวนมาก ตัวอย่างเช่น คุณสามารถรับชื่อของไดเร็กทอรีซึ่งมีไฟล์การกำหนดค่าอยู่และกำหนด:
#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}ด้วยเหตุนี้ จึงไม่จำเป็นต้องระบุชื่อแอปพลิเคชันเพิ่มเติมในการกำหนดค่า และยังสามารถวางไว้ในโมดูลทั่วไปได้ เช่น ใน eureka เดียวกัน:
client:
serviceUrl:
defaultZone: http://${endpoints@eurekaip}:6782/eureka/
spring.application.name: ${this@name}ไฟล์การกำหนดค่า ใบสั่ง จะถูกลดเหลือหนึ่งบรรทัด:
#include eureka, oracle
server.port: ${ports@order}หากเราไม่ต้องการการตั้งค่าใดๆ จากการกำหนดค่าหลัก เราสามารถระบุการตั้งค่าดังกล่าวในการกำหนดค่าของเราได้ และจะมีการใช้งานระหว่างการสร้าง นั่นคือ หากเราต้องการชื่อที่ไม่ซ้ำกันสำหรับบริการสั่งซื้อด้วยเหตุผลบางอย่าง เราก็จะปล่อยพารามิเตอร์ไว้ spring.application.name.
สมมติว่าคุณต้องเพิ่มการตั้งค่าการบันทึกแบบกำหนดเองให้กับบริการ ซึ่งจัดเก็บไว้ในไฟล์แยกต่างหาก เช่น logback.xml. มาสร้างกลุ่มการตั้งค่าแยกต่างหาก:
ในการกำหนดค่าพื้นฐาน เราจะบอกเฟรมเวิร์กว่าจะวางไฟล์การตั้งค่าการบันทึกที่เราต้องการโดยใช้ตัวยึดตำแหน่งไว้ที่ไหน @ConfigDir:
microconfig.template.logback.fromFile: ${logback@configDir}/logback.xmlในไฟล์ logback.xml เรากำหนดค่าส่วนต่อท้ายมาตรฐาน ซึ่งในทางกลับกันก็อาจมีตัวยึดตำแหน่งที่เฟรมเวิร์กจะเปลี่ยนระหว่างการสร้างการกำหนดค่า เช่น:
<file>logs/${this@name}.log</file>โดยการเพิ่มการนำเข้าการกำหนดค่าบริการ เข้าสู่ระบบกลับเราได้รับการกำหนดค่าการบันทึกสำหรับแต่ละบริการโดยอัตโนมัติ:
#include eureka, oracle, logback
server.port: ${ports@order}ถึงเวลาทำความคุ้นเคยกับรายละเอียดเพิ่มเติมเกี่ยวกับตัวยึดตำแหน่งที่มีอยู่ทั้งหมดของกรอบงาน:
${นี่@env} - ส่งกลับชื่อของสภาพแวดล้อมปัจจุบัน
${...@ชื่อ} — ส่งคืนชื่อของส่วนประกอบ
${...@configDir} — ส่งคืนเส้นทางแบบเต็มไปยังไดเร็กทอรี config ของส่วนประกอบ
${...@resultDir} — ส่งคืนพาธแบบเต็มไปยังไดเร็กทอรีปลายทางของคอมโพเนนต์ (ไฟล์ผลลัพธ์จะถูกวางไว้ในไดเร็กทอรีนี้)
${this@configRoot} — ส่งคืนพาธแบบเต็มไปยังไดเร็กทอรีรากของที่เก็บการกำหนดค่า
ระบบยังอนุญาตให้คุณรับตัวแปรสภาพแวดล้อม เช่น เส้นทางไปยัง java:
${env@JAVA_HOME}
เนื่องจากมีการเขียนกรอบไว้ JAVAเราสามารถรับตัวแปรระบบคล้ายกับการโทร ระบบ::getProperty โดยใช้โครงสร้างดังนี้:
${[ป้องกันอีเมล]}
เป็นมูลค่าการกล่าวขวัญถึงการสนับสนุนภาษาส่วนขยาย สปริง เอล. นิพจน์ต่อไปนี้มีผลบังคับใช้ในการกำหนดค่า:
connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} และคุณสามารถใช้ตัวแปรโลคัลในไฟล์คอนฟิกูเรชันโดยใช้นิพจน์ #วาร์:
#var feedRoot: ${[email protected]}/feed
folder:
root: ${this@feedRoot}
success: ${this@feedRoot}/archive
error: ${this@feedRoot}/errorดังนั้นเฟรมเวิร์กจึงเป็นเครื่องมือที่ทรงพลังพอสมควรสำหรับการปรับแต่งอย่างละเอียดและการกำหนดค่าไมโครเซอร์วิสที่ยืดหยุ่น เฟรมเวิร์กตอบสนองงานหลักได้อย่างสมบูรณ์แบบ - กำจัดการคัดลอกและวางในการตั้งค่า รวมการตั้งค่า และลดข้อผิดพลาดที่อาจเกิดขึ้นได้ ในขณะเดียวกันก็ช่วยให้คุณสามารถรวมการกำหนดค่าและเปลี่ยนแปลงในสภาพแวดล้อมที่แตกต่างกันได้อย่างง่ายดาย
หากคุณสนใจกรอบการทำงานนี้ ฉันขอแนะนำให้ไปที่หน้าอย่างเป็นทางการและทำความคุ้นเคยกับกรอบการทำงานทั้งหมด หรือเจาะลึกถึงแหล่งที่มา .
ที่มา: will.com