ตรรกะทางธุรกิจที่ควรนั่งในสถาปัตยกรรมบริการไมโคร?

ยังคงพยายามคลุมหัวของฉันรอบ ๆ สถาปัตยกรรมไมโครบริการเนื่องจากฉันคุ้นเคยกับวิธีการแบบเสาหิน

สมมติว่าเราพยายามสร้างระบบการจอง Uber ที่ง่ายมาก เพื่อลดความซับซ้อนของสิ่งที่เราสมมติว่าเรามี 3 บริการและ API ประตูสำหรับไคลเอนต์: Booking, Drivers, Notificationและเรามีขั้นตอนการทำงานต่อไปนี้:

เมื่อสร้างการจองใหม่:

1. ตรวจสอบว่าผู้ใช้ปัจจุบันมีการจองแล้ว
2. รับรายการไดรเวอร์ที่มี
3. ส่งการแจ้งเตือนไปยังผู้ขับขี่เพื่อรับการจอง
4. คนขับรับการจอง

สมมติว่าการส่งข้อความทั้งหมดทำได้ผ่านการโทร http แทนที่จะส่งข้อความบัสเช่นคาฟคาเพื่อให้ทุกอย่างง่ายขึ้น

ดังนั้นในกรณีนี้ฉันคิดว่าBookingบริการสามารถทำการตรวจสอบการจองที่มีอยู่ แต่ใครจะได้รับรายชื่อของไดรเวอร์และการแจ้งเตือนที่มีอยู่ ฉันกำลังคิดที่จะทำในระดับเกตเวย์ แต่ตอนนี้ตรรกะแบ่งออกเป็นสองที่:

• Gateway - รับรายการไดรเวอร์ที่มีอยู่ + ส่งการแจ้งเตือน
• Booking - ตรวจสอบการจองที่มีอยู่

และฉันค่อนข้างแน่ใจว่าเกตเวย์ไม่ใช่สถานที่ที่เหมาะสมที่จะทำ แต่ฉันรู้สึกว่าถ้าเราทำในBookingบริการมันจะกลายเป็นคู่แน่น?

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

อีกวิธีหนึ่งในการทำฉันคิดว่าแต่ละโครงการมีบริการจองของตัวเองที่จะพูดคุยกับบริการจองหลัก แต่ฉันไม่แน่ใจว่าวิธีที่ดีที่สุดที่นี่ :-)

ผู้คนมักได้ยิน "บริการไมโคร" และคิดว่า "บริการนาโน" และสิ่งนี้อาจทำให้เกิดความสับสน นี่คือบริการไมโครดังนั้นคุณไม่จำเป็นต้องมีบริการแยกต่างหากสำหรับทุกเอนทิตีเดียว ทุกสิ่งที่คุณพยายามทำควรอยู่ในbookingและnotificationบริการ คุณไม่ต้องการdriverบริการ (สำหรับกิจกรรมใด ๆ ที่คุณอธิบาย)

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

ตอนนี้สำหรับการนำกลับมาใช้ซ้ำข้อดีของการมี micro-service แยกต่างหากคือตอนนี้คุณสามารถมีสามทีมแยกกันทำให้ผู้บริโภคหันมาใช้แอพ ทีมเดียวสำหรับแอปเว็บ html มาตรฐานแอป Android และแอป iOS แอปพลิเคชั่นที่แตกต่างกันทั้งหมดนี้สามารถสร้างได้แตกต่างกันโดยสิ้นเชิงและดูเหมาะสมกับแพลตฟอร์มเฉพาะของพวกเขา (โดยไม่ต้องใช้รหัสซ้ำ) bookingรหัสบริการนำกลับมาใช้โดยทั้งสามของปพลิเคชันเหล่านี้เพราะทั้งสามปพลิเคชันโทร http การให้บริการแทนมีรหัสการจองห้องพักของตัวเอง

ขั้นตอนการจองทั่วไปจะมีลักษณะเช่นนี้:

1. แอพ android เรียกใช้bookingบริการเพื่อรับรายการไดรเวอร์ที่มี
2. บริการจองจะส่งคืนรายการไดรเวอร์ไปยังแอป
3. จากนั้นผู้ใช้เลือกไดรเวอร์ของพวกเขาและแอปเรียกว่า "หนังสือ" วิธีการbookingให้บริการ
4. bookingบริการบริการเรียกnotificationบริการที่มีรายละเอียดการจองห้องพัก
5. notificationบริการส่งการแจ้งเตือนให้คนขับรถ, แจ้งให้ทราบของการจองห้องพัก
6. แอพไดรเวอร์ส่งข้อความไปยังnotificationบริการเมื่อลูกค้าอยู่ในระยะทางไม่เกินหนึ่งไมล์ของลูกค้า
7. notificationบริการส่งการแจ้งเตือนให้กับลูกค้าว่าคนขับรถของพวกเขาเกือบจะมี

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

ทุกอย่างขึ้นอยู่กับความต้องการที่แน่นอนของคุณ

สมมติว่าคุณมีสองแอปพลิเคชันที่ทำการจอง:

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

สำหรับระบบการแจ้งเตือนคุณสามารถให้ microservices เชื่อมต่อกับบริการจองของคุณเพื่อรับฟังการจองใหม่ ๆ เช่นเดียวกับแผนกบริการการจองจะแจ้งให้สมาชิกทุกท่านทราบและจะดำเนินการตามนั้น

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

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

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

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