สวัสดีฮับ วันนี้ฉันยังคงเผยแพร่ชุดสิ่งพิมพ์ที่ฉันเขียนโดยเฉพาะสำหรับการเริ่มต้นสตรีมใหม่ของหลักสูตร .
การแนะนำ
การเลือกรูปแบบสถาปัตยกรรมเป็นหนึ่งในการตัดสินใจทางเทคนิคขั้นพื้นฐานเมื่อสร้างระบบข้อมูล ในบทความชุดนี้ ฉันเสนอให้วิเคราะห์รูปแบบสถาปัตยกรรมที่ได้รับความนิยมมากที่สุดสำหรับการสร้างแอปพลิเคชัน และตอบคำถามว่ารูปแบบสถาปัตยกรรมใดที่เหมาะสมที่สุดเมื่อใด ในกระบวนการนำเสนอ ฉันจะพยายามวาดห่วงโซ่เชิงตรรกะที่อธิบายการพัฒนารูปแบบสถาปัตยกรรมตั้งแต่เสาหินไปจนถึงไมโครเซอร์วิส
В เราจัดการกับ Monolith และได้ข้อสรุปว่า Monolith มีปัญหาหลายประการ เช่น ขนาด การเชื่อมต่อ การใช้งาน ความสามารถในการปรับขนาด ความน่าเชื่อถือ และความแข็งแกร่ง
ครั้งนี้ ฉันขอเสนอให้พูดถึงความเป็นไปได้ในการจัดระบบเป็นชุดของโมดูล/ไลบรารี (สถาปัตยกรรมเชิงส่วนประกอบ) หรือบริการ (สถาปัตยกรรมเชิงบริการ)
สถาปัตยกรรมเชิงส่วนประกอบ
สถาปัตยกรรมเชิงส่วนประกอบเกี่ยวข้องกับการดำเนินการระบบเป็นชุดส่วนประกอบที่สามารถใช้ได้ทั้งในโครงการปัจจุบันและอนาคต เมื่อแบ่งระบบออกเป็นส่วนประกอบต่างๆ จะต้องคำนึงถึงสิ่งต่อไปนี้: การนำกลับมาใช้ใหม่ได้ ความสามารถในการเปลี่ยนได้ ความเป็นอิสระของบริบท ความสามารถในการขยาย การห่อหุ้ม และความเป็นอิสระ
ด้วยการใช้ส่วนประกอบอย่างเหมาะสม ปัญหาของ “สิ่งสกปรกก้อนใหญ่” (ขนาดใหญ่ + ข้อต่อสูง) จะได้รับการแก้ไข และส่วนประกอบต่างๆ เองก็สามารถเป็นได้ทั้งหน่วยประกอบ (โมดูล ไลบรารี) และหน่วยปรับใช้ (บริการ) หน่วยการปรับใช้งานไม่ได้ถูกแม็ปกับกระบวนการที่ทำงานอยู่เสมอไป ตัวอย่างเช่น เว็บแอปพลิเคชันและฐานข้อมูลจะถูกปรับใช้ร่วมกัน
ส่วนใหญ่แล้วเสาหินจะได้รับการพัฒนาเป็นชุดโมดูล แนวทางนี้นำไปสู่การพัฒนาอย่างอิสระ แต่ปัญหาของการปรับขนาดและการปรับใช้ที่เป็นอิสระ ความทนทานต่อข้อผิดพลาด และความเป็นอิสระจากกลุ่มเทคโนโลยีโดยรวมยังคงอยู่ นั่นคือสาเหตุที่โมดูลนี้เป็นส่วนประกอบอิสระบางส่วน
ปัญหาที่ใหญ่ที่สุดของเสาหินดังกล่าวคือการแบ่งออกเป็นโมดูลนั้นเป็นไปตามตรรกะล้วนๆ และนักพัฒนาสามารถแตกแยกได้ง่าย โมดูลหลักอาจปรากฏขึ้น ซึ่งค่อยๆ กลายเป็นที่ทิ้งขยะ กราฟของการพึ่งพาระหว่างโมดูลอาจเพิ่มขึ้น และอื่นๆ เพื่อหลีกเลี่ยงปัญหาดังกล่าว การพัฒนาควรดำเนินการโดยทีมงานที่เป็นผู้ใหญ่มาก หรือภายใต้คำแนะนำของ “สถาปนิก” ที่มีส่วนร่วมในการตรวจสอบโค้ดเต็มเวลา และเอาชนะมือของนักพัฒนาที่ละเมิดโครงสร้างเชิงตรรกะ
เสาหิน "อุดมคติ" คือชุดของโมดูลที่แยกออกจากกันตามตรรกะ ซึ่งแต่ละโมดูลจะพิจารณาในฐานข้อมูลของตัวเอง
สถาปัตยกรรมเชิงบริการ
หากระบบควรจะจัดในรูปแบบของชุดบริการ เรากำลังพูดถึงสถาปัตยกรรมที่มุ่งเน้นบริการ หลักการของมันคือการทำงานร่วมกันของแอปพลิเคชันโดยเน้นผู้ใช้เป็นศูนย์กลาง การใช้บริการทางธุรกิจซ้ำ ความเป็นอิสระของสแต็กเทคโนโลยี และความเป็นอิสระ (วิวัฒนาการที่เป็นอิสระ ความสามารถในการปรับขนาด และการปรับใช้)
สถาปัตยกรรมเชิงบริการ (SOA = สถาปัตยกรรมเชิงบริการ) แก้ปัญหาที่ระบุทั้งหมดของเสาหิน: มีเพียงบริการเดียวเท่านั้นที่ได้รับผลกระทบเมื่อมีการเปลี่ยนแปลงเกิดขึ้น และ API ที่กำหนดไว้อย่างดีรองรับการห่อหุ้มส่วนประกอบที่ดี
แต่ไม่ใช่ทุกอย่างจะราบรื่นนัก SOA สร้างปัญหาใหม่ การโทรระยะไกลมีราคาแพงกว่าการโทรในพื้นที่ และการแบ่งความรับผิดชอบระหว่างส่วนประกอบต่างๆ มีราคาแพงกว่ามาก
อย่างไรก็ตาม ความเป็นไปได้ของการปรับใช้แบบอิสระถือเป็นคุณสมบัติที่สำคัญมากของบริการ หากบริการต้องถูกปรับใช้ร่วมกันหรือยิ่งไปกว่านั้นในลำดับที่แน่นอน ระบบจะไม่ถือว่ามุ่งเน้นการบริการ ในกรณีนี้ พวกเขาพูดถึงเสาหินแบบกระจาย (ถือเป็นรูปแบบการต่อต้านไม่เพียงแต่จากมุมมองของ SOA แต่ยังมาจากมุมมองของสถาปัตยกรรมไมโครเซอร์วิสด้วย)
สถาปัตยกรรมเชิงบริการได้รับการสนับสนุนอย่างดีจากชุมชนสถาปัตยกรรมและผู้ขาย นี่แสดงถึงการมีอยู่ของหลักสูตรและการรับรองมากมาย รูปแบบที่ได้รับการพัฒนาอย่างดี อย่างหลังนี้รวมถึง ตัวอย่างเช่น บัสบริการระดับองค์กรที่มีชื่อเสียง (ESB = บัสบริการระดับองค์กร) ในขณะเดียวกัน ESB ก็เป็นสัมภาระจากผู้ขาย โดยไม่จำเป็นต้องใช้ใน SOA
ความนิยมของสถาปัตยกรรมเชิงบริการถึงจุดสูงสุดในปี 2008 หลังจากนั้นก็เริ่มลดลง ซึ่งกลายเป็นเรื่องที่น่าทึ่งมากขึ้นหลังจากการถือกำเนิดของไมโครเซอร์วิส (~ 2015)
ข้อสรุป
หลังจากที่เราได้พูดคุยถึงความเป็นไปได้ของการจัดระบบข้อมูลในรูปแบบของบริการและโมดูลแล้ว ฉันขอเสนอให้ไปที่หลักการของสถาปัตยกรรมไมโครเซอร์วิสในที่สุด และให้ความสนใจเป็นพิเศษกับความแตกต่างระหว่างสถาปัตยกรรมไมโครเซอร์วิสและสถาปัตยกรรมที่มุ่งเน้นบริการในส่วนถัดไป
ที่มา: will.com