เรามาเต็มวงกลมด้วย microservices ย้อนกลับไปยังโรงเรียนเก่า

ในแง่ของสถาปัตยกรรมซอฟต์แวร์และการออกแบบ microservices "stack up" (เล่นสำนวนเจตนา) กับมิดเดิลแวร์อย่างไร ฉันมาจาก Java และดูเหมือนว่าเมื่อคุณย้ายออกจาก REST แบบตรงเป็น API และแยกแยะเลเยอร์และพารามิเตอร์การเชื่อมต่อต่าง ๆ อย่างน้อยที่สุดใน Java คุณเกือบจะกลับมาที่ความคิดเก่า ๆ . เราได้กลับมาสู่การจำลองเสมือน ... ซึ่ง JVM นั้นเสมือนจริงอยู่แล้ว

ด้วยวิธีที่ไม่เชื่อเรื่องพระเจ้าคุณสามารถและฉันจะเถียงข้อได้เปรียบที่เป็นนามธรรม, สงบเงียบ API กับ CORBA หรือในทางที่มีจาวาเป็นศูนย์กลางมากกว่า JMS หรือ MDB

ในครั้งเดียว EJB เป็นเรื่องใหญ่ใน Java แล้วมันได้รับการยอมรับว่าเป็นกลุ่มของคลัสเตอร์ แต่ตอนนี้เรากลับไปที่จุดเริ่มต้นหรือไม่?

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

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

แน่นอนว่ายังมีตัวเลือกจำนวนไม่แน่นอนระหว่างสุดขั้วเหล่านี้

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

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

เหตุใดการขยายในแนวนอนจึงแพร่หลายมากหรือเป็นที่ต้องการอย่างน้อยที่สุด

TL; DR ฉันมีความสุขที่ได้ดื่มเครื่องดื่มรสเลิศจาก Kool-Aid จาก Microserver ฉันจึงสามารถพูดถึงเหตุผลเบื้องหลังพวกเขาได้

ข้อดี:

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

จุดด้อย:

• คุณไม่สามารถใช้คุณสมบัติใหม่และเป็นประกายของการอ้างอิงของคุณ
• คุณไม่สามารถหยุดความเข้ากันได้ของ API ย้อนหลัง (หรืออย่างน้อยก็ไม่ได้สำหรับรอบการพัฒนาจำนวนมาก)

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

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

หากจำเป็นต้องเปลี่ยนแปลง API จะต้องเปลี่ยนในลักษณะที่เข้ากันได้ย้อนหลัง

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

เกี่ยวกับข้อต่อหลวม ๆ ฉันคิดว่าคุณเข้าใจเป้าหมายผิดไปเล็กน้อย ถ้า task A ต้องการเรียก task B นั้นจะไม่มีทางที่จะทำให้ A และ B แยกออกได้ 100% จะไม่เกิดขึ้น สิ่งที่คุณสามารถทำได้คือตรวจสอบให้แน่ใจว่าถ้างาน B เรียกงาน C ดังนั้นงาน C ไม่ควรกังวลเกี่ยวกับการเปลี่ยนแปลง A ถ้างานทั้งสามนี้เชื่อมโยงกันใน Blob ก้อนใหญ่ผ่านการสร้างโครงสร้างให้กันและกัน โอกาสสำคัญที่พวกเขาทุกคนจะต้องเปลี่ยนถ้ามีคนใดคนหนึ่งทำ แต่ถ้าทั้งสามคนเป็นไมโครไซต์คุณก็รับประกันได้ว่าการเปลี่ยนเป็น A จะบังคับให้ B อัปเดตเท่านั้น (เว้นแต่จะเป็นการเปลี่ยนแปลงครั้งใหญ่สำหรับฟังก์ชันหลักของ A ที่คุณน่าจะทำให้เป็นบริการใหม่ล่าสุด) นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งหากการอัพเดทไมโครบริการทั้งหมดทำในวิธีที่เข้ากันได้แบบย้อนหลังซึ่งควรจะเป็น

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

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

บริการเหล่านี้กระจัดกระจายไปทั่วเครื่องต่างกันอย่างไร

เพราะเมฆ

หัวเราะเสร็จแล้วเหรอ? แม้ว่าอย่างจริงจัง - สำหรับธุรกิจจำนวนมากต้นทุนที่ใหญ่ที่สุดสำหรับซอฟต์แวร์ไม่ใช่ซอฟต์แวร์อีกต่อไป มันคือแบนด์วิดธ์, ฮาร์ดแวร์, ค่าใช้จ่าย CDN และอื่น ๆ ตอนนี้ทุกคนมีอุปกรณ์พกพา และนั่นจะยิ่งแย่ลงเมื่อเครื่องปิ้งขนมปังของคุณได้รับการเชื่อมต่ออินเทอร์เน็ตของตัวเอง

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

เหตุใดการขยายในแนวนอนจึงแพร่หลายมากหรือเป็นที่ต้องการอย่างน้อยที่สุด

เพราะมันตอบปัญหาทางธุรกิจนี้ (ใหญ่และเพิ่มมากขึ้น)

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

เป็นสิ่งที่ดีเพราะช่วยให้คุณสามารถจัดสรรการจัดสรรเซิร์ฟเวอร์เพื่อให้คุณสามารถ:

1. ใช้เซิร์ฟเวอร์ส่วนใหญ่ที่คุณมีให้เหลือน้อย "เสีย"
2. วัดประสิทธิภาพองค์ประกอบส่วนบุคคลของซอฟต์แวร์ของคุณ
3. ลดเวลาการใช้งาน / ดาวน์เนื่องจากการเผยแพร่

การมีการปรับใช้ที่ละเอียดมากทำให้ทั้งสองสิ่งนั้นง่ายขึ้น / ดีขึ้น (นอกเหนือจากการช่วยในการบังคับใช้การแยกความกังวลให้ดีขึ้น)