คุณจะใช้บริการเว็บอย่างมีประสิทธิภาพในสภาพแวดล้อมขององค์กรได้อย่างไรถ้าคุณไม่สามารถใช้ธุรกรรมได้?


14

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

ฉันไม่เห็นว่าคุณจะสามารถใช้บริการเว็บเพื่อการทำงานอย่างจริงจังได้อย่างไร ฉันจะเรียกใช้บริการหลาย ๆ สายอย่างปลอดภัยได้อย่างไรถ้าฉันไม่สามารถใช้งานธุรกรรมได้?

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

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

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

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

โดยทั่วไปคุณจะจัดการกับวิธีนี้อย่างไร


เพื่อให้คำตอบแบบเต็มฉันต้องการข้อมูลเพิ่มเติม มีหลายสิ่งที่ต้องพิจารณาเมื่อย้ายไปยังสถาปัตยกรรมที่อิงกับบริการ ตัวอย่างเช่นคุณมีสภาพแวดล้อมที่แตกต่างกัน (ภาษาและแพลตฟอร์มที่แตกต่างกัน) หรือสภาพแวดล้อมที่เป็นเนื้อเดียวกัน (ภาษาเดียวและแพลตฟอร์ม) คุณมีระบบบัสบริการหรือไม่? ถ้าคุณไม่ได้วางแผนที่จะใช้หรือไม่ คุณวางแผนที่จะเข้าถึงบริการของคุณอย่างไร (ที่ตั้งอินทราเน็ตเดียว, หลายสถานที่, ลูกค้าที่กระจายการกดปุ่มบริการสาธารณะ API) มีตัวแปรหลายตัวที่ส่งผลต่อการแก้ปัญหา "ที่ดีที่สุด"
Michael Brown

@MikeBrown: บริการทั้งหมดจะถูกเขียนเป็นภาษาเดียว แต่ใช้งานได้หลายแพลตฟอร์ม ไม่มีความคิดเกี่ยวกับการนำ EBS มาใช้เรายังไม่ได้เริ่มให้บริการประเภทใดเลยดังนั้นจึงเป็นไปได้ บริการส่วนใหญ่จะถูกใช้ภายในเครือข่ายท้องถิ่นของเรา แต่มีบางอย่างที่จะต้องเปิดเผยต่อสาธารณะสำหรับแอปพลิเคชันมือถือ
ryeguy

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

@ S.Lott: อาจเป็นเพราะการบริการอีเมลและโทรสารเป็นเพียงการแทรกเข้าคิวซึ่งได้รับการส่งโดยกระบวนการที่แตกต่างกัน หากธุรกรรมที่ฉันอธิบายไว้ข้างต้นเกิดขึ้นการแทรกคิวจะถูกยกเลิก
ryeguy

1
@ryeguy: โปรดอัปเดตคำถาม โปรดอย่าเพิ่มความคิดเห็นในคำถาม นี่เป็นส่วนสำคัญของสถาปัตยกรรมของคุณ กรุณาเปิดเผยในคำถาม
S.Lott

คำตอบ:


5

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


3

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

ทางเลือกหนึ่งสำหรับการสนับสนุนการทำธุรกรรมในสภาพแวดล้อมที่ต่างกันคือการใช้กลไกการขนส่งที่รองรับการทำธุรกรรมและได้รับการสนับสนุนในทุกแพลตฟอร์มที่จะใช้ ขั้นสูงคิวข้อความพิธีสาร (AMQP) ไม่สนับสนุนการทำธุรกรรมและมี API พื้นเมืองสำหรับเกือบทุกภาษาที่ใช้กันทั่วไปในวันนี้ RabbitMQเป็นเซิร์ฟเวอร์ที่ใช้ AMQP และได้รับการตรวจสอบในอุตสาหกรรมเป็นโซลูชั่นที่แข็งแกร่ง

การใช้ประโยชน์จากระบบที่ใช้ RabbitMQ จะทำให้คุณได้รับ ESB อย่างเต็มรูปแบบหากคุณต้องการที่จะเติบโต คุณเผยแพร่ข้อความไปยังสถานีและสมัครคิว ที่ใดที่มีประสิทธิภาพมากจริง ๆ ก็คือระหว่างแชนเนลกับคิวคุณสามารถทำสิ่งที่น่าสนใจมากมาย ช่องสามารถป้อนหลายคิว (pub / sub) สามารถป้อนคิวได้หลายช่องคุณสามารถกำหนดเส้นทางข้อความไปยังคิวที่แตกต่างกันตามเนื้อหา ฯลฯ

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

แน่นอนหลุมกระต่าย (ให้อภัย the pun) ยิ่งลึกลงไปจากที่นั่น คุณสามารถใช้ Rabbit เพื่อทำ orchestrations ที่ซับซ้อนด้วยบริการเว็บทั้งภายในและภายนอก

สำหรับเว็บเซิร์ฟเวอร์สาธารณะของคุณมันจะง่ายเสีย บริการของคุณ (ไม่ว่าจะเป็น SOAP, REST หรือ JSON) เพียงแค่เผยแพร่ข้อความไปยังคิวบริการที่เหมาะสมและให้ระบบภายในของคุณจัดการกับมันจากที่นั่น

นอกจากนี้ยังมีฟังก์ชั่นสำหรับสร้างคำขอ / ตอบกลับข้อความสำหรับสถานการณ์ที่คุณคาดหวังว่าข้อมูลจะกลับมาอย่างรวดเร็ว


2

คำหลักที่คุณต้องการคือ 'การออกแบบท่าเต้นบนเว็บ'

ลองอ่านบทความของWikipediaเกี่ยวกับเรื่องนี้


บางครั้งเรียกว่า "orchestration" เช่นกัน
S.Lott

1

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

การสร้าง wrapper ช่วยให้การควบคุมธุรกรรมและการจัดการข้อผิดพลาดดีขึ้น นอกจากนี้ยังช่วยรักษาความปลอดภัยที่ดีขึ้นด้วยการควบคุมการเข้าถึงบริการเครือข่ายภายในจากแหล่งภายนอก โดยทั่วไปฉันเห็นความจำเป็นในการทำธุรกรรมและการจัดการบริการเป็นเหตุผลที่ถูกต้องในการสร้าง wrapper ที่เหมาะสมสำหรับโซลูชันเดียวตราบใดที่โค้ดถูกนำมาใช้ซ้ำอย่างถูกต้อง (ไม่มีการเข้ารหัส cut-n-paste)


1

ฉันไม่เห็นว่าคุณจะสามารถใช้บริการเว็บเพื่อการทำงานอย่างจริงจังได้อย่างไร ฉันจะเรียกใช้บริการหลาย ๆ สายอย่างปลอดภัยได้อย่างไรถ้าฉันไม่สามารถใช้งานธุรกรรมได้?

คุณทำไม่ได้

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

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