portunusd
Acuminatus
Cute Docs Roadmap ทวีต
portunusd เป็นเซิร์ฟเวอร์แอปพลิเคชันเครือข่ายที่ได้รับแรงบันดาลใจจาก OpenBSD ของ relayd และ Heirloom Unix inetd มันฟังการเชื่อมต่อเครือข่ายที่เข้ามาส่งต่อข้อมูลที่เข้ามาผ่านประตูอิลลูมอสไปยังแอปพลิเคชันที่ตั้งใจไว้และส่งคืนการตอบกลับในลักษณะที่คล้ายกัน portunusd แผนที่แต่ละพอร์ตที่เชื่อมต่อกับประตูบนระบบไฟล์ที่จัดทำโดยแอปพลิเคชันเป้าหมาย
ลำดับ
ลูกค้าผู้เข้าร่วม
ผู้เข้าร่วม portunusd
ประตูเข้าร่วม
แอปพลิเคชันผู้เข้าร่วม
แอปพลิเคชัน->> ประตู: สร้าง /var/run/app.door
portunusd->> ประตู: เปิด
portunusd->> portunusd: ฟังบนพอร์ต 80
การร้องขอการจัดการแบบวนรอบ
ไคลเอนต์->>+portunusd: ส่งคำขอ http
portunusd->>+แอปพลิเคชัน: ส่งต่อคำขอผ่าน door_call
แอปพลิเคชัน->>-portunusd: ส่งการตอบกลับผ่าน door_return
portunusd->>-ไคลเอนต์: ส่งการตอบกลับ http
จบ
เป้าหมายหลักของ portunusd คือการอำนวยความสะดวกในการปรับขนาดของแอปพลิเคชันแบบเธรดเดี่ยว ภายใต้โมเดล inetd กระบวนการใหม่ถูกสร้างขึ้นเพื่อจัดการทุกคำขอ ด้วยการใช้ประโยชน์จากประตู portunusd สามารถสร้างเธรดใหม่ในกระบวนการแอปพลิเคชันได้ก็ต่อเมื่อมีการทำเครื่องหมายที่สูงขึ้นมาพร้อมกัน มิฉะนั้นเธรดที่มีอยู่จะถูกนำกลับมาใช้ใหม่เพื่อจัดการคำขอที่ตามมา
เราต้องการให้แอปพลิเคชันที่หันหน้าเข้าหาเครือข่ายของเราตามความต้องการของผู้ใช้ เราต้องการลดต้นทุนทรัพยากรของแอปพลิเคชันให้น้อยที่สุดเมื่อไม่ได้ใช้งานและเราต้องการรักษาค่าใช้จ่ายของเราในแง่ของความต้องการ เราต้องการลดระดับที่ผู้พัฒนาแอปพลิเคชันรับผิดชอบการจัดการทรัพยากรและเราต้องการรักษาสภาพแวดล้อมการพัฒนาที่คุ้นเคยของเครื่องมือบรรทัดคำสั่ง Unix
การเลือกรางรถไฟเป็นตัวอย่างแอปพลิเคชันทับทิมเดียวบนรางบนรางสามารถจัดการคำขอของผู้ใช้ทีละครั้ง ไม่สามารถจัดการคำขอได้หลายครั้งพร้อมกันโดยไม่ต้องมีสำเนาหลายสำเนาของแอปพลิเคชันที่อยู่อาศัยในหน่วยความจำ (ในล่ามทับทิมแยกต่างหาก) รุ่นนี้ใช้หน่วยความจำจำนวนมากแม้ว่าจะมีความต้องการของผู้ใช้เพียงเล็กน้อยทำให้เป็นเรื่องยากสำหรับโฮสต์ในการเรียกใช้เวิร์กโหลดอื่น ๆ การเพจและการทำดิสก์จำนวนมากจะเกิดขึ้น
สภาพแวดล้อมเช่น node.js จัดการกับปัญหานี้โดยการทำให้อะซินโครนิกโปร่งใสมากขึ้นกับโปรแกรมเมอร์ ในขณะที่มันจะเป็นประโยชน์ในการโอบกอดธรรมชาติแบบอะซิงโครนัสของคอมพิวเตอร์ แต่ก็ยังแนะนำการเปลี่ยนแปลงภาษาที่สนับสนุน นี่ไม่ใช่การเปลี่ยนแปลงของไวยากรณ์เพียงอย่างเดียว แต่ยังเป็นการเปลี่ยนแปลงที่ไม่น่าสนใจสำหรับโมเดลจิตที่ใช้ในการอ่านเขียนและเข้าใจโปรแกรม
ที่ปลายอีกด้านของสเปกตรัมแอปพลิเคชัน CGI ต้องการกระบวนการที่ไม่ซ้ำกันและพื้นที่ที่อยู่สำหรับแต่ละคำขอ แอปพลิเคชันเหล่านี้สามารถปรับขนาดเป็นเส้นตรงตามความต้องการของผู้ใช้รวมถึงการปรับขนาดให้เป็นศูนย์หน่วยความจำ / CPU เมื่อใช้งานไม่ได้ใช้งาน แต่ค่าใช้จ่ายของการเรียกใช้ execv(2) สำหรับแต่ละคำขอสามารถขัดขวางปริมาณงาน
วิธีการโพสต์โมเดิร์น "Serverless" เป็นไปตามเกณฑ์เหล่านี้ แต่ด้วยค่าใช้จ่ายใน การละทิ้ง Sytem ปฏิบัติการ มันเป็นวิธีการที่ไม่คุ้นเคยอย่างมากในการพัฒนาซอฟต์แวร์และทิ้งเครื่องมือมากมายที่สามารถใช้ในการสังเกตและดีบักแอปพลิเคชันที่รันไทม์
ประตูเปิดใช้งานรูปแบบใหม่ (เก่า?) ของการพัฒนาแอปพลิเคชันเครือข่ายที่นักพัฒนามีหน้าที่รับผิดชอบในการรักษาและทำความเข้าใจกับงานเชิงเส้นแบบซิงโครนัสในขณะที่ระบบปฏิบัติการ + เว็บเซิร์ฟเวอร์ทำงานร่วมกันในปัญหาการปรับขนาด
คุณสมบัติเหล่านี้ช่วยให้เราสามารถระบุคำสั่งปัญหาของเราได้โดยการพัฒนาแอปพลิเคชันเครือข่ายที่รู้สึกเหมือนเครื่องมือบรรทัดคำสั่ง Unix แบบเธรดเดี่ยวนำเสนอค่าใช้จ่ายน้อยที่สุดเมื่อไม่ได้ใช้งานและปรับขนาดเป็นเส้นตรงบนความละเอียดต่อการตอบสนอง
แน่นอนว่าประตูเพียงอย่างเดียวจะไม่จัดการกับการปรับขนาดข้ามขอบเขตของอินสแตนซ์ของระบบปฏิบัติการเดียว แต่การทำงานร่วมกันในสไตล์รีเลย์กับไฟร์วอลล์สามารถอำนวยความสะดวกนี้ได้ นี่คือที่มาของ portunusd
ภาพตัวอย่างโซเชียลมีเดียคือ Loudon Dodd - งานของตัวเอง, CC BY -SA 3.0
คำถาม Illumos / Rust / Doors ที่คลุมเครือจำนวนมากได้รับคำตอบโดย @jasonbking
