Josh Evans พูดถึงโลกที่วุ่นวายและเต็มไปด้วยสีสันของไมโครเซอร์วิสของ Netflix โดยเริ่มจากพื้นฐานเบื้องต้น นั่นคือ กายวิภาคของไมโครเซอร์วิส ความท้าทายที่เกี่ยวข้องกับระบบแบบกระจาย และคุณประโยชน์ต่างๆ จากรากฐานนี้ เขาสำรวจแนวทางปฏิบัติทางวัฒนธรรม สถาปัตยกรรม และการปฏิบัติงานที่นำไปสู่ความเชี่ยวชาญด้านไมโครเซอร์วิส
แตกต่างจากการดำเนินงานดริฟท์ การแนะนำภาษาใหม่สำหรับการบริการที่เป็นสากลและเทคโนโลยีใหม่ เช่น ตู้คอนเทนเนอร์ เป็นการตัดสินใจอย่างมีสติเพื่อเพิ่มความซับซ้อนใหม่ให้กับสิ่งแวดล้อม ทีมปฏิบัติการของฉันสร้างมาตรฐานตามแผนงานด้านเทคโนโลยีที่ดีที่สุดสำหรับ Netflix ซึ่งรวมเข้ากับแนวทางปฏิบัติที่ดีที่สุดที่กำหนดไว้ล่วงหน้าโดยอิงตาม Java และ EC2 แต่เมื่อธุรกิจเติบโตขึ้น นักพัฒนาก็เริ่มเพิ่มส่วนประกอบใหม่ เช่น Python, Ruby, Node-JS และ Docker
ฉันภูมิใจมากที่เราเป็นคนแรกที่สนับสนุนให้ผลิตภัณฑ์ของเราทำงานได้ดีโดยไม่ต้องรอการร้องเรียนจากลูกค้า ทุกอย่างเริ่มต้นอย่างเรียบง่ายเพียงพอ - เรามีโปรแกรมปฏิบัติการใน Python และแอปพลิเคชัน back-office บางส่วนใน Ruby แต่สิ่งต่างๆ มีความน่าสนใจมากขึ้นเมื่อนักพัฒนาเว็บของเราประกาศว่าพวกเขาจะทิ้ง JVM และกำลังจะย้ายเว็บ แอปพลิเคชันบนแพลตฟอร์มซอฟต์แวร์ Node.js หลังจากการเปิดตัว Docker สิ่งต่างๆ ก็มีความซับซ้อนมากขึ้น เราปฏิบัติตามตรรกะและเทคโนโลยีที่เราคิดขึ้นมาก็กลายเป็นความจริงเมื่อเรานำเทคโนโลยีเหล่านั้นมาใช้กับลูกค้า เพราะมันสมเหตุสมผลมาก ฉันจะบอกคุณว่าทำไมถึงเป็นเช่นนั้น
API Gateway มีความสามารถในการรวมสคริปต์ที่ยอดเยี่ยมซึ่งสามารถทำหน้าที่เป็นจุดสิ้นสุดสำหรับนักพัฒนา UI ได้ พวกเขาแปลงสคริปต์แต่ละรายการในลักษณะที่หลังจากทำการเปลี่ยนแปลงแล้ว พวกเขาสามารถนำสคริปต์เหล่านั้นไปใช้กับการใช้งานจริงและจากนั้นไปยังอุปกรณ์ของผู้ใช้ได้ และการเปลี่ยนแปลงทั้งหมดนี้ซิงโครไนซ์กับตำแหน่งข้อมูลที่ทำงานในเกตเวย์ API
อย่างไรก็ตาม สิ่งนี้ทำให้เกิดปัญหาซ้ำซากในการสร้างเสาหินใหม่ที่บริการ API มีโค้ดมากเกินไปในลักษณะที่ทำให้เกิดสถานการณ์ความล้มเหลวต่างๆ ตัวอย่างเช่น ตำแหน่งข้อมูลบางส่วนถูกลบออก หรือสคริปต์สร้างบางสิ่งแบบสุ่มหลายเวอร์ชันจนเวอร์ชันนั้นใช้หน่วยความจำที่มีอยู่ทั้งหมดของบริการ API
การนำตำแหน่งข้อมูลเหล่านี้และดึงออกจากบริการ API เป็นเรื่องที่สมเหตุสมผล เพื่อทำเช่นนี้ เราได้สร้างส่วนประกอบ Node.js ที่ทำงานเป็นแอปพลิเคชันขนาดเล็กในคอนเทนเนอร์ Docker สิ่งนี้ทำให้เราสามารถแยกปัญหาและข้อขัดข้องที่เกิดจากแอปพลิเคชันโหนดเหล่านี้ได้
ค่าใช้จ่ายของการเปลี่ยนแปลงเหล่านี้ค่อนข้างมากและประกอบด้วยปัจจัยต่อไปนี้:
- เครื่องมือเพิ่มประสิทธิภาพการทำงาน การจัดการเทคโนโลยีใหม่จำเป็นต้องมีเครื่องมือใหม่ เนื่องจากทีม UI ซึ่งใช้สคริปต์ที่ดีมากในการสร้างแบบจำลองที่มีประสิทธิภาพ ไม่ต้องใช้เวลาในการจัดการโครงสร้างพื้นฐานมากนัก พวกเขาเพียงเขียนสคริปต์และตรวจสอบฟังก์ชันการทำงานเท่านั้น
ข้อมูลเชิงลึกและการเรียงลำดับโอกาส - ตัวอย่างสำคัญคือเครื่องมือใหม่ที่จำเป็นในการเปิดเผยข้อมูลตัวขับเคลื่อนประสิทธิภาพ จำเป็นต้องทราบว่าโปรเซสเซอร์ใช้งานไปเท่าใด หน่วยความจำถูกใช้อย่างไร และการรวบรวมข้อมูลนี้จำเป็นต้องใช้เครื่องมือที่แตกต่างกัน - การกระจายตัวของอิมเมจฐาน - AMI พื้นฐานแบบธรรมดามีการแยกส่วนและเชี่ยวชาญมากขึ้น
- การจัดการโหนด ไม่มีสถาปัตยกรรมหรือเทคโนโลยีที่มีจำหน่ายทั่วไปที่ช่วยให้คุณจัดการโหนดในระบบคลาวด์ได้ เราจึงสร้าง Titus ซึ่งเป็นแพลตฟอร์มการจัดการคอนเทนเนอร์ที่ให้การปรับใช้งานคอนเทนเนอร์ที่ปรับขนาดได้และเชื่อถือได้ และการผสานรวมระบบคลาวด์กับ Amazon AWS
- การทำสำเนาห้องสมุดหรือแพลตฟอร์ม การจัดหาเทคโนโลยีใหม่ที่มีฟังก์ชันการทำงานหลักแบบเดียวกันของแพลตฟอร์ม จำเป็นต้องทำซ้ำลงในเครื่องมือสำหรับนักพัฒนา Node.js บนคลาวด์
- เส้นโค้งการเรียนรู้และประสบการณ์ทางอุตสาหกรรม การแนะนำเทคโนโลยีใหม่ย่อมสร้างความท้าทายใหม่ ๆ ที่ต้องเอาชนะและเรียนรู้จากมันอย่างหลีกเลี่ยงไม่ได้
ดังนั้นเราจึงไม่สามารถจำกัดตัวเองอยู่เพียง “ถนนลาดยาง” เพียงเส้นเดียวได้ และต้องสร้างวิธีการใหม่ๆ เพื่อพัฒนาเทคโนโลยีของเราอย่างต่อเนื่อง เพื่อลดต้นทุน เราได้จำกัดการสนับสนุนแบบรวมศูนย์และมุ่งเน้นไปที่ JVM, โหนดใหม่ และ Docker เราจัดลำดับความสำคัญของผลกระทบที่มีประสิทธิผล แจ้งทีมเกี่ยวกับต้นทุนในการตัดสินใจ และสนับสนุนให้พวกเขามองหาวิธีนำโซลูชันที่มีผลกระทบสูงที่พวกเขาได้พัฒนาไปแล้วไปใช้ซ้ำ เราใช้วิธีนี้ในการแปลบริการเป็นภาษาต่างประเทศเพื่อส่งมอบผลิตภัณฑ์ให้กับลูกค้าต่างประเทศ ตัวอย่างได้แก่ ไลบรารีไคลเอ็นต์ที่ค่อนข้างเรียบง่ายที่สามารถสร้างได้โดยอัตโนมัติ ดังนั้นจึงค่อนข้างง่ายที่จะสร้างเวอร์ชัน Python, เวอร์ชัน Ruby, เวอร์ชัน Java ฯลฯ
เรามองหาโอกาสในการใช้เทคโนโลยีที่ได้รับการพิสูจน์แล้วซึ่งพิสูจน์ตัวเองในที่เดียวและในสถานการณ์อื่นที่คล้ายคลึงกันอย่างต่อเนื่อง
เรามาพูดถึงองค์ประกอบสุดท้าย - การเปลี่ยนแปลงหรือรูปแบบต่างๆ ดูว่าการบริโภคผลิตภัณฑ์ของเราแตกต่างกันอย่างไม่สม่ำเสมอตามวันในสัปดาห์และรายชั่วโมงตลอดทั้งวัน คุณอาจพูดได้ว่าเวลา 9 น. เป็นช่วงเวลาที่ยากที่สุดสำหรับ Netflix เมื่อภาระงานในระบบถึงขีดสุด
เราจะบรรลุการนำนวัตกรรมซอฟต์แวร์ไปใช้อย่างรวดเร็วได้อย่างไร นั่นคือทำการเปลี่ยนแปลงใหม่ๆ ในระบบอย่างต่อเนื่อง โดยไม่ทำให้เกิดการหยุดชะงักในการให้บริการ และไม่สร้างความไม่สะดวกให้กับลูกค้าของเรา Netflix บรรลุเป้าหมายนี้ด้วยการใช้ Spinnaker ซึ่งเป็นแพลตฟอร์มการจัดการบนคลาวด์ระดับโลกและแพลตฟอร์มการจัดส่งต่อเนื่อง (CD)
ที่สำคัญ Spinnaker ได้รับการออกแบบมาเพื่อผสานรวมแนวทางปฏิบัติที่ดีที่สุดของเรา เพื่อที่เมื่อเราปรับใช้ส่วนประกอบต่างๆ ในการผลิต เราก็สามารถรวมเอาต์พุตเข้ากับเทคโนโลยีการจัดส่งสื่อของเราได้โดยตรง
เราสามารถรวมเทคโนโลยีสองอย่างเข้ากับขั้นตอนการส่งมอบที่เราให้ความสำคัญเป็นอย่างสูง ได้แก่ การวิเคราะห์คานารีแบบอัตโนมัติและการปรับใช้แบบเป็นขั้น การวิเคราะห์ Canary หมายความว่าเรากำหนดทิศทางการรับส่งข้อมูลจำนวนเล็กน้อยไปยังโค้ดเวอร์ชันใหม่ และส่งต่อปริมาณการใช้งานจริงที่เหลือผ่านเวอร์ชันเก่า จากนั้นเราจะตรวจสอบว่าโค้ดใหม่รับมือกับงานอย่างไร - ดีขึ้นหรือแย่ลงกว่าเดิม
การเปิดตัวแบบสลับสับเปลี่ยนหมายความว่าหากการเปิดตัวในภูมิภาคหนึ่งมีปัญหา เราจะย้ายไปที่การเปิดตัวในภูมิภาคอื่น ในกรณีนี้ รายการตรวจสอบที่กล่าวมาข้างต้นจะต้องรวมอยู่ในไปป์ไลน์การผลิต ฉันจะช่วยคุณประหยัดเวลาและแนะนำให้คุณดูการพูดคุยครั้งก่อนของฉัน เรื่อง Engineering Global Netflix Operations in the Cloud หากคุณสนใจที่จะเจาะลึกในหัวข้อนี้ สามารถชมวิดีโอบันทึกคำพูดได้ตามลิงค์ด้านล่างสไลด์
ในตอนท้ายของการบรรยาย ฉันจะพูดสั้นๆ เกี่ยวกับองค์กรและสถาปัตยกรรมของ Netflix ในตอนแรก เรามีรูปแบบที่เรียกว่า Electronic Delivery ซึ่งเป็นเวอร์ชันแรกของการสตรีมสื่อ NRDP 1.x สามารถใช้คำว่า "backstream" ที่นี่ได้ เนื่องจากในตอนแรกผู้ใช้จะสามารถดาวน์โหลดเนื้อหาเพื่อเล่นบนอุปกรณ์ในภายหลังเท่านั้น แพลตฟอร์มการจัดส่งดิจิทัลแพลตฟอร์มแรกของ Netflix ย้อนกลับไปในปี 2009 มีลักษณะเช่นนี้
อุปกรณ์ของผู้ใช้มีแอปพลิเคชัน Netflix ซึ่งประกอบด้วยอินเทอร์เฟซ UI โมดูลความปลอดภัย การเปิดใช้งานและการเล่นบริการ โดยอิงตามแพลตฟอร์ม NRDP - แพลตฟอร์มอุปกรณ์ที่รองรับ Netflix
ในเวลานั้นอินเทอร์เฟซผู้ใช้นั้นเรียบง่ายมาก มันมีสิ่งที่เรียกว่า Queque Reader และผู้ใช้จะไปที่ไซต์เพื่อเพิ่มบางอย่างลงใน Queque แล้วดูเนื้อหาที่เพิ่มบนอุปกรณ์ของพวกเขา ข้อดีก็คือทีมส่วนหน้าและทีมส่วนหลังอยู่ในองค์กร Electronic Delivery เดียวกันและมีความสัมพันธ์ในการทำงานที่ใกล้ชิด เพย์โหลดถูกสร้างขึ้นตาม XML ในเวลาเดียวกัน Netflix API สำหรับธุรกิจดีวีดีก็ถูกสร้างขึ้น ซึ่งสนับสนุนให้แอปพลิเคชันบุคคลที่สามกำหนดเส้นทางการรับส่งข้อมูลไปยังบริการของเรา
อย่างไรก็ตาม Netflix API ได้รับการจัดเตรียมมาอย่างดีเพื่อช่วยเราด้วยอินเทอร์เฟซผู้ใช้ที่เป็นนวัตกรรมใหม่ซึ่งประกอบด้วยข้อมูลเมตาของเนื้อหาทั้งหมด ข้อมูลเกี่ยวกับภาพยนตร์ที่มีให้บริการ ซึ่งสร้างความสามารถในการสร้างรายการเฝ้าดู มี REST API ทั่วไปตามสคีมา JSON, รหัสตอบกลับ HTTP ซึ่งเป็นรหัสเดียวกับที่ใช้ในสถาปัตยกรรมสมัยใหม่ และโมเดลความปลอดภัย OAuth ซึ่งเป็นสิ่งที่จำเป็นสำหรับแอปพลิเคชันส่วนหน้าในขณะนั้น สิ่งนี้ทำให้สามารถย้ายจากรูปแบบการส่งเนื้อหาสตรีมมิ่งแบบสาธารณะไปเป็นแบบส่วนตัวได้
ปัญหาเกี่ยวกับการเปลี่ยนแปลงคือการแตกแฟรกเมนต์ เนื่องจากขณะนี้ระบบของเราได้ดำเนินการสองบริการตามหลักการทำงานที่แตกต่างกันโดยสิ้นเชิง - บริการหนึ่งบน Rest, JSON และ OAuth อีกบริการหนึ่งบน RPC, XML และกลไกความปลอดภัยของผู้ใช้ตามระบบโทเค็น NTBA นี่เป็นสถาปัตยกรรมไฮบริดแรก
โดยพื้นฐานแล้วมีไฟร์วอลล์ระหว่างสองทีมของเรา เนื่องจากในตอนแรก API ไม่ได้ปรับขนาดได้ดีนักกับ NCCP และสิ่งนี้ทำให้เกิดความขัดแย้งระหว่างทีม ความแตกต่างอยู่ที่บริการ โปรโตคอล วงจร โมดูลความปลอดภัย และนักพัฒนามักจะต้องสลับระหว่างบริบทที่แตกต่างกันโดยสิ้นเชิง
ในเรื่องนี้ ฉันได้พูดคุยกับวิศวกรอาวุโสคนหนึ่งของบริษัท ซึ่งฉันถามคำถามว่า "สถาปัตยกรรมระยะยาวที่เหมาะสมควรเป็นอย่างไร" และเขาก็ถามคำถามสวนกลับ: "คุณคงกังวลมากกว่า เกี่ยวกับผลที่ตามมาขององค์กร - จะเกิดอะไรขึ้นถ้าเรารวมสิ่งเหล่านี้เข้าด้วยกัน และมันทำลายสิ่งที่เราได้เรียนรู้มาว่าทำได้ดี? แนวทางนี้มีความเกี่ยวข้องอย่างมากกับกฎหมายของคอนเวย์: "องค์กรที่ออกแบบระบบถูกจำกัดด้วยการออกแบบที่จำลองโครงสร้างการสื่อสารขององค์กรนั้น" นี่เป็นคำจำกัดความที่เป็นนามธรรมมาก ดังนั้นฉันจึงชอบคำที่เจาะจงมากกว่า: “ซอฟต์แวร์ใดๆ ก็ตามที่สะท้อนถึงโครงสร้างองค์กรที่สร้างขึ้น” ต่อไปนี้เป็นคำพูดที่ฉันชอบจาก Eric Raymond: "ถ้าคุณมีทีมนักพัฒนาสี่ทีมที่ทำงานเกี่ยวกับคอมไพเลอร์ คุณจะจบลงด้วยคอมไพเลอร์สี่รอบ" Netflix มีคอมไพเลอร์สี่รอบ และนั่นคือวิธีการทำงานของเรา
เราสามารถพูดได้ว่าในกรณีนี้หางคือการกระดิกสุนัข สิ่งสำคัญอันดับแรกของเราไม่ใช่การแก้ปัญหา แต่เป็นองค์กร แต่เป็นองค์กรที่ขับเคลื่อนสถาปัตยกรรมที่เรามี จากการผสมผสานบริการต่างๆ เราค่อยๆ ย้ายไปยังสถาปัตยกรรมที่เราเรียกว่า Blade Runner เพราะที่นี่เรากำลังพูดถึงบริการ Edge และความสามารถของ NCCP ที่จะแยกและรวมเข้ากับพร็อกซี Zuul, เกตเวย์ API และฟังก์ชันที่เกี่ยวข้องโดยตรง “ชิ้นส่วน” ได้กลายเป็นไมโครเซอร์วิสใหม่พร้อมฟีเจอร์การรักษาความปลอดภัย เล่นซ้ำ การเรียงลำดับข้อมูล ฯลฯ ขั้นสูงยิ่งขึ้น
ดังนั้นจึงอาจกล่าวได้ว่าโครงสร้างแผนกและพลวัตของบริษัทมีบทบาทสำคัญในการกำหนดรูปแบบการออกแบบระบบ และเป็นปัจจัยที่ส่งเสริมหรือขัดขวางการเปลี่ยนแปลง สถาปัตยกรรมไมโครเซอร์วิสนั้นซับซ้อนและเป็นธรรมชาติ และสุขภาพของสถาปัตยกรรมนั้นขึ้นอยู่กับระเบียบวินัยและความวุ่นวายที่เกิดขึ้น
โฆษณาสักหน่อย
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com