ไมโครเซอร์วิส: คืออะไร ทำไมจึงเป็นเช่นนั้น และเมื่อใดจึงควรนำไปใช้

ฉันอยากจะเขียนบทความเกี่ยวกับหัวข้อสถาปัตยกรรมไมโครเซอร์วิสมาเป็นเวลานาน แต่มีสองสิ่งที่ทำให้ฉันหยุดอยู่ - ยิ่งฉันกระโจนเข้าสู่หัวข้อนี้มากเท่าไหร่ สำหรับฉันก็ยิ่งดูเหมือนว่าสิ่งที่ฉันรู้นั้นชัดเจน และสิ่งที่ฉันไม่รู้' ไม่รู้ก็ต้องศึกษาและศึกษา ในทางกลับกัน ฉันคิดว่ามีเรื่องที่ต้องพูดคุยกันในหมู่ผู้ชมในวงกว้างอยู่แล้ว ดังนั้นจึงยินดีรับความคิดเห็นอื่น

กฎของคอนเวย์กับความสัมพันธ์ระหว่างธุรกิจ องค์กร และระบบสารสนเทศ

ฉันจะอนุญาตให้ตัวเองพูดอีกครั้ง:

“องค์กรใดๆ ที่ออกแบบระบบ (ในความหมายกว้างๆ) จะได้รับการออกแบบที่มีโครงสร้างที่จำลองโครงสร้างของทีมในองค์กรนั้น”
— เมลวิน คอนเวย์, 1967

ในความคิดของฉันกฎหมายนี้มีแนวโน้มที่จะเกี่ยวข้องกับความเป็นไปได้ในการจัดระเบียบธุรกิจมากกว่าที่จะเกี่ยวข้องกับระบบข้อมูลโดยตรง ให้ฉันอธิบายด้วยตัวอย่าง สมมติว่าเรามีโอกาสทางธุรกิจที่ค่อนข้างมั่นคงโดยมีวงจรชีวิตที่ยาวจนสมเหตุสมผลในการจัดระเบียบองค์กร (นี่ไม่ใช่การพิมพ์ผิด แต่ฉันชอบคำนี้ที่ฉันขโมยมามาก) โดยธรรมชาติแล้วระบบสนับสนุนของธุรกิจนี้ จะสอดคล้องกับธุรกิจนี้ทั้งในระดับองค์กรและกระบวนการ

การวางแนวธุรกิจระบบสารสนเทศ

ให้ฉันอธิบายด้วยตัวอย่าง สมมติว่ามีโอกาสทางธุรกิจในการจัดตั้งธุรกิจขายพิซซ่า ในเวอร์ชัน V1 (ขอเรียกว่าข้อมูลล่วงหน้า) บริษัทคือร้านพิซซ่า เครื่องบันทึกเงินสด และบริการจัดส่ง เวอร์ชันนี้มีอายุการใช้งานยาวนานในสภาวะที่มีความแปรปรวนของสภาพแวดล้อมต่ำ จากนั้นเวอร์ชัน 2 ก็เข้ามาแทนที่ - ล้ำหน้ากว่าและสามารถใช้ระบบข้อมูลเป็นแกนหลักสำหรับธุรกิจด้วยสถาปัตยกรรมแบบเสาหิน และในความคิดของฉันมีความอยุติธรรมอย่างมากเกี่ยวกับเสาหิน - สถาปัตยกรรมเสาหินที่ถูกกล่าวหาว่าไม่สอดคล้องกับรูปแบบธุรกิจของโดเมน. ใช่ หากเป็นเช่นนั้น ระบบจะไม่สามารถทำงานได้เลย ซึ่งขัดแย้งกับกฎของคอนเวย์และสามัญสำนึกเดียวกัน ไม่ สถาปัตยกรรมเสาหินมีความสอดคล้องกับรูปแบบธุรกิจในขั้นตอนของการพัฒนาธุรกิจนี้อย่างสมบูรณ์ - แน่นอนว่าฉันหมายถึงขั้นตอนที่ระบบได้ถูกสร้างขึ้นและนำไปใช้งานแล้ว เป็นข้อเท็จจริงที่ยอดเยี่ยมอย่างยิ่งว่า ไม่ว่าสถาปัตยกรรมจะเป็นอย่างไร ทั้งสถาปัตยกรรมเชิงบริการเวอร์ชัน 3 และสถาปัตยกรรมไมโครเซอร์วิสเวอร์ชัน N จะทำงานได้ดีพอๆ กัน จับอะไร?

ทุกอย่างลื่นไหล ทุกอย่างเปลี่ยนแปลง หรือไมโครเซอร์วิสเป็นเครื่องมือในการต่อสู้กับความซับซ้อนหรือไม่?

ก่อนที่เราจะดำเนินการต่อไป เรามาดูความเข้าใจผิดบางประการเกี่ยวกับสถาปัตยกรรมไมโครเซอร์วิสกันก่อน

ผู้เสนอแนวทางการใช้ไมโครเซอร์วิสมักโต้แย้งว่าการแบ่งส่วนสำคัญออกเป็นไมโครเซอร์วิสช่วยลดความยุ่งยากในแนวทางการพัฒนาโดยการลดฐานรหัสของแต่ละบริการ ในความเห็นของฉัน ข้อความนี้ถือเป็นเรื่องไร้สาระโดยสมบูรณ์ จริงๆ แล้วการโต้ตอบที่ชัดเจนภายในโค้ดขนาดใหญ่และเป็นเนื้อเดียวกันนั้นดูซับซ้อนใช่ไหม หากเป็นกรณีนี้จริงๆ ในตอนแรกโปรเจ็กต์ทั้งหมดจะถูกสร้างขึ้นเป็นไมโครเซอร์วิส ในขณะที่การปฏิบัติจริงแสดงให้เห็นว่าการย้ายจากโมโนลิธไปสู่ไมโครเซอร์วิสนั้นเป็นเรื่องปกติมากกว่ามาก ความซับซ้อนไม่ได้หายไป เพียงแต่ย้ายจากแต่ละโมดูลไปยังอินเทอร์เฟซ (ไม่ว่าจะเป็นบัสข้อมูล, RPC, API และโปรโตคอลอื่นๆ) และระบบการจัดการ และนี่เป็นเรื่องยาก!

ข้อดีของการใช้สแต็กที่ต่างกันก็เป็นที่น่าสงสัยเช่นกัน ฉันจะไม่โต้แย้งว่าสิ่งนี้เป็นไปได้เช่นกัน แต่ในความเป็นจริงมันไม่ค่อยเกิดขึ้น (มองไปข้างหน้า - สิ่งนี้ควรเกิดขึ้น - แต่เป็นผลที่ตามมามากกว่าข้อได้เปรียบ)

วงจรชีวิตผลิตภัณฑ์และวงจรชีวิตการบริการ

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

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

ไมโครเซอร์วิสเป็นวิธีการต่อสู้กับความซับซ้อน... การจัดการการกำหนดค่า

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

ผลการวิจัย

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

ที่มา: will.com