สถาปัตยกรรมไมโครเซอร์วิส:
จากของฉัน คุณต้องมีความเข้าใจพื้นฐานเกี่ยวกับสถาปัตยกรรมไมโครเซอร์วิสแต่เป็นมืออาชีพด้วย จะต้องใช้มากกว่าแค่พื้นฐาน ในบล็อกนี้คุณจะได้เจาะลึกแนวคิดทางสถาปัตยกรรมและนำไปใช้โดยใช้กรณีศึกษาของ UBER
ในบล็อกนี้คุณจะได้เรียนรู้สิ่งต่อไปนี้:
- ความหมายของสถาปัตยกรรมไมโครเซอร์วิส
- แนวคิดหลักของสถาปัตยกรรมไมโครเซอร์วิส
- ข้อดีและข้อเสียของสถาปัตยกรรมไมโครเซอร์วิส
- UBER - กรณีศึกษา
คุณสามารถอ้างถึงไฟล์ เพื่อทำความเข้าใจพื้นฐานและประโยชน์ของ Microservices
จะยุติธรรมก็ต่อเมื่อฉันให้คำจำกัดความของ Microservices แก่คุณ
ความหมายของไมโครเซอร์วิส
ด้วยเหตุนี้จึงไม่มีคำจำกัดความที่เหมาะสมของ Microservices หรือที่รู้จักกันในชื่อ Microservice Architecture แต่คุณสามารถพูดได้ว่าเป็นเฟรมเวิร์กที่ประกอบด้วยบริการขนาดเล็กที่ปรับใช้แยกกันได้ซึ่งดำเนินการต่างกัน
Microservices มุ่งเน้นไปที่โดเมนธุรกิจเดียวที่สามารถนำไปใช้เป็นบริการที่ปรับใช้งานได้อย่างอิสระและนำไปใช้กับสแต็คเทคโนโลยีที่แตกต่างกัน
รูปที่ 1: ความแตกต่างระหว่าง Monolithic และ Microservice Architecture - Microservice Architecture
ดูแผนภาพด้านบนเพื่อทำความเข้าใจความแตกต่างระหว่างสถาปัตยกรรมเสาหินและสถาปัตยกรรมไมโครเซอร์วิสเพื่อความเข้าใจที่ดีขึ้นเกี่ยวกับความแตกต่างระหว่างทั้งสองสถาปัตยกรรมคุณสามารถดูบล็อกก่อนหน้าของฉัน
เพื่อให้คุณเข้าใจได้ดีขึ้นขอบอกแนวคิดหลักบางประการเกี่ยวกับสถาปัตยกรรมไมโครเซอร์วิส
แนวคิดหลักของสถาปัตยกรรมไมโครเซอร์วิส
ก่อนที่คุณจะเริ่มสร้างแอปพลิเคชันของคุณเองโดยใช้ไมโครเซอร์วิสคุณต้องมีความชัดเจนเกี่ยวกับขอบเขตและฟังก์ชันการทำงานของแอปพลิเคชันของคุณ
ต่อไปนี้เป็นแนวทางปฏิบัติบางประการขณะพูดคุยเกี่ยวกับไมโครเซอร์วิส
แนวทางในการออกแบบไมโครเซอร์วิส
keyerror ใน python คืออะไร
- ในฐานะนักพัฒนาเมื่อคุณตัดสินใจที่จะสร้างแอปพลิเคชันแยกโดเมนและชัดเจนกับฟังก์ชันการทำงาน
- ไมโครเซอร์วิสแต่ละตัวที่คุณออกแบบจะมุ่งเน้นไปที่บริการเดียวของแอปพลิเคชันเท่านั้น
- ตรวจสอบให้แน่ใจว่าคุณได้ออกแบบแอปพลิเคชันในลักษณะที่แต่ละบริการสามารถปรับใช้แยกกันได้
- ตรวจสอบให้แน่ใจว่าการสื่อสารระหว่างไมโครเซอร์วิสดำเนินการผ่านเซิร์ฟเวอร์ไร้สถานะ
- แต่ละบริการสามารถปรับโครงสร้างใหม่ให้เป็นบริการขนาดเล็กได้โดยมีไมโครเซอร์วิสของตัวเอง
ตอนนี้คุณได้อ่านหลักเกณฑ์พื้นฐานในขณะที่ออกแบบไมโครเซอร์วิสแล้วเรามาทำความเข้าใจกับสถาปัตยกรรมของไมโครเซอร์วิสกัน
สถาปัตยกรรมไมโครเซอร์วิสทำงานอย่างไร
Microservice Architecture (MSA) ทั่วไปควรประกอบด้วยองค์ประกอบต่อไปนี้:
- ลูกค้า
- ผู้ให้บริการข้อมูลประจำตัว
- เกตเวย์ API
- รูปแบบการส่งข้อความ
- ฐานข้อมูล
- เนื้อหาคงที่
- การจัดการ
- การค้นพบบริการ
โปรดดูแผนภาพด้านล่าง
รูปที่ 2: สถาปัตยกรรมของไมโครเซอร์วิส - สถาปัตยกรรมไมโครเซอร์วิส
ฉันรู้ว่าสถาปัตยกรรมดูซับซ้อนไปหน่อย แต่ช่างเถอะผมทำให้ง่ายขึ้นสำหรับคุณ
1. ลูกค้า
สถาปัตยกรรมเริ่มต้นด้วยไคลเอนต์ประเภทต่างๆจากอุปกรณ์ต่าง ๆ ที่พยายามใช้ความสามารถในการจัดการต่างๆเช่นการค้นหาสร้างกำหนดค่าเป็นต้น
2. ผู้ให้บริการข้อมูลประจำตัว
จากนั้นคำขอเหล่านี้จากไคลเอ็นต์จะถูกส่งต่อไปยังผู้ให้บริการข้อมูลประจำตัวที่ตรวจสอบสิทธิ์คำขอของไคลเอ็นต์และสื่อสารคำขอไปยัง API Gateway จากนั้นคำขอจะถูกสื่อสารไปยังบริการภายในผ่าน API Gateway ที่กำหนดไว้อย่างดี
3. API เกตเวย์
เนื่องจากลูกค้าไม่ได้เรียกใช้บริการโดยตรง API Gateway จึงทำหน้าที่เป็นจุดเริ่มต้นสำหรับลูกค้าในการส่งต่อคำขอไปยังไมโครเซอร์วิสที่เหมาะสม
ข้อดีของการใช้เกตเวย์ API ได้แก่ :
- บริการทั้งหมดสามารถอัปเดตได้โดยที่ลูกค้าไม่ทราบ
- บริการยังสามารถใช้โปรโตคอลการส่งข้อความที่ไม่เหมาะกับเว็บ
- API Gateway สามารถทำหน้าที่ตัดขวางเช่นการรักษาความปลอดภัยการทำโหลดบาลานซ์เป็นต้น
หลังจากได้รับการร้องขอจากไคลเอ็นต์สถาปัตยกรรมภายในประกอบด้วยไมโครเซอร์วิสที่สื่อสารกันผ่านข้อความเพื่อจัดการกับคำขอของไคลเอ็นต์
4. รูปแบบการส่งข้อความ
ข้อความที่ใช้สื่อสารมีสองประเภท:
- ข้อความซิงโครนัส: ในสถานการณ์ที่ลูกค้ารอการตอบกลับจากบริการมักจะใช้ Microservices REST (การถ่ายโอนสถานะตัวแทน) เนื่องจากขึ้นอยู่กับเซิร์ฟเวอร์ไคลเอ็นต์ไร้สถานะและไฟล์ โปรโตคอล HTTP . โปรโตคอลนี้ใช้เนื่องจากเป็นสภาพแวดล้อมแบบกระจายซึ่งแต่ละฟังก์ชันจะแสดงด้วยทรัพยากรเพื่อดำเนินการ
- ข้อความแบบอะซิงโครนัส: ในสถานการณ์ที่ลูกค้าไม่รอการตอบกลับจากบริการโดยปกติ Microservices มักจะใช้โปรโตคอลเช่น AMQP, STOMP, MQTT . โปรโตคอลเหล่านี้ใช้ในการสื่อสารประเภทนี้เนื่องจากมีการกำหนดลักษณะของข้อความและข้อความเหล่านี้จะต้องทำงานร่วมกันได้ระหว่างการนำไปใช้งาน
คำถามต่อไปที่อาจเกิดขึ้นในใจของคุณคือแอปพลิเคชันที่ใช้ Microservices จัดการกับข้อมูลของพวกเขาอย่างไร?
5. การจัดการข้อมูล
Microservice แต่ละตัวเป็นเจ้าของฐานข้อมูลส่วนตัวเพื่อเก็บข้อมูลและใช้ฟังก์ชันทางธุรกิจที่เกี่ยวข้องนอกจากนี้ฐานข้อมูลของ Microservices จะได้รับการอัปเดตผ่าน API บริการเท่านั้น โปรดดูแผนภาพด้านล่าง:
รูปที่ 3: การเป็นตัวแทนของการจัดการข้อมูลไมโครเซอร์วิส - สถาปัตยกรรมไมโครเซอร์วิส
บริการที่จัดเตรียมโดย Microservices จะถูกส่งต่อไปยังบริการระยะไกลใด ๆ ซึ่งสนับสนุนการสื่อสารระหว่างกระบวนการสำหรับกองเทคโนโลยีที่แตกต่างกัน
6. เนื้อหาคงที่
หลังจากที่ Microservices สื่อสารภายในตัวเองแล้วพวกเขาก็ปรับใช้เนื้อหาแบบคงที่ไปยังบริการจัดเก็บข้อมูลบนคลาวด์ที่สามารถส่งมอบให้กับลูกค้าโดยตรงผ่านทาง เครือข่ายการจัดส่งเนื้อหา (CDN) .
นอกเหนือจากส่วนประกอบข้างต้นแล้วยังมีส่วนประกอบอื่น ๆ อีกบางส่วนที่ปรากฏใน Microservices Architecture ทั่วไป:
7. การจัดการ
ส่วนประกอบนี้มีหน้าที่ในการปรับสมดุลของบริการบนโหนดและการระบุความล้มเหลว
8. การค้นพบบริการ
ทำหน้าที่เป็นแนวทางให้กับ Microservices เพื่อค้นหาเส้นทางการสื่อสารระหว่างกันเนื่องจากมีการเก็บรักษารายการบริการที่มีโหนดอยู่
สมัครสมาชิกช่อง YouTube ของเราเพื่อรับการอัปเดตใหม่ .. !
ตอนนี้เรามาดูข้อดีข้อเสียของสถาปัตยกรรมนี้เพื่อทำความเข้าใจให้ดีขึ้นว่าเมื่อใดควรใช้สถาปัตยกรรมนี้
ข้อดีและข้อเสียของสถาปัตยกรรมไมโครเซอร์วิส
โปรดดูตารางด้านล่าง
ข้อดีของสถาปัตยกรรมไมโครเซอร์วิส | จุดด้อยของ Microservice สถาปัตยกรรม |
อิสระในการใช้เทคโนโลยีต่างๆ | เพิ่มความท้าทายในการแก้ไขปัญหา |
ไมโครเซอร์วิสแต่ละตัวมุ่งเน้นไปที่ความสามารถทางธุรกิจเดียว | เพิ่มความล่าช้าเนื่องจากการโทรระยะไกล |
รองรับหน่วยที่ปรับใช้ได้แต่ละหน่วย | เพิ่มความพยายามในการกำหนดค่าและการดำเนินการอื่น ๆ |
อนุญาตให้ออกซอฟต์แวร์บ่อยครั้ง | ยากต่อการรักษาความปลอดภัยในการทำธุรกรรม |
มั่นใจในความปลอดภัยของแต่ละบริการ | ยากที่จะติดตามข้อมูลในขอบเขตบริการต่างๆ |
บริการหลายอย่างได้รับการพัฒนาและปรับใช้แบบคู่ขนาน | ยากที่จะย้ายรหัสระหว่างบริการ |
ให้เราเข้าใจเพิ่มเติมเกี่ยวกับ Microservices โดยการเปรียบเทียบสถาปัตยกรรมก่อนหน้าของ UBER กับสถาปัตยกรรมปัจจุบัน
UBER กรณีศึกษา
สถาปัตยกรรมก่อนหน้าของ UBER
เช่นเดียวกับ บริษัท ที่เพิ่งเริ่มต้นจำนวนมาก UBER เริ่มต้นการเดินทางด้วยสถาปัตยกรรมเสาหินที่สร้างขึ้นเพื่อการเสนอขายเดียวในเมืองเดียว ในเวลานั้นการมีโค้ดเบสเพียงตัวเดียวดูเหมือนจะหมดจดและแก้ปัญหาธุรกิจหลักของ UBER ได้ อย่างไรก็ตามในขณะที่ UBER เริ่มขยายไปทั่วโลกพวกเขาต้องเผชิญกับปัญหาต่างๆอย่างเข้มงวดเกี่ยวกับความสามารถในการปรับขนาดและการผสานรวมอย่างต่อเนื่อง
รูปที่ 4: สถาปัตยกรรมเสาหินของ UBER - สถาปัตยกรรมไมโครเซอร์วิส
แผนภาพด้านบนแสดงให้เห็นถึงสถาปัตยกรรมก่อนหน้าของ UBER
- มี REST API ที่ผู้โดยสารและคนขับเชื่อมต่อ
- ใช้อะแดปเตอร์ที่แตกต่างกันสามตัวกับ API ภายในเพื่อดำเนินการต่างๆเช่นการเรียกเก็บเงินการชำระเงินการส่งอีเมล / ข้อความที่เราเห็นเมื่อเราจองรถแท็กซี่
- ฐานข้อมูล MySQL เพื่อจัดเก็บข้อมูลทั้งหมด
ดังนั้นหากคุณสังเกตเห็นที่นี่คุณสมบัติทั้งหมดเช่นการจัดการผู้โดยสารการเรียกเก็บเงินคุณสมบัติการแจ้งเตือนการชำระเงินการจัดการการเดินทางและการจัดการคนขับถูกรวบรวมไว้ในกรอบเดียว
คำชี้แจงปัญหา
ในขณะที่ UBER เริ่มขยายไปทั่วโลกกรอบลักษณะนี้ได้นำเสนอความท้าทายต่างๆ ต่อไปนี้เป็นความท้าทายที่โดดเด่นบางประการ
- คุณสมบัติทั้งหมดต้องถูกสร้างขึ้นใหม่ปรับใช้และทดสอบซ้ำแล้วซ้ำอีกเพื่ออัปเดตคุณสมบัติเดียว
- การแก้ไขข้อบกพร่องกลายเป็นเรื่องยากมากในที่เก็บเดียวเนื่องจากนักพัฒนาต้องเปลี่ยนรหัสครั้งแล้วครั้งเล่า
- การปรับขนาดคุณสมบัติพร้อมกันกับการเปิดตัวคุณสมบัติใหม่ทั่วโลกนั้นค่อนข้างยากที่จะจัดการร่วมกัน
สารละลาย
เพื่อหลีกเลี่ยงปัญหาดังกล่าว UBER จึงตัดสินใจเปลี่ยนสถาปัตยกรรมและติดตาม บริษัท อื่น ๆ ที่มีการเติบโตสูงเช่น Amazon, Netflix, Twitter และอื่น ๆ อีกมากมาย ดังนั้น UBER จึงตัดสินใจที่จะแยกสถาปัตยกรรมเสาหินออกเป็นฐานรหัสหลายฐานเพื่อสร้างสถาปัตยกรรมไมโครเซอร์วิส
ดูแผนผังด้านล่างเพื่อดูสถาปัตยกรรมไมโครเซอร์วิสของ UBER
รูปที่ 5: Microservice Architecture Of UBER - สถาปัตยกรรมไมโครเซอร์วิส
- การเปลี่ยนแปลงที่สำคัญที่เราสังเกตเห็นในที่นี้คือการเปิดตัว API Gateway ซึ่งเชื่อมต่อระหว่างผู้ขับขี่และผู้โดยสารทั้งหมด จาก API Gateway เชื่อมต่อจุดภายในทั้งหมดเช่นการจัดการผู้โดยสารการจัดการคนขับการจัดการการเดินทางและอื่น ๆ
- หน่วยเป็นหน่วยที่สามารถปรับใช้งานได้แยกกันซึ่งทำหน้าที่แยกกัน
- ตัวอย่างเช่นหากคุณต้องการเปลี่ยนแปลงสิ่งใด ๆ ใน Microservices การเรียกเก็บเงินคุณเพียงแค่ปรับใช้เฉพาะบริการการเรียกเก็บเงิน Microservices เท่านั้นและไม่จำเป็นต้องทำให้อุปกรณ์อื่นใช้งานได้
- ขณะนี้คุณลักษณะทั้งหมดได้รับการปรับขนาดแยกกันเช่นการพึ่งพาซึ่งกันและกันระหว่างแต่ละคุณลักษณะและทุกคุณลักษณะจะถูกลบออก
- ตัวอย่างเช่นเราทุกคนทราบดีว่าจำนวนคนที่ค้นหารถแท็กซี่นั้นมีมากกว่าจำนวนคนที่จองรถแท็กซี่และชำระเงินจริงๆ สิ่งนี้ทำให้เราอนุมานได้ว่าจำนวนกระบวนการที่ทำงานกับไมโครบริการจัดการผู้โดยสารมีมากกว่าจำนวนกระบวนการที่ทำงานเกี่ยวกับการชำระเงิน
ในเรื่องนี้ทางUBER ได้รับประโยชน์จากการขยับของมันสถาปัตยกรรมจากเสาหินไปจนถึงไมโครเซอร์วิส
ฉันหวังว่าคุณจะสนุกกับการอ่านโพสต์นี้เกี่ยวกับ Microservice Architectureฉันจะมาพร้อมกับบล็อกเพิ่มเติมซึ่งจะมีการลงมือปฏิบัติเช่นกัน
สนใจเรียนรู้เพิ่มเติมเกี่ยวกับไมโครเซอร์วิสหรือไม่?
หากคุณต้องการเรียนรู้ Microservices และสร้างแอปพลิเคชันของคุณเองโปรดดูที่ ซึ่งมาพร้อมกับการฝึกอบรมสดที่นำโดยผู้สอนและประสบการณ์โครงการในชีวิตจริง การฝึกอบรมนี้จะช่วยให้คุณเข้าใจ Microservices ในเชิงลึกและช่วยให้คุณมีความเชี่ยวชาญในเรื่องนั้น ๆ
มีคำถามสำหรับเรา? โปรดระบุไว้ในส่วนความคิดเห็นของ ' สถาปัตยกรรมไมโครเซอร์วิส ” แล้วฉันจะติดต่อกลับไป