Service Meshes and API Gateways (Service Mesh และ API Gateway)

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

ในภาษาศัพท์ data center ทั่วไป เราจะพูดถึง traffic แบบ "east-west" ว่าเป็น traffic ภายใน data center โดย traffic แบบ "north-south" เกี่ยวข้องกับ interaction ที่เข้าหรือออกจาก data center จากโลกภายนอก จากมุมมองของ networking สิ่งที่ data center เป็นได้กลายเป็น แนวคิดที่ค่อนข้างเลือนราง ดังนั้นเพื่อจุดประสงค์ของเรา เราจะพูดถึง networked perimeter ในความหมายที่กว้างขึ้น นี่อาจเกี่ยวข้องกับ data center ทั้งหมด, Kubernetes cluster หรือบางทีก็แค่แนวคิด virtual networking อย่างกลุ่มของเครื่องที่รันบน virtual LAN เดียวกัน

พูดโดยทั่วไป API gateway อยู่ที่ perimeter ของระบบของคุณและจัดการ traffic แบบ north-south ความกังวลหลักของมันคือการจัดการการเข้าถึง จากโลกภายนอกไปยังไมโครเซอร์วิสภายในของคุณ Service mesh ในทางกลับกัน จัดการกับการสื่อสารระหว่างไมโครเซอร์วิสภายใน perimeter ของคุณ อย่างแคบมาก—traffic แบบ east-west—อย่างที่ Figure 5-6 แสดงให้เห็น

Figure 5-6. An overview of where API gateways and service meshes are used (ภาพรวมของจุดที่ API gateway และ service mesh ถูกใช้)

Service mesh และ API gateway อาจให้ไมโครเซอร์วิสแชร์ code กันได้โดยไม่ต้องสร้าง client library หรือไมโครเซอร์วิสใหม่ พูดง่ายๆ (มากๆ) service mesh และ API gateway สามารถทำงานเป็น proxy ระหว่างไมโครเซอร์วิสได้ นี่อาจหมายความว่าพวกมันอาจถูกใช้เพื่อ implement พฤติกรรมที่ไม่ขึ้นกับไมโครเซอร์วิสตัวใดตัวหนึ่งบางอย่าง ซึ่งไม่เช่นนั้นก็ต้องทำใน code เช่น service discovery หรือ logging

ถ้าคุณกำลังใช้ API gateway หรือ service mesh เพื่อ implement พฤติกรรมร่วมที่ใช้ทั่วไปสำหรับไมโครเซอร์วิสของคุณ มันสำคัญมากที่ พฤติกรรมนี้จะต้อง generic โดยสิ้นเชิง—กล่าวอีกนัยหนึ่งคือ พฤติกรรมใน proxy ไม่มีความเกี่ยวข้องใดๆ กับพฤติกรรมเฉพาะของไมโครเซอร์วิส ตัวใดตัวหนึ่ง

ตอนนี้ หลังจากอธิบายแบบนั้นแล้ว ผมก็ต้องอธิบายด้วยว่าโลกไม่ได้ชัดเจนขนาดนั้นเสมอไป API gateway จำนวนหนึ่งพยายามให้ capability สำหรับ traffic แบบ east-west ด้วยเช่นกัน แต่นั่นเป็นสิ่งที่เราจะพูดถึงในไม่ช้า อย่างแรก มาดู API gateway และประเภทของสิ่งที่พวกมันทำได้กัน

API Gateways

ด้วยการมุ่งเน้นไปที่ traffic แบบ north-south มากกว่า ความกังวลหลักของ API gateway ในสภาพแวดล้อมไมโครเซอร์วิสคือการ map request จากฝ่ายภายนอกไปยังไมโครเซอร์วิสภายใน ความรับผิดชอบนี้คล้ายกับสิ่งที่คุณสามารถบรรลุได้ด้วย HTTP proxy ธรรมดา และที่จริงแล้ว API gateway มักจะสร้าง feature เพิ่มเติมบน HTTP proxy product ที่มีอยู่แล้ว และพวกมันส่วนใหญ่ทำหน้าที่เป็น reverse proxy นอกจากนี้ API gateway ยังสามารถใช้ implement กลไกอย่าง API key สำหรับฝ่ายภายนอก, logging, rate limiting และ สิ่งที่คล้ายกัน API gateway product บางตัวยังให้ developer portal ด้วย ซึ่งมักมุ่งเป้าไปที่ผู้เรียกใช้ภายนอก

ส่วนหนึ่งของความสับสนรอบๆ API gateway เกี่ยวข้องกับประวัติศาสตร์ สักพักหนึ่งที่ผ่านมา มีความสนใจอย่างมากในสิ่งที่เรียกว่า "the API economy" วงการเริ่มเข้าใจถึงพลังของการเสนอ API สู่ managed solution ตั้งแต่ SaaS product อย่าง Salesforce ไปจนถึง platform อย่าง AWS เพราะมันชัดเจนว่า API ให้ความยืดหยุ่นมากขึ้นแก่ลูกค้าในการใช้ software ของพวกเขา สิ่งนี้ทำให้คนจำนวนหนึ่ง เริ่มมองไปที่ software ที่พวกเขามีอยู่แล้ว และพิจารณาประโยชน์ของการเปิดเผย functionality นั้นให้กับลูกค้าของพวกเขา ไม่ใช่แค่ผ่าน GUI แต่ผ่าน API ด้วย ความหวังคือสิ่งนี้จะเปิดโอกาสทางการตลาดที่ใหญ่กว่า และ ก็คือ ทำเงินได้มากขึ้น ท่ามกลางความสนใจนี้ กลุ่มของ API gateway product ก็ผุดขึ้นมาเพื่อช่วยทำให้บรรลุเป้าหมายเหล่านั้นเป็นไปได้ feature set ของพวกมันเน้นหนักไปที่การจัดการ API key สำหรับบุคคลที่สาม การบังคับใช้ rate limit และการติดตามการใช้งานเพื่อจุดประสงค์ chargeback ความจริงคือ แม้ API จะถูกพิสูจน์แล้วว่า เป็นวิธีที่ยอดเยี่ยมในการส่งมอบ service ให้กับลูกค้าบางกลุ่ม แต่ขนาดของ API economy ก็ไม่ได้ใหญ่เท่าที่หลายคนหวังไว้ และหลายบริษัท ก็พบว่าพวกเขาได้ซื้อ API gateway product ที่เต็มไปด้วย feature ที่พวกเขาไม่เคยต้องการจริงๆ

บ่อยครั้งมาก สิ่งเดียวที่ API gateway ถูกใช้จริงๆ คือการจัดการการเข้าถึงไมโครเซอร์วิสขององค์กรจาก GUI client ของตัวเอง (หน้าเว็บ, native mobile application) ผ่าน public internet ไม่มี "บุคคลที่สาม" อยู่ในสมการนี้เลย ความจำเป็นในการมี API gateway รูปแบบใดรูปแบบหนึ่งสำหรับ Kubernetes นั้นจำเป็นมาก เพราะ Kubernetes จัดการ networking โดยธรรมชาติเฉพาะภายใน cluster เท่านั้น และไม่ได้ทำอะไรเกี่ยวกับการจัดการการสื่อสารเข้าและออกจากตัว cluster เอง แต่ใน use case แบบนั้น API gateway ที่ออกแบบมาสำหรับ การเข้าถึงจากบุคคลที่สามภายนอกก็เกินความจำเป็นไปมาก

ดังนั้นถ้าคุณต้องการ API gateway ให้ชัดเจนจริงๆ ว่าคุณคาดหวังอะไรจากมัน ที่จริงแล้ว ผมขอไปไกลกว่านั้นและบอกว่าคุณควรหลีกเลี่ยง การมี API gateway ที่ทำอะไรมากเกินไป แต่เราจะไปถึงเรื่องนั้นต่อไป

Where to use them (จะใช้พวกมันเมื่อไหร่)

เมื่อคุณเริ่มเข้าใจว่าคุณมี use case ประเภทไหนบ้าง มันก็จะง่ายขึ้นเล็กน้อยที่จะเห็นว่าคุณต้องการ gateway ประเภทไหน ถ้ามันเป็นแค่ กรณีของการเปิดเผยไมโครเซอร์วิสที่รันอยู่ใน Kubernetes คุณอาจรัน reverse proxy ของคุณเอง—หรือดีกว่านั้น คุณอาจดู product เฉพาะทางอย่าง Ambassador ซึ่งถูกสร้างขึ้นมาตั้งแต่แรกโดยคำนึงถึง use case นั้น ถ้าคุณพบว่าตัวเองต้องจัดการผู้ใช้บุคคลที่สาม จำนวนมากที่เข้าถึง API ของคุณจริงๆ ก็มี product อื่นๆ ที่น่าจะควรดู เป็นไปได้จริงๆ ที่คุณอาจจบลงด้วยการมี gateway มากกว่าหนึ่งตัว ในระบบเพื่อจัดการ separation of concerns ได้ดีขึ้น และผมก็เห็นว่านั่นสมเหตุสมผลในหลายสถานการณ์ แม้ว่าข้อควรระวังทั่วไปเกี่ยวกับ การเพิ่มความซับซ้อนของระบบโดยรวมและการเพิ่ม network hop จะยังคงใช้ได้อยู่

ผมเคยมีส่วนร่วมเป็นครั้งคราวในการทำงานโดยตรงกับ vendor เพื่อช่วยเลือกเครื่องมือ ผมสามารถพูดได้โดยไม่ลังเลว่าผมเคยเจอการขาย ที่ผิดพลาดและพฤติกรรมที่แย่หรือโหดร้ายในพื้นที่ของ API gateway มากกว่าพื้นที่อื่นใด—และเป็นผลให้คุณจะไม่พบการอ้างอิงถึง product ของ vendor บางตัวในบทนี้ ผมโทษส่วนใหญ่ไปที่บริษัทที่ได้รับทุนจาก VC ซึ่งสร้าง product สำหรับยุครุ่งเรืองของ API economy แต่กลับพบว่าตลาดนั้นไม่มีอยู่จริง และดังนั้นพวกเขาจึงต้องต่อสู้ในสองแนวรบ: พวกเขาแย่งชิงผู้ใช้จำนวนน้อยที่ต้องการสิ่งที่ gateway ที่ซับซ้อนกว่านำเสนอจริงๆ ในขณะเดียวกันก็เสียธุรกิจให้กับ API gateway product เฉพาะทางที่ถูกสร้างมาสำหรับความต้องการ ที่ง่ายกว่าของคนส่วนใหญ่

What to avoid (สิ่งที่ควรหลีกเลี่ยง)

ส่วนหนึ่งเป็นเพราะความสิ้นหวังที่ปรากฏชัดของ API gateway vendor บางราย มีการอ้างสิทธิ์ทุกรูปแบบเกี่ยวกับสิ่งที่ product เหล่านี้ ทำได้ สิ่งนี้นำไปสู่การใช้ product เหล่านี้ผิดวิธีมากมาย และในทางกลับกันก็นำไปสู่ความไม่ไว้วางใจที่น่าเสียดายต่อสิ่งที่โดยพื้นฐาน แล้วเป็นแนวคิดที่ค่อนข้างง่าย ตัวอย่างสำคัญสองอย่างของการใช้ API gateway ผิดวิธีที่ผมเคยเห็นคือ call aggregation และ protocol rewriting แต่ผมก็เคยเห็นการผลักดันที่กว้างขึ้นให้ใช้ API gateway สำหรับ call ภายใน perimeter (east-west) ด้วยเช่นกัน

ในบทนี้เราได้ดูประโยชน์ของ protocol อย่าง GraphQL ไปแล้วสั้นๆ ที่ช่วยเราในสถานการณ์ที่เราต้องยิง call จำนวนหนึ่งแล้วรวม และกรองผลลัพธ์ แต่คนก็มักถูกล่อลวงให้แก้ปัญหานี้ใน API gateway layer ด้วยเช่นกัน มันเริ่มต้นอย่างไม่มีพิษภัย: คุณรวม call สองสามตัวและคืน payload เดียว จากนั้นคุณก็เริ่มทำ downstream call อีกตัวเป็นส่วนหนึ่งของ flow ที่รวมกันเดียวกัน จากนั้น คุณก็เริ่มอยากเพิ่ม conditional logic และก่อนที่คุณจะรู้ตัว คุณก็ตระหนักว่าคุณได้ฝัง core business process เข้าไปใน third-party tool ที่ไม่เหมาะกับงานนี้

ถ้าคุณพบว่าตัวเองจำเป็นต้องทำ call aggregation และ filtering ให้ดูที่ศักยภาพของ GraphQL หรือ BFF pattern ซึ่งเราจะครอบคลุม ใน Chapter 14 ถ้า call aggregation ที่คุณกำลังทำนั้นโดยพื้นฐานแล้วเป็น business process การทำผ่าน saga ที่ model ไว้อย่างชัดเจนจะดีกว่า ซึ่งเราจะครอบคลุมใน Chapter 6

นอกเหนือจากมุม aggregation แล้ว protocol rewriting ก็มักถูกผลักดันให้เป็นสิ่งที่ API gateway ควรถูกใช้เช่นกัน ผมจำได้ว่า vendor รายหนึ่งที่ไม่ขอเอ่ยนามได้โปรโมทแนวคิดอย่างก้าวร้าวมากว่า product ของมันสามารถ "เปลี่ยน SOAP API ใดๆ ให้เป็น REST API" ได้ อย่างแรก REST เป็นแนวคิดสถาปัตยกรรมทั้งชุดที่ไม่สามารถ implement ได้ง่ายๆ ใน proxy layer อย่างที่สอง protocol rewriting ซึ่งโดยพื้นฐานแล้วคือสิ่งที่มันพยายามทำ ไม่ควรทำใน intermediate layer เพราะมันผลักดันพฤติกรรมมากเกินไปไปยังที่ผิด

ปัญหาหลักของทั้งความสามารถ protocol rewriting และการ implement call aggregation ภายใน API gateway คือเรากำลังละเมิดกฎ ของการรักษาให้ pipe โง่และ endpoint ฉลาด "ความฉลาด" ในระบบของเราต้องการอยู่ใน code ของเรา ที่ที่เราสามารถควบคุมมันได้อย่าง เต็มที่ API gateway ในตัวอย่างนี้เป็น pipe—เราต้องการให้มันง่ายที่สุดเท่าที่จะทำได้ กับไมโครเซอร์วิส เรากำลังผลักดันโมเดล ที่การเปลี่ยนแปลงสามารถทำได้และถูก release ได้ง่ายขึ้นผ่าน independent deployability การรักษาความฉลาดไว้ในไมโครเซอร์วิสของเรา ช่วยเรื่องนี้ ถ้าตอนนี้เราต้องทำการเปลี่ยนแปลงใน intermediate layer ด้วย สิ่งต่างๆ ก็จะยิ่งมีปัญหามากขึ้น เนื่องจากความสำคัญ ของ API gateway การเปลี่ยนแปลงที่ทำกับมันมักถูกควบคุมอย่างเข้มงวด ดูเหมือนไม่น่าเป็นไปได้ที่แต่ละทีมจะได้รับอิสระเต็มที่ใน การเปลี่ยนแปลง service ที่มักถูกจัดการแบบรวมศูนย์เหล่านี้ด้วยตัวเอง นั่นหมายความว่าอะไร? Ticket ในการ roll out การเปลี่ยนแปลง software ของคุณ คุณจะจบลงด้วยการให้ทีม API gateway ทำการเปลี่ยนแปลงให้คุณ ยิ่งคุณปล่อยพฤติกรรมรั่วไหลเข้าไปใน API gateway (หรือใน enterprise service bus) มากเท่าไหร่ คุณก็ยิ่งเสี่ยงต่อการส่งต่องาน การประสานงานที่เพิ่มขึ้น และการส่งมอบที่ช้าลง มากเท่านั้น

ปัญหาสุดท้ายคือการใช้ API gateway เป็นตัวกลางสำหรับ call ระหว่างไมโครเซอร์วิสทั้งหมด สิ่งนี้อาจมีปัญหาอย่างมาก ถ้าเราแทรก API gateway หรือ network proxy ธรรมดาระหว่างไมโครเซอร์วิสสองตัว เราก็มักจะเพิ่ม network hop อย่างน้อยหนึ่งครั้ง call จาก ไมโครเซอร์วิส A ไปยังไมโครเซอร์วิส B จะไปจาก A ไปยัง API gateway ก่อน แล้วจึงไปจาก API gateway ไปยัง B เราต้องพิจารณา ผลกระทบด้าน latency ของ network call เพิ่มเติมนี้และ overhead ของสิ่งที่ proxy กำลังทำอยู่ Service mesh ซึ่งเราจะสำรวจ ต่อไป อยู่ในตำแหน่งที่ดีกว่ามากในการแก้ปัญหานี้

Service Meshes

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

Feature ทั่วไปที่ implement โดย service mesh รวมถึง mutual TLS, correlation ID, service discovery และ load balancing และอื่นๆ บ่อยครั้งที่ functionality ประเภทนี้ค่อนข้าง generic จากไมโครเซอร์วิสหนึ่งไปอีกตัว ดังนั้นเราก็จะจบลงด้วยการใช้ shared library เพื่อจัดการมัน แต่แล้วคุณก็ต้องจัดการกับสิ่งที่เกิดขึ้นถ้าไมโครเซอร์วิสที่แตกต่างกันมี library version ที่แตกต่างกัน กำลังรันอยู่ หรือสิ่งที่เกิดขึ้นถ้าคุณมีไมโครเซอร์วิสที่เขียนด้วย runtime ที่แตกต่างกัน

อย่างน้อยในอดีต Netflix กำหนดให้การสื่อสารผ่านเครือข่ายแบบ nonlocal ทั้งหมดต้องทำแบบ JVM ต่อ JVM นี่เพื่อให้แน่ใจว่า common library ที่ผ่านการทดสอบและพิสูจน์แล้ว ซึ่งเป็นส่วนสำคัญของการจัดการการสื่อสารที่มีประสิทธิภาพระหว่างไมโครเซอร์วิส สามารถถูกใช้ซ้ำได้ อย่างไรก็ตาม ด้วยการใช้ service mesh เรามีความเป็นไปได้ที่จะใช้ common inter-microservice functionality ซ้ำข้ามไมโครเซอร์วิสที่ เขียนด้วยภาษาโปรแกรมที่แตกต่างกัน Service mesh ยังสามารถมีประโยชน์อย่างเหลือเชื่อในการ implement พฤติกรรมมาตรฐานข้ามไมโครเซอร์วิส ที่สร้างโดยทีมที่แตกต่างกัน—และการใช้ service mesh โดยเฉพาะบน Kubernetes ได้กลายเป็นส่วนที่ถูกสมมติไว้ล่วงหน้ามากขึ้นเรื่อยๆ ของ platform ใดก็ตามที่คุณอาจสร้างสำหรับการ deploy และจัดการไมโครเซอร์วิสแบบ self-service

การทำให้ง่ายที่จะ implement พฤติกรรมทั่วไปข้ามไมโครเซอร์วิสเป็นหนึ่งในประโยชน์ใหญ่ของ service mesh ถ้า functionality ทั่วไปนี้ ถูก implement ผ่าน shared library เพียงอย่างเดียว การเปลี่ยนพฤติกรรมนี้จะต้องการให้ไมโครเซอร์วิสทุกตัวดึง library version ใหม่ เข้ามาและถูก deploy ก่อนที่การเปลี่ยนแปลงนั้นจะมีผล กับ service mesh คุณมีความยืดหยุ่นมากขึ้นในการ roll out การเปลี่ยนแปลงในแง่ของ การสื่อสารระหว่างไมโครเซอร์วิส โดยไม่ต้อง rebuild และ redeploy

How they work (พวกมันทำงานอย่างไร)

โดยทั่วไป เราคาดหวังว่าจะมี traffic แบบ north-south น้อยกว่า traffic แบบ east-west ในสถาปัตยกรรมไมโครเซอร์วิส north-south call เดียว—การสั่งซื้อ ตัวอย่างเช่น—อาจส่งผลให้เกิด east-west call หลายตัว นี่หมายความว่าเมื่อพิจารณา proxy ประเภทใดก็ตาม สำหรับ call ภายใน perimeter เราต้องตระหนักถึง overhead ที่ call เพิ่มเติมเหล่านี้อาจก่อให้เกิด และนี่เป็นข้อพิจารณาหลักใน แง่ของวิธีที่ service mesh ถูกสร้างขึ้น

Service mesh มาในรูปทรงและขนาดที่ต่างกัน แต่สิ่งที่รวมพวกมันเข้าด้วยกันคือสถาปัตยกรรมของพวกมันถูกสร้างบนพื้นฐานของการพยายาม จำกัดผลกระทบที่เกิดจาก call ไปและกลับจาก proxy สิ่งนี้ทำได้เป็นหลักโดยการกระจาย proxy process ให้รันบนเครื่องจริงเดียวกันกับ microservice instance เพื่อให้แน่ใจว่าจำนวน remote network call ถูกจำกัด ใน Figure 5-7 เราเห็นสิ่งนี้ในการทำงาน— Order Processor กำลังส่ง request ไปยังไมโครเซอร์วิส Payment Call นี้ถูก route ไปยัง proxy instance ที่รันบนเครื่องเดียวกันกับ Order Processor ในเบื้องต้นก่อน แล้วจึงดำเนินต่อไปยังไมโครเซอร์วิส Payment ผ่าน proxy instance ในเครื่องของมัน Order Processor คิดว่ามันกำลังทำ network call ธรรมดา โดยไม่รู้ว่า call นั้นถูก route ในเครื่องเดียวกัน ซึ่งเร็วกว่ามาก (และมีแนวโน้มที่จะ ถูก partition น้อยกว่าด้วย)

Figure 5-7. A service mesh is deployed to handle all direct inter-microservice communication (Service mesh ถูก deploy เพื่อจัดการการสื่อสารระหว่างไมโครเซอร์วิสโดยตรงทั้งหมด)

Control plane จะอยู่เหนือ local mesh proxy ทั้งหมด ทำหน้าที่เป็นทั้งที่ที่พฤติกรรมของ proxy เหล่านี้สามารถถูกเปลี่ยนแปลงได้ และที่ที่คุณสามารถเก็บรวบรวมข้อมูลเกี่ยวกับสิ่งที่ proxy กำลังทำอยู่

เมื่อ deploy บน Kubernetes คุณจะ deploy แต่ละ microservice instance ใน pod พร้อมกับ local proxy ของมันเอง pod เดียว จะถูก deploy เป็นหน่วยเดียวเสมอ ดังนั้นคุณจะรู้เสมอว่าคุณมี proxy พร้อมใช้ ยิ่งไปกว่านั้น การที่ proxy ตัวเดียวตายจะส่งผลกระทบ เฉพาะ pod ตัวนั้นตัวเดียว การตั้งค่านี้ยังให้คุณสามารถกำหนดค่า proxy แต่ละตัวแตกต่างกันสำหรับจุดประสงค์ที่ต่างกันได้ เราจะดู แนวคิดเหล่านี้ในรายละเอียดมากขึ้นใน "Kubernetes and Container Orchestration"

Service mesh implementation หลายตัวใช้ proxy Envoy เป็นพื้นฐานสำหรับ process ที่รันในเครื่องเหล่านี้ Envoy เป็น proxy C++ น้ำหนักเบาที่มักถูกใช้เป็น building block สำหรับ service mesh และ proxy-based software ประเภทอื่นๆ—มันเป็น building block ที่สำคัญสำหรับ Istio และ Ambassador ตัวอย่างเช่น

Proxy เหล่านี้ในทางกลับกันก็ถูกจัดการโดย control plane นี่จะเป็นชุดของ software ที่ช่วยให้คุณเห็นว่าเกิดอะไรขึ้นและควบคุม สิ่งที่กำลังถูกทำ เมื่อใช้ service mesh เพื่อ implement mutual TLS ตัวอย่างเช่น control plane จะถูกใช้เพื่อกระจาย client และ server certificate

Aren't service meshes smart pipes? (Service Mesh ไม่ใช่ Smart Pipe หรือ?)

ดังนั้น การพูดถึงการผลักพฤติกรรมทั่วไปเข้าไปใน service mesh ทั้งหมดนี้อาจทำให้บางคนรู้สึกเป็นสัญญาณเตือนภัย นี่ไม่ใช่แนวทางที่ เปิดรับปัญหาแบบเดียวกันกับ enterprise service bus หรือ API gateway ที่บวมเกินไปหรอกหรือ? เราไม่ได้เสี่ยงที่จะผลัก "ความฉลาด" เข้าไปใน service mesh ของเรามากเกินไปหรอกหรือ?

สิ่งสำคัญที่ต้องจำไว้ตรงนี้คือพฤติกรรมทั่วไปที่เรากำลังใส่เข้าไปใน mesh นั้นไม่ได้เฉพาะเจาะจงกับไมโครเซอร์วิสตัวใดตัวหนึ่ง ไม่มี business functionality รั่วไหลออกไปสู่ภายนอก เรากำลังกำหนดค่าสิ่งทั่วไปอย่างวิธีที่ request time-out ถูกจัดการ ในแง่ของ พฤติกรรมทั่วไปที่อาจต้องถูกปรับแต่งตามแต่ละไมโครเซอร์วิส นั่นมักเป็นสิ่งที่ถูกรองรับได้ดีอยู่แล้ว โดยไม่ต้องมีงานที่ต้องทำบน platform กลาง ตัวอย่างเช่น กับ Istio ผมสามารถกำหนดความต้องการ time-out ของผมแบบ self-service ได้เพียงแค่เปลี่ยน service definition ของผม

Do you need one? (คุณต้องการมันไหม?)

เมื่อการใช้ service mesh เริ่มได้รับความนิยมเป็นครั้งแรก หลังจากที่ฉบับพิมพ์ครั้งแรกของหนังสือเล่มนี้ออกมาไม่นาน ผมเห็นข้อดี มากมายในแนวคิดนี้ แต่ก็เห็นความปั่นป่วนมากมายในพื้นที่นี้เช่นกัน มีการเสนอ deployment model ที่แตกต่างกัน สร้างขึ้น แล้วก็ถูก ทิ้งไป และจำนวนบริษัทที่เสนอทางออกในพื้นที่นี้ก็เพิ่มขึ้นอย่างมาก แต่แม้แต่เครื่องมือที่มีมานานแล้ว ก็ยังมีการขาดเสถียรภาพที่ ปรากฏชัด Linkerd ซึ่งอาจกล่าวได้ว่าทำมากกว่าใครในการบุกเบิกพื้นที่นี้ ได้สร้าง product ของมันขึ้นใหม่ทั้งหมดตั้งแต่ต้นในการเปลี่ยนจาก v1 เป็น v2 Istio ซึ่งเป็น service mesh ที่ Google รับรอง ใช้เวลาหลายปีกว่าจะไปถึง release 1.0 เริ่มต้น และแม้จะถึงตอนนั้นแล้ว มันก็ยังมีการ เปลี่ยนแปลงที่สำคัญตามมาในสถาปัตยกรรมของมัน (ย้ายไปสู่โมเดล deployment แบบ monolithic มากขึ้นสำหรับ control plane ของมัน ซึ่งค่อนข้างประชดประชันแต่ก็สมเหตุสมผล)

ตลอดส่วนใหญ่ของห้าปีที่ผ่านมา เมื่อผมถูกถามว่า "เราควรได้ service mesh ไหม?" คำแนะนำของผมคือ "ถ้าคุณสามารถรอหกเดือนก่อน ตัดสินใจได้ ก็ให้รอหกเดือน" ผมถูกโน้มน้าวด้วยแนวคิดนี้แต่กังวลเกี่ยวกับเสถียรภาพ และอะไรบางอย่างอย่าง service mesh ไม่ใช่ที่ ที่ผมส่วนตัวอยากเสี่ยงมาก—มันสำคัญมาก จำเป็นมากต่อการที่ทุกอย่างจะทำงานได้ดี คุณกำลังวาง mesh ไว้บน critical path ของคุณ มันอยู่ในระดับเดียวกับการเลือก message broker หรือ cloud provider ในแง่ของความจริงจังที่ผมจะให้กับมัน

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

Monzo เป็นหนึ่งในองค์กรที่พูดอย่างเปิดเผยว่าการใช้ service mesh ของพวกเขาจำเป็นแค่ไหนในการช่วยให้พวกเขารันสถาปัตยกรรมของ พวกเขาได้ในระดับ scale ที่พวกเขาทำอยู่ การใช้ Linkerd version 1 เพื่อช่วยจัดการ inter-microservice RPC call พิสูจน์แล้วว่า มีประโยชน์อย่างมาก ที่น่าสนใจคือ Monzo ต้องจัดการ กับความเจ็บปวดของการย้าย service mesh เพื่อช่วยให้บรรลุ scale ที่พวกเขาต้องการ เมื่อสถาปัตยกรรมเก่าของ Linkerd v1 ไม่ตรง กับความต้องการของพวกเขาอีกต่อไป ในที่สุดพวกเขาก็ย้ายไปยัง in-house service mesh ที่ใช้ Envoy proxy อย่างมีประสิทธิภาพ

What About Other Protocols? (แล้ว Protocol อื่นๆ ล่ะ?)

API gateway และ service mesh ถูกใช้เป็นหลักเพื่อจัดการ call ที่เกี่ยวข้องกับ HTTP ดังนั้น REST, SOAP, gRPC และสิ่งที่คล้ายกัน สามารถถูกจัดการผ่าน product เหล่านี้ได้ อย่างไรก็ตาม สิ่งต่างๆ จะเริ่มคลุมเครือมากขึ้นเมื่อคุณเริ่มดูการสื่อสารผ่าน protocol อื่นๆ เช่น การใช้ message broker อย่าง Kafka โดยทั่วไป ณ จุดนี้ service mesh จะถูกข้ามไป—การสื่อสารจะทำโดยตรงกับตัว broker เอง นี่หมายความว่าคุณไม่สามารถสมมติได้ว่า service mesh ของคุณสามารถทำงานเป็นตัวกลางสำหรับ call ทั้งหมดระหว่างไมโครเซอร์วิสได้