สถาปัตยกรรม GraphQL และ Microservice

ฉันพยายามเข้าใจว่า GraphQL เหมาะสมที่สุดที่จะใช้ภายในสถาปัตยกรรม Microservice หรือไม่

มีการถกเถียงกันเกี่ยวกับการมีสกีมา GraphQL เพียง 1 ตัวที่ทำหน้าที่เป็น API เกตเวย์เป็นผู้รับการร้องขอไปยังไมโครไซต์เป้าหมายและบีบบังคับการตอบสนองของพวกเขา Microservices ยังคงใช้โปรโตคอล REST / Thrift สำหรับการสื่อสารความคิด

อีกวิธีหนึ่งคือการมีหลาย ๆ สโคป GraphQL หนึ่งรายการต่อ microservice แทน มีเซิร์ฟเวอร์ API เกตเวย์ขนาดเล็กกว่าซึ่งกำหนดเส้นทางการร้องขอไปยัง microservice เป้าหมายด้วยข้อมูลทั้งหมดของคำขอ + แบบสอบถาม GraphQL

แนวทางที่ 1

การมี 1 GraphQL Schema เป็น API Gateway จะมีข้อเสียที่ทุกครั้งที่คุณเปลี่ยนอินพุต / เอาต์พุตสัญญา microservice ของคุณเราต้องเปลี่ยน GraphQL Schema ตามด้าน API Gateway

แนวทางที่ 2

หากใช้หลาย GraphQL Schema ต่อ microservices ให้เหตุผลเพราะ GraphQL บังคับใช้ข้อกำหนด schema และผู้บริโภคจะต้องเคารพอินพุต / เอาต์พุตที่ได้รับจาก microservice

คำถาม

• คุณคิดว่า GraphQL เหมาะสมกับการออกแบบสถาปัตยกรรมบริการไมโครหรือไม่?

• คุณจะออกแบบ API Gateway ด้วยการใช้ GraphQL ที่เป็นไปได้อย่างไร

เข้าหา # 1 อย่างแน่นอน

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

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

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

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

ดูบทความที่นี่ซึ่งบอกวิธีและเหตุผลที่ # 1 ทำงานได้ดีขึ้น ดูภาพด้านล่างที่นำมาจากบทความที่ฉันพูดถึงด้วย:

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

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

บทความต่อไปนี้อธิบายถึงประโยชน์ทั้งสองนี้พร้อมกับประโยชน์อื่น ๆ ได้เป็นอย่างดี: https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/

สำหรับวิธีที่ # 2 ในความเป็นจริงเป็นวิธีที่ฉันเลือกเพราะง่ายกว่าการบำรุงรักษาเกตเวย์ API ด้วยตนเองที่น่ารำคาญ ด้วยวิธีนี้คุณสามารถพัฒนาบริการของคุณได้อย่างอิสระ ทำให้ชีวิตง่ายขึ้นมาก: หน้า

มีเครื่องมือที่ยอดเยี่ยมในการรวม schemas ไว้ในที่เดียวเช่นgraphql-weaverและgraphql-toolsของ apollo ที่ฉันใช้graphql-weaverมันใช้งานง่ายและใช้งานได้ดี

ในช่วงกลางปี ​​2562 การแก้ปัญหาสำหรับแนวทางที่ 1ตอนนี้มีชื่อว่า " สหพันธ์สคีมา " ประกาศเกียรติคุณจากคนอพอลโล (ก่อนหน้านี้มักเรียกกันว่าการเย็บ GraphQL) พวกเขายังเสนอโมดูล@apollo/federationและ@apollo/gatewayสำหรับสิ่งนี้

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

ตั้งแต่ปี 2019 วิธีที่ดีที่สุดคือการเขียน microservises ที่ใช้สเปคเกตเวย์ของอพอลโลและเชื่อมโยงบริการเหล่านี้เข้าด้วยกันโดยใช้เกตเวย์ตามแนวทาง # 1 วิธีที่เร็วที่สุดในการสร้างเกตเวย์คือภาพนักเทียบท่าเช่นนี้ จากนั้นใช้นักเทียบท่าประกอบเพื่อเริ่มบริการทั้งหมดพร้อมกัน:

version: '3'

services:
    service1:
        build: service1
    service2:
        build: service2
    gateway:
        ports:
            - 80:80
        image: xmorse/apollo-federation-gateway
        environment: 
            - CACHE_MAX_AGE=5
            - "FORWARD_HEADERS=Authorization, X-Custom-Header" # default is Authorization, pass '' to reset
            - URL_0=http://service1
            - URL_1=http://service2

วิธีที่อธิบายไว้ในคำถามนี้ฉันเชื่อว่าการใช้เกตเวย์ API ที่กำหนดเองเป็นบริการการประสานงานสามารถทำให้รู้สึกสมเหตุสมผลสำหรับแอปพลิเคชันที่เน้นองค์กรขนาดใหญ่ GraphQL สามารถเป็นตัวเลือกเทคโนโลยีที่ดีสำหรับบริการ orchestration ดังกล่าว ข้อดีของวิธีการแรกของคุณ (หนึ่งสคีมาสำหรับ microservices ทั้งหมด) คือความสามารถในการต่อข้อมูลจากหลาย microservices เข้าด้วยกันในคำขอเดียว นั่นอาจจะหรืออาจจะไม่สำคัญมากขึ้นอยู่กับสถานการณ์ของคุณ หาก GUI เรียกใช้การเรนเดอร์ข้อมูลจากหลายไมโครไซต์ทั้งหมดในคราวเดียววิธีการนี้จะทำให้รหัสไคลเอนต์ง่ายขึ้นซึ่งการเรียกครั้งเดียวสามารถส่งคืนข้อมูลที่เหมาะสำหรับการผูกข้อมูลกับองค์ประกอบ GUI ของเฟรมเวิร์คเช่น Angular หรือ React ข้อได้เปรียบนี้ใช้ไม่ได้กับการกลายพันธุ์

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

ในการเปรียบเทียบGraphQL กับ REST นี้คุณจะพบว่า GraphQL นั้นมีประสิทธิภาพไม่มากเท่ากับ RESTful APIs ดังนั้นฉันไม่แนะนำให้แทนที่ REST ด้วย GraphQL สำหรับ API ข้อมูล

คำถามที่ 1 Intuit รับทราบพลังของ GraphQL เมื่อไม่กี่ปีที่ผ่านมาเมื่อมีการประกาศย้ายไปยังระบบนิเวศของ API หนึ่ง Intuit ( https://www.slideshare.net/IntuitDeveloper/building-the-next-generation-of-quickbooks-app-integrations) -quickbooks-connect-2017 ) ตรัสรู้เลือกที่จะไปด้วยวิธีที่ 1 ข้อเสียเปรียบที่คุณพูดถึงป้องกันนักพัฒนาจากการแนะนำการเปลี่ยนแปลง schema ที่อาจทำลายแอปพลิเคชันไคลเอนต์

GraphQL ช่วยปรับปรุงประสิทธิภาพของนักพัฒนาซอฟต์แวร์ได้หลายวิธี

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

2. GraphQL ช่วยให้แอปพลิเคชันไคลเอนต์ง่ายขึ้นและเร็วขึ้น ต้องการดึงข้อมูลจาก / อัปเดตข้อมูลเป็นหลายไมโครไซต์หรือไม่ แอปพลิเคชันไคลเอนต์ทั้งหมดต้องดำเนินการตามคำขอ ONE GraphQL และเลเยอร์นามธรรมเกตเวย์ API จะใช้ความระมัดระวังในการดึงและตรวจสอบข้อมูลจากหลายแหล่ง (ไมโครไซต์) เฟรมเวิร์กโอเพนซอร์สเช่น Apollo ( https://www.apollographql.com/ ) ได้ช่วยเร่งการยอมรับ GraphQL

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

คำถามที่ 2: เราสร้างเลเยอร์นามธรรมที่กำหนดเองที่ API เกตเวย์ที่รู้ว่าส่วนใดของสคีมาที่เป็นเจ้าของโดยบริการใด (ผู้ให้บริการ) เมื่อมีการร้องขอคิวรีมาถึงเลเยอร์นามธรรมจะส่งต่อคำร้องขอไปยังบริการที่เหมาะสม เมื่อบริการพื้นฐานส่งกลับการตอบสนองเลเยอร์นามธรรมมีหน้าที่ส่งคืนฟิลด์ที่ร้องขอ

อย่างไรก็ตามในวันนี้มีหลายแพลตฟอร์มอยู่ที่นั่น (เซิร์ฟเวอร์ Apollo, graphql-yoga, ฯลฯ ) ที่อนุญาตให้หนึ่งสร้างเลเยอร์นามธรรม GraphQL ในเวลาไม่นาน

ฉันทำงานกับ GraphQL และบริการไมโคร

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

ตัวอย่างจากภาพของคำตอบจาก Enayat สิ่งที่ฉันจะทำในกรณีนี้คือมี 3 กราฟเกตเวย์ (ไม่ใช่ 5 เหมือนในภาพ)

• แอพ (ผลิตภัณฑ์, ตะกร้า, การจัดส่ง, สินค้าคงคลัง, จำเป็น / เชื่อมโยงกับบริการอื่น ๆ )

• การชำระเงิน

• ผู้ใช้งาน

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

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

วิธีนี้ง่ายกว่าที่จะ ...

• ปรับขนาด / ปิดโหนดเกตเวย์ที่แตกต่างกันขึ้นอยู่กับการใช้งาน (ตัวอย่างเช่นผู้คนอาจไม่ได้แก้ไขโปรไฟล์หรือจ่ายเงิน ... แต่การค้นหาผลิตภัณฑ์อาจถูกใช้บ่อยกว่า)

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

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

UPDATE:

ฉันมี kubernetes คลัสเตอร์ออนไลน์ที่ใช้วิธีการเดียวกับที่ฉันอธิบายที่นี่กับแบ็กเอนด์ทั้งหมดที่ใช้ GraphQL, opensource ทั้งหมดที่นี่เป็นที่เก็บหลัก: https://github.com/vicjicaman/microservice-realm

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

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

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