สวัสดีฮับ วันนี้ฉันยังคงเผยแพร่ชุดสิ่งพิมพ์ที่ฉันเขียนโดยเฉพาะสำหรับการเริ่มต้นสตรีมใหม่ของหลักสูตร .
การแนะนำ
การเลือกรูปแบบสถาปัตยกรรมเป็นหนึ่งในการตัดสินใจทางเทคนิคขั้นพื้นฐานเมื่อสร้างระบบข้อมูล ในบทความชุดนี้ ฉันเสนอให้วิเคราะห์รูปแบบสถาปัตยกรรมที่ได้รับความนิยมมากที่สุดสำหรับการสร้างแอปพลิเคชัน และตอบคำถามว่ารูปแบบสถาปัตยกรรมใดที่เหมาะสมที่สุดเมื่อใด ในกระบวนการนำเสนอ ฉันจะพยายามวาดห่วงโซ่เชิงตรรกะที่อธิบายการพัฒนารูปแบบสถาปัตยกรรมตั้งแต่เสาหินไปจนถึงไมโครเซอร์วิส
ครั้งที่แล้วเราได้พูดคุยเกี่ยวกับเสาหินประเภทต่างๆ และการใช้ส่วนประกอบเพื่อสร้างมัน ทั้งส่วนประกอบการสร้างและส่วนประกอบการปรับใช้ เราเข้าใจสถาปัตยกรรมที่มุ่งเน้นการบริการ
ในที่สุดเราก็จะได้กำหนดลักษณะสำคัญของสถาปัตยกรรมไมโครเซอร์วิสแล้ว
ความสัมพันธ์ของสถาปัตยกรรม
มีความจำเป็นต้องเข้าใจว่าตามคำจำกัดความที่ให้ไว้ในบทความก่อนหน้านี้ บริการใดๆ ก็เป็นส่วนประกอบ แต่ไม่ใช่ว่าทุกบริการจะเป็นไมโครเซอร์วิส
ลักษณะของสถาปัตยกรรมไมโครเซอร์วิส
ลักษณะสำคัญของสถาปัตยกรรมไมโครเซอร์วิสคือ:
- จัดโดยคำนึงถึงความสามารถทางธุรกิจ
- สินค้าไม่ใช่โครงการ
- จุดสิ้นสุดอัจฉริยะและท่อใบ้
- การปกครองแบบกระจายอำนาจ
- การจัดการข้อมูลแบบกระจายอำนาจ
- ระบบอัตโนมัติโครงสร้างพื้นฐาน
- การออกแบบเพื่อความล้มเหลว
- สถาปัตยกรรมที่มีการพัฒนาเชิงวิวัฒนาการ (Evolutionary Design)
ประเด็นที่ 1 มาจากสถาปัตยกรรมเชิงบริการ เนื่องจากไมโครเซอร์วิสเป็นบริการพิเศษ ประเด็นอื่นๆ สมควรได้รับการพิจารณาแยกต่างหาก
จัดโดยคำนึงถึงความสามารถทางธุรกิจ
ตอนนี้จำเป็นต้องจำกฎของคอนเวย์: องค์กรที่สร้างระบบจัดสถาปัตยกรรมของตนโดยคัดลอกโครงสร้างปฏิสัมพันธ์ภายในองค์กรเหล่านี้ ตัวอย่างเช่น เราจำกรณีของการสร้างคอมไพเลอร์ได้: ทีมเจ็ดคนพัฒนาคอมไพเลอร์เจ็ดรอบ และทีมห้าคนพัฒนาคอมไพเลอร์ห้ารอบ
หากเรากำลังพูดถึงโมโนลิธและไมโครเซอร์วิส หากการพัฒนาถูกจัดโดยแผนกการทำงาน (แบ็กเอนด์ ฟรอนต์เอนด์ ผู้ดูแลระบบฐานข้อมูล) เราก็จะได้โมโนลิธแบบคลาสสิก
หากต้องการรับไมโครเซอร์วิส ทีมต้องได้รับการจัดระเบียบตามความสามารถทางธุรกิจ (คำสั่งซื้อ การจัดส่ง ทีมงานแค็ตตาล็อก) องค์กรนี้จะช่วยให้ทีมมุ่งเน้นไปที่การสร้างส่วนเฉพาะของแอปพลิเคชัน
สินค้าไม่ใช่โครงการ
แนวทางโครงการที่ทีมถ่ายโอนฟังก์ชันการทำงานที่พัฒนาแล้วไปยังทีมอื่นนั้นไม่เหมาะสมอย่างยิ่งในกรณีของสถาปัตยกรรมไมโครเซอร์วิส ทีมงานจะต้องสนับสนุนระบบตลอดวงจรชีวิต Amazon หนึ่งในผู้นำในการใช้งานไมโครเซอร์วิสกล่าวว่า “คุณสร้าง คุณดำเนินการ” แนวทางผลิตภัณฑ์ช่วยให้ทีมรู้สึกถึงความต้องการของธุรกิจ
จุดสิ้นสุดอัจฉริยะและท่อใบ้
สถาปัตยกรรม SOA ให้ความสำคัญกับช่องทางการสื่อสารเป็นอย่างมาก โดยเฉพาะ Enterprise Service Bus ซึ่งมักนำไปสู่ Erroneous Spaghetti Box นั่นคือความซับซ้อนของเสาหินกลายเป็นความซับซ้อนในการเชื่อมต่อระหว่างบริการต่างๆ สถาปัตยกรรมไมโครเซอร์วิสใช้วิธีการสื่อสารง่ายๆ เท่านั้น
การปกครองแบบกระจายอำนาจ
การตัดสินใจที่สำคัญเกี่ยวกับไมโครเซอร์วิสควรกระทำโดยผู้ที่พัฒนาไมโครเซอร์วิสจริงๆ ในที่นี้ การตัดสินใจที่สำคัญหมายถึงทางเลือกต่างๆ
ภาษาโปรแกรม วิธีการปรับใช้ สัญญาอินเทอร์เฟซสาธารณะ ฯลฯ
การจัดการข้อมูลแบบกระจายอำนาจ
แนวทางมาตรฐานซึ่งแอปพลิเคชันอาศัยฐานข้อมูลเดียว ไม่สามารถคำนึงถึงลักษณะเฉพาะของแต่ละบริการได้ MSA เกี่ยวข้องกับการจัดการข้อมูลแบบกระจายอำนาจ รวมถึงการใช้เทคโนโลยีต่างๆ
ระบบอัตโนมัติโครงสร้างพื้นฐาน
MSA รองรับกระบวนการปรับใช้และส่งมอบอย่างต่อเนื่อง สิ่งนี้สามารถทำได้โดยกระบวนการอัตโนมัติเท่านั้น ในขณะเดียวกัน การปรับใช้บริการจำนวนมากก็ไม่ใช่เรื่องน่ากลัวอีกต่อไป กระบวนการปรับใช้ควรจะน่าเบื่อ ด้านที่สองเกี่ยวข้องกับการจัดการบริการในสภาพแวดล้อมของผลิตภัณฑ์ หากไม่มีระบบอัตโนมัติ การจัดการกระบวนการที่ทำงานในสภาพแวดล้อมการทำงานที่แตกต่างกันจะเป็นไปไม่ได้
การออกแบบเพื่อความล้มเหลว
บริการ MSA จำนวนมากมีแนวโน้มที่จะล้มเหลว ในขณะเดียวกัน การจัดการข้อผิดพลาดในระบบแบบกระจายก็ไม่ใช่เรื่องเล็กน้อย สถาปัตยกรรมแอปพลิเคชันจะต้องยืดหยุ่นต่อความล้มเหลวดังกล่าว Rebecca Parsons คิดว่าเป็นสิ่งสำคัญมากที่เราจะต้องไม่ใช้การสื่อสารระหว่างบริการอีกต่อไป เราใช้ HTTP เพื่อการสื่อสารแทน ซึ่งแทบไม่น่าเชื่อถือเท่าที่ควร
สถาปัตยกรรมที่มีการพัฒนาเชิงวิวัฒนาการ (Evolutionary Design)
สถาปัตยกรรมของระบบ MSA ควรพัฒนาแบบวิวัฒนาการ ขอแนะนำให้จำกัดการเปลี่ยนแปลงที่จำเป็นในขอบเขตของบริการเดียว ต้องคำนึงถึงผลกระทบต่อบริการอื่นด้วย วิธีการดั้งเดิมคือการพยายามแก้ไขปัญหานี้ด้วยการกำหนดเวอร์ชัน แต่ MSA แนะนำให้ใช้การกำหนดเวอร์ชันใน
เป็นทางเลือกสุดท้าย
ข้อสรุป
หลังจากทั้งหมดที่กล่าวมาข้างต้น เราสามารถกำหนดได้ว่าไมโครเซอร์วิสคืออะไร สถาปัตยกรรมไมโครเซอร์วิสเป็นแนวทางในการพัฒนาแอปพลิเคชันเดียวในรูปแบบคอลเลกชันของบริการขนาดเล็ก โดยแต่ละบริการทำงานในกระบวนการของตัวเองและโต้ตอบผ่านกลไกที่ไม่ซับซ้อน ซึ่งมักจะเป็น API ทรัพยากร HTTP บริการเหล่านี้สร้างขึ้นจากความสามารถทางธุรกิจและสามารถนำไปใช้งานได้อย่างอิสระโดยสมบูรณ์
กลไกการปรับใช้อัตโนมัติ มีระดับขั้นต่ำของการจัดการแบบรวมศูนย์ของบริการเหล่านี้ ซึ่งสามารถเขียนในภาษาการเขียนโปรแกรมที่แตกต่างกัน และใช้เทคโนโลยีการจัดเก็บข้อมูลที่แตกต่างกัน
ที่มา: will.com