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


10

คำปฏิเสธ

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

พื้นหลัง

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

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

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

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

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

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

คำถาม

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

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

อ้างอิง

ปรับปรุง

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

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

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

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

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

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


แฟชั่นสำหรับการคำนวณแบบกระจายในปัจจุบันมี "ตัวแทน" หรือ "โมดุล" ที่มีข้อผิดพลาดที่ชัดเจนมีความรับผิดชอบเฉพาะและเชื่อมต่อกันด้วยโปรโตคอลการสื่อสารที่เรียบง่ายตรงไปตรงมา SOA นั้นค่อนข้างตรงกันข้ามกับทุกอย่าง คุณสังเกตโมลฮิลที่มีความคล้ายคลึงกันเพียงผิวเผินและมองเห็นภูเขาแห่งความแตกต่าง
Robert Harvey

1
SOA ไม่ควรใช้ส่วนประกอบที่มีขนาดเล็กอย่างหลวม ๆ ด้วยหรือ ฉันรู้ว่าที่ปลายด้านหลังของ SOA, มีการใช้งานอเนกประสงค์อธิบายส่วนใหญ่เป็น "ที่ดีที่สุดของสายพันธุ์" การให้บริการเพื่อการใช้งานและบริการอื่น ๆ การบริโภคจากการใช้งานอื่น ๆ โดยใช้รูปแบบใดข้อความโปรโตคอลและการเข้าถึงสื่อที่เหมาะสมสำหรับมัน
.Rashad

มันควร แต่ตามที่คุณเพิ่งชี้ให้เห็นมันมักจะไม่
Robert Harvey

Martin Fowler's Site (I think he hates it big time)นั่นไม่ใช่ความรู้สึกของฉันเมื่อฉันไปพูดที่บาร์เซโลนา เขาตระหนักถึงการแลกเปลี่ยนและวิธีการที่ผู้คนเปลี่ยนมาใช้สถาปัตยกรรมนี้โดยไม่คำนึงว่า MS ไม่เหมาะสำหรับทุกคน
Laiv

1
Microservices เป็นกลุ่มการตลาด ไม่มีความแตกต่าง ผู้คนกำลังทำสิ่งนี้เมื่อหลายปีก่อนและตอนนี้มีคนใส่ชื่อและตอนนี้มันมีอะไรใหม่ คุณถูกต้อง MS เป็นกรณี (ไม่ใช่พิเศษ) ของ SOA โปรดหยุดด้วยการพยายามทำบางสิ่งออกมา
Kyle Johnson

คำตอบ:


12

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

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

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

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

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

1
ด้วยเหตุผลเหล่านี้ทั้งหมดที่ฉันมองว่า microservices เป็นวิธีแก้ปัญหาเฉพาะสำหรับปัญหาเฉพาะ (การขยายผ่านการคำนวณแบบกระจาย) และไม่ใช่สถาปัตยกรรมแอปพลิเคชันโดยรวม
Robert Harvey

1
พวกเขาได้รับผลกระทบมากพอที่ฉันคิดว่าพวกเขาควรถูกมองว่าเป็นสถาปัตยกรรมแอพพลิเคชั่นที่มีความยืดหยุ่น / การคำนวณแบบกระจายเป็นแบบกลับหัว (มีความซับซ้อนและข้อเสียอื่น ๆ ตามการแลกเปลี่ยน)
Telastyn

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

1
ตอนนี้ฉันสับสนมากขึ้น! เป็นไปได้หรือไม่ที่แอพพลิเคชั่นแบบเสาหินจะแสดง microservices? หรือต้องเป็นแอปพลิเคชันขนาดเล็กแบบสแตนด์อโลน
A.Rashad

1
ลองดูที่บทความนี้ในDZone Microservices VS SOA
Laiv

2

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

Smart Endpoints Dumb Pipes

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.