การจัดการข้อมูลแบบกระจายอำนาจ - ห่อหุ้มฐานข้อมูลลงในไมโครไซต์บริการ [ปิด]

ฉันเพิ่งเรียนหลักสูตรการออกแบบซอฟต์แวร์และมีการอภิปราย / ข้อเสนอแนะล่าสุดเกี่ยวกับการใช้แบบจำลอง 'บริการขนาดเล็ก' โดยที่ส่วนประกอบของบริการจะถูกแยกออกเป็นส่วนย่อยของบริการ microservice ที่เป็นอิสระที่สุด

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

คุณสามารถอ่านคำอธิบายที่ละเอียดและมีรายละเอียดมากขึ้นเกี่ยวกับสิ่งนี้ได้ที่นี่: http://martinfowler.com/articles/microservices.htmlภายใต้หัวข้อการจัดการข้อมูลแบบกระจายอำนาจ

ส่วนที่สำคัญที่สุดที่พูดนี้:

Microservices ต้องการให้แต่ละบริการจัดการฐานข้อมูลของตัวเองไม่ว่าจะเป็นอินสแตนซ์ที่แตกต่างกันของเทคโนโลยีฐานข้อมูลเดียวกันหรือระบบฐานข้อมูลที่แตกต่างกันโดยสิ้นเชิง - แนวทางที่เรียกว่า Polyglot Persistence คุณสามารถใช้การคงอยู่หลายภาษาในหินใหญ่ก้อนเดียว แต่ปรากฏขึ้นบ่อยครั้งด้วย microservices

รูปที่ 4

ฉันชอบแนวคิดนี้และในหลาย ๆ สิ่งเห็นว่าการปรับปรุงที่ดีในการบำรุงรักษาและการมีโครงการที่มีหลายคนทำงานอยู่ ที่กล่าวว่าฉันไม่เคยมีประสบการณ์สถาปนิกซอฟต์แวร์ มีใครเคยลองใช้บ้างไหม คุณได้ประโยชน์อะไรและอุปสรรคอะไรบ้าง?

มาพูดถึงข้อดีและข้อเสียของวิธีไมโครเซอร์วิส

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

ผมขออธิบายข้อเสียที่แท้จริง พิจารณากรณีที่คุณมีไมโครไซต์บริการ 100 รายการที่เรียกว่าขณะสร้างหน้าเว็บแต่ละแห่งทำสิ่งที่ถูกต้อง 99.9% ของเวลา แต่ 0.05% ของเวลาที่พวกเขาให้ผลลัพธ์ที่ผิด และ 0.05% ของเวลาที่มีการร้องขอการเชื่อมต่อที่ช้าซึ่งจำเป็นต้องใช้การหมดเวลา TCP / IP เพื่อเชื่อมต่อและใช้เวลา 5 วินาที ประมาณ 90.5% ของเวลาที่คำขอของคุณทำงานได้อย่างสมบูรณ์ แต่ประมาณ 5% ของเวลาที่คุณมีผลลัพธ์ที่ไม่ถูกต้องและประมาณ 5% ของเวลาที่เพจของคุณช้า และทุกความล้มเหลวที่ไม่สามารถทำซ้ำได้มีสาเหตุที่แตกต่าง

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

ตกลงฟังดูเหมือนฝันร้าย (และมากกว่าหนึ่ง บริษัท สร้างปัญหาใหญ่ให้กับตัวเองด้วยการลงเส้นทางนี้) ความสำเร็จเป็นไปได้เพียงคุณเท่านั้นที่ตระหนักถึงข้อเสียที่อาจเกิดขึ้นและทำงานอย่างสม่ำเสมอเพื่อจัดการกับมัน

แล้ววิธีเสาหินนั่นล่ะ?

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

ตกลงแล้วทำไม บริษัท ถึงต้องใช้วิธีไมโครเซอร์วิส

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

กฎส่วนบุคคลของฉันคือการเปลี่ยนจากรหัสในภาษาสคริปต์ (เช่น Python) ไปเป็น C ++ ที่ปรับให้เหมาะสมที่สุดโดยทั่วไปสามารถปรับปรุงขนาดของคำสั่ง 1-2 รายการสำหรับทั้งประสิทธิภาพและการใช้หน่วยความจำ การไปยังอีกทางหนึ่งเพื่อสถาปัตยกรรมแบบกระจายเพิ่มขนาดความต้องการทรัพยากร แต่ให้คุณปรับขนาดได้อย่างไม่มีกำหนด คุณสามารถสร้างสถาปัตยกรรมแบบกระจายได้ แต่การทำเช่นนั้นยากขึ้น

ดังนั้นฉันจะบอกว่าถ้าคุณกำลังเริ่มต้นโครงการส่วนบุคคลไปเสาหิน เรียนรู้วิธีการทำสิ่งนั้นให้ดี ไม่ต้องเผยแพร่เพราะ (Google | eBay | Amazon | etc) นั้น หากคุณลงจอดใน บริษัท ขนาดใหญ่ที่มีการแจกจ่ายให้ใส่ใจกับวิธีที่พวกเขาทำให้มันใช้งานได้และอย่าทำให้พลาด และถ้าคุณเลิกทำต้องระวังตัวให้ดีเพราะคุณกำลังทำอะไรที่ยากที่จะได้รับมากผิดมาก

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

ฉันเห็นด้วยอย่างสุดใจกับคำตอบของ btilly แต่เพียงต้องการเพิ่มอีกแง่บวกสำหรับ Microservices ว่าฉันคิดว่าเป็นแรงบันดาลใจดั้งเดิมที่อยู่เบื้องหลัง

ในโลก Microservices บริการต่าง ๆ สอดคล้องกับโดเมนและได้รับการจัดการโดยทีมแยก (ทีมหนึ่งอาจจัดการหลายบริการ) ซึ่งหมายความว่าแต่ละทีมสามารถปล่อยบริการทั้งหมดแยกต่างหากและเป็นอิสระจากบริการอื่น ๆ (สมมติว่าเวอร์ชันอื่นถูกต้อง)

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

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

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

มันไม่ได้มีค่าใช้จ่ายมากนักเมื่อเทียบกับฐานข้อมูลเสาหิน แต่ฉันคิดว่านี่เป็นส่วนใหญ่เนื่องจากลักษณะของข้อมูลที่มีอยู่แล้วในกลุ่มแยก

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

Roger Sessions ในจดหมายข่าว Objectwatch ที่ยอดเยี่ยมของเขาอธิบายบางสิ่งที่คล้ายกับแนวคิด Software Fortresses ของเขา (น่าเสียดายที่จดหมายข่าวไม่ได้ออนไลน์อีกต่อไป แต่คุณสามารถซื้อหนังสือของเขาได้)