Microservices ในการใช้งานนักเทียบท่า

เรากำลังเขียนบริการไมโครครั้งแรกของเราโดยใช้คอนเทนเนอร์ Docker โดยใช้ Amazon fargate เรามีข้อสงสัยมากมายเกี่ยวกับระดับการใช้งานโดยใช้ Spring Boot

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

เราวางแผนที่จะปรับใช้แอปพลิเคชั่นใน AWS fargate และแอปพลิเคชันของเราจะมีตัวเลือกมากมายในการขยายในอนาคตและคาดว่าจะมีบริการไมโครแตกต่างกันประมาณ 100 ถึง 150 ในกรณีนี้จะมีประสิทธิภาพหรือไม่ถ้าเราอัพโหลด microservices เหล่านี้ทั้งหมดในตู้คอนเทนเนอร์ต่าง ๆ ด้วย?

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

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

ตัวอย่างเช่นหากองค์กรของคุณ:

• มีพนักงานเทคโนโลยีน้อยกว่า 25 คน
• จัดเป็น 1 หรือ 2 ทีม
• แต่ละอันทำงานได้กับส่วนใดส่วนหนึ่งของผลิตภัณฑ์
• ซึ่งน้อยกว่า 12 เดือน
• และมีการปรับใช้ทั้งหมดในคราวเดียว (เช่นรายวันรายสัปดาห์รายเดือน)
• และองค์กรไม่ได้เติบโตอย่างรวดเร็ว

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

เรามาดูกันต่อไปอีกหน่อยและพิจารณาองค์กรที่ ...

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

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

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

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

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