เมื่อพัฒนาระบบด้วยตัวเองฉันควรใช้ microservices หรือไม่

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

คำถามของฉันคือฉันควรใช้วิธีไมโครไซต์เพื่อพยายามทำสิ่งนี้หรือใช้แอพพลิเคชั่นแบบเสาหินเนื่องจากฉันจะทำการพัฒนาส่วนใหญ่ด้วยตัวเอง ความคิดของฉันคือ microservices (โดยใช้ Nameko) ให้การแยกโดยธรรมชาติระหว่างองค์ประกอบของกรอบงานที่มีรูปแบบการดำเนินการที่แตกต่างกัน (ไปป์ไลน์ข้อมูล, กิจกรรมที่เปิดตัว, ตามคำขอ, เว็บแอปพลิเคชั่น ฯลฯ ) และวิธีที่ชัดเจน การสื่อสารข้ามหลายกระบวนการ ความกังวลของฉันคือฉันอาจท้ายด้วยกลุ่ม Kubernetes เพื่อจัดการ (ฉันคุ้นเคยกับ Docker แต่ยังค่อนข้างใหม่กับ Kubernetes), บริการหลายอย่าง (rabbitmq, redis และอื่น ๆ ) ที่จำเป็นเพียงเพื่ออำนวยความสะดวกในการใช้งานระบบ และอาจมีโค้ดขนาดเล็กจำนวนมากที่จะใช้ความสามารถที่จำเป็นทั้งหมดที่เรามีอยู่จริง

สำหรับโครงการที่มีผู้พัฒนามากกว่าหนึ่งรายเล็กน้อย microservices ยังทำให้การพัฒนาและบำรุงรักษาระบบที่ซับซ้อนเช่นนี้ง่ายขึ้นหรือไม่? มีวิธีการ / ระบบ / กรอบฉันควรพิจารณาใช้แทนหรือเพื่อลดค่าใช้จ่ายที่เกี่ยวข้องในการออกแบบระบบด้วยวิธีนี้หรือไม่

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

• บริการต่าง ๆ สามารถพัฒนาและปรับใช้อย่างอิสระโดยทีมงานที่แตกต่างกัน
• บริการที่แตกต่างสามารถปรับสัดส่วนได้อย่างอิสระ

เนื่องจากคุณจะเป็นผู้พัฒนาเพียงผู้เดียวคุณไม่ต้องการความยืดหยุ่นในการพัฒนาบริการอย่างอิสระ

แต่คุณทราบว่าบางส่วนอาจถูกผูกไว้กับ CPU ดังนั้นจึงอาจเป็นที่พึงประสงค์ในการปรับขนาดเหล่านั้นแยกจากส่วนที่เหลือของแอปพลิเคชัน หากเป็นกรณีนี้ไม่ได้หมายความว่าคุณจะต้องเปลี่ยนโครงการทั้งหมดเป็นสถาปัตยกรรมบริการไมโคร คุณจะต้องย้ายส่วนที่ใช้ CPU มาก ๆ ไปไว้ในบริการของตัวเองเท่านั้น ตามแนวที่ระบบควรจะแยกเป็นเรื่องยากที่จะบอก แต่โดยทั่วไปความคิด DDD ของ "บริบทบริบท" เป็นแนวทางที่ดี

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

พิจารณาแนวคิดของ Martin Fowler เกี่ยวกับMicroservice Premium (2015): microservices นำเสนอความซับซ้อนที่สำคัญของพวกเขาเองนอกเหนือจากความซับซ้อนพื้นฐานของระบบของคุณ คุณต้องจ่าย "พรีเมี่ยม" นี้ในแง่ของประสิทธิภาพที่ลดลง ซึ่งหมายความว่าสำหรับโครงการที่เรียบง่ายบริการไมโครทำให้คุณมีประสิทธิภาพลดลง การเปลี่ยนแปลงนี้สำหรับโครงการที่ซับซ้อนมากขึ้น: ในขณะที่วิธีการแก้ปัญหาแบบเสาหินอาจกลายเป็นเรื่องยากที่จะทำงานกับสถาปัตยกรรม microservice ปรับขนาดได้ดีขึ้นมากและต้องใช้ความพยายามอย่างต่อเนื่อง คุณต้องรู้ว่าความพยายามเริ่มต้นพิเศษของบริการไมโครซอฟท์นั้นคุ้มค่ากับระบบซอฟต์แวร์ของคุณหรือไม่ เมื่อคุณถามคำถามนี้คำตอบน่าจะเป็น "ไม่" ฟาวเลอร์พูดต่อ:

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