องค์ประกอบบริการ SOA ใช้งานได้จริงหรือไม่

หนึ่งในหลักการออกแบบการบริการ SOA หลักคือหลักการบริการการรวมบริการ ( https://en.wikipedia.org/wiki/Service_composability_principle )

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

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

ก่อนอื่นคุณต้องแก้ไขปัญหาการทำธุรกรรมก่อนที่จะสามารถเขียนบริการที่ไม่สำคัญ แน่นอนถ้าตัวอย่างมีบริการ "findCurrentTime ()" และ "writeLogMessage ()" มันง่ายที่จะไม่กังวลเกี่ยวกับการทำธุรกรรม แต่ไม่เมื่อมีตัวอย่างในโลกแห่งความจริงเช่น "depositMoney ()" และ "drawMoney () "

ฉันรู้สองตัวเลือก:

1. ใช้งานธุรกรรมจริงกับ WS-Atomic Transaction หรือ
2. ใช้โซลูชันที่อิงตามค่าตอบแทนซึ่งชดเชยการเรียกไปยัง A ด้วย "CancA ()" หรือ somesuch หากการเรียกไปยัง B ล้มเหลว

ทั้งสองอย่างดูมีปัญหามาก / ใกล้จะใช้ไม่ได้กับฉัน:

• ธุรกรรม WS-Atomic
  • จำนวนมากของความซับซ้อนคำแนะนำมากที่สุดที่ผมพบว่าเพียงแค่เตือน "อาการปวดในตูด, อย่าทำมัน"
  • การสนับสนุนมี จำกัด ตัวอย่างเช่นถ้าคุณใช้ ESB แบบโอเพ่นซอร์สตัวเลือกหลัก ServiceMix, Mule หรือ WSO2 ไม่รองรับ
• ค่าตอบแทน
  • การใช้การจัดการค่าตอบแทนนั้นซับซ้อนมากสำหรับฉัน เราจะทำอย่างไรถ้าบริการ A ประสบความสำเร็จและเราไม่เคยได้รับคำตอบจากบริการ B และไม่ทราบว่ามันล้มเหลวหรือสำเร็จ การจัดการตรรกะดังกล่าวด้วยตนเอง (ในฐานะผู้ดำเนินการด้านการจัดองค์ประกอบบริการ) ทำให้ฉันต้องการที่จะกรีดข้อมือ - นี่เป็นงานประเภทหนึ่งที่เครื่องมือบางอย่างควรทำเพื่อฉัน!
  • ฉันยังไม่เห็นว่าคุณสามารถมีวิธีการชดเชยในบริการที่ไม่สำคัญได้อย่างไร บอกว่าบริการของคุณคือ "depositMoney ()" และประสบความสำเร็จการกระทำอื่น ๆ จะโอนเงินไปที่อื่นอย่างรวดเร็วและจากนั้นเราได้รับ "offsetateDepositMoney ()" เราจะทำอย่างไร ดูเหมือนเวิร์มกระป๋องขนาดใหญ่

สำหรับผมแล้วมันดูเหมือนว่าองค์ประกอบของบริการดังกล่าวเป็นหลักการ SOA พื้นฐานที่คุณจริงๆไม่ได้รับประโยชน์ของ SOA ถ้าคุณไม่สามารถ (สิ่งอำนวยความสะดวก) บริการให้เขียน ความจริงคืออะไร 90% ของผู้ใช้ SOA ใช้ "criplled SOA" โดยไม่ต้องใช้บริการจริงหรือไม่ หรือผู้ใช้ส่วนใหญ่ทำในความเป็นจริงใช้องค์ประกอบบริการและฉันกำลังพูดเกินจริงความยากลำบากของมัน?

คำตอบสั้น ๆ คือใช่!

ฉันเห็นสิ่งนี้ทำได้ในองค์กรทางการเงินขนาดใหญ่หลายแห่งและทำงานได้ดี

ปัญหาการทำธุรกรรมมีความซับซ้อน แต่มักจะจัดการโดยมิดเดิลแวร์ (แพง) เช่น Oracles WebLogic EAI หรือ IBMs Websphere ESB

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

เพื่อตอบข้อกังวลของคุณที่เฉพาะเจาะจงมากขึ้น ...

คุณสามารถใช้ธุรกรรม:

1. WS-TX เป็น PITA และฉันจะหลีกเลี่ยง
2. บริการทั้งหมดของคุณอาจทำงานในเซิร์ฟเวอร์แอปพลิเคชันเดียวซึ่งในกรณีนี้คุณสามารถขยายบริการทั้งหมดด้วยธุรกรรม XA นี่คือเหตุผลที่สิ่งต่าง ๆ เช่นแอปพลิเคชันเซิร์ฟเวอร์ถูกประดิษฐ์ขึ้น

พิจารณาวิธีการชดเชยตาม:

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

ในบางสถานการณ์ไม่สำคัญ:

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

นอกจากนี้คุณยังสามารถเก็บบันทึกอีเมลที่ส่งและใช้เพื่อยกเลิกการซ้ำกันเมื่อตั้งค่าสถานะและด้วยวิธีนี้จะส่งอีเมลเพียงครั้งเดียว

คุณสามารถใช้การส่งข้อความแบบอะซิงโครนัสเพื่อแยกธุรกรรมออกเป็นชิ้นเล็ก ๆ :

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

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

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

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

ไม่มันเป็นตำนาน นี่เป็นความตั้งใจที่ผิดเมื่อมีการออกแบบสถาปัตยกรรมบริการ มีปัญหาทั้งหมด:

1. คลัปแน่นมาก หากมีการเปลี่ยนแปลงบริการหนึ่งคุณต้องทดสอบระบบทั้งหมด
2. บริการดังกล่าวมีความละเอียดมากดังนั้นจึงมีการสื่อสารภายในจำนวนมาก
3. เป็นผลมาจากการเป็นเม็ดเล็กมีบริการมากมาย ระบบเริ่มเข้าใจยากขึ้นข้อความค้นหาเริ่มยากขึ้น
4. บริการเอนทิตีถูกห่อหุ้มไม่ดี: ไม่มีกฎธุรกิจที่ถูกตรวจสอบที่นั่นตรรกะนี้อยู่ในบริการการดำเนินการ ดังนั้นบริการใด ๆ สามารถเรียกเอนทิตีเซอร์วิสและอัพเดตข้อมูลด้วยเคียวรีอัพเดตทั่วไปที่มีอยู่ในอินเตอร์เฟส บริการเอนทิตีประเภทนี้มักถูกเรียกว่า data-centric ซึ่งตรงข้ามกับบริการที่เน้นกระบวนการเป็นศูนย์กลาง
5. ลักษณะโดยธรรมชาติของการสื่อสารระหว่างบริการเหล่านี้เป็นแบบซิงโครนัส ดังนั้นโอกาสที่การขนส่งที่เลือกจะเป็น http ดังนั้นข้อเสียทั้งหมดที่ฉันจะพูดถึงในภายหลัง

มีมากยิ่งขึ้นเป็นวิธีการที่ไม่ถูกต้องที่จะเข้าใกล้สถาปัตยกรรมบริการ ดังนั้นจงระมัดระวัง