คำถามติดแท็ก microservices

เบื้องหน้า เรากำลังเปลี่ยนจากแพลตฟอร์มเสาหินเป็นสถาปัตยกรรมที่เน้นการบริการมากขึ้น เราใช้หลักการ DDD ขั้นพื้นฐานมากและแยกโดเมนของเรากับบริบทที่แตกต่างกัน แต่ละโดเมนมีการกระจายและเปิดเผยบริการผ่านเว็บ API (REST) เนื่องจากลักษณะของธุรกิจของเราเรามีบริการเช่นการจอง , บริการ , ลูกค้า , ผลิตภัณฑ์ฯลฯ เรายังได้ติดตั้งเซิร์ฟเวอร์ข้อมูลประจำตัว (ขึ้นอยู่กับเซิร์ฟเวอร์ข้อมูลประจำตัวของ Thinktecture 3) ซึ่งมีบทบาทหลักคือ: การพิสูจน์ตัวตนจากศูนย์กลาง (ให้ข้อมูลรับรองว่ามันเป็นปัญหาโทเค็น) เพิ่มการอ้างสิทธิ์ในโทเค็นเช่น: ขอบเขตของลูกค้า (ตามลูกค้าฉันหมายถึงแอปพลิเคชันที่ทำการร้องขอ), ตัวระบุลูกค้า (ตามลูกค้าฉันหมายถึงบุคคลที่ใช้แอปพลิเคชัน) นอกจากนี้เรายังแนะนำบทบาทของAPI เกตเวย์ซึ่งเป็นศูนย์กลางการเข้าถึงจากภายนอกสู่บริการของเรา API Gateway มีฟังก์ชันที่ไม่ต้องการความรู้อย่างลึกซึ้งเกี่ยวกับโดเมนภายในเช่น: Reverse proxy: กำหนดเส้นทางคำขอที่เข้ามาในบริการภายในที่เหมาะสม การกำหนดเวอร์ชัน: เวอร์ชันของ API เกตเวย์จับคู่กับเวอร์ชันต่างๆของบริการภายใน การตรวจสอบความถูกต้อง: คำขอของลูกค้ารวมถึงโทเค็นที่ออกโดยเซิร์ฟเวอร์ประจำตัวและ API เกตเวย์ตรวจสอบโทเค็น (ตรวจสอบให้แน่ใจว่าผู้ใช้คือใครบอกว่าเธอเป็น) การควบคุมปริมาณ: จำกัด จำนวนการร้องขอต่อลูกค้า การอนุญาต สิ่งที่เกี่ยวข้องกับการอนุญาตนี้ไม่ได้รับการจัดการใน API …

19 api  microservices  soa  authorization 

ฉันค่อนข้างใหม่กับสถาปัตยกรรมไมโครเซอร์วิส เรามีเว็บแอปพลิเคชันขนาดปานกลางและฉันชั่งน้ำหนักข้อดีและข้อเสียของการแบ่งมันออกเป็น microservices แทนระบบเสาหินที่เราได้ก้าวไปข้างหน้า เท่าที่ฉันเข้าใจพิจารณา microservices AและBแต่ละรายการนั้นอาศัยชุดย่อยของข้อมูลที่อีกฝ่ายมี หากข้อความถูกโพสต์โดยAบอกว่ามีบางอย่างเปลี่ยนแปลงBสามารถใช้ข้อความนั้นและทำซ้ำสำเนาของAข้อมูลในเครื่องและใช้สิ่งนั้นเพื่อทำสิ่งที่Bต้องทำ อย่างไรก็ตามจะเกิดอะไรขึ้นถ้าBลงไป / ล้มเหลวและหลังจากนั้นไม่นานก็กลับมาอีกครั้ง ในช่วงเวลาดังกล่าวAได้เผยแพร่ข้อความอีกสองข้อความ จะBทราบวิธีการอัปเดตAข้อมูลในเครื่องได้อย่างไร? จริงอยู่ถ้าBเป็นผู้บริโภคAคิวเพียงคนเดียวก็สามารถเริ่มอ่านได้เมื่อกลับมาออนไลน์ แต่จะเกิดอะไรขึ้นถ้ามีผู้บริโภครายอื่นของคิวนั้นและข้อความเหล่านั้นถูกบริโภค? เป็นตัวอย่างที่ชัดเจนยิ่งขึ้นถ้าUsersบริการมีการปรับปรุงที่อยู่อีเมลในขณะที่บริการBillingไมโครซอฟต์ล่มหากบริการBillingไมโครซอฟท์กลับมาอีกครั้งจะรู้ได้อย่างไรว่าอีเมลนั้นได้รับการปรับปรุงแล้ว? เมื่อ microservices กลับมารายการออกอากาศจะพูดว่า "เฮ้ฉันสำรองข้อมูลเอาข้อมูลปัจจุบันของคุณทั้งหมดให้ฉันหรือเปล่า" โดยทั่วไปแล้ววิธีปฏิบัติทางอุตสาหกรรมที่ดีที่สุดสำหรับการซิงโครไนซ์ข้อมูลคืออะไร

19 database  microservices 

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

19 microservices 

ทีมของฉันกำลังย้ายจากแอปพลิเคชัน ASP.NET แบบเสาหินไปยัง. NET Core และ Kubernetes การเปลี่ยนแปลงรหัสดูเหมือนจะเป็นไปตามคาด แต่ทีมของฉันกำลังเผชิญกับความไม่ลงรอยกันอยู่รอบฐานข้อมูล ขณะนี้เรามีฐานข้อมูล SQL Server ค่อนข้างใหญ่ที่รวบรวมข้อมูลทั้งหมดสำหรับธุรกิจทั้งหมดของเรา ฉันเสนอให้เราแยกฐานข้อมูลในลักษณะที่คล้ายคลึงกับการแยกรหัส - ข้อมูลแคตตาล็อกในฐานข้อมูลหนึ่ง (ตรรกะ) ข้อมูลสินค้าคงคลังในอีกคำสั่งซื้อในอื่นและอื่น ๆ - และแต่ละ microservice จะเป็นผู้ดูแลฐานข้อมูลของมัน . ความหมายที่นี่คือกุญแจต่างประเทศที่ข้ามขอบเขตการให้บริการจะต้องถูกลบออก แบบจำลองข้อมูลทั้งหมดอาจหรือไม่อาจอยู่ในฐานข้อมูลทางกายภาพเดียวกัน แต่แม้ว่าพวกเขาทำแบบนั้นพวกเขาไม่ควรโต้ตอบกันโดยตรง คำสั่งซื้ออาจยังคงอ้างอิงรายการแคตตาล็อกโดย Id แต่ความสมบูรณ์ของข้อมูลจะไม่ถูกบังคับใช้อย่างเคร่งครัดในระดับฐานข้อมูลและข้อมูลนั้นจะต้องเข้าร่วมในรหัสมากกว่าใน SQL ฉันเห็นการสูญเสียสิ่งเหล่านี้เมื่อมีการแลกเปลี่ยนที่จำเป็นเมื่อต้องย้ายไปที่ไมโครเซอร์วิสและรับผลประโยชน์ที่ปรับขนาดได้ที่มาพร้อมกับ ตราบใดที่เราเลือกตะเข็บของเราอย่างชาญฉลาดและพัฒนาไปรอบ ๆ มันก็น่าจะดี สมาชิกในทีมคนอื่น ๆ ยืนกรานว่าทุกอย่างจะต้องอยู่ในฐานข้อมูลเสาหินเดียวกันดังนั้นทุกอย่างสามารถเป็นกรดและรักษาความสมบูรณ์ของการอ้างอิงได้ทุกที่ สิ่งนี้นำมาสู่คำถามของฉัน ก่อนอื่นท่าทางของฉันเกี่ยวกับข้อ จำกัด ของคีย์ต่างประเทศและเข้าร่วมเป็นไปได้หรือไม่ ถ้าเป็นเช่นนั้นมีใครรู้บ้างเกี่ยวกับวัสดุการอ่านที่น่าเชื่อถือที่ฉันสามารถเสนอให้เพื่อนร่วมงานของฉันได้หรือไม่? ตำแหน่งของพวกเขาเกือบจะเป็นศาสนาและพวกเขาดูเหมือนว่าพวกเขาจะถูกครอบงำด้วยอะไรก็ตามที่สั้น ๆ ของ Martin Fowler เขาบอกพวกเขาว่าพวกเขาผิด

18 architecture  database  refactoring  microservices 

เมื่ออ่านเกี่ยวกับ API เกตเวย์สิ่งหนึ่งที่เกิดขึ้นทุกครั้งคือ API เกตเวย์เป็นสถานที่ที่คุณควรรวมผลลัพธ์จากจุดปลายหลายจุด ฟังดูดีจริงๆ อย่างไรก็ตามโซลูชันเกตเวย์ API ยอดนิยมจำนวนมากเช่น AWS API Gateway, Kongo และ Netflix Zuul ไม่สนับสนุนคุณสมบัติดังกล่าว คุณต้องแฮ็คหรือใช้ตัวกรองที่กำหนดเองได้ การรวมตัวกันถือว่าเป็นการปฏิบัติที่ไม่ดีหรือไม่? ผู้คนส่งคืนผลลัพธ์จากหลายจุดสิ้นสุดได้อย่างไร

16 rest  api  microservices 

ฉันมี microservices มากมายที่มีฟังก์ชั่นที่ฉันเปิดเผยผ่าน REST API ตามรูปแบบเกตเวย์ API เนื่องจาก microservices เหล่านี้เป็นแอปพลิเคชั่น Spring Boot ฉันจึงใช้ Spring AMQP เพื่อให้เกิดการสื่อสารแบบซิงโครนัสสไตล์ RPC ระหว่างไมโครไซต์เหล่านี้ สิ่งต่าง ๆ ราบรื่นไปแล้ว อย่างไรก็ตามยิ่งฉันอ่านเกี่ยวกับสถาปัตยกรรม microservice ที่ขับเคลื่อนด้วยเหตุการณ์มากขึ้นและดูโครงการเช่น Spring Cloud Stream ยิ่งฉันเชื่อมั่นมากขึ้นว่าฉันอาจทำสิ่งที่ผิดกับ RPC วิธีการแบบซิงโครนัส เพื่อตอบสนองการร้องขอนับร้อยหรือพันต่อวินาทีจากแอปพลิเคชันไคลเอนต์) ฉันเข้าใจจุดหลังสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ สิ่งที่ฉันไม่ค่อยเข้าใจคือวิธีการใช้รูปแบบดังกล่าวจริงเมื่อนั่งอยู่ข้างหลังแบบจำลอง (REST) ​​ที่คาดว่าจะตอบสนองต่อทุกคำขอ ตัวอย่างเช่นถ้าฉันมีเกตเวย์ API เป็น microservice และอีกบริการหนึ่งที่เก็บและจัดการผู้ใช้ฉันจะสร้างแบบจำลองเช่นGET /users/1ในเหตุการณ์ที่ขับเคลื่อนด้วยเหตุการณ์ได้อย่างหมดจดได้อย่างไร

16 spring  asynchronous-programming  microservices  event 

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

16 rest  api  web-services  microservices 

TL; DR - การใช้ไลบรารี POJO ร่วมกันระหว่างบริการต่าง ๆ เป็นเรื่องปกติไหม โดยทั่วไปเราต้องการให้การแบ่งปันระหว่างบริการ จำกัด อย่างเข้มงวดเป็นไม่ถ้าเป็นไปได้ มีการถกเถียงกันบ้างหรือไม่ว่าบริการที่ใช้ข้อมูลร่วมกันนั้นควรจัดให้มีห้องสมุดลูกค้าให้ลูกค้าใช้หรือไม่ โดยทั่วไปแล้ว client-lib นั้นเป็นทางเลือกสำหรับลูกค้าของบริการที่จะใช้และสามารถใช้งาน API ได้อย่างไรก็ตามพวกเขาจะโปรดใช้ว่าจะใช้ client-lib หรือใช้ภาษาอื่นและใช้ลักษณะทั่วไปของไลบรารีและเช่นนั้น ในกรณีของฉัน - ฉันพิจารณาบริการที่สร้างวัตถุของข้อมูล สมมติว่าวัตถุนี้เป็นสัตว์เลี้ยง มันไม่ใช่เอนทิตีของฐานข้อมูล แต่เป็น POJO ที่แสดงถึงข้อมูลพื้นฐานโดยนัย POJO นี้เป็นสิ่งที่ API ได้กำหนดไว้ สมมติว่า: สัตว์เลี้ยง - อายุ, น้ำหนัก, ชื่อ, เจ้าของ, ที่อยู่, สปีชี่ ฯลฯ บริการ 1 - PetKeeper: มันจะสร้างสัตว์เลี้ยงด้วยเหตุผลใดก็ตามและเก็บข้อมูลทั้งหมดไว้และต้องอ้างอิงบริการนี้เพื่อรับสัตว์เลี้ยงหรือทำการดัดแปลงสัตว์เลี้ยงให้พูดการเปลี่ยนชื่อหรือการเปลี่ยนที่อยู่จะต้องทำผ่าน การเรียก API ไปยังบริการนี้ บริการ …

15 java  dto  microservices 

ฉันได้อ่านเกี่ยวกับบริการไมโครเมื่อไม่นานมานี้และนี่คือข้อสรุปบางอย่างที่ฉันได้รับ (โปรดแก้ไขฉันหากฉันผิดที่จุดใด) สถาปัตยกรรมบริการไมโครเป็นไปด้วยดีกับการออกแบบที่ขับเคลื่อนด้วยโดเมน โดยทั่วไปแล้วหนึ่ง MS หมายถึงบริบทที่มีขอบเขตหนึ่ง ถ้า micro-service Aต้องการฟังก์ชันที่อยู่ใน micro-service BโมเดลของฉันอาจผิดและAและB ควรเป็น micro-service / BC หนึ่งอัน การสื่อสารแบบซิงโครนัสระหว่างบริการไมโคร (คำขอ HTTP โดยตรง) ไม่ดีทำให้ขัดต่อวัตถุประสงค์ของบริการไมโครและแนะนำการมีเพศสัมพันธ์ระหว่างส่วนประกอบ การสื่อสารแบบอะซิงโครนัสระหว่างบริการเป็นที่ต้องการ บริการควรเผยแพร่กิจกรรมไปยังคิวข้อความเพื่อให้บริการอื่น ๆ สามารถสมัครและประมวลผลส่วนหนึ่งของเหตุการณ์หรือใช้เพื่อทำซ้ำส่วนของข้อมูลที่จำเป็นสำหรับบริบทของพวกเขา วิธีนี้บริการสามารถดำเนินการตามคำขอแม้บริการอื่น ๆ จะหยุดทำงานซึ่งไม่ได้เกิดขึ้นในการสื่อสารแบบซิงโครนัส ถ้า micro-service Aเผยแพร่เหตุการณ์, micro-service Bสมัครสมาชิกกับเหตุการณ์นั้นและสร้างเหตุการณ์ใหม่เป็นผลลัพธ์, micro-service Aไม่ควรเป็นการประมวลผลเหตุการณ์ที่สร้างขึ้นใหม่, ซึ่งจะเป็นการอ้างอิงแบบวงกลม ในกรณีนี้เราควรแนะนำบริการไมโครที่สามหรือรวมAและBเข้ากับบริการไมโครAB บริการไมโครเป็นจริงคำที่ทำให้เข้าใจผิด เราควรพยายามเพื่อบริบทขนาดเล็ก แต่ไม่จำเป็นต้องเป็นกรณี คำไม่ควรเป็น "บริการไมโคร" แต่ " ใหญ่พอที่จะทำงานบริการ " บริการไมโครช่วยให้เราสามารถแนะนำฟังก์ชั่นใหม่ได้อย่างง่ายดายและไม่ต้องกลัวว่าเราจะทำลายทั้งระบบ มันสามารถทำได้โดยการแนะนำบริการใหม่หรือ refactoring หนึ่งในที่มีอยู่ …

15 architecture  domain-driven-design  soa  microservices 

เราวางแผนที่จะปรับระบบของ บริษัท ให้เป็นระบบที่ใช้บริการแบบไมโคร บริการไมโครนี้จะถูกใช้โดยแอปพลิเคชันภายใน บริษัท ของเราและโดยคู่ค้าบุคคลที่สามหากจำเป็น หนึ่งสำหรับการจองหนึ่งสำหรับผลิตภัณฑ์ ฯลฯ เราไม่แน่ใจว่าจะจัดการกับบทบาทและขอบเขตอย่างไร แนวคิดคือการสร้างบทบาทผู้ใช้พื้นฐาน 3 ประการเช่นผู้ดูแลระบบตัวแทนและผู้ใช้ขั้นปลายและให้แอพสำหรับผู้บริโภคปรับขอบเขตหากจำเป็น ผู้ดูแลระบบสามารถสร้างอัปเดตอ่านและลบทรัพยากรทั้งหมดตามค่าเริ่มต้น (สำหรับ บริษัท ของพวกเขา) ตัวแทนสามารถสร้างอัปเดตและอ่านข้อมูลสำหรับ บริษัท ของพวกเขา ผู้ใช้ปลายทางสามารถสร้างอัปเดตลบและอ่านข้อมูล แต่ไม่สามารถเข้าถึงจุดปลายเดียวกันกับตัวแทนหรือผู้ดูแลระบบ พวกเขาจะสามารถสร้างหรือแก้ไขข้อมูลได้ไม่เพียง แต่อยู่ในระดับเดียวกับตัวแทนหรือผู้ดูแลระบบ ตัวอย่างเช่นผู้ใช้ปลายทางสามารถอัปเดตหรืออ่านข้อมูลบัญชีของพวกเขาเช่นเดียวกับเอเจนต์จะสามารถทำได้สำหรับพวกเขา แต่พวกเขาไม่สามารถดูหรืออัปเดตบันทึกของผู้ดูแลระบบได้ สมมติว่าตัวแทนโดยค่าเริ่มต้นสามารถสร้างอ่านและอัปเดตแต่ละทรัพยากรสำหรับ บริษัท ของพวกเขาและนั่นคือขอบเขตสูงสุดของพวกเขาซึ่งสามารถขอโทเค็น / เซสชั่นของพวกเขา แต่นักพัฒนาของลูกค้า (ผู้บริโภค API) ได้ตัดสินใจว่า อ่านและสร้างทรัพยากรบางอย่างเท่านั้น เป็นวิธีปฏิบัติที่ดีกว่าในการจัดการเรื่องนี้ในการรักษาความปลอดภัยภายในของเราหรือไม่และปล่อยให้พวกเขาเขียนข้อมูลนั้นในฐานข้อมูลของเราหรือให้ลูกค้าจัดการกับสิ่งนั้นภายในโดยการร้องขอโทเค็นที่มีขอบเขตน้อยกว่า ? วิธีนี้เราจะต้องติดตามขอบเขตโทเค็นเท่านั้น ข้อเสียของสิ่งนี้คือทีมของเราจะต้องสร้างกลไกการเข้าถึงที่ปรับแต่งในแอปพลิเคชันภายในของเรา ด้วยวิธีคิดนี้บริการไมโครและระบบการอนุญาตไม่ควรใส่ใจกับความต้องการของลูกค้าเพราะพวกเขาเป็นเพียงผู้บริโภคและไม่ได้เป็นส่วนหนึ่งของระบบ (แม้ว่าผู้บริโภคเหล่านั้นจะเป็นแอพภายในของเราเอง)? การมอบหมายนี้เป็นแนวทางที่ดีหรือไม่?

15 security  authentication  microservices  authorization 

หนึ่งในข้อโต้แย้งที่พบบ่อยสำหรับการใช้ microservices คือความยืดหยุ่นที่ดีขึ้น แต่ฉันสงสัยว่าอาร์กิวเมนต์นี้ใช้ได้จริงหรือไม่ ช่วยบอกว่าเรามีแอปพลิเคชันซึ่งประกอบด้วย 10 microservice กับ 9 ในนั้นมีสองอินสแตนซ์ (สำหรับความซ้ำซ้อน) และหนึ่งในนั้นมี 4 อินสแตนซ์เพื่อจัดการกับโหลด (scalability) อาร์กิวเมนต์ pro-microservice จะทำให้คุณสามารถปรับขนาด miroservice นี้ได้อย่างอิสระจากบริการอื่น ๆ อย่างไรก็ตามสมมติว่า 10 microservices ทั้งหมดเป็นโมดูลในโมโนลิ ธ เดียวและอินสแตนซ์หลายตัวอย่าง (เช่น 22 จากผลรวมจากด้านบน) ของโมโนลิ ธ นี้ถูกปรับใช้ ระบบควรสามารถจัดการกับโหลดสำหรับส่วนที่สำคัญอย่างหนึ่งได้เนื่องจากมีอินสแตนซ์เพียงพอที่จะทำเช่นนั้น หากอินสแตนซ์นั้นมีโปรแกรมตรรกะไม่จำเป็นต้องมีข้อเสียเพียงอย่างเดียวคือว่าไบนารีและปริมาณ RAM ที่ต้องการจะใหญ่ขึ้นเล็กน้อย แต่จากนั้นอีกครั้งความแตกต่างไม่ควรใหญ่เกินไปในกรณีส่วนใหญ่ - อย่างน้อยก็ไม่ต้องเปรียบเทียบกับสแต็กที่เหลือ (คิดว่า Spring Boot) คว่ำของ monlith ที่ปรับขนาดจะเป็นระบบที่ง่ายขึ้นโดยไม่ต้อง (ส่วนใหญ่) ความผิดพลาดของระบบกระจาย ฉันพลาดอะไรไปรึเปล่า?

15 microservices 

เรากำลังพยายามหาวิธีที่ดีที่สุดในการอนุญาตผู้ใช้ในสถาปัตยกรรม microservice ในขณะที่มั่นใจว่า microservices มีสิทธิ์ จำกัด สถาปัตยกรรมของเราใช้บริการการอนุญาตจากส่วนกลางเพื่อจัดการการออกโทเค็น JWT เรามีข้อกำหนดดังต่อไปนี้: ผู้ใช้ควรถูก จำกัด ให้ดำเนินบทบาทบางอย่าง เช่นผู้ใช้ควรสามารถสร้าง / แก้ไข / อ่านเนื้อหาที่เขาเป็นเจ้าของได้เท่านั้น Microservices ควร จำกัด เฉพาะการอนุญาตที่จำเป็นเท่านั้น เช่นบริการไมโครเว็บที่เพียงต้องการอ่านข้อมูลจากบริการอื่นควรถูกห้ามอย่างชัดเจนจากการเขียนข้อมูลไปยังบริการนั้น ตัวอย่างเช่นสมมติว่าเรามีระบบที่ผู้ใช้สามารถอัปโหลดรูปภาพไปยังบริการเก็บรูปภาพ เรามีบริการติดแท็กที่ติดแท็กรูปภาพด้วยตำแหน่งโดยอัตโนมัติ ผู้ใช้สามารถ CRUD ภาพของตัวเอง บริการติดแท็กสามารถอ่านภาพใด ๆ จากบริการเก็บรูปภาพอย่างไรก็ตามไม่ควรแก้ไข / ลบ เป็นวิธีที่ดีในการบรรลุเป้าหมายข้างต้นโดยใช้โทเค็น JWT คืออะไร? วิธีแก้ปัญหาบางอย่างที่เรากล่าวถึงคือ: บริการเก็บรูปภาพแสดง 2 APIs หนึ่งที่พร้อมใช้งานภายนอก (ให้สิทธิ์การเข้าถึง CRUD ผู้ใช้) และอีกหนึ่งที่พร้อมใช้งานภายใน (ให้การเข้าถึงแบบอ่านอย่างเดียวภายใน) ดูเหมือนว่าไม่ยืดหยุ่น - จะเกิดอะไรขึ้นถ้าบริการภายในอื่นต้องการการเข้าถึงเพื่ออ่าน / เขียนภาพทั้งหมด …

13 security  microservices  jwt 

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

13 microservices  search 

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

13 testing  web-services  user-experience  microservices 

ฉันมีไมโครไซต์สองรายการ เราจะเรียกพวกเขาและAB ฐานข้อมูลภายใต้ microservice Aมีตารางต่อไปนี้: A |-- users ฐานข้อมูลภายใต้ microservice Bมีตารางต่อไปนี้: B |-- trackers ข้อกำหนดระบุว่าusersและtrackersมีความสัมพันธ์แบบกลุ่มต่อกลุ่ม ฉันไม่แน่ใจว่าจะจัดการสิ่งนี้ภายในสถาปัตยกรรม microservices อย่างไร ฉันเห็นการทำงานนี้หนึ่งในสามวิธี: user_trackersตารางจะถูกเพิ่ม AMICROSERVICE นี้ทำหน้าที่คล้ายกับตารางเข้าร่วมประกอบด้วย "คีย์ต่างประเทศ" เพื่อและuserstrackers ownersตารางจะถูกเพิ่ม BMICROSERVICE ตารางนี้ทำหน้าที่คล้ายกับตารางเข้าร่วม polymorphic นี่จะทำให้บริการใด ๆ สร้างการเชื่อมโยงกับตัวติดตาม สิ่งนี้อาจมีลักษณะเช่นนี้: B |-- trackers |-- owners |-- owner_id |-- owner_type |-- tracker_id เก็บบันทึกสำหรับusersและtrackersในแต่ละบริการไมโคร ทำให้พวกเขาซิงค์กับระบบ pubsub บางประเภท เดิมฉันจะไปกับตัวเลือก 2 เพราะฉันชอบที่มันรักษาขอบเขตการทำธุรกรรม …

13 microservices