ไมโครเซอร์วิสระยะสุดท้าย

ฉันอ่านเกี่ยวกับความพยายามของทีม Amazon Prime Video ในการขยายขนาดและลดต้นทุนลง 90%ด้วยการรวมไมโครเซอร์วิสเข้าด้วยกันเป็นก้อนเดียว แม้ว่าฉันแน่ใจว่ามีเรื่องราวมากกว่านี้ แต่ก็มีเรื่องราวที่คล้ายกัน เผยแพร่ทางอินเทอร์เน็ต เป็นการโต้แย้งความนิยมของไมโครเซอร์วิสในทศวรรษที่ผ่านมา

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

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

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

เราต้องคำนึงถึงความซับซ้อนของงานที่ถ่ายโอนไปยังทีมที่เป็นเจ้าของบริการขนาดเล็กและระบบนิเวศที่กว้างขึ้น ตรงกันข้ามกับเสาหินเดี่ยวหรือจำนวนน้อย งานที่ถ่ายจะขึ้นอยู่กับความสมบูรณ์ของกองเทคโนโลยีขององค์กร แต่อาจรวมถึง:

กระจายความรับผิดชอบในการดำเนินงานและค่าใช้จ่ายระหว่างทีมที่เป็นเจ้าของบริการทั้งหมด

• ความเข้าใจและการกำหนดค่าส่วนประกอบโครงสร้างพื้นฐานของบริการจากการจัดตารางงานและเครื่องมือการปรับใช้ การค้นพบบริการ กรอบ RPC, VM และการปรับแต่งที่เกี่ยวข้อง การตรวจสอบบริการและการบันทึก
• คำจำกัดความแบบกระจายและกระบวนการพัฒนาสำหรับ SLO และ SLI ความล้มเหลวของบริการและการจัดการข้อบกพร่อง การจัดการแรงดันย้อนกลับและการส่งสัญญาณข้อผิดพลาด
• การวางแผนกำลังการผลิตแบบกระจายและมักไม่สอดคล้องกัน การทดสอบโหลด การดำเนินการทดสอบการรวมระบบและความรับผิดชอบ

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

• แนวทางที่แปลเป็นภาษาท้องถิ่นเพื่อแก้ปัญหาการอนุมานและการจัดอันดับ การประมวลผลเหตุการณ์ การแปล HTTP/โปรโตคอลภายใน API และการแมปแบบจำลองข้อมูล
• การแยกส่วนทั่วไปและการรักษามาตรฐานทั่วทั้งสแต็กอย่างยากลำบาก

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

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

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

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

พบการใช้ประโยชน์จาก Microservice ที่ชั้นการประมวลผล (ไม่ว่าจะเป็นการจัดเตรียมและเรียกใช้งานงานบริการหรือคอนเทนเนอร์), การค้นหาบริการ, VM (ใช้ได้ในบางบริบท) กรอบงานบริการ (เช่นgRPC , FinagleหรือRest.Li ) และเครื่องมือสำหรับนักพัฒนาแบบรวมศูนย์ แน่นอนตาข่ายบริการสรุปข้อกังวลเหล่านี้ได้อย่างดี

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

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

บางสิ่งที่ควรทราบโดยเฉพาะอย่างยิ่งหากคุณทำงานกับ microlith รุ่นเก่า:

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