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

7
จัดเตรียม microservices
รูปแบบมาตรฐานของ microservices จัดรูปแบบคืออะไร หาก microservice รู้เฉพาะเกี่ยวกับโดเมนของตัวเอง แต่มีการไหลของข้อมูลที่ต้องการให้บริการหลายอย่างมีปฏิสัมพันธ์ในบางลักษณะวิธีการเกี่ยวกับมันคืออะไร? สมมติว่าเรามีสิ่งนี้: ออกใบแจ้งหนี้ การส่งสินค้า และเพื่อประโยชน์ของการโต้แย้งสมมติว่าเมื่อมีการส่งคำสั่งซื้อควรสร้างใบแจ้งหนี้ ที่ไหนสักแห่งมีคนกดปุ่มในGUI"ฉันเสร็จแล้วลองทำสิ่งนี้!" ในสถาปัตยกรรมบริการ monolith แบบคลาสสิกฉันจะบอกว่ามีทั้งการESBจัดการนี้หรือบริการการจัดส่งมีความรู้เกี่ยวกับบริการใบแจ้งหนี้และเพียงเรียกว่า แต่อะไรคือวิธีที่ผู้คนจัดการกับสิ่งนี้ในโลกใหม่ที่กล้าหาญของการบริการระดับไมโคร? ฉันเข้าใจว่าเรื่องนี้ถือได้ว่าเป็นความคิดเห็นอย่างสูง แต่มีด้านที่เป็นรูปธรรมสำหรับมันเนื่องจาก microservices ไม่ควรทำข้างต้น ดังนั้นจะต้องมี "สิ่งที่ควรตามนิยามทำแทน" ซึ่งไม่ได้อิงตามความคิดเห็น ยิง.

10
การทำธุรกรรมทั่ว REST microservices?
สมมติว่าเรามี Microservices ผู้ใช้ Wallet REST และเกตเวย์ API ที่จับคู่สิ่งต่าง ๆ เข้าด้วยกัน เมื่อ Bob ลงทะเบียนในเว็บไซต์ของเราเกตเวย์ API ของเราจำเป็นต้องสร้างผู้ใช้ผ่าน microservice ของผู้ใช้และกระเป๋าเงินผ่าน microservice ของ Wallet ต่อไปนี้คือสถานการณ์บางอย่างที่อาจเกิดความผิดพลาด: การสร้างผู้ใช้ Bob ล้มเหลว: ไม่เป็นไรเราเพิ่งส่งคืนข้อความแสดงข้อผิดพลาดไปยัง Bob เรากำลังใช้ธุรกรรม SQL ดังนั้นจึงไม่มีใครเห็น Bob ในระบบ ทุกอย่างดี :) Bob ของผู้ใช้ถูกสร้างขึ้น แต่ก่อนที่จะสร้าง Wallet ของเราได้ API ของฮาร์ดไดรฟ์จะขัดข้อง ตอนนี้เรามีผู้ใช้ที่ไม่มีกระเป๋าเงิน (ข้อมูลไม่สอดคล้องกัน) Bob ผู้ใช้ถูกสร้างขึ้นและในขณะที่เรากำลังสร้าง Wallet การเชื่อมต่อ HTTP จะลดลง การสร้างกระเป๋าเงินอาจสำเร็จหรือไม่ได้ มีวิธีแก้ไขปัญหาใดบ้างที่ป้องกันไม่ให้เกิดความไม่สอดคล้องกันของข้อมูล …

10
สถาปัตยกรรม GraphQL และ Microservice
ฉันพยายามเข้าใจว่า GraphQL เหมาะสมที่สุดที่จะใช้ภายในสถาปัตยกรรม Microservice หรือไม่ มีการถกเถียงกันเกี่ยวกับการมีสกีมา GraphQL เพียง 1 ตัวที่ทำหน้าที่เป็น API เกตเวย์เป็นผู้รับการร้องขอไปยังไมโครไซต์เป้าหมายและบีบบังคับการตอบสนองของพวกเขา Microservices ยังคงใช้โปรโตคอล REST / Thrift สำหรับการสื่อสารความคิด อีกวิธีหนึ่งคือการมีหลาย ๆ สโคป GraphQL หนึ่งรายการต่อ microservice แทน มีเซิร์ฟเวอร์ API เกตเวย์ขนาดเล็กกว่าซึ่งกำหนดเส้นทางการร้องขอไปยัง microservice เป้าหมายด้วยข้อมูลทั้งหมดของคำขอ + แบบสอบถาม GraphQL แนวทางที่ 1 การมี 1 GraphQL Schema เป็น API Gateway จะมีข้อเสียที่ทุกครั้งที่คุณเปลี่ยนอินพุต / เอาต์พุตสัญญา microservice ของคุณเราต้องเปลี่ยน GraphQL Schema ตามด้าน …

3
กลยุทธ์การตรวจสอบความถูกต้องของ Microservice
ฉันมีปัญหาในการเลือกกลยุทธ์การตรวจสอบสิทธิ์ที่เหมาะสม / ปลอดภัยสำหรับสถาปัตยกรรมไมโครเซอร์วิส โพสต์ SO เดียวที่ฉันพบในหัวข้อนี้คือSingle Sign-On ใน Microservice Architecture ความคิดของฉันที่นี่คือการมีในแต่ละบริการ (เช่นการรับรองความถูกต้องการส่งข้อความการแจ้งเตือนโปรไฟล์ ฯลฯ ) การอ้างอิงที่ไม่ซ้ำกันสำหรับผู้ใช้แต่ละคน (ค่อนข้างมีเหตุผลแล้วของเขาuser_id) และความเป็นไปได้ที่จะรับผู้ใช้ปัจจุบันidหากเข้าสู่ระบบ จากการวิจัยของฉันฉันเห็นว่ามีสองกลยุทธ์ที่เป็นไปได้: 1. สถาปัตยกรรมที่ใช้ร่วมกัน ในกลยุทธ์นี้แอปตรวจสอบความถูกต้องเป็นหนึ่งในบริการอื่น ๆ แต่แต่ละบริการต้องสามารถทำการแปลงsession_id=> ได้user_idดังนั้นจึงต้องตายง่ายๆ นั่นเป็นเหตุผลที่ฉันนึกถึง Redis ซึ่งจะเก็บคีย์: ค่าsession_id:user_idไว้ 2. สถาปัตยกรรมไฟร์วอลล์ ในกลยุทธ์นี้การจัดเก็บเซสชันไม่ได้มีความสำคัญมากนักเนื่องจากได้รับการจัดการโดยแอปตรวจสอบสิทธิ์เท่านั้น จากนั้นuser_idสามารถส่งต่อไปยังบริการอื่น ๆ ฉันนึกถึง Rails + Devise (+ Redis หรือ mem-cached หรือที่เก็บคุกกี้ ฯลฯ ) แต่มีความเป็นไปได้มากมาย สิ่งเดียวที่สำคัญคือ Service X ไม่จำเป็นต้องตรวจสอบสิทธิ์ผู้ใช้ วิธีการแก้ปัญหาทั้งสองนี้เปรียบเทียบกันอย่างไรในแง่ของ: …

5
Microservices และการรวมฐานข้อมูล
สำหรับผู้ที่แยกแอปพลิเคชันเสาหินออกเป็นไมโครเซอร์วิสคุณจะจัดการกับปัญหาการแยกฐานข้อมูลได้อย่างไร แอปพลิเคชันทั่วไปที่ฉันเคยใช้ทำการรวมฐานข้อมูลจำนวนมากด้วยเหตุผลด้านประสิทธิภาพและความเรียบง่าย หากคุณมีตารางสองตารางที่มีความแตกต่างกันในเชิงตรรกะ (บริบทที่มีขอบเขตถ้าคุณต้องการ) แต่คุณมักจะทำการประมวลผลรวมกับข้อมูลจำนวนมากจากนั้นในเสาหินคุณมีแนวโน้มที่จะละทิ้งการวางแนววัตถุและใช้มาตรฐานฐานข้อมูลของคุณแทน เข้าร่วมคุณลักษณะเพื่อประมวลผลข้อมูลบนฐานข้อมูลก่อนที่จะส่งคืนมุมมองรวมกลับไปยังระดับแอปของคุณ คุณจะปรับการแยกข้อมูลดังกล่าวออกเป็นไมโครเซอร์วิสได้อย่างไรโดยที่คุณคาดว่าจะต้อง "เข้าร่วม" ข้อมูลผ่าน API ไม่ใช่ที่ฐานข้อมูล ฉันเคยอ่านหนังสือ Microservices ของ Sam Newman และในบทที่เกี่ยวกับการแยก Monolith เขาได้ยกตัวอย่างของ "Breaking Foreign Key Relationships" ซึ่งเขายอมรับว่าการเข้าร่วมข้าม API นั้นจะช้าลง - แต่เขากล่าวต่อไปว่า แอปพลิเคชันของคุณเร็วพออยู่แล้วมันสำคัญหรือไม่ว่ามันจะช้ากว่าเดิม? นี่ดูเหมือนกะล่อนไปหน่อย? ประสบการณ์ของผู้คนคืออะไร? คุณใช้เทคนิคใดเพื่อให้การรวม API ทำงานได้อย่างยอมรับ

1
Elixir / Erlang เข้ากับวิธีการของไมโครเซอร์วิสได้ที่ไหน? [ปิด]
ปิด . คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ขณะนี้ยังไม่ยอมรับคำตอบ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เน้นไปที่ปัญหาเดียวโดยแก้ไขโพสต์นี้เท่านั้น ปิดให้บริการใน5 ปีที่ผ่านมา ปรับปรุงคำถามนี้ เมื่อเร็ว ๆ นี้ฉันได้ทำการทดลองกับนักเทียบท่าเพื่อปรับใช้ไมโครเซอร์วิสที่ทำงานร่วมกันได้หลายตัว ฉันเห็นประโยชน์มากมายที่ไมโครเซอร์วิสมอบให้และตอนนี้มีชุดเครื่องมือที่ดีสำหรับการจัดการแล้วฉันคิดว่ามันไม่ยากเลยที่จะกระโดดเข้าไปในรถบรรทุกขนาดเล็ก แต่ฉันได้ทดลองกับ Elixir ด้วยและฉันก็ค่อนข้างชอบประโยชน์ที่ได้รับจากตัวมันเอง เนื่องจากมันสนับสนุนให้บรรจุรหัสของคุณลงในแอปพลิเคชันที่แยกตัวออกมาหลายตัวและรองรับการอัปเกรดรหัสร้อนคุณจะผสมนักเทียบท่ากับยาอมฤต (หรือ erlang สำหรับเรื่องนั้นอย่างไร) ตัวอย่างเช่นถ้าฉันต้องการใช้นักเทียบท่าเพราะมันมีความเท่าเทียมกันของ dev-prod ยาอมจะเข้ากันได้อย่างไร? เนื่องจากคอนเทนเนอร์นักเทียบท่าไม่เปลี่ยนรูปฉันจึงสูญเสียความสามารถในการอัปเกรดรหัสด่วนใช่ไหม? สิ่งที่เกี่ยวกับการปรับใช้สีน้ำเงิน / เขียวหรือการเผยแพร่ Canary? ฉันหมายความว่าฉันสามารถเขียน microservices ด้วย Elixir และใช้งานได้ราวกับว่ามันถูกเขียนในภาษาอื่น ๆ การพูดหลายภาษาก็เป็นประโยชน์อย่างหนึ่งของ microservices อยู่ดี แต่ฉันก็ไม่ได้รับประโยชน์เต็มที่จากการใช้แพลตฟอร์ม OTP เดาว่าแอปพลิเคชัน Erlang ที่ทำงานร่วมกันอย่างแท้จริงเป็นวิธีที่ดีที่สุดในการใช้คิวกลางเพื่อสื่อสารระหว่างไมโครเซอร์วิสที่เขียนด้วยภาษา (หรือไม่) ที่แตกต่างกัน

3
เกตเวย์ API เทียบกับพร็อกซีย้อนกลับ
เพื่อที่จะจัดการกับสถาปัตยกรรม MICROSERVICE ก็มักจะใช้ควบคู่ไปกับพร็อกซี (Reverse เช่น Nginx หรือ Apache httpd) และสำหรับการตัดความกังวลการดำเนินการข้าม รูปแบบเกตเวย์ API ถูกนำมาใช้ บางครั้ง Reverse proxy ทำงานกับเกตเวย์ API จะเป็นการดีที่จะเห็นความแตกต่างที่ชัดเจนระหว่างสองแนวทางนี้ ดูเหมือนว่าประโยชน์ที่เป็นไปได้ของการใช้งานเกตเวย์ API คือการเรียกใช้ไมโครเซอร์วิสหลาย ๆ ตัวและรวบรวมผลลัพธ์ ความรับผิดชอบอื่น ๆ ทั้งหมดของเกตเวย์ API สามารถใช้งานได้โดยใช้ Reverse Proxy เช่น: การพิสูจน์ตัวตน (สามารถทำได้โดยใช้สคริปต์ nginx LUA) ความปลอดภัยในการขนส่ง ตัวมันเองงาน Reverse Proxy; โหลดบาลานซ์ .... จากนี้มีคำถามหลายข้อ: มันสมเหตุสมผลหรือไม่ที่จะใช้เกตเวย์ API และพร็อกซีย้อนกลับพร้อมกัน (ดังตัวอย่างคำขอ -> เกตเวย์ Api-> …

4
การ seed ฐานข้อมูล microservices
รับบริการ A (CMS) ที่ควบคุมรูปแบบ (ผลิตภัณฑ์สมมติว่ามีเพียงฟิลด์เดียวที่มี id ชื่อเรื่องราคา) และบริการ B (การจัดส่ง) และ C (อีเมล) ที่ต้องแสดงรูปแบบที่กำหนดแนวทางที่ควรจะเป็น การซิงโครไนซ์ข้อมูลโมเดลที่ได้รับจากบริการเหล่านั้นในแนวทางการจัดหากิจกรรม สมมติว่ารายการสินค้าที่ไม่ค่อยมีการเปลี่ยนแปลง ( แต่ไม่เปลี่ยนแปลง) และว่ามีผู้ดูแลระบบที่เข้าถึงข้อมูลสามารถของการจัดส่งและอีเมลบ่อยมาก (ตัวอย่างเช่นฟังก์ชันคือ: B: display titles of products the order containedและ C: display content of email about shipping that is going to be sent) แต่ละบริการมีฐานข้อมูลของตนเอง โซลูชันที่ 1 ส่งข้อมูลที่จำเป็นทั้งหมดเกี่ยวกับผลิตภัณฑ์ภายในเหตุการณ์ซึ่งหมายถึงโครงสร้างต่อไปนี้สำหรับorder_placed: { order_id: [guid], product: { …

2
Microservices ในการใช้งานนักเทียบท่า
เรากำลังเขียนบริการไมโครครั้งแรกของเราโดยใช้คอนเทนเนอร์ Docker โดยใช้ Amazon fargate เรามีข้อสงสัยมากมายเกี่ยวกับระดับการใช้งานโดยใช้ Spring Boot เราจะมีบริการไมโครหลายรายการในโครงการนี่เป็นวิธีปฏิบัติที่ดีที่เรากำลังเขียนบริการไมโครทั้งหมดในภาชนะเดียวหรือฉันต้องสร้างภาชนะ Docker แยกต่างหากสำหรับบริการไมโครแยกต่างหาก ด้วยวิธีที่คุ้มค่าเราใช้ตู้คอนเทนเนอร์เดียว แต่นั่นทำให้ปัญหากับโครงสร้างโครงการของเราในอนาคตหรือไม่ เราวางแผนที่จะปรับใช้แอปพลิเคชั่นใน AWS fargate และแอปพลิเคชันของเราจะมีตัวเลือกมากมายในการขยายในอนาคตและคาดว่าจะมีบริการไมโครแตกต่างกันประมาณ 100 ถึง 150 ในกรณีนี้จะมีประสิทธิภาพหรือไม่ถ้าเราอัพโหลด microservices เหล่านี้ทั้งหมดในตู้คอนเทนเนอร์ต่าง ๆ ด้วย?
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.