บริการควรพูดคุยกันโดยตรงในสถาปัตยกรรมบริการไมโครสโคปหรือไม่?

ฉันมีเว็บเซอร์วิสจำนวนหนึ่งที่รวมเป็นเว็บแอปพลิเคชัน ลูกค้าสามารถเข้าถึงบริการเหล่านี้ผ่านการเรียกใช้ REST API

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

ลูกค้าควรเรียกพวกเขาโดยตรงเพื่อรับข้อมูลที่จำเป็นในการโหลดหน้าเว็บบนไคลเอนต์หรือไม่

หรือฉันควรมีเลเยอร์อื่นอยู่ด้านบนของบริการที่จัดการการร้องขอจากไคลเอนต์ดึงข้อมูลสำหรับการร้องขอนั้นแล้วส่งกลับไปยังไคลเอนต์หรือไม่

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

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

ฉันไม่เห็นด้วยกับ @Robert Harvey

อย่างไรก็ตามในทางปฏิบัติ microservices ของคุณหนึ่งอันหรือมากกว่านั้น (อาจทั้งหมด) จะพูดคุยกับแหล่งข้อมูลส่วนกลางบางแห่งเช่นฐานข้อมูล SQL

ฐานข้อมูลการรวมเป็นที่รู้จักกันดี antipattern

ทางออกที่ดีกว่าคือการใช้รูปแบบการประกาศสมัครสมาชิกเพื่อให้การสื่อสารระหว่างบริการของคุณไม่ตรงกัน:

โปรดดูวิธีการใช้ CQRS / ES ในการใช้วิธีการสื่อสารนี้เกร็กยังและคนอื่น ๆเสนอวิดีโอดีๆมากมายในหัวข้อนี้ เพียง google สำหรับคำหลัก "CQRS / ES" ในวิธีการนี้แต่ละบริการจะกลายเป็นผู้เผยแพร่และผู้สมัครสมาชิกในเวลาเดียวกัน

นี่คือบทความที่ดีเกี่ยวกับไมโครไซต์ที่ให้ความกระจ่างเกี่ยวกับการโต้เถียงรอบหัวข้อ คำอธิบายโดยละเอียดพร้อมภาพประกอบที่ดีมาก

คุณจะได้รับจำนวนมากของความคิดที่ดีมากจากการอ่านสิ่งที่ Udi Dahan ได้กล่าวเกี่ยวกับSOA

บริการเป็นหน่วยงานด้านเทคนิคสำหรับความสามารถทางธุรกิจที่เฉพาะเจาะจง ข้อมูลหรือกฎใด ๆ จะต้องเป็นของบริการเดียวเท่านั้น

สิ่งนี้หมายความว่าแม้เมื่อบริการกำลังเผยแพร่และสมัครสมาชิกกิจกรรมของกันและกันเราก็รู้อยู่เสมอว่าแหล่งข้อมูลความจริงที่เชื่อถือได้นั้นมีไว้สำหรับข้อมูลและกฎทุกชิ้น

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

โดยเฉพาะเกี่ยวกับองค์ประกอบของUIบทความของ Mauro Servienti เกี่ยวกับองค์ประกอบของ UIเป็นจุดเริ่มต้นที่ดี ดูเพิ่มเติมวิดีโอ Udi ของที่นี่

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

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

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

ขึ้นอยู่กับสิ่งที่คุณหมายถึงโดย "โดยตรง"

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

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

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

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

สิ่งที่คุณกำลังจริงๆหลังจากที่มี microservices เป็นcoupling หลวม ; คุณสามารถทำได้โดยเพียงแค่มี microservice หนึ่งสอบปากคำผ่าน API สาธารณะหรือใช้ Event Bus

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

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

ฉันแน่ใจว่าบางคนจะบอกว่านี่ไม่ใช่คำตอบ แต่แล้วพวกเขาก็พลาดประเด็นไป สถาปัตยกรรมบริการไมโครมีจุดประสงค์เพื่อหลีกเลี่ยงปัญหาต่าง ๆ ในหมู่พวกเขาปัญหาของ "การแต่งงานกันอย่างแน่นหนา" ดังนั้นหากคุณจบการสร้างบริการไมโครที่ขึ้นอยู่กับรายละเอียดเล็ก ๆ น้อย ๆ มากเกินไปคุณก็จะสร้างคับคัปปลิ้งแน่น ๆ ไม่ว่าคุณจะใช้บัสข้อความย่อย pub / sub หรือโทรโดยตรง - ทำลาย ความสามารถของคุณในการเขียนคำตอบใหม่ ๆ จากชิ้นส่วนกำหนดค่าแต่ละชิ้นใหม่โดยไม่ทำให้ระบบทั้งหมด ฯลฯ

ลูกค้าควรเรียกพวกเขาโดยตรงเพื่อรับข้อมูลที่จำเป็นในการโหลดหน้าเว็บบนไคลเอนต์หรือไม่

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

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

ดังนั้นนั่นหมายความว่าด้วย microservices บางครั้งมันมีประโยชน์ที่จะมี microservice wrapper ที่ช่วยให้ลูกค้ามีจุดปลายที่มี abstractions ที่เป็นประโยชน์และมีการประสานงานระดับสูงของ microservices อื่น ๆ

(นอกจากนี้การไปกลับไปยังลูกค้าอาจมีราคาแพงกว่าจากไมโครไซต์ของคุณซึ่งกันและกัน)

ตัวอย่างเช่นหากคุณดูทิศทางที่ดำเนินการโดย GraphQL คุณจะพบว่าลูกค้าที่ออกข้อความค้นหาที่เกี่ยวข้องโดยตรงไปยังจุดสิ้นสุดซึ่งอาจนำไปใช้หรืออาจไม่ได้นำไปใช้เป็นชุดของ micrservices เนื่องจากสถาปัตยกรรมของ microservices ถูกซ่อนอยู่ด้านหลัง GraphQL ทำให้สถาปัตยกรรมสามารถปรับโครงสร้างได้ง่ายขึ้นและเป็นมิตรกับลูกค้า ดูตัวอย่างเช่นhttps://stackoverflow.com/a/38079681/471129

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