สวัสดีฮับ. การลงทะเบียนสำหรับสตรีมหลักสูตรใหม่เปิดให้บริการแล้วที่ OTUS . ก่อนเริ่มหลักสูตร ฉันต้องการแบ่งปันบทความต้นฉบับของฉันกับคุณ
การแนะนำ
การเลือกรูปแบบสถาปัตยกรรมเป็นหนึ่งในการตัดสินใจทางเทคนิคขั้นพื้นฐานเมื่อสร้างระบบข้อมูล ในบทความชุดนี้ ฉันเสนอให้วิเคราะห์รูปแบบสถาปัตยกรรมที่ได้รับความนิยมมากที่สุดสำหรับการสร้างแอปพลิเคชัน และตอบคำถามว่ารูปแบบสถาปัตยกรรมใดที่เหมาะสมที่สุดเมื่อใด ในกระบวนการนำเสนอ ฉันจะพยายามวาดห่วงโซ่เชิงตรรกะที่อธิบายการพัฒนารูปแบบสถาปัตยกรรมตั้งแต่เสาหินไปจนถึงไมโครเซอร์วิส
บิตของประวัติศาสตร์
หากคุณพยายามถามนักพัฒนาว่า “ทำไมเราถึงต้องการไมโครเซอร์วิส” คุณจะได้รับคำตอบที่หลากหลาย คุณจะได้ยินว่าไมโครเซอร์วิสปรับปรุงความสามารถในการปรับขนาด ทำให้โค้ดเข้าใจง่ายขึ้น ปรับปรุงความทนทานต่อข้อผิดพลาด และบางครั้งคุณจะได้ยินว่าไมโครเซอร์วิสช่วยให้คุณ "ล้างโค้ดของคุณ" มาดูประวัติเพื่อทำความเข้าใจจุดประสงค์เบื้องหลังการเกิดขึ้นของไมโครเซอร์วิสกันดีกว่า
กล่าวโดยสรุป ไมโครเซอร์วิสในความเข้าใจปัจจุบันของเราเกิดขึ้นดังนี้: ในปี 2011 James Lewis ซึ่งวิเคราะห์งานของบริษัทต่างๆ ได้ดึงความสนใจไปที่การเกิดขึ้นของรูปแบบ "ไมโครแอป" ใหม่ ซึ่งปรับ SOA ให้เหมาะสมในแง่ของการเร่งการใช้งาน บริการ ต่อมาในปี 2012 ที่การประชุมสุดยอดด้านสถาปัตยกรรม รูปแบบดังกล่าวได้เปลี่ยนชื่อเป็นไมโครเซอร์วิส ดังนั้นเป้าหมายเริ่มแรกของการแนะนำไมโครเซอร์วิสคือการปรับปรุงสิ่งที่ฉาวโฉ่ เวลาไปตลาด.
ไมโครเซอร์วิสกำลังได้รับความนิยมในปี 2015 จากการศึกษาบางชิ้น การประชุมเพียงครั้งเดียวจะไม่สมบูรณ์หากไม่มีรายงานเกี่ยวกับหัวข้อไมโครเซอร์วิส นอกจากนี้ การประชุมบางงานก็จัดขึ้นเพื่อไมโครเซอร์วิสโดยเฉพาะ ปัจจุบัน หลายโครงการเริ่มใช้รูปแบบสถาปัตยกรรมนี้ และหากโครงการมีรหัสเดิมจำนวนมาก การย้ายไปยังไมโครเซอร์วิสก็อาจกำลังดำเนินการอย่างจริงจัง
แม้จะมีทั้งหมดที่กล่าวมาข้างต้น แต่มีนักพัฒนาจำนวนค่อนข้างน้อยที่ยังสามารถกำหนดแนวคิดของ “ไมโครเซอร์วิส” ได้ แต่เราจะพูดถึงเรื่องนี้อีกหน่อยในภายหลัง...
เสาหิน
รูปแบบสถาปัตยกรรมที่ตัดกันกับไมโครเซอร์วิสคือรูปแบบโมโนลิธ (หรือออลอินวัน) อาจไม่สมเหตุสมผลที่จะบอกว่าเสาหินคืออะไร ดังนั้นฉันจะแสดงรายการข้อเสียของรูปแบบสถาปัตยกรรมนี้ทันที ซึ่งได้ริเริ่มการพัฒนารูปแบบสถาปัตยกรรมเพิ่มเติม: ขนาด การเชื่อมต่อ การนำไปใช้งาน ความสามารถในการปรับขนาด ความน่าเชื่อถือ และความแข็งแกร่ง ด้านล่างนี้ฉันเสนอให้พิจารณาข้อบกพร่องแต่ละข้อแยกกัน
ขนาด
เสาหินมีขนาดใหญ่มาก และมักจะสื่อสารกับฐานข้อมูลขนาดใหญ่มาก แอปพลิเคชันมีขนาดใหญ่เกินกว่าที่นักพัฒนารายหนึ่งจะเข้าใจเลย เฉพาะผู้ที่ใช้เวลามากกับโค้ดนี้เท่านั้นจึงจะสามารถทำงานได้ดีกับหินใหญ่ก้อนเดียว ในขณะที่ผู้เริ่มต้นจะใช้เวลามากในการพยายามหาหินใหญ่ก้อนเดียว และไม่มีการรับประกันว่าพวกเขาจะเข้าใจได้ โดยปกติแล้ว เมื่อทำงานกับหินใหญ่ก้อนเดียว จะมีผู้อาวุโส "มีเงื่อนไข" บางคนที่รู้จักหินใหญ่ก้อนนี้ไม่มากก็น้อยและเอาชนะมือของนักพัฒนาหน้าใหม่คนอื่นๆ ได้ภายในหนึ่งปีครึ่ง โดยธรรมชาติแล้วผู้อาวุโสที่มีเงื่อนไขดังกล่าวเป็นจุดแห่งความล้มเหลวเพียงจุดเดียวและการจากไปของเขาอาจนำไปสู่ความตายของเสาหินได้
ความเชื่อมโยง
หินใหญ่ก้อนนี้เปรียบเสมือน "ก้อนโคลนก้อนใหญ่" การเปลี่ยนแปลงซึ่งอาจนำไปสู่ผลลัพธ์ที่ไม่อาจคาดเดาได้ เมื่อทำการเปลี่ยนแปลงในที่เดียว คุณสามารถสร้างความเสียหายให้กับเสาหินในอีกที่หนึ่งได้ (แบบเดียวกับที่ “คุณเกาหู *@ หลุดออก”) นี่เป็นเพราะความจริงที่ว่าส่วนประกอบในหินใหญ่ก้อนเดียวมีความซับซ้อนมากและที่สำคัญที่สุดคือความสัมพันธ์ที่ไม่ชัดเจน
การปรับใช้
การปรับใช้เสาหินเนื่องจากความสัมพันธ์ที่ซับซ้อนระหว่างส่วนประกอบต่างๆ จึงเป็นกระบวนการที่ยาวนานและมีพิธีกรรมของตัวเอง พิธีกรรมดังกล่าวมักจะไม่ได้มาตรฐานอย่างสมบูรณ์และส่งต่อ "ด้วยวาจา"
ความสามารถในการปรับขนาด
โมดูลขนาดใหญ่อาจมีความต้องการทรัพยากรที่ขัดแย้งกัน ซึ่งจำเป็นต้องมีการประนีประนอมในแง่ของฮาร์ดแวร์ ลองนึกภาพว่าคุณมีบริการขนาดใหญ่ที่ประกอบด้วยบริการ A และ B บริการ A ต้องการขนาดของฮาร์ดไดรฟ์ และบริการ B ต้องการ RAM ในกรณีนี้ เครื่องที่ติดตั้งเสาหินจะต้องรองรับข้อกำหนดของบริการทั้งสอง หรือคุณจะต้องปิดใช้งานบริการใดบริการหนึ่งโดยไม่ตั้งใจด้วยตนเอง
อีกตัวอย่างหนึ่ง (คลาสสิกกว่า): บริการ A ได้รับความนิยมมากกว่าบริการ B มาก ดังนั้นคุณจึงต้องการให้มี 100 บริการ A และ 10 บริการ B ขอย้ำอีกครั้งว่ามีสองตัวเลือก: เราจะปรับใช้ Monoliths เต็มรูปแบบ 100 รายการ หรือในบางส่วน บริการ B จะต้องปิดการใช้งานด้วยตนเอง
ความเชื่อถือได้
เนื่องจากบริการทั้งหมดตั้งอยู่รวมกัน หากเสาหินพัง บริการทั้งหมดก็จะพังพร้อมกัน ที่จริงแล้วสิ่งนี้อาจไม่เลวร้ายนัก อย่างน้อยก็จะไม่มีความล้มเหลวบางส่วนในระบบแบบกระจาย แต่ในทางกลับกัน เนื่องจากข้อบกพร่องในการใช้งานที่ผู้ใช้ 0.001% ใช้ คุณอาจสูญเสียผู้ใช้ทั้งหมด ของระบบของคุณ
ความเฉื่อย
เนื่องจากขนาดของเสาหินจึงเป็นเรื่องยากที่จะเปลี่ยนมาใช้เทคโนโลยีใหม่ ด้วยเหตุนี้ การรักษาผู้อาวุโสคนเดิมจึงเป็นงานที่แยกจากกัน กลุ่มเทคโนโลยีที่เลือกเมื่อเริ่มต้นโครงการอาจกลายเป็นบล็อกที่ขัดขวางการพัฒนาผลิตภัณฑ์ได้
ข้อสรุป
ครั้งต่อไปเราจะพูดถึงวิธีที่ผู้คนพยายามแก้ไขปัญหาเหล่านี้โดยการย้ายไปยังส่วนประกอบและ SOA
อ่านเพิ่มเติม:
ที่มา: will.com