Microservices อาคารหนังสืออธิบายรายละเอียดสไตล์ที่กล่าวถึงโดย @RogerAlsing ในคำตอบของเขา
ในหน้า 43 ภายใต้ Orchestration vs Choreography หนังสือเล่มนี้พูดว่า:
เมื่อเราเริ่มสร้างแบบจำลองตรรกะที่ซับซ้อนมากขึ้นเราต้องจัดการกับปัญหาในการจัดการกระบวนการทางธุรกิจที่ครอบคลุมขอบเขตของการบริการส่วนบุคคล และด้วย microservices เราจะถึงขีด จำกัด นี้เร็วกว่าปกติ [... ] เมื่อพูดถึงการนำกระแสนี้ไปใช้จริงมีสองรูปแบบของสถาปัตยกรรมที่เราสามารถติดตามได้ ด้วย orchestration เราพึ่งพาสมองส่วนกลางเพื่อนำทางและขับเคลื่อนกระบวนการเหมือนกับตัวนำในวงออเคสตร้า ด้วยการออกแบบท่าเต้นเราแจ้งให้แต่ละส่วนของระบบงานทราบและปล่อยให้มันทำรายละเอียดออกมาเช่นนักเต้นทุกคนค้นหาวิธีการของพวกเขาและโต้ตอบกับคนอื่น ๆ รอบตัวพวกเขาในบัลเล่ต์
หนังสือเล่มนี้อธิบายวิธีสองสไตล์ orchestration style สอดคล้องกับแนวคิด SOA ของorchestration / task servicesในขณะที่สไตล์ท่าเต้นนั้นสอดคล้องกับท่อ dumb และจุดปลายอัจฉริยะที่กล่าวถึงในบทความของ Martin Fowler
สไตล์ออเคสตร้า
ภายใต้สไตล์นี้หนังสือด้านบนกล่าวถึง:
ลองคิดดูว่าการแก้ปัญหาออเคสตร้าจะเป็นอย่างไรสำหรับโฟลว์นี้ ที่นี่สิ่งที่ง่ายที่สุดที่ควรทำคือให้บริการลูกค้าของเราทำหน้าที่เป็นศูนย์กลางสมอง ในการสร้างมันพูดคุยกับธนาคารคะแนนความภักดีบริการอีเมลและบริการไปรษณีย์ [... ] ผ่านชุดของการร้องขอ / ตอบสนองการโทร ฝ่ายบริการลูกค้าสามารถติดตามตำแหน่งที่ลูกค้าอยู่ในกระบวนการนี้ สามารถตรวจสอบเพื่อดูว่าบัญชีของลูกค้าได้รับการตั้งค่าหรืออีเมลที่ส่งหรือโพสต์ส่ง เราจะนำ flowchart [... ] และวางมันลงในโค้ดโดยตรง เราสามารถใช้เครื่องมือที่ใช้สำหรับเราหรืออาจใช้เครื่องมือสร้างกฎที่เหมาะสม มีเครื่องมือทางการค้าสำหรับจุดประสงค์นี้ในรูปแบบของซอฟต์แวร์การสร้างแบบจำลองกระบวนการทางธุรกิจ สมมติว่าเราใช้คำขอ / ตอบสนองแบบซิงโครนัส เราสามารถทราบได้ว่าแต่ละขั้นตอนทำงาน [... ] ข้อเสียของแนวทางการประสานงานนี้คือการบริการลูกค้าสามารถกลายเป็นอำนาจการปกครองที่มากเกินไปหรือไม่ มันสามารถกลายเป็นฮับที่อยู่ตรงกลางของเว็บและเป็นจุดศูนย์กลางที่ตรรกะเริ่มมีชีวิตอยู่ ฉันได้เห็นวิธีการนี้ส่งผลให้บริการ“ เทพเจ้า” อันชาญฉลาดจำนวนน้อยบอกกับบริการ CRUD เกี่ยวกับโลหิตจางว่าควรทำอะไร
หมายเหตุ: ฉันคิดว่าเมื่อผู้เขียนกล่าวถึงเครื่องมือเขาอ้างถึงบางสิ่งบางอย่างเช่นBPM (เช่นกิจกรรม , Apache ODE , Camunda ) ตามความเป็นจริงเว็บไซต์รูปแบบเวิร์กโฟลว์มีชุดรูปแบบที่ยอดเยี่ยมในการทำ orchestration ชนิดนี้และยังมีรายละเอียดการประเมินผลของเครื่องมือผู้จำหน่ายต่าง ๆ ที่ช่วยในการปรับใช้วิธีนี้ ฉันไม่คิดว่าผู้เขียนบอกเป็นนัยว่าจำเป็นต้องใช้เครื่องมืออย่างใดอย่างหนึ่งเหล่านี้เพื่อใช้การรวมรูปแบบนี้ แต่สามารถใช้เฟรมเวิร์ก orchestration น้ำหนักเบาอื่น ๆ เช่นSpring Integration , Apache CamelหรือMule ESB
อย่างไรก็ตามหนังสือเล่มอื่น ๆ ที่ฉันได้อ่านในหัวข้อของ Microservices และโดยทั่วไปบทความส่วนใหญ่ที่ฉันพบในเว็บดูเหมือนจะไม่ชอบแนวทางการประสานเสียงและแทนที่จะแนะนำให้ใช้หนังสือเล่มต่อไปแทน
สไตล์การออกแบบท่าเต้น
ภายใต้สไตล์การออกแบบท่าเต้นผู้เขียนพูดว่า:
ด้วยวิธีออกแบบท่าเต้นเราสามารถให้บริการลูกค้าปล่อยเหตุการณ์ในลักษณะอะซิงโครนัสแทนที่จะบอกว่าลูกค้าสร้างขึ้น บริการอีเมลบริการไปรษณีย์และธนาคารคะแนนความภักดีจากนั้นเพียงสมัครสมาชิกกับกิจกรรมเหล่านี้และตอบสนองตาม [... ] วิธีการนี้เป็นวิธีที่ดีกว่า หากบริการอื่น ๆ จำเป็นต้องเข้าถึงการสร้างลูกค้าเพียงแค่ต้องสมัครรับข้อมูลกิจกรรมและทำงานเมื่อจำเป็น ข้อเสียคือมุมมองที่ชัดเจนของกระบวนการทางธุรกิจที่เราเห็นใน [เวิร์กโฟลว์] ตอนนี้สะท้อนให้เห็นโดยเฉพาะในระบบของเรา [... ] ซึ่งหมายความว่าจำเป็นต้องมีงานเพิ่มเติมเพื่อให้แน่ใจว่าคุณสามารถตรวจสอบและติดตามสิ่งที่ถูกต้องได้ ที่เกิดขึ้น ตัวอย่างเช่น, คุณจะทราบได้ไหมว่าธนาคารคะแนนสะสมมีข้อผิดพลาดและด้วยเหตุผลบางอย่างไม่ได้ตั้งค่าบัญชีที่ถูกต้อง? วิธีหนึ่งที่ฉันชอบในการจัดการกับสิ่งนี้คือการสร้างระบบการตรวจสอบที่ตรงกับมุมมองของกระบวนการทางธุรกิจใน [เวิร์กโฟลว์] แต่จากนั้นติดตามว่าแต่ละบริการทำอะไรในฐานะองค์กรอิสระทำให้คุณเห็นข้อยกเว้นแปลก ๆ ผังกระบวนการที่ชัดเจนยิ่งขึ้น [flowchart] [... ] ไม่ใช่แรงผลักดัน แต่มีเพียงเลนส์เดียวที่เราสามารถเห็นได้ว่าระบบทำงานอย่างไร โดยทั่วไปแล้วฉันได้พบว่าระบบที่มีแนวโน้มมากขึ้นในการออกแบบท่าเต้นนั้นมีการเชื่อมโยงกันอย่างหลวม ๆ และมีความยืดหยุ่นและคล้อยตามการเปลี่ยนแปลงได้มากขึ้น อย่างไรก็ตามคุณต้องทำงานพิเศษเพื่อติดตามและติดตามกระบวนการข้ามขอบเขตระบบ ฉันพบว่าการใช้งานที่มีการเตรียมการอย่างหนักส่วนใหญ่มีความเปราะมากและมีค่าใช้จ่ายในการเปลี่ยนแปลงที่สูงขึ้น ด้วยความคิดนั้นฉันจึงชอบที่จะเล็งไปที่ระบบการออกแบบท่าเต้นที่ซึ่งการบริการแต่ละอย่างนั้นฉลาดพอที่จะเข้าใจบทบาทของมันในการเต้นทั้งหมด
หมายเหตุ: จนถึงวันนี้ฉันยังไม่แน่ใจว่าการออกแบบท่าเต้นเป็นเพียงอีกชื่อหนึ่งสำหรับสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (EDA) แต่ถ้า EDA เป็นวิธีเดียวที่จะทำ (ดูที่ "การขับเคลื่อนเหตุการณ์" หมายถึงอะไรและความหมายของสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ ) นอกจากนี้ดูเหมือนว่าสิ่งต่าง ๆ เช่น CQRS และ EventSourcing จะสะท้อนเสียงดังมากด้วยรูปแบบสถาปัตยกรรมนี้ใช่ไหม
หลังจากนี้มาถึงความสนุกสนาน หนังสือ Microservices ไม่ถือว่า microservices นั้นจะถูกนำไปใช้กับ REST ตามความเป็นจริงในส่วนถัดไปในหนังสือพวกเขาดำเนินการพิจารณาโซลูชันที่ใช้ RPC และ SOA และในที่สุดก็ใช้ REST จุดสำคัญที่นี่คือ Microservices ไม่ได้หมายความว่า REST
ดังนั้นสิ่งที่เกี่ยวกับ HATEOAS (Hypermedia เป็นเอ็นจินของสถานะแอปพลิเคชัน)
ตอนนี้ถ้าเราต้องการทำตามวิธี RESTful เราไม่สามารถเพิกเฉยต่อ HATEOAS หรือ Roy Fielding จะยินดีมากที่จะพูดในบล็อกของเขาว่าโซลูชันของเราไม่ใช่ REST อย่างแท้จริง ดูโพสต์บล็อกของเขาในREST API ต้องเป็น Hypertext Driven :
ฉันรู้สึกหงุดหงิดกับจำนวนคนที่เรียกใช้ REST API ที่ใช้อินเตอร์เฟส HTTP ใด ๆ สิ่งที่ต้องทำเพื่อทำให้ลักษณะสถาปัตยกรรม REST ชัดเจนในความคิดที่ว่าไฮเปอร์เท็กซ์เป็นข้อ จำกัด ? กล่าวอีกนัยหนึ่งถ้าเอ็นจินของสถานะแอปพลิเคชัน (และด้วยเหตุนี้ API) ไม่ได้ถูกขับเคลื่อนด้วยไฮเปอร์เท็กซ์ข้อความนั้นจะไม่สามารถสงบและไม่สามารถเป็น REST API ได้ ระยะเวลา มีคู่มือที่หักบางส่วนที่ต้องแก้ไขหรือไม่
ดังนั้นอย่างที่คุณเห็น Fielding คิดว่าหากไม่มี HATEOAS คุณไม่ได้สร้างแอปพลิเคชั่น RESTful ขึ้นมา สำหรับ Fielding นั้น HATEOAS เป็นหนทางที่จะดำเนินการเมื่อมีการจัดการบริการ ฉันเพิ่งจะเรียนรู้ทั้งหมดนี้ แต่สำหรับฉัน HATEOAS ไม่ได้ระบุอย่างชัดเจนว่าใครหรืออะไรคือแรงผลักดันที่อยู่เบื้องหลังการติดตามลิงก์ ใน UI ที่อาจเป็นผู้ใช้ แต่ในการโต้ตอบระหว่างคอมพิวเตอร์กับคอมพิวเตอร์ฉันคิดว่าต้องทำโดยบริการระดับสูงกว่า
ตาม HATEOAS ลิงก์เดียวที่ผู้ใช้ API ต้องการทราบอย่างแท้จริงคือลิงก์ที่เริ่มต้นการสื่อสารกับเซิร์ฟเวอร์ (เช่น POST / คำสั่งซื้อ) จากจุดนี้เป็นต้นไป REST จะดำเนินการไหลเนื่องจากในการตอบสนองของจุดสิ้นสุดนี้ทรัพยากรที่ส่งคืนจะมีลิงก์ไปยังสถานะที่เป็นไปได้ถัดไป ผู้บริโภค API จะตัดสินใจว่าลิงก์ใดที่จะติดตามและย้ายแอปพลิเคชันไปยังสถานะถัดไป
แม้จะฟังดูดีแค่ไหนลูกค้าก็ยังต้องรู้ว่าลิงค์นั้นต้องโพสต์โพสต์เอาต์แพทช์และอื่น ๆ และลูกค้ายังต้องตัดสินใจว่าเพย์โหลดใดจะผ่าน ลูกค้ายังต้องระวังว่าจะทำอย่างไรหากล้มเหลว (ลองอีกครั้งชดเชยชดเชยยกเลิกเป็นต้น)
ฉันค่อนข้างใหม่สำหรับสิ่งนี้ แต่สำหรับฉันจากมุมมอง HATEOAs ลูกค้ารายนี้หรือผู้บริโภค API เป็นบริการสั่งซื้อสูง หากเราคิดจากมุมมองของมนุษย์คุณสามารถจินตนาการผู้ใช้ปลายทางบนหน้าเว็บตัดสินใจว่าจะลิงค์ไปตามอะไร แต่โปรแกรมเมอร์ของเว็บเพจต้องตัดสินใจว่าจะใช้วิธีใดในการเรียกลิงก์ และน้ำหนักบรรทุกที่จะผ่าน ดังนั้นถึงจุดของฉันในการโต้ตอบระหว่างคอมพิวเตอร์กับคอมพิวเตอร์คอมพิวเตอร์ใช้บทบาทของผู้ใช้ปลายทาง อีกครั้งนี่คือสิ่งที่เราเรียกว่าบริการ orchestrations
ฉันคิดว่าเราสามารถใช้ HATEOAS กับการบรรเลงหรือการออกแบบท่าเต้น
รูปแบบเกตเวย์ API
อีกรูปแบบที่น่าสนใจคือการแนะนำโดยคริสริชาร์ดที่ยังนำเสนอสิ่งที่เขาเรียกว่าแบบ API เกตเวย์
ในสถาปัตยกรรมแบบเสาหินไคลเอนต์ของแอปพลิเคชันเช่นเว็บเบราว์เซอร์และแอปพลิเคชันดั้งเดิมทำการร้องขอ HTTP ผ่านตัวโหลดบาลานซ์ไปยังอินสแตนซ์ N ตัวใดตัวหนึ่งของแอปพลิเคชัน แต่ในสถาปัตยกรรมไมโครเซอร์วิสเสาหินถูกแทนที่ด้วยชุดของบริการ ดังนั้นคำถามสำคัญที่เราต้องตอบคือลูกค้ามีปฏิสัมพันธ์กับอะไร
แอปพลิเคชันไคลเอนต์เช่นแอปพลิเคชันมือถือแบบดั้งเดิมสามารถส่งคำขอ RESTful HTTP ไปยังบริการส่วนบุคคล [... ] บนพื้นผิวสิ่งนี้อาจดูน่าสนใจ อย่างไรก็ตามมีแนวโน้มที่จะมีความไม่ตรงกันอย่างมีนัยสำคัญในเรื่องละเอียดระหว่าง APIs ของแต่ละบริการและข้อมูลที่ลูกค้าต้องการ ตัวอย่างเช่นการแสดงหน้าเว็บเดียวอาจต้องมีการโทรไปยังบริการจำนวนมาก ตัวอย่างเช่น Amazon.com
อธิบายว่าบางหน้าต้องมีการโทรไปยังบริการ 100+ การร้องขอจำนวนมากแม้ผ่านการเชื่อมต่ออินเทอร์เน็ตความเร็วสูงทำให้เครือข่ายมือถือที่มีแบนด์วิดธ์ต่ำกว่าความหน่วงแฝงที่สูงกว่านั้นจะไม่มีประสิทธิภาพและทำให้ผู้ใช้มีประสบการณ์ที่ไม่ดี
วิธีที่ดีกว่ามากสำหรับลูกค้าที่จะทำการร้องขอจำนวนน้อยต่อหน้าอาจจะน้อยเพียงหนึ่งครั้งผ่านทางอินเทอร์เน็ตไปยังเซิร์ฟเวอร์ส่วนหน้าหรือที่เรียกว่าเกตเวย์ API
เกตเวย์ API ตั้งอยู่ระหว่างไคลเอนต์ของแอปพลิเคชันและไมโครไซต์ มันมี API ที่ปรับให้เหมาะกับลูกค้า เกตเวย์ API จัดทำ API แบบหยาบให้กับไคลเอนต์มือถือและ API แบบละเอียดสำหรับไคลเอ็นต์เดสก์ท็อปที่ใช้เครือข่ายประสิทธิภาพสูง ในตัวอย่างนี้เดสก์ท็อปไคลเอนต์ทำการร้องขอหลายครั้งเพื่อดึงข้อมูลเกี่ยวกับผลิตภัณฑ์ในขณะที่ไคลเอนต์มือถือทำการร้องขอเดียว
เกตเวย์ API จัดการคำขอที่เข้ามาด้วยการส่งคำขอไปยัง microservices จำนวนหนึ่งผ่าน LAN ประสิทธิภาพสูง ตัวอย่างเช่น Netflix
อธิบาย
ว่าแต่ละคำขอให้แฟน ๆ ใช้บริการแบ็กเอนด์เฉลี่ยหกครั้งอย่างไร ในตัวอย่างนี้คำร้องขอที่ละเอียดจากเดสก์ท็อปไคลเอ็นต์นั้นถูกส่งไปยังเซอร์วิสที่เกี่ยวข้องโดยเฉพาะในขณะที่คำร้องขอหยาบแบบหยาบจากไคลเอนต์มือถือจะถูกจัดการโดยการรวมผลลัพธ์ของการโทรหลายบริการ
เกตเวย์ API ไม่เพียงเพิ่มประสิทธิภาพการสื่อสารระหว่างไคลเอนต์และแอปพลิเคชัน แต่ยังรวมถึงรายละเอียดของไมโครไซต์ สิ่งนี้ทำให้ microservices พัฒนาโดยไม่ส่งผลกระทบต่อลูกค้า ตัวอย่างเช่นสอง microservices อาจถูกรวมเข้าด้วยกัน microservice อื่นอาจถูกแบ่งพาร์ติชันเป็นสองบริการขึ้นไป ต้องอัปเดตเกตเวย์ API เท่านั้นเพื่อให้สอดคล้องกับการเปลี่ยนแปลงเหล่านี้ ลูกค้าไม่ได้รับผลกระทบ
ตอนนี้เราได้ดูว่า API เกตเวย์ไกล่เกลี่ยระหว่างแอปพลิเคชันและไคลเอนต์ตอนนี้มาดูวิธีการใช้การสื่อสารระหว่างไมโครไซต์
นี่ฟังดูคล้ายกับสไตล์ออเคสตร้าที่ได้กล่าวมาข้างต้นโดยมีจุดประสงค์ที่แตกต่างกันเล็กน้อยในกรณีนี้ดูเหมือนว่าทั้งหมดจะเกี่ยวกับประสิทธิภาพและความเรียบง่ายของการโต้ตอบ
.