สถาปัตยกรรมไมโครเซอร์วิส - เรียนรู้สร้างและปรับใช้ไมโครเซอร์วิส

สถาปัตยกรรมไมโครเซอร์วิส:

จากของฉัน คุณต้องมีความเข้าใจพื้นฐานเกี่ยวกับสถาปัตยกรรมไมโครเซอร์วิสแต่เป็นมืออาชีพด้วย จะต้องใช้มากกว่าแค่พื้นฐาน ในบล็อกนี้คุณจะได้เจาะลึกแนวคิดทางสถาปัตยกรรมและนำไปใช้โดยใช้กรณีศึกษาของ UBER

ในบล็อกนี้คุณจะได้เรียนรู้สิ่งต่อไปนี้:

• ความหมายของสถาปัตยกรรมไมโครเซอร์วิส
• แนวคิดหลักของสถาปัตยกรรมไมโครเซอร์วิส
• ข้อดีและข้อเสียของสถาปัตยกรรมไมโครเซอร์วิส
• UBER - กรณีศึกษา

คุณสามารถอ้างถึงไฟล์ เพื่อทำความเข้าใจพื้นฐานและประโยชน์ของ Microservices

จะยุติธรรมก็ต่อเมื่อฉันให้คำจำกัดความของ Microservices แก่คุณ

ความหมายของไมโครเซอร์วิส

ด้วยเหตุนี้จึงไม่มีคำจำกัดความที่เหมาะสมของ Microservices หรือที่รู้จักกันในชื่อ Microservice Architecture แต่คุณสามารถพูดได้ว่าเป็นเฟรมเวิร์กที่ประกอบด้วยบริการขนาดเล็กที่ปรับใช้แยกกันได้ซึ่งดำเนินการต่างกัน

Microservices มุ่งเน้นไปที่โดเมนธุรกิจเดียวที่สามารถนำไปใช้เป็นบริการที่ปรับใช้งานได้อย่างอิสระและนำไปใช้กับสแต็คเทคโนโลยีที่แตกต่างกัน

รูปที่ 1: ความแตกต่างระหว่าง Monolithic และ Microservice Architecture - Microservice Architecture

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

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

แนวคิดหลักของสถาปัตยกรรมไมโครเซอร์วิส

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

ต่อไปนี้เป็นแนวทางปฏิบัติบางประการขณะพูดคุยเกี่ยวกับไมโครเซอร์วิส

แนวทางในการออกแบบไมโครเซอร์วิส

keyerror ใน python คืออะไร

• ในฐานะนักพัฒนาเมื่อคุณตัดสินใจที่จะสร้างแอปพลิเคชันแยกโดเมนและชัดเจนกับฟังก์ชันการทำงาน
• ไมโครเซอร์วิสแต่ละตัวที่คุณออกแบบจะมุ่งเน้นไปที่บริการเดียวของแอปพลิเคชันเท่านั้น
• ตรวจสอบให้แน่ใจว่าคุณได้ออกแบบแอปพลิเคชันในลักษณะที่แต่ละบริการสามารถปรับใช้แยกกันได้
• ตรวจสอบให้แน่ใจว่าการสื่อสารระหว่างไมโครเซอร์วิสดำเนินการผ่านเซิร์ฟเวอร์ไร้สถานะ
• แต่ละบริการสามารถปรับโครงสร้างใหม่ให้เป็นบริการขนาดเล็กได้โดยมีไมโครเซอร์วิสของตัวเอง

ตอนนี้คุณได้อ่านหลักเกณฑ์พื้นฐานในขณะที่ออกแบบไมโครเซอร์วิสแล้วเรามาทำความเข้าใจกับสถาปัตยกรรมของไมโครเซอร์วิสกัน

สถาปัตยกรรมไมโครเซอร์วิสทำงานอย่างไร

Microservice Architecture (MSA) ทั่วไปควรประกอบด้วยองค์ประกอบต่อไปนี้:

1. ลูกค้า
2. ผู้ให้บริการข้อมูลประจำตัว
3. เกตเวย์ API
4. รูปแบบการส่งข้อความ
5. ฐานข้อมูล
6. เนื้อหาคงที่
7. การจัดการ
8. การค้นพบบริการ

โปรดดูแผนภาพด้านล่าง

รูปที่ 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 ของเราเพื่อรับการอัปเดตใหม่ .. !

ตอนนี้เรามาดูข้อดีข้อเสียของสถาปัตยกรรมนี้เพื่อทำความเข้าใจให้ดีขึ้นว่าเมื่อใดควรใช้สถาปัตยกรรมนี้

ข้อดีและข้อเสียของสถาปัตยกรรมไมโครเซอร์วิส

โปรดดูตารางด้านล่าง

ให้เราเข้าใจเพิ่มเติมเกี่ยวกับ 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 ในเชิงลึกและช่วยให้คุณมีความเชี่ยวชาญในเรื่องนั้น ๆ

มีคำถามสำหรับเรา? โปรดระบุไว้ในส่วนความคิดเห็นของ ' สถาปัตยกรรมไมโครเซอร์วิส ” แล้วฉันจะติดต่อกลับไป