แนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการไฟล์คอนฟิกูเรชัน / คุณสมบัติโครงสร้างจำนวนมาก


15

ลองนึกภาพระบบที่มีเซิร์ฟเวอร์จำนวนมาก แต่ละรายการมีการตั้งค่าจำนวนมาก:

  • บางอย่างเฉพาะกับเซิร์ฟเวอร์
  • เฉพาะบางภูมิภาค
  • บางคนพบเห็นได้ทั่วทุกคน
  • บางทีคุณอาจมีการจัดกลุ่มแบบกำหนดเองบางอย่างเช่นกลุ่มเซิร์ฟเวอร์นี้มีไว้สำหรับอ่านเท่านั้น
  • เป็นต้น

การปฏิบัติปัจจุบันที่ฉันมีอยู่ในใจเป็นโครงสร้างที่เรียบง่ายพร้อมความสามารถที่เหนือกว่า

ให้ใช้เซิร์ฟเวอร์ของ Google เพื่อเป็นตัวอย่าง แต่ละรายการมีรายการการตั้งค่าที่จะโหลด

ตัวอย่างเช่นเซิร์ฟเวอร์ลอนดอนอาจมี:

rootsettings.properties, europesettings.properties, londonsettings.properties, searchengine.propertiesฯลฯ

ที่แต่ละไฟล์มีชุดของคุณสมบัติและลำดับการโหลดช่วยให้คุณสามารถแทนที่คุณสมบัติได้ยิ่งคุณไปได้ไกลเท่าไหร่

ตัวอย่างเช่น: rootsettings.propertiesอาจมีaccessible=falseค่าเริ่มต้น แต่อยู่เหนือsearchengine.propertiesด้วยaccessible=true


ปัญหาที่ฉันมีกับโครงสร้างนี้คือมันง่ายมากที่จะออกจากการควบคุม มันไม่ได้มีโครงสร้างเลยหมายความว่าคุณสามารถกำหนดคุณสมบัติใด ๆ ได้ทุกระดับและหลายรายการอาจล้าสมัย

นอกจากนี้การเปลี่ยนระดับกลางจะเป็นไปไม่ได้เมื่อเครือข่ายโตขึ้นเนื่องจากตอนนี้คุณส่งผลกระทบต่อเซิร์ฟเวอร์จำนวนมาก

ท้ายสุด แต่ไม่ท้ายสุดแต่ละอินสแตนซ์แต่ละรายการอาจต้องการคุณสมบัติพิเศษ 1 รายการซึ่งหมายความว่าแผนผังของคุณจะจบลงด้วยการกำหนดค่าสำหรับเซิร์ฟเวอร์แต่ละเครื่องอย่างไรก็ตามมันจึงไม่ใช่โซลูชันที่ดีที่สุด

ฉันจะขอขอบคุณอย่างมากหากคุณมีข้อเสนอแนะ / แนวคิดเกี่ยวกับสถาปัตยกรรมการจัดการการกำหนดค่าที่ดีขึ้น


1
สิ่งแรก: บันทึกคุณสมบัติทั้งหมดที่โหลดเมื่อเริ่มต้นอย่างน้อยคุณก็รู้ค่าที่ใช้
Walfrat

@Stoyan คุณกำลังมองหาแนวทาง "การกำหนดค่าซอฟต์แวร์" หรือ "การกำหนดค่าเซิร์ฟเวอร์" หรือไม่
Yusubov

ความคิดที่แปลกประหลาด แต่ไม่ค่อยดี: มีใครใช้ระบบ "CSS-like" สำหรับสิ่งนี้ไหม แทนที่จะเป็น (หรือเพิ่มเติมจาก) ชื่อไฟล์ที่มีโครงสร้างข้อมูลภายในจะเป็น
user949300

ฉันสร้างระบบการจัดการการตั้งค่าส่วนกลางที่ใช้ CSS เป็นกฎ มีอิสระที่จะใช้และเปิดแหล่งที่มา ดูคำตอบของฉันด้านล่างสำหรับรายละเอียดเพิ่มเติม
bikeman868

ดูเหมือนว่าวิธีการที่สมเหตุสมผลสำหรับฉัน
dagnelies

คำตอบ:


5

ฉันคิดว่าคุณต้องถามคำถามตัวเองก่อนและชี้แจงบางประเด็นจากนั้นคุณสามารถตัดสินใจได้ดีขึ้นว่าจะแก้ปัญหาของคุณอย่างไร

อย่างแรก: ใครจะเป็นผู้ควบคุมเซิร์ฟเวอร์

  • เป็นผู้ดูแลระบบเดียวที่จะควบคุมเซิร์ฟเวอร์นับร้อยหรือไม่ จากนั้นคุณต้องรวมศูนย์การกำหนดค่าให้มากที่สุด

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

ข้อที่สอง: คุณต้องการตัวเลือกการกำหนดค่ามากมายหรือไม่หรือคุณสามารถลดจำนวนลงได้บ้าง? แทนที่จะทำให้ทุกอย่างสามารถกำหนดค่าได้ "ในกรณี" ดีกว่า จำกัด ตัวเองกับตัวเลือกที่คุณรู้ว่าระบบของคุณต้องการจริงๆ สิ่งนี้สามารถทำได้ตัวอย่างเช่นโดย

  • ทำให้ซอฟต์แวร์ของคุณฉลาดขึ้นเล็กน้อย (ตัวอย่างเช่นโปรแกรมสามารถกำหนดสิ่งใดโดยอัตโนมัติโดยถามถึงสภาพแวดล้อม)

  • ทำตาม "การประชุมผ่านการตั้งค่า" อย่างเคร่งครัด - ตัวอย่างเช่นโดยการสร้างแบบแผนการตั้งชื่อบางอย่างหรือโดยการหาตัวเลือกบางอย่างเป็นค่าเริ่มต้นจากตัวเลือกอื่น ๆ

ประการที่สาม: คุณต้องการระดับการกำหนดค่าฮาร์ดโค้ดในซอฟต์แวร์หรือไม่? ลองนึกภาพคุณไม่ทราบมาก่อนว่าจะมีเซิร์ฟเวอร์กี่เครื่องถ้าลำดับชั้นที่มีโครงสร้างคล้ายต้นไม้เป็นโครงสร้างที่ดีที่สุดสำหรับพวกเขาหรือต้องมีต้นไม้กี่ระดับ วิธีแก้ปัญหาที่ง่ายที่สุดที่ฉันคิดได้ก็คือไม่ต้องมีการกำหนดค่าส่วนกลางเลยเพียงไฟล์เดียวต่อเซิร์ฟเวอร์และให้ผู้ดูแลระบบเซิร์ฟเวอร์ที่เชื่อถือได้ตัดสินใจด้วยตัวเองว่าพวกเขาแก้ปัญหาการจัดการการกำหนดค่าของหลายเซิร์ฟเวอร์ได้อย่างไร

ตัวอย่างเช่นผู้ดูแลระบบอาจเขียนสคริปต์ตัวสร้างซึ่งแจกจ่ายไฟล์กำหนดค่าส่วนกลางไปยังกลุ่มของเซิร์ฟเวอร์ที่แตกต่างกันและทำการแก้ไขเล็กน้อยในแต่ละสำเนา ด้วยวิธีนี้คุณไม่จำเป็นต้องตั้งสมมติฐานใด ๆ เกี่ยวกับ "การแจกจ่ายเซิร์ฟเวอร์โทโพโลยี" ล่วงหน้าโทโพโลยีสามารถปรับได้ตลอดเวลาตามความต้องการของโลกแห่งความจริง ข้อเสียคือคุณต้องมีผู้ดูแลระบบที่มีความรู้เกี่ยวกับวิธีการเขียนสคริปต์ในภาษาเช่น Perl, Python, Bash หรือ Powershell


แม้ว่าสิ่งนี้จะไม่ได้ให้วิธีแก้ปัญหาโดยตรง แต่ก็สมเหตุสมผลดีที่สุดเกี่ยวกับวิธีจัดการกับสถานการณ์ที่เลวร้ายไปแล้ว โดยเฉพาะอย่างยิ่งการทำให้ซอฟต์แวร์ของคุณฉลาดขึ้นเล็กน้อย
SDekov

2

โดยส่วนตัวฉันไม่เคยชอบการสืบทอดไฟล์ config คุณพูดถึงการมีลำดับการโหลดไม่แน่ใจว่ามันถูกกำหนดหรือได้รับมาอย่างไร อาจช่วยให้ลำดับที่ชัดเจนโดยทำมิเรอร์ในโครงสร้างไดเรกทอรีที่คุณใส่ไฟล์ในหรือรวมไว้ในชื่อไฟล์

rootsettings.properties
rootsettings.eurosettings.properties
rootsettings.eurosettings.londonsettings.properties

สิ่งนี้จะทำงานได้ถึงจุดที่คุณมีการรวมค่าการกำหนดค่าที่ไม่สอดคล้องกับภูมิภาค ดังนั้นคุณต้องคำนึงถึงแกนองค์กรที่คุณเลือกด้วย

สิ่งที่ฉันชอบมากกว่าคือการแยกการรวมค่าการกำหนดค่าเป็นไฟล์ของตนเองและมีไฟล์การกำหนดค่า (ลีฟ) ชี้ไปที่หนึ่ง

ตัวอย่าง:

bigcity.searchsettings.properties
regional.searchsettings.properties

ภายในlondonsettings.propertiesคุณสามารถมีค่าเช่น:

searchsettings:bigcity.searchsettings.properties

สิ่งนี้จะช่วยให้มีอิสระมากขึ้นหรือเพิ่มอีกหนึ่งระดับ


2

ฉันมีปัญหาเดียวกันและเปิดทางแก้ปัญหาของฉัน คุณสามารถค้นหาซอร์สโค้ดได้ที่นี่https://github.com/Bikeman868/Urchin

ฉันใช้สำหรับระบบขนาดใหญ่ที่มีเซิร์ฟเวอร์จำนวนมากพร้อมกับแอพพลิเคชั่นมากมายในแต่ละเซิร์ฟเวอร์และสภาพแวดล้อมที่หลากหลาย มันมี UI ที่เขียนใน Dart เพื่อจัดการการกำหนดค่า

คุณสามารถติดต่อฉันโดยตรงหากคุณต้องการความช่วยเหลือในการออกจากพื้นดิน

โซลูชันที่ฉันนำมาใช้นั้นเป็นไปตามกฎ โดยทั่วไปคุณเริ่มต้นด้วยกฎหนึ่งข้อที่ใช้กับการกำหนดค่าทั้งหมดจากนั้นเพิ่มคุณสามารถเพิ่มกฎเช่น "เครื่องทั้งหมดในสภาพแวดล้อมนี้สร้างไฟล์บันทึกไปยังเส้นทาง UNC นี้" กฎสามารถเฉพาะสำหรับสภาพแวดล้อมแอปพลิเคชันเครื่องหรืออินสแตนซ์ของแอปพลิเคชัน กฎอาจมีความเฉพาะเจาะจงมากขึ้นเช่นเดียวกับอินสแตนซ์เฉพาะของแอปพลิเคชันนี้ที่ทำงานบนเซิร์ฟเวอร์เฉพาะนี้

กฎจะถูกนำไปใช้ตามลำดับอย่างน้อยที่สุดโดยเฉพาะกับกฎส่วนใหญ่และกฎในภายหลังสามารถแทนที่ค่าที่ระบุในกฎก่อนหน้า นี่หมายถึงตัวอย่างเช่นคุณสามารถสร้างกฎที่ใช้กับแอปพลิเคชันเฉพาะจากนั้นแทนที่ด้วยค่าที่แตกต่างกันสำหรับเครื่องเฉพาะหรืออินสแตนซ์เฉพาะของแอปพลิเคชันเป็นต้น

เซิร์ฟเวอร์มีอินเตอร์เฟส REST + JSON เพื่อให้ทำงานร่วมกับระบบการพัฒนาส่วนใหญ่และยังมีไลบรารีไคลเอ็นต์ที่สะดวกสำหรับแอปพลิเคชัน. Net


1

การตั้งค่าประเภทนี้เป็นฝันร้ายที่ต้องจัดการ มันเป็นการดีที่สุดที่จะลองและลดให้มากที่สุดโดยให้ส่วนประกอบซอฟต์แวร์ของคุณจัดการกับทุกกรณี

เช่นแทนที่จะตั้งค่าเซิร์ฟเวอร์ api สำหรับภูมิภาคส่งผ่านพื้นที่ด้วยการเรียก api และให้การตั้งค่าเซิร์ฟเวอร์เดียวจัดการทุกภูมิภาค

อย่างไรก็ตามเนื่องจากคุณอยู่ในสถานะที่คุณอยู่ฉันจะแนะนำให้ตั้งค่าระบบสำหรับการสร้างการตั้งค่า มันเพิ่มความซับซ้อนให้กับปัญหาที่ซับซ้อนอยู่แล้วเท่านั้น

ให้ตั้งค่าไว้ในเครื่องมือปรับใช้ของคุณตามประเภทเซิร์ฟเวอร์แทน (การตั้งค่าการปรับใช้ปลาหมึกยักษ์, การเขียนไฟล์ teamcity ฯลฯ ) สิ่งนี้ช่วยให้คุณแน่ใจได้ว่าคุณกำลังปรับใช้การตั้งค่าคอนฟิกแบบเดียวกับที่คุณทำเมื่อครั้งล่าสุดเมื่ออัพเกรดซอฟต์แวร์และให้การควบคุมที่เปลี่ยนแปลง

คุณไม่ต้องการที่จะอยู่ในสถานการณ์ที่คุณทำการเปลี่ยนแปลงไฟล์ meta-config ของคุณและจากนั้นต้องทดสอบว่าไฟล์ config ใดที่สร้างขึ้นในภูมิภาค / เซิร์ฟเวอร์ / การจัดกลุ่มแบบกำหนดเองต่างๆ


0

ไม่มีการวิจัย ความเห็นส่วนตัว 30+ ประสบการณ์ไอที ฟังดูเหมือนโครงสร้างข้อมูลที่ซับซ้อนซึ่งสามารถเปลี่ยน / แก้ไขได้อย่างรวดเร็วด้วยผู้ใช้จำนวนมาก

พิจารณาที่เก็บฐานข้อมูล (เช่น. SQL) เพื่อจัดโครงสร้างข้อมูลด้วยกระบวนการแยกแบบกำหนดเองที่สร้างไฟล์กำหนดค่าส่วนบุคคลสำหรับผู้ใช้แต่ละคน คุณสามารถใช้แบบสอบถามของฐานข้อมูลเพื่อพิจารณาผลกระทบของการเปลี่ยนแปลงก่อนนำไปใช้ ค้นหารายการที่ซ้ำกัน ฯลฯ ไฟล์แฟลตเดี่ยวเป็นส่วนหนึ่งของปัญหา รวมทั้งคุณสามารถรับบันทึกการเปลี่ยนแปลงและการกู้คืน / สร้างการสนับสนุน ด้วยการควบคุมฐานข้อมูลคุณอาจสามารถขจัดปัญหาการสืบทอดการกำหนดค่า โซลูชันประเภทนั้นจะต้องใช้โครงสร้างฐานข้อมูลเพิ่มเติม โครงสร้างคีย์คอมโพสิตที่ถูกต้องมีความสำคัญมาก

นั่นคือคำแนะนำของฉัน

คุณอาจพิจารณาถึงความปลอดภัยของระบบผู้ขายที่มีราคาแพงและระบบควบคุมที่ใช้บริการประเภทนี้ พิจารณาพวกเขา โดยทั่วไปจะขึ้นอยู่กับสภาพแวดล้อม

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.