อะไรคือความแตกต่างระหว่าง SOA และ Microservices

คำปฏิเสธ

ฉันหวังว่าฉันจะไม่เหยียบนิ้วเท้าของใครก็ตาม

พื้นหลัง

ฉันค้นหาความแตกต่างที่แท้จริงระหว่าง Service Oriented Architecture และ Microservices โดยไม่ต้องค้นหาคำตอบที่ชัดเจน

ฉันอ่านสิ่งที่ชอบ:

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

แต่ถึงกระนั้นก็ไม่มีอะไรกำหนดความแตกต่างทางสถาปัตยกรรมอย่างชัดเจนระหว่าง Service Oriented Architecture (เป็นแนวคิด) และ Microservices (เป็นแนวคิด)

ตามที่ฉันเข้าใจพวกเขาทั้งสองมี:

• ผู้ให้บริการทำสิ่งเดียวเท่านั้น
• Service Gateway / ESB เปิดเผยบริการเหล่านั้นต่อผู้บริโภค
• ผู้บริโภคบริการเข้าถึงบริการผ่าน ESB / เกตเวย์บริการ

คำถาม

ดังนั้นจะมีอะไรที่แตกต่างไปจากการติดฉลาก SOA ใหม่ใน Microservices บ้างไหม? เป็นข้อ จำกัด ทางเทคโนโลยีหรือไม่ที่จะ จำกัด Microservices ไม่ให้กลายเป็นมาโคร

หมายเหตุ: ฉันไม่ได้มองหาความคิดเห็นเพียงข้อเท็จจริงยากหวังว่าในหัวข้อย่อย

อ้างอิง

• คำถามวิศวกรรมซอฟต์แวร์
• เว็บไซต์ Martin Fowler (ฉันคิดว่าเขาเกลียดครั้งใหญ่)
• ข้อมูลโลก
• เว็บไซต์ Michael Fethers
• กองคำถามล้น

ปรับปรุง

ดูเหมือนว่าการอภิปรายที่คล้ายกันเกิดขึ้นในคำถามล้นสแต็คโดยความคิดเห็นที่ถูกแบ่งออกหรือไม่ Microservices คือ Service Oriented Architecture โดยซ่อนเร้น

บทสรุปจากคำถาม SO:

• MS เป็นกรณีพิเศษของ SOA
• MS รับรองแอปพลิเคชันที่ให้บริการโฮสต์ที่มีขนาดเล็กลง
• MS ขึ้นอยู่กับเทคโนโลยี (การใช้ HTTP มากกว่าตัวเลือกโปรโตคอลแบบเปิด)
• MS อาศัยเทคโนโลยีในการบังคับใช้ระเบียบวินัย (การปรับใช้บริการโดยอัตโนมัติ)
• MS พิจารณาESB (ร้าย) แต่ใช้เกตเวย์ API ซึ่ง IMHO เป็น ESB ประเภทหนึ่ง

สรุปว่า MS คือ SOA หากสิ่งต่อไปนี้เป็นจริง:

• MS สนับสนุนแนวคิดเรื่อง Orchestration หรือไม่? กระบวนการหลักหนึ่งกระบวนการขึ้นไปจัดการเวิร์กโฟลว์
• มีเลเยอร์นายหน้าข้อความใน MS หรือไม่? ชุดของอะแดปเตอร์แปลรูปแบบข้อความจากพื้นที่ข้อความของผู้ผลิตบริการไปยังผู้ใช้บริการ
• microservices สามารถอ่านข้อมูลจากแอพพลิเคชั่นองค์กรขนาดใหญ่ได้หรือไม่? มันเป็น API ของแอพพลิเคชั่นแบบเสาหินหรือไม่? หรือจะต้องเป็นแอพพลิเคชั่นที่มีอยู่ในตัวเองสามารถทำงานได้อย่างอิสระ?

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

ผู้ให้บริการทำสิ่งเดียวเท่านั้น

ความแตกต่างหลักซึ่งมีผลกระทบอย่างกว้างขวางของโครงการคือมี Microservices ให้บริการเหล่านี้มีอิสระ deployable และปรับขนาดได้

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

แต่มันมาพร้อมกับความหมายบางอย่าง:

• กระบวนการวางจำหน่ายของคุณจำเป็นต้องเปลี่ยนแปลงเนื่องจากการปรับใช้บริการบางอย่างนั้นแตกต่างจากการปรับใช้บริการไม่กี่โหล
• กระบวนการวางจำหน่ายของคุณจำเป็นต้องเปลี่ยนแปลงเนื่องจากการปรับใช้บริการกับเครื่องหนึ่งนั้นแตกต่างจากการปรับใช้กับเครื่องไม่กี่โหล
• การออกแบบฐานข้อมูลการใช้งานและการปรับใช้ของคุณจำเป็นต้องเปลี่ยนแปลงเนื่องจากมันไม่มีความหมายในการปรับใช้บริการหากจำเป็นต้องปรับใช้ฐานข้อมูลที่ใช้ร่วมกันขนาดใหญ่นี้ให้ทำงาน (ทำลายบริการอื่น ๆ ทั้งหมดของคุณ)
• การออกแบบและการใช้งานไลบรารี่ของคุณจำเป็นต้องเปลี่ยนแปลงเพราะมันไม่มีความหมายในการปรับใช้บริการหากจำเป็นต้องอัพเดตไลบรารี่ที่แชร์นี้ (ทำลายบริการอื่น ๆ ทั้งหมดของคุณ)
• อนุมัติ / การจัดการ / เซสชั่นการเข้าสู่ระบบของคุณ / etc ความต้องการการเปลี่ยนแปลงเพราะมันสวยง่ายต่อการแบ่งปันสิ่งต่างๆเมื่อคุณเพียงแค่บริการหนึ่ง แต่ที่แตกต่างกันเมื่อคุณมีพวงของบริการเล็ก ๆ น้อย ๆ ที่เป็นอิสระที่ทำขึ้นสินค้า - และพวกเขากำลังจะไป ต้องการแบ่งปันเนื้อหา โอ้และทุกสิ่งที่แบ่งปันต้องจัดการกับความเป็นไปได้ในรุ่นที่แตกต่างกัน
• การสื่อสารของคุณต้องเปลี่ยน ด้วยบริการไม่กี่อย่างคุณสามารถแยกแยะสิ่งต่าง ๆ ตามสายที่การสื่อสารไม่ได้เกิดขึ้นบ่อยและ / หรืออาจเกิดขึ้นช้า ด้วย microservices พวกเขาจะพูดคุยกันมากและเวลาแฝงที่สูงจะไม่ลดลง

นี่คือผลกำไรความแตกต่างที่ชัดเจนระหว่างSOAและMicroservicesคือแนวคิดของ

Smart Endpoints Dumb Pipes

ซึ่งแตกต่างจากSOAที่จะขึ้นอยู่กับผู้บริโภคและผู้ผลิตที่หลงลืมการมอบหมายการจัดการการจราจรการแปลรูปแบบข้อความและการจัดบริการไปยังระบบภายนอกเช่น ESB ผู้ดูแลบริการ, นายหน้าข้อความ