คุณใช้เวลาหลายเดือนในการออกแบบโมโนลิธของคุณใหม่ให้เป็นไมโครเซอร์วิส และในที่สุดทุกคนก็มารวมตัวกันเพื่อพลิกเปลี่ยน คุณไปที่หน้าเว็บแรก... และไม่มีอะไรเกิดขึ้น คุณโหลดซ้ำ - และไม่มีอะไรดีอีกแล้วไซต์ช้ามากจนไม่ตอบสนองเป็นเวลาหลายนาที เกิดอะไรขึ้น
ในการพูดคุยของเขา Jimmy Bogard จะดำเนินการ "ชันสูตรพลิกศพ" เกี่ยวกับภัยพิบัติไมโครเซอร์วิสในชีวิตจริง เขาจะแสดงปัญหาด้านการสร้างแบบจำลอง การพัฒนา และการผลิตที่เขาค้นพบ และวิธีที่ทีมของเขาค่อยๆ เปลี่ยนเสาหินแบบกระจายใหม่ให้กลายเป็นภาพสุดท้ายของความสมบูรณ์ แม้ว่าการป้องกันข้อผิดพลาดในการออกแบบจะเป็นไปไม่ได้อย่างสมบูรณ์ แต่อย่างน้อยคุณก็สามารถระบุปัญหาได้ตั้งแต่เนิ่นๆ ในกระบวนการออกแบบเพื่อให้แน่ใจว่าผลิตภัณฑ์ขั้นสุดท้ายจะกลายเป็นระบบกระจายที่เชื่อถือได้
สวัสดีทุกคน ฉันชื่อ Jimmy และวันนี้คุณจะได้ฟังวิธีการหลีกเลี่ยงภัยพิบัติครั้งใหญ่เมื่อสร้างไมโครเซอร์วิส นี่คือเรื่องราวของบริษัทที่ผมทำงานมาประมาณหนึ่งปีครึ่งเพื่อช่วยป้องกันไม่ให้เรือของพวกเขาชนกับภูเขาน้ำแข็ง เพื่อบอกเล่าเรื่องราวนี้อย่างถูกต้อง เราจะต้องย้อนเวลากลับไปและพูดคุยเกี่ยวกับจุดเริ่มต้นของบริษัทนี้ และโครงสร้างพื้นฐานด้านไอทีของบริษัทเติบโตขึ้นอย่างไรเมื่อเวลาผ่านไป เพื่อปกป้องชื่อของผู้บริสุทธิ์ในภัยพิบัติครั้งนี้ ฉันจึงได้เปลี่ยนชื่อบริษัทนี้เป็น Bell Computers สไลด์ถัดไปแสดงให้เห็นว่าโครงสร้างพื้นฐานด้านไอทีของบริษัทดังกล่าวมีลักษณะอย่างไรในช่วงกลางทศวรรษที่ 90 นี่เป็นสถาปัตยกรรมทั่วไปของเซิร์ฟเวอร์ HP Tandem Mainframe ขนาดใหญ่ที่ทนทานต่อข้อผิดพลาดสากลสำหรับการดำเนินงานร้านฮาร์ดแวร์คอมพิวเตอร์
พวกเขาจำเป็นต้องสร้างระบบเพื่อจัดการคำสั่งซื้อ การขาย การคืนสินค้า แค็ตตาล็อกผลิตภัณฑ์ และฐานลูกค้าทั้งหมด ดังนั้นพวกเขาจึงเลือกโซลูชันเมนเฟรมที่ใช้กันมากที่สุดในขณะนั้น ระบบขนาดยักษ์นี้บรรจุข้อมูลทุกอย่างเกี่ยวกับบริษัท ทุกอย่างที่เป็นไปได้ และทุกธุรกรรมดำเนินการผ่านเมนเฟรมนี้ พวกเขาเก็บไข่ทั้งหมดไว้ในตะกร้าใบเดียวและคิดว่าเป็นเรื่องปกติ สิ่งเดียวที่ไม่รวมอยู่ที่นี่คือแคตตาล็อกการสั่งซื้อทางไปรษณีย์และการสั่งซื้อทางโทรศัพท์
เมื่อเวลาผ่านไป ระบบก็ใหญ่ขึ้นเรื่อยๆ และมีขยะสะสมอยู่ในนั้นจำนวนมหาศาล นอกจากนี้ COBOL ไม่ใช่ภาษาที่แสดงออกมากที่สุดในโลก ดังนั้นระบบจึงกลายเป็นขยะชิ้นใหญ่ที่ใหญ่โต ภายในปี 2000 พวกเขาพบว่าหลายบริษัทมีเว็บไซต์ที่ใช้ดำเนินธุรกิจได้ทั้งหมด และตัดสินใจสร้างเว็บไซต์ดอทคอมเชิงพาณิชย์แห่งแรก
การออกแบบเริ่มแรกดูค่อนข้างดีและประกอบด้วยไซต์ระดับบนสุด bell.com และโดเมนย่อยจำนวนหนึ่งสำหรับแต่ละแอปพลิเคชัน: Catalog.bell.com, Accounts.bell.com, orders.bell.com, product search search.bell ดอทคอม แต่ละโดเมนย่อยใช้เฟรมเวิร์ก ASP.Net 1.0 และฐานข้อมูลของตัวเอง และโดเมนย่อยทั้งหมดได้พูดคุยกับแบ็คเอนด์ของระบบ อย่างไรก็ตาม คำสั่งซื้อทั้งหมดยังคงได้รับการประมวลผลและดำเนินการภายในเมนเฟรมขนาดใหญ่เพียงเครื่องเดียว โดยที่ขยะทั้งหมดยังคงอยู่ แต่ส่วนหน้าเป็นเว็บไซต์ที่แยกจากกันโดยมีแอปพลิเคชันแต่ละรายการและฐานข้อมูลแยกกัน
ดังนั้นการออกแบบระบบจึงดูเป็นระเบียบและสมเหตุสมผล แต่ระบบจริงกลับเป็นไปตามที่แสดงในสไลด์ถัดไป
องค์ประกอบทั้งหมดจัดการกับการเรียกหากัน API ที่เข้าถึง dll ของบริษัทอื่นที่ฝังไว้ และอื่นๆ ที่คล้ายกัน บ่อยครั้งเกิดขึ้นที่ระบบควบคุมเวอร์ชันจะคว้าโค้ดของคนอื่น ยัดมันเข้าไปในโปรเจ็กต์ จากนั้นทุกอย่างก็จะพัง MS SQL Server 2005 ใช้แนวคิดของเซิร์ฟเวอร์ลิงก์ และแม้ว่าฉันจะไม่แสดงลูกศรบนสไลด์ แต่ฐานข้อมูลแต่ละแห่งก็พูดคุยกันด้วย เพราะไม่มีอะไรผิดปกติกับการสร้างตารางตามข้อมูลที่ได้รับจากหลายฐานข้อมูล .
เนื่องจากตอนนี้พวกเขามีการแบ่งแยกระหว่างพื้นที่ตรรกะต่างๆ ของระบบ สิ่งนี้จึงกลายเป็นคราบสกปรกกระจาย โดยขยะที่ใหญ่ที่สุดยังคงอยู่ในแบ็กเอนด์ของเมนเฟรม
สิ่งที่ตลกก็คือเมนเฟรมนี้สร้างโดยคู่แข่งของ Bell Computers และยังคงได้รับการดูแลโดยที่ปรึกษาทางเทคนิคของพวกเขา ด้วยความเชื่อมั่นในประสิทธิภาพที่ไม่น่าพึงพอใจของแอพพลิเคชั่น บริษัทจึงตัดสินใจกำจัดแอพพลิเคชั่นเหล่านั้นและออกแบบระบบใหม่
แอปพลิเคชันที่มีอยู่ได้รับการผลิตมาเป็นเวลา 15 ปี ซึ่งถือเป็นสถิติสำหรับแอปพลิเคชันที่ใช้ ASP.Net บริการนี้ยอมรับคำสั่งซื้อจากทั่วทุกมุมโลก และรายรับต่อปีจากแอปพลิเคชันเดียวนี้สูงถึงพันล้านดอลลาร์ กำไรส่วนสำคัญถูกสร้างขึ้นโดยเว็บไซต์ bell.com ในช่วง Black Friday จำนวนคำสั่งซื้อผ่านเว็บไซต์มีจำนวนหลายล้านรายการ อย่างไรก็ตาม สถาปัตยกรรมที่มีอยู่ไม่อนุญาตให้มีการพัฒนาใด ๆ เนื่องจากการเชื่อมต่อระหว่างกันอย่างเข้มงวดขององค์ประกอบระบบในทางปฏิบัติไม่อนุญาตให้ทำการเปลี่ยนแปลงใด ๆ กับบริการ
ปัญหาที่ร้ายแรงที่สุดคือการไม่สามารถสั่งซื้อจากประเทศหนึ่ง ชำระเงินในอีกประเทศหนึ่ง และส่งไปยังประเทศที่สาม แม้ว่าแผนการซื้อขายดังกล่าวจะพบเห็นได้ทั่วไปในบริษัทระดับโลกก็ตาม เว็บไซต์ที่มีอยู่ไม่อนุญาตให้กระทำการเช่นนี้ ดังนั้นพวกเขาจึงต้องยอมรับและสั่งซื้อทางโทรศัพท์ สิ่งนี้ทำให้บริษัทมีความคิดมากขึ้นเกี่ยวกับการเปลี่ยนแปลงสถาปัตยกรรม โดยเฉพาะอย่างยิ่งการเปลี่ยนไปใช้ไมโครเซอร์วิส
พวกเขาทำสิ่งที่ชาญฉลาดโดยมองไปที่บริษัทอื่นๆ เพื่อดูว่าพวกเขาแก้ไขปัญหาที่คล้ายกันได้อย่างไร หนึ่งในโซลูชันเหล่านี้คือสถาปัตยกรรมบริการของ Netflix ซึ่งประกอบด้วยไมโครเซอร์วิสที่เชื่อมต่อผ่าน API และฐานข้อมูลภายนอก
ฝ่ายบริหารของ Bell Computers ตัดสินใจสร้างสถาปัตยกรรมดังกล่าวโดยยึดตามหลักการพื้นฐานบางประการ ประการแรก พวกเขากำจัดความซ้ำซ้อนของข้อมูลโดยใช้วิธีฐานข้อมูลที่ใช้ร่วมกัน ไม่มีการส่งข้อมูล ในทางกลับกัน ทุกคนที่ต้องการข้อมูลจะต้องไปที่แหล่งข้อมูลแบบรวมศูนย์ ตามมาด้วยการแยกตัวและเอกราช - แต่ละบริการมีความเป็นอิสระจากบริการอื่นๆ พวกเขาตัดสินใจใช้ Web API สำหรับทุกสิ่ง หากคุณต้องการรับข้อมูลหรือเปลี่ยนแปลงระบบอื่น ทั้งหมดนี้ทำได้ผ่าน Web API สิ่งที่สำคัญที่สุดประการสุดท้ายคือเมนเฟรมใหม่ที่เรียกว่า "Bell on Bell" ซึ่งตรงข้ามกับเมนเฟรม "Bell" ที่ใช้ฮาร์ดแวร์ของคู่แข่ง
ดังนั้น ตลอดระยะเวลา 18 เดือน พวกเขาจึงสร้างระบบตามหลักการสำคัญเหล่านี้และนำไปสู่ขั้นตอนก่อนการผลิตจริง กลับไปทำงานหลังสุดสัปดาห์ นักพัฒนามารวมตัวกันและเปิดเซิร์ฟเวอร์ทั้งหมดที่ระบบใหม่เชื่อมต่ออยู่ ทำงาน 18 เดือน นักพัฒนาหลายร้อยคน ฮาร์ดแวร์ Bell ที่ทันสมัยที่สุด - และไม่มีผลลัพธ์เชิงบวก! สิ่งนี้ทำให้ผู้คนจำนวนมากผิดหวังเพราะพวกเขาใช้ระบบนี้บนแล็ปท็อปหลายครั้งและทุกอย่างเรียบร้อยดี
พวกเขาฉลาดที่จะทุ่มเงินทั้งหมดเพื่อแก้ไขปัญหานี้ พวกเขาติดตั้งชั้นวางเซิร์ฟเวอร์ที่ทันสมัยที่สุดพร้อมสวิตช์ ใช้ใยแก้วนำแสงกิกะบิต ฮาร์ดแวร์เซิร์ฟเวอร์ที่ทรงพลังที่สุดพร้อม RAM จำนวนมหาศาล เชื่อมต่อทั้งหมด กำหนดค่า - และอีกครั้ง ไม่มีอะไรเลย! จากนั้นพวกเขาก็เริ่มสงสัยว่าสาเหตุอาจเป็นเพราะการหมดเวลา ดังนั้นพวกเขาจึงเข้าไปที่การตั้งค่าเว็บทั้งหมด การตั้งค่า API ทั้งหมด และอัปเดตการกำหนดค่าการหมดเวลาทั้งหมดให้เป็นค่าสูงสุด เพื่อที่พวกเขาจะทำได้ก็แค่นั่งรอให้บางสิ่งเกิดขึ้น ไปที่ไซต์ พวกเขารอแล้วรออีกประมาณ 9 นาทีครึ่งจนกระทั่งเว็บไซต์โหลดในที่สุด
หลังจากนั้น พวกเขาก็ตระหนักว่าสถานการณ์ปัจจุบันจำเป็นต้องมีการวิเคราะห์อย่างละเอียด และพวกเขาก็เชิญเรา สิ่งแรกที่เราค้นพบคือตลอด 18 เดือนของการพัฒนา ไม่มีการสร้าง "ไมโคร" ที่แท้จริงแม้แต่ตัวเดียว ทุกอย่างยิ่งใหญ่ขึ้นเท่านั้น หลังจากนั้นเราก็เริ่มเขียนการชันสูตรพลิกศพหรือที่เรียกว่า “ย้อนหลัง” หรือ “ย้อนหลังเศร้า” หรือที่เรียกว่า “พายุตำหนิ” คล้ายกับ “พายุสมอง” เพื่อทำความเข้าใจสาเหตุของภัยพิบัติ
เรามีเบาะแสหลายประการ หนึ่งในนั้นคือความอิ่มตัวของการรับส่งข้อมูลโดยสมบูรณ์ ณ เวลาที่เรียกใช้ API เมื่อคุณใช้สถาปัตยกรรมบริการแบบเสาหิน คุณสามารถเข้าใจได้ทันทีว่ามีอะไรผิดปกติเกิดขึ้น เนื่องจากคุณมีการติดตามสแต็กเดียวที่รายงานทุกสิ่งที่อาจทำให้เกิดความล้มเหลว ในกรณีที่บริการจำนวนมากเข้าถึง API เดียวกันพร้อมกัน ไม่มีทางที่จะติดตามการติดตามได้ยกเว้นใช้เครื่องมือตรวจสอบเครือข่ายเพิ่มเติม เช่น WireShark ซึ่งคุณสามารถตรวจสอบคำขอเดียวและค้นหาว่าเกิดอะไรขึ้นระหว่างการใช้งาน ดังนั้นเราจึงใช้หน้าเว็บหนึ่งหน้าและใช้เวลาเกือบ 2 สัปดาห์ในการรวบรวมชิ้นส่วนของปริศนาเข้าด้วยกัน ทำการเรียกที่หลากหลาย และวิเคราะห์ว่าแต่ละส่วนนำไปสู่อะไร
มองไปที่ภาพนี้. มันแสดงว่าคำขอภายนอกหนึ่งคำขอแจ้งให้บริการทำการโทรภายในจำนวนมากที่โทรกลับ ปรากฎว่าการโทรภายในแต่ละครั้งทำให้เกิดการกระโดดเพิ่มเติมเพื่อให้สามารถให้บริการตามคำขอนี้ได้อย่างอิสระ เนื่องจากไม่สามารถหันไปรับข้อมูลที่จำเป็นจากที่อื่นได้ รูปภาพนี้ดูเหมือนการโทรต่อเนื่องที่ไม่มีความหมาย เนื่องจากคำขอภายนอกเรียกใช้บริการเพิ่มเติม ซึ่งเรียกใช้บริการเพิ่มเติมอื่นๆ และอื่นๆ แทบจะไม่มีที่สิ้นสุด
สีเขียวในแผนภาพนี้แสดงครึ่งวงกลมที่บริการต่างๆ เรียกใช้ซึ่งกันและกัน - บริการ A โทรบริการ B บริการ B โทรบริการ C และเรียกบริการ A อีกครั้ง เป็นผลให้เราได้รับ "การหยุดชะงักแบบกระจาย" คำขอเดียวทำให้เกิดการเรียก API เครือข่ายนับพันครั้ง และเนื่องจากระบบไม่มีความทนทานต่อข้อผิดพลาดและการป้องกันลูปในตัว คำขอจึงล้มเหลวหากแม้แต่การเรียก API เหล่านี้ล้มเหลวแม้แต่รายการเดียว
เราทำคณิตศาสตร์บางอย่าง การเรียก API แต่ละครั้งมี SLA ไม่เกิน 150 ms และสถานะการออนไลน์ 99,9% คำขอหนึ่งทำให้เกิดการโทรที่แตกต่างกัน 200 ครั้ง และในกรณีที่ดีที่สุด หน้าเว็บสามารถแสดงได้ในขนาด 200 x 150 ms = 30 วินาที แน่นอนว่านี่ไม่ใช่เรื่องดี เมื่อคูณเวลาทำงาน 99,9% ด้วย 200 เราจะได้ความพร้อมใช้งาน 0% ปรากฎว่าสถาปัตยกรรมนี้ถึงวาระที่จะล้มเหลวตั้งแต่แรกเริ่ม
เราถามนักพัฒนาว่าพวกเขาล้มเหลวในการรับรู้ปัญหานี้ได้อย่างไรหลังจากทำงานมา 18 เดือน ปรากฎว่าพวกเขานับเฉพาะ SLA สำหรับโค้ดที่พวกเขาใช้งาน แต่ถ้าบริการของพวกเขาเรียกใช้บริการอื่น พวกเขาจะไม่นับเวลานั้นใน SLA ของพวกเขา ทุกสิ่งที่เปิดตัวภายในกระบวนการเดียวจะเป็นไปตามค่า 150 มิลลิวินาที แต่การเข้าถึงกระบวนการบริการอื่นๆ ทำให้ความล่าช้าโดยรวมเพิ่มขึ้นหลายเท่า บทเรียนแรกที่เรียนรู้คือ: “คุณเป็นผู้ควบคุม SLA ของคุณ หรือ SLA เป็นผู้ควบคุมคุณ” ในกรณีของเรา มันเป็นอย่างหลัง
สิ่งต่อไปที่เราค้นพบคือพวกเขารู้เกี่ยวกับแนวคิดเรื่องความเข้าใจผิดเกี่ยวกับการคำนวณแบบกระจาย ซึ่งกำหนดโดย Peter Deitch และ James Gosling แต่พวกเขากลับเพิกเฉยต่อส่วนแรก โดยระบุว่าข้อความ “เครือข่ายเชื่อถือได้” “เวลาแฝงเป็นศูนย์” และ “ปริมาณงานไม่จำกัด” ถือเป็นความเข้าใจผิด ความเข้าใจผิดอื่นๆ ได้แก่ ข้อความ “เครือข่ายมีความปลอดภัย” “โทโพโลยีไม่เคยเปลี่ยนแปลง” “มีผู้ดูแลระบบเพียงคนเดียวเสมอ” “ค่าใช้จ่ายในการถ่ายโอนข้อมูลเป็นศูนย์” และ “เครือข่ายเป็นเนื้อเดียวกัน”
พวกเขาทำผิดพลาดเนื่องจากได้ทดสอบบริการบนเครื่องในพื้นที่และไม่เคยเชื่อมต่อกับบริการภายนอกเลย เมื่อพัฒนาภายในเครื่องและใช้แคชในเครื่อง พวกเขาไม่เคยพบกับการกระโดดข้ามเครือข่ายเลย ตลอด 18 เดือนของการพัฒนา พวกเขาไม่เคยสงสัยเลยว่าจะเกิดอะไรขึ้นหากบริการภายนอกได้รับผลกระทบ
หากดูขอบเขตการบริการในภาพก่อนหน้าจะเห็นว่าไม่ถูกต้องทั้งหมด มีแหล่งข้อมูลมากมายที่ให้คำแนะนำเกี่ยวกับวิธีกำหนดขอบเขตการบริการ และส่วนใหญ่ให้ข้อมูลผิด เช่น Microsoft ในสไลด์ถัดไป
รูปภาพนี้มาจากบล็อก MS ในหัวข้อ “วิธีสร้างไมโครเซอร์วิส” ซึ่งจะแสดงเว็บแอปพลิเคชันแบบธรรมดา บล็อกตรรกะทางธุรกิจ และฐานข้อมูล คำขอมาโดยตรง อาจมีเซิร์ฟเวอร์หนึ่งเครื่องสำหรับเว็บ หนึ่งเซิร์ฟเวอร์สำหรับธุรกิจ และอีกหนึ่งเซิร์ฟเวอร์สำหรับฐานข้อมูล หากเพิ่มการเข้าชมรูปภาพจะเปลี่ยนไปเล็กน้อย
โหลดบาลานเซอร์เพื่อกระจายการรับส่งข้อมูลระหว่างเว็บเซิร์ฟเวอร์สองแห่ง แคชที่อยู่ระหว่างบริการเว็บและตรรกะทางธุรกิจ และแคชอื่นระหว่างตรรกะทางธุรกิจและฐานข้อมูล นี่เป็นสถาปัตยกรรมที่ Bell ใช้สำหรับการปรับสมดุลโหลดและแอปพลิเคชันการปรับใช้งานสีน้ำเงิน/เขียวในช่วงกลางทศวรรษ 2000 จนกระทั่งบางครั้งทุกอย่างทำงานได้ดีเนื่องจากโครงการนี้มีไว้สำหรับโครงสร้างเสาหิน
รูปภาพต่อไปนี้แสดงให้เห็นว่า MS แนะนำให้ย้ายจากบริการขนาดใหญ่ไปสู่ไมโครเซอร์วิสอย่างไร เพียงแยกบริการหลักแต่ละรายการออกเป็นไมโครเซอร์วิสแยกกัน ในระหว่างการดำเนินการตามโครงการนี้เองที่เบลล์ทำผิดพลาด
พวกเขาแบ่งบริการทั้งหมดออกเป็นระดับต่างๆ ซึ่งแต่ละบริการประกอบด้วยบริการส่วนบุคคลมากมาย ตัวอย่างเช่น บริการเว็บประกอบด้วยไมโครเซอร์วิสสำหรับการแสดงเนื้อหาและการรับรองความถูกต้อง บริการตรรกะทางธุรกิจประกอบด้วยไมโครเซอร์วิสสำหรับการประมวลผลคำสั่งซื้อและข้อมูลบัญชี ฐานข้อมูลถูกแบ่งออกเป็นไมโครเซอร์วิสกลุ่มหนึ่งที่มีข้อมูลเฉพาะทาง ทั้งเว็บ ตรรกะทางธุรกิจ และฐานข้อมูลเป็นบริการไร้สัญชาติ
อย่างไรก็ตาม ภาพนี้ผิดอย่างสิ้นเชิง เนื่องจากไม่ได้แมปหน่วยธุรกิจใดๆ ภายนอกคลัสเตอร์ไอทีของบริษัท โครงการนี้ไม่ได้คำนึงถึงความเกี่ยวข้องใดๆ กับโลกภายนอก ดังนั้นจึงยังไม่ชัดเจนว่าจะรับการวิเคราะห์ธุรกิจของบุคคลที่สามได้อย่างไร เป็นต้น ฉันทราบว่าพวกเขายังมีบริการหลายอย่างที่คิดค้นขึ้นเพื่อพัฒนาอาชีพของพนักงานแต่ละคนที่พยายามจัดการคนให้ได้มากที่สุดเพื่อให้ได้เงินมากขึ้น
พวกเขาเชื่อว่าการเปลี่ยนไปใช้ไมโครเซอร์วิสนั้นง่ายพอๆ กับการใช้โครงสร้างพื้นฐานฟิสิคัลเลเยอร์ N-tier ภายในและติด Docker ไว้ มาดูกันว่าสถาปัตยกรรม N-tier แบบดั้งเดิมมีหน้าตาเป็นอย่างไร
ประกอบด้วย 4 ระดับ: ระดับส่วนติดต่อผู้ใช้ UI, ระดับตรรกะทางธุรกิจ, ระดับการเข้าถึงข้อมูล และฐานข้อมูล ความก้าวหน้าที่มากขึ้นคือ DDD (Domain-Driven Design) หรือสถาปัตยกรรมเชิงซอฟต์แวร์ โดยที่ระดับกลางสองระดับคืออ็อบเจ็กต์โดเมนและพื้นที่เก็บข้อมูล
ฉันพยายามดูการเปลี่ยนแปลงในด้านต่างๆ ความรับผิดชอบที่แตกต่างกันในสถาปัตยกรรมนี้ ในการใช้งานระดับ N ทั่วไป พื้นที่ของการเปลี่ยนแปลงต่างๆ จะถูกจัดประเภทซึ่งแทรกซึมโครงสร้างในแนวตั้งจากบนลงล่าง สิ่งเหล่านี้ได้แก่ แค็ตตาล็อก การตั้งค่าที่ดำเนินการในคอมพิวเตอร์แต่ละเครื่อง และการตรวจสอบการชำระเงิน ซึ่งทีมของฉันจัดการ
ลักษณะเฉพาะของโครงการนี้คือขอบเขตของการเปลี่ยนแปลงเหล่านี้ไม่เพียงส่งผลต่อระดับตรรกะทางธุรกิจเท่านั้น แต่ยังขยายไปยังฐานข้อมูลด้วย
มาดูกันว่าการบริการหมายถึงอะไร คำจำกัดความของบริการมีคุณสมบัติเฉพาะ 6 ประการ - เป็นซอฟต์แวร์ที่:
- สร้างและใช้งานโดยองค์กรเฉพาะ
- มีหน้าที่รับผิดชอบในเนื้อหา การประมวลผล และ/หรือการจัดเตรียมข้อมูลบางประเภทภายในระบบ
- สามารถสร้าง ปรับใช้ และรันได้อย่างอิสระเพื่อตอบสนองความต้องการในการปฏิบัติงานเฉพาะด้าน
- สื่อสารกับผู้บริโภคและบริการอื่น ๆ โดยให้ข้อมูลตามข้อตกลงหรือการรับประกันตามสัญญา
- ป้องกันตัวเองจากการเข้าถึงโดยไม่ได้รับอนุญาตและข้อมูลจากการสูญหาย
- จัดการกับความล้มเหลวในลักษณะที่ไม่นำไปสู่ความเสียหายของข้อมูล
คุณสมบัติทั้งหมดนี้สามารถอธิบายได้ด้วยคำเดียวว่า "ความเป็นอิสระ" บริการต่างๆ ดำเนินงานโดยแยกจากกัน ปฏิบัติตามข้อจำกัดบางประการ และกำหนดสัญญาโดยยึดตามการที่ผู้คนสามารถรับข้อมูลที่ต้องการได้ ฉันไม่ได้พูดถึงเทคโนโลยีเฉพาะซึ่งการใช้งานนั้นชัดเจนในตัวเอง
ตอนนี้เรามาดูคำจำกัดความของไมโครเซอร์วิสกันดีกว่า:
- ไมโครเซอร์วิสมีขนาดเล็กและออกแบบมาเพื่อแก้ไขปัญหาเฉพาะอย่างหนึ่ง
- ไมโครเซอร์วิสเป็นแบบอัตโนมัติ
- เมื่อสร้างสถาปัตยกรรมไมโครเซอร์วิส จะใช้คำเปรียบเทียบการวางผังเมือง นี่คือคำจำกัดความจากหนังสือ Building Microservices ของ Sam Newman
คำจำกัดความของ Bounded Context นำมาจากหนังสือ Domain-Driven Design ของ Eric Evans นี่คือรูปแบบหลักใน DDD ซึ่งเป็นศูนย์ออกแบบสถาปัตยกรรมที่ทำงานร่วมกับแบบจำลองสถาปัตยกรรมเชิงปริมาตร โดยแบ่งแบบจำลองออกเป็นบริบทที่มีขอบเขตต่างกัน และกำหนดปฏิสัมพันธ์ระหว่างแบบจำลองอย่างชัดเจน
พูดง่ายๆ ก็คือ Bounded Context หมายถึงขอบเขตที่โมดูลใดสามารถใช้ได้ ภายในบริบทนี้คือโมเดลแบบรวมเชิงตรรกะที่สามารถมองเห็นได้ เช่น ในโดเมนธุรกิจของคุณ หากคุณถามเจ้าหน้าที่ที่เกี่ยวข้องกับคำสั่งซื้อว่า “ใครคือลูกค้า” คุณจะได้คำจำกัดความหนึ่ง หากคุณถามผู้ที่เกี่ยวข้องกับการขาย คุณจะได้รับอีกคำจำกัดความหนึ่ง และผู้แสดงจะให้คำจำกัดความที่สามแก่คุณ
ดังนั้น Bounded Context กล่าวว่าหากเราไม่สามารถให้คำจำกัดความที่ชัดเจนว่าผู้บริโภคบริการของเราคืออะไร เรามากำหนดขอบเขตที่เราสามารถพูดถึงความหมายของคำนี้ได้ จากนั้นจึงกำหนดจุดเปลี่ยนระหว่างคำจำกัดความที่แตกต่างกันเหล่านี้ นั่นคือหากเรากำลังพูดถึงลูกค้าจากมุมมองของการสั่งซื้อ นี่หมายถึงสิ่งนี้และสิ่งนั้น และหากจากมุมมองของการขาย นี่หมายถึงสิ่งนี้และสิ่งนั้น
คำจำกัดความถัดไปของไมโครเซอร์วิสคือการห่อหุ้มการดำเนินการภายในทุกประเภท เพื่อป้องกัน "การรั่วไหล" ของส่วนประกอบของกระบวนการทำงานออกสู่สิ่งแวดล้อม ถัดมาเป็น "คำจำกัดความของสัญญาที่ชัดเจนสำหรับการโต้ตอบภายนอกหรือการสื่อสารภายนอก" ซึ่งแสดงโดยแนวคิดของสัญญาที่ส่งคืนจาก SLA คำจำกัดความสุดท้ายคือคำอุปมาของเซลล์หรือเซลล์ ซึ่งหมายถึงการห่อหุ้มชุดการดำเนินการภายในไมโครเซอร์วิสอย่างสมบูรณ์และการมีอยู่ของตัวรับสำหรับการสื่อสารกับโลกภายนอก
ดังนั้นเราจึงบอกกับทีมงานที่ Bell Computers ว่า “เราไม่สามารถแก้ไขความวุ่นวายใดๆ ที่คุณสร้างขึ้นได้ เนื่องจากคุณไม่มีเงินพอที่จะแก้ไข แต่เราจะแก้ไขเพียงบริการเดียวเพื่อให้ทุกอย่างเกิดขึ้น ความรู้สึก." ณ จุดนี้ ฉันจะเริ่มต้นด้วยการบอกคุณว่าเราแก้ไขบริการเดียวของเราอย่างไรเพื่อให้ตอบกลับคำขอได้เร็วกว่า 9 นาทีครึ่ง
22:30 นาที
ต่อไปในเร็วๆ นี้...
โฆษณาสักหน่อย
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ 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