19 กันยายนที่กรุงมอสโก การประชุมเฉพาะเรื่องครั้งแรก HUG (กลุ่มผู้ใช้ Highload++) ซึ่งมีไว้สำหรับไมโครเซอร์วิสโดยเฉพาะ มีการนำเสนอ “การดำเนินงานไมโครเซอร์วิส: ขนาดมีความสำคัญ แม้ว่าคุณจะมี Kubernetes” ซึ่งเราได้แบ่งปันประสบการณ์ที่กว้างขวางของ Flant ในการดำเนินโครงการด้วยสถาปัตยกรรมไมโครเซอร์วิส ก่อนอื่น มันจะมีประโยชน์สำหรับนักพัฒนาทุกคนที่กำลังคิดจะใช้แนวทางนี้ในโปรเจ็กต์ปัจจุบันหรือในอนาคต
แนะนำตัว (50 นาที มีข้อมูลมากกว่าบทความมาก) รวมถึงเนื้อหาหลักจากบทความนี้ในรูปแบบข้อความ
หมายเหตุ: มีวิดีโอและการนำเสนออยู่ท้ายโพสต์นี้ด้วย
การแนะนำ
โดยปกติแล้วเรื่องราวที่ดีจะต้องมีจุดเริ่มต้น โครงเรื่องหลัก และปณิธาน รายงานนี้เป็นเหมือนโหมโรงและเป็นเรื่องน่าเศร้าในตอนนั้น สิ่งสำคัญที่ควรทราบคือให้มุมมองของไมโครเซอร์วิสจากบุคคลภายนอก การเอารัดเอาเปรียบ.
ฉันจะเริ่มต้นด้วยกราฟนี้ซึ่งผู้เขียน (ในปี 2015) มาร์ติน ฟาวเลอร์:
โดยจะแสดงให้เห็นว่าในกรณีของการใช้งานแบบเสาหินซึ่งมีมูลค่าถึงระดับหนึ่ง ประสิทธิภาพการผลิตเริ่มลดลงได้อย่างไร ไมโครเซอร์วิสมีความแตกต่างกันตรงที่ผลผลิตเริ่มแรกจะลดลง แต่เมื่อความซับซ้อนเพิ่มขึ้น ประสิทธิภาพที่ลดลงก็ไม่สังเกตเห็นได้ชัดเจนสำหรับพวกเขา
ฉันจะเพิ่มกราฟนี้สำหรับกรณีการใช้ Kubernetes:
เหตุใดแอปพลิเคชันที่มีไมโครเซอร์วิสจึงดีกว่า เนื่องจากสถาปัตยกรรมดังกล่าวทำให้เกิดข้อกำหนดที่จริงจังสำหรับสถาปัตยกรรม ซึ่งได้รับการครอบคลุมอย่างสมบูรณ์ด้วยความสามารถของ Kubernetes ในทางกลับกัน ฟังก์ชันบางอย่างจะมีประโยชน์สำหรับหินใหญ่ก้อนเดียว โดยเฉพาะอย่างยิ่งเนื่องจากหินใหญ่ก้อนเดียวทั่วไปในปัจจุบันไม่ใช่หินใหญ่ก้อนเดียวอย่างแน่นอน (รายละเอียดจะอยู่ในรายงานในภายหลัง)
อย่างที่คุณเห็นกราฟสุดท้าย (เมื่อทั้งแอปพลิเคชันแบบเสาหินและไมโครเซอร์วิสอยู่ในโครงสร้างพื้นฐานที่มี Kubernetes) ไม่ได้แตกต่างจากกราฟดั้งเดิมมากนัก ต่อไปเราจะพูดถึงแอปพลิเคชันที่ทำงานโดยใช้ Kubernetes
ไมโครเซอร์วิสที่เป็นประโยชน์และเป็นอันตราย
และนี่คือแนวคิดหลัก:
อะไรคือสิ่งที่ ปกติ สถาปัตยกรรมไมโครเซอร์วิส? ควรให้ประโยชน์อย่างแท้จริงแก่คุณ เพิ่มประสิทธิภาพในการทำงานของคุณ ถ้าเรากลับไปที่กราฟนี่คือ:
ถ้าคุณโทรหาเธอ มีประโยชน์แล้วอีกด้านของกราฟก็จะมี เป็นอันตราย ไมโครเซอร์วิส (รบกวนการทำงาน):
กลับมาที่ “แนวคิดหลัก”: ฉันควรเชื่อถือประสบการณ์ของตัวเองหรือไม่? ตั้งแต่ต้นปีนี้ผมได้ดู 85 โครงการ. ไม่ใช่ทั้งหมดจะเป็นไมโครเซอร์วิส (ประมาณหนึ่งในสามถึงครึ่งหนึ่งมีสถาปัตยกรรมเช่นนี้) แต่ก็ยังมีจำนวนมาก เรา (บริษัท Flant) ในฐานะผู้ให้บริการภายนอกจัดการเพื่อดูแอปพลิเคชันที่หลากหลายที่พัฒนาทั้งในบริษัทขนาดเล็ก (ที่มีนักพัฒนา 5 คน) และในบริษัทขนาดใหญ่ (ประมาณ 500 นักพัฒนา) ประโยชน์เพิ่มเติมคือเราเห็นแอปพลิเคชันเหล่านี้ใช้งานได้จริงและมีการพัฒนาตลอดหลายปีที่ผ่านมา
ทำไมต้องไมโครเซอร์วิส?
สำหรับคำถามเกี่ยวกับประโยชน์ของไมโครเซอร์วิสที่มีอยู่ จาก Martin Fowler ที่ได้กล่าวไปแล้ว:
- ขอบเขตที่ชัดเจนของความเป็นโมดูล
- การใช้งานอิสระ
- อิสระในการเลือกเทคโนโลยี
ฉันได้พูดคุยกับสถาปนิกและนักพัฒนาซอฟต์แวร์มากมาย และถามว่าทำไมพวกเขาถึงต้องการไมโครเซอร์วิส และฉันก็ทำรายการความคาดหวังของพวกเขาแล้ว นี่คือสิ่งที่เกิดขึ้น:
หากเราอธิบายบางประเด็น "ในความรู้สึก" แล้ว:
- ขอบเขตที่ชัดเจนของโมดูล: ที่นี่เรามีเสาหินที่น่ากลัวและตอนนี้ทุกอย่างจะถูกจัดเรียงอย่างเรียบร้อยในที่เก็บ Git ซึ่งทุกอย่าง "บนชั้นวาง" ความอบอุ่นและความนุ่มนวลจะไม่ปะปนกัน
- ความเป็นอิสระในการปรับใช้: เราจะสามารถเปิดตัวบริการได้อย่างอิสระเพื่อให้การพัฒนาดำเนินไปเร็วขึ้น (เผยแพร่คุณสมบัติใหม่พร้อมกัน)
- ความเป็นอิสระในการพัฒนา: เราสามารถมอบไมโครเซอร์วิสนี้ให้กับทีม/นักพัฒนาทีมหนึ่ง และอีกทีมหนึ่งต่ออีกทีมหนึ่ง ซึ่งต้องขอบคุณการที่เราพัฒนาได้เร็วขึ้น
- боความน่าเชื่อถือที่มากขึ้น: หากเกิดการเสื่อมสภาพบางส่วน (หนึ่งไมโครเซอร์วิสจาก 20 ฟอลส์) จะมีเพียงปุ่มเดียวเท่านั้นที่จะหยุดทำงาน และระบบโดยรวมจะยังคงทำงานต่อไป
สถาปัตยกรรมไมโครเซอร์วิสทั่วไป (เป็นอันตราย)
เพื่ออธิบายว่าทำไมความเป็นจริงจึงไม่เป็นอย่างที่เราคาดหวัง ผมจะนำเสนอ โดยรวม รูปภาพของสถาปัตยกรรมไมโครเซอร์วิสที่อิงจากประสบการณ์จากโปรเจ็กต์ต่างๆ มากมาย
ตัวอย่างจะเป็นร้านค้าออนไลน์ที่เป็นนามธรรมที่จะแข่งขันกับ Amazon หรืออย่างน้อย OZON สถาปัตยกรรมไมโครเซอร์วิสมีลักษณะดังนี้:
ด้วยเหตุผลหลายประการ ไมโครเซอร์วิสเหล่านี้จึงถูกเขียนขึ้นบนแพลตฟอร์มที่แตกต่างกัน:
เนื่องจากไมโครเซอร์วิสแต่ละรายการต้องมีอิสระ ผู้ให้บริการจำนวนมากจึงต้องการฐานข้อมูลและแคชของตัวเอง สถาปัตยกรรมขั้นสุดท้ายมีดังนี้:
ผลที่ตามมาคืออะไร?
ฟาวเลอร์ก็มีเรื่องนี้เหมือนกัน — เกี่ยวกับ “การชำระเงิน” สำหรับการใช้งานไมโครเซอร์วิส:
และเราจะดูว่าเป็นไปตามความคาดหวังของเราหรือไม่
ล้างขอบเขตของโมดูล...
แต่ เราจำเป็นต้องแก้ไขไมโครเซอร์วิสจำนวนเท่าใดเพื่อเปิดตัวการเปลี่ยนแปลง? เราจะคิดออกไหมว่าทุกอย่างทำงานอย่างไรโดยไม่มีตัวติดตามแบบกระจาย (ท้ายที่สุดแล้ว คำขอใดๆ จะถูกประมวลผลโดยไมโครเซอร์วิสครึ่งหนึ่ง)
มีแบบ”“ และที่นี่กลายเป็นก้อนดินกระจายอยู่ เพื่อยืนยันสิ่งนี้ ต่อไปนี้เป็นภาพประกอบโดยประมาณว่าคำขอดำเนินไปอย่างไร:
ความเป็นอิสระในการปรับใช้...
ในทางเทคนิคแล้ว บรรลุผลสำเร็จแล้ว: เราสามารถเปิดตัวไมโครเซอร์วิสแต่ละรายการแยกกันได้ แต่ในทางปฏิบัติคุณต้องคำนึงว่าจะมีการเผยแพร่อยู่เสมอ ไมโครเซอร์วิสมากมายและเราต้องคำนึงถึงด้วย ลำดับการเปิดตัว. ในทางที่ดี โดยทั่วไปเราจำเป็นต้องทดสอบในวงจรแยกต่างหากว่าเรากำลังเปิดตัวรุ่นตามลำดับที่ถูกต้องหรือไม่
อิสระในการเลือกเทคโนโลยี...
เธอคือ. เพียงจำไว้ว่าเสรีภาพมักมีพรมแดนติดกับความผิดกฎหมาย เป็นสิ่งสำคัญมากที่นี่ที่จะไม่เลือกเทคโนโลยีเพียงเพื่อ "เล่น" กับพวกเขา
ความเป็นอิสระในการพัฒนา...
จะสร้าง test loop สำหรับแอปพลิเคชันทั้งหมดได้อย่างไร (ที่มีส่วนประกอบมากมาย) แต่คุณยังต้องให้มันทันสมัยอยู่เสมอ ทั้งหมดนี้นำไปสู่ความจริงที่ว่า จำนวนวงจรทดสอบจริงซึ่งโดยหลักการแล้วเราสามารถมีได้ กลายเป็นว่าน้อยที่สุด.
แล้วปรับใช้ทั้งหมดนี้ในเครื่องล่ะ?.. ปรากฎว่าบ่อยครั้งที่นักพัฒนาทำงานอย่างอิสระ แต่ "สุ่ม" เพราะเขาถูกบังคับให้รอจนกว่าวงจรจะว่างสำหรับการทดสอบ
แยกมาตราส่วน...
ได้ แต่จำกัดอยู่ในขอบเขตของ DBMS ที่ใช้ ในตัวอย่างสถาปัตยกรรมที่ให้มา Cassandra จะไม่มีปัญหา แต่ MySQL และ PostgreSQL จะมีปัญหา
Боความน่าเชื่อถือที่มากขึ้น...
ความล้มเหลวของไมโครเซอร์วิสตัวเดียวในความเป็นจริงไม่เพียงแต่มักจะทำลายการทำงานที่ถูกต้องของทั้งระบบ แต่ยังมีปัญหาใหม่อีกด้วย: การทำให้ทุกไมโครเซอร์วิสสามารถทนต่อข้อผิดพลาดนั้นเป็นเรื่องยากมาก. เนื่องจากไมโครเซอร์วิสใช้เทคโนโลยีที่แตกต่างกัน (memcache, Redis ฯลฯ) คุณต้องคิดให้รอบคอบและนำไปปฏิบัติในแต่ละครั้ง ซึ่งแน่นอนว่าเป็นไปได้ แต่ต้องใช้ทรัพยากรจำนวนมาก
โหลดการวัด...
นี่เป็นสิ่งที่ดีจริงๆ
“ความเบา” ของไมโครเซอร์วิส...
เราไม่เพียงแต่จะมีขนาดใหญ่เท่านั้น ค่าใช้จ่ายเครือข่าย (คำขอ DNS กำลังทวีคูณ ฯลฯ ) แต่ยังเนื่องมาจากแบบสอบถามย่อยจำนวนมากที่เราเริ่มต้น ทำซ้ำข้อมูล (แคชเก็บ) ซึ่งนำไปสู่การจัดเก็บข้อมูลจำนวนมาก
และนี่คือผลลัพธ์ของการบรรลุความคาดหวังของเรา:
แต่นั่นไม่ใช่ทั้งหมด!
เพราะ:
- เป็นไปได้มากว่าเราจะต้องมีบัสข้อความ
- จะทำการสำรองข้อมูลอย่างสม่ำเสมอในช่วงเวลาที่เหมาะสมได้อย่างไร? เพียงผู้เดียว, เพียงคนเดียว จริง ตัวเลือกคือการปิดการรับส่งข้อมูลสำหรับสิ่งนี้ แต่จะทำอย่างไรในการผลิต?
- หากเรากำลังพูดถึงการสนับสนุนหลายภูมิภาค การจัดการความยั่งยืนในแต่ละภูมิภาคนั้นเป็นงานที่ต้องใช้แรงงานมาก
- ปัญหาของการเปลี่ยนแปลงแบบรวมศูนย์เกิดขึ้น ตัวอย่างเช่น หากเราจำเป็นต้องอัปเดตเวอร์ชัน PHP เราจะต้องคอมมิตกับแต่ละพื้นที่เก็บข้อมูล (และมีหลายสิบแห่ง)
- การเติบโตของความซับซ้อนในการดำเนินงานเป็นแบบทวีคูณ
จะทำอย่างไรกับทั้งหมดนี้?
เริ่มต้นด้วยแอปพลิเคชันเสาหิน. ประสบการณ์ของฟาวเลอร์ ว่าแอปพลิเคชันไมโครเซอร์วิสที่ประสบความสำเร็จเกือบทั้งหมดเริ่มต้นจากเสาหินที่มีขนาดใหญ่เกินไปและพังทลายลง ในเวลาเดียวกัน ระบบเกือบทั้งหมดที่สร้างขึ้นเป็นไมโครเซอร์วิสตั้งแต่เริ่มต้นไม่ช้าก็เร็วก็ประสบปัญหาร้ายแรง
ความคิดอันทรงคุณค่าอีกประการหนึ่งคือการที่โครงการที่มีสถาปัตยกรรมไมโครเซอร์วิสจะประสบความสำเร็จ คุณต้องรู้เป็นอย่างดี และสาขาวิชา และวิธีการสร้างไมโครเซอร์วิส. และวิธีที่ดีที่สุดในการเรียนรู้สาขาวิชาคือการสร้างเสาหิน
แต่ถ้าเราอยู่ในสถานการณ์นี้แล้วล่ะ?
ขั้นตอนแรกในการแก้ปัญหาคือต้องยอมรับและเข้าใจว่าเป็นปัญหาที่เราไม่อยากทนอีกต่อไป
หากในกรณีของเสาหินที่รกเกินไป (เมื่อเราหมดโอกาสในการซื้อทรัพยากรเพิ่มเติมสำหรับมัน) เราก็ตัดมันออกไป ในกรณีนี้ กลับกลายเป็นเรื่องตรงกันข้าม: เมื่อไมโครเซอร์วิสที่มากเกินไปไม่ช่วยอีกต่อไป แต่ขัดขวาง - ตัดส่วนเกินออกและขยายใหญ่ขึ้น!
ตัวอย่างเช่น สำหรับภาพรวมที่กล่าวถึงข้างต้น...
กำจัดไมโครเซอร์วิสที่น่าสงสัยที่สุด:
รวมไมโครเซอร์วิสทั้งหมดที่รับผิดชอบในการสร้างส่วนหน้า:
... ลงในไมโครเซอร์วิสเดียว เขียนด้วยภาษา/กรอบงาน (สมัยใหม่และปกติตามที่คุณคิด) เดียว:
โดยจะมีหนึ่ง ORM (หนึ่ง DBMS) และแอปพลิเคชันสองสามรายการแรก:
... แต่โดยทั่วไปแล้วคุณสามารถถ่ายโอนได้มากกว่านั้นมาก โดยได้ผลลัพธ์ดังต่อไปนี้:
ยิ่งไปกว่านั้น ใน Kubernetes เรารันทั้งหมดนี้ในอินสแตนซ์ที่แยกจากกัน ซึ่งหมายความว่าเรายังคงสามารถวัดโหลดและปรับขนาดแยกกันได้
สรุป
ดูภาพใหญ่. บ่อยครั้งที่ปัญหาเกี่ยวกับไมโครเซอร์วิสเหล่านี้เกิดขึ้นเพราะมีคนรับหน้าที่ของตน แต่ต้องการ "เล่นกับไมโครเซอร์วิส"
ในคำว่า "ไมโครเซอร์วิส" ส่วน "ไมโคร" นั้นซ้ำซ้อน. พวกมันเป็น "ไมโคร" เพียงเพราะมันมีขนาดเล็กกว่าเสาหินขนาดใหญ่เท่านั้น แต่อย่าคิดว่ามันเป็นสิ่งเล็กๆ
และสำหรับความคิดสุดท้าย เรากลับมาที่แผนภูมิเดิม:
มีข้อความเขียนไว้บนนั้น (ขวาบน) เดือดลงไปถึงความจริงที่ว่า ทักษะของทีมที่ทำให้โครงการของคุณเป็นอันดับแรกเสมอ — พวกเขาจะมีบทบาทสำคัญในการเลือกของคุณระหว่างไมโครเซอร์วิสและโมโนลิธ หากทีมไม่มีทักษะเพียงพอแต่เริ่มสร้างไมโครเซอร์วิสเรื่องราวจะถึงแก่ชีวิตอย่างแน่นอน
วิดีโอและสไลด์
วิดีโอจากการกล่าวสุนทรพจน์ (ประมาณ 50 นาที น่าเสียดายที่ไม่ได้ถ่ายทอดอารมณ์ความรู้สึกมากมายของผู้เยี่ยมชม ซึ่งกำหนดอารมณ์ของรายงานเป็นส่วนใหญ่ แต่เป็นเช่นนั้น):
การนำเสนอรายงาน:
PS
รายงานอื่นๆ ในบล็อกของเรา:
- «» (Dmitry Stolyarov; 28 พฤษภาคม 2018 ที่ RootConf);
- «» (Dmitry Stolyarov; 7 พฤศจิกายน 2017 บน HighLoad++);
- «» (Dmitry Stolyarov; 6 มิถุนายน 2017 ที่ RootConf);
- «» (Dmitry Stolyarov; 8 พฤศจิกายน 2016 บน HighLoad++);
- «» (Dmitry Stolyarov; 31 พฤษภาคม 2016 ที่ RootConf).
คุณอาจสนใจสิ่งพิมพ์ต่อไปนี้:
- «";
- «";
- «'
ที่มา: will.com