Enabling Technology (เทคโนโลยีที่ช่วยเปิดทาง)

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

กระนั้น เทคโนโลยีก็มีบทบาทสำคัญในการรับ microservices มาใช้ในฐานะแนวคิด การเข้าใจเครื่องมือที่มีอยู่เพื่อช่วย ให้คุณได้ประโยชน์สูงสุดจากสถาปัตยกรรมนี้จะเป็นส่วนสำคัญในการทำให้การ implement microservices ประสบความสำเร็จ อันที่จริง ผมกล้าพูดได้ว่า microservices ต้องการความเข้าใจในเทคโนโลยีที่รองรับมันมากถึงขนาดที่ความแตกต่าง แบบเดิมระหว่างสถาปัตยกรรมเชิงตรรกะ (logical) และเชิงกายภาพ (physical) อาจกลายเป็นปัญหาได้—หากคุณมีส่วนช่วย กำหนดรูปร่างสถาปัตยกรรม microservice คุณจะต้องมีความเข้าใจกว้างขวางในทั้งสองโลกนี้

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

Log Aggregation and Distributed Tracing (Log Aggregation และ Distributed Tracing)

เมื่อจำนวน process ที่คุณจัดการเพิ่มขึ้น การเข้าใจว่าระบบของคุณทำงานอย่างไรในสภาพแวดล้อม production อาจ ยากขึ้น สิ่งนี้ในทางกลับกันทำให้การแก้ปัญหายากขึ้นไปอีก เราจะสำรวจแนวคิดเหล่านี้อย่างละเอียดขึ้นใน Chapter 10 แต่อย่างน้อยที่สุด ผมสนับสนุนอย่างยิ่งให้ implement ระบบ log aggregation เป็นข้อกำหนดเบื้องต้นก่อนรับ สถาปัตยกรรม microservice มาใช้

Tip (เคล็ดลับ)

ระวังการรับเทคโนโลยีใหม่มากเกินไปเมื่อคุณเริ่มต้นใช้ microservices กระนั้น เครื่องมือ log aggregation ก็จำเป็นมากถึงขนาดที่คุณควรพิจารณาว่าเป็นข้อกำหนดเบื้องต้นสำหรับการรับ microservices มาใช้

ระบบเหล่านี้ช่วยให้คุณรวบรวมและรวม log จากทุก service ของคุณ ทำให้คุณมีที่ศูนย์กลางในการวิเคราะห์ log และแม้กระทั่งทำให้เป็นส่วนหนึ่งของกลไกการแจ้งเตือนแบบ active ตัวเลือกมากมายในพื้นที่นี้รองรับสถานการณ์ ต่างๆ มากมาย ผมชอบ Humio ด้วยเหตุผลหลายประการ แต่บริการ logging แบบง่ายๆ ที่ public cloud vendor รายใหญ่มอบให้ก็อาจเพียงพอที่จะ เริ่มต้นได้

คุณสามารถทำให้เครื่องมือ log aggregation เหล่านี้มีประโยชน์มากขึ้นได้ด้วยการ implement correlation ID ซึ่ง ID เดียวถูกใช้สำหรับชุดการเรียก service ที่เกี่ยวข้องกัน—ตัวอย่างเช่น ลำดับการเรียกที่อาจถูกกระตุ้น จากการโต้ตอบของผู้ใช้ ด้วยการบันทึก ID นี้เป็นส่วนหนึ่งของแต่ละ log entry การแยก log ที่เกี่ยวข้องกับ flow การเรียกใดๆ ก็ทำได้ง่ายขึ้นมาก ซึ่งในทางกลับกันก็ทำให้การแก้ปัญหาง่ายขึ้นมาก

เมื่อระบบของคุณเติบโตซับซ้อนขึ้น การพิจารณาเครื่องมือที่ช่วยให้คุณสำรวจได้ดีขึ้นว่าระบบของคุณกำลังทำอะไร อยู่ก็กลายเป็นสิ่งจำเป็น โดยให้ความสามารถในการวิเคราะห์ trace ข้าม service หลายตัว ตรวจจับ bottleneck และตั้งคำถามกับระบบของคุณที่คุณไม่รู้ด้วยซ้ำว่าจะอยากถามในตอนแรก เครื่องมือ open source สามารถให้ความ สามารถบางอย่างเหล่านี้ได้ ตัวอย่างหนึ่งคือ Jaeger ซึ่งเน้นไปที่ด้าน distributed tracing

แต่ผลิตภัณฑ์อย่าง Lightstep และ Honeycomb (แสดงใน Figure 1-9 ) นำแนวคิดเหล่านี้ไปไกลกว่านั้น พวกมันเป็นตัวแทนของเครื่องมือรุ่นใหม่ที่ก้าวข้ามแนวทาง monitoring แบบดั้งเดิม ทำให้การสำรวจสถานะของระบบที่กำลังทำงานอยู่ง่ายขึ้นมาก คุณอาจมีเครื่องมือแบบดั้งเดิมกว่าอยู่แล้ว แต่คุณควร ดูความสามารถที่ผลิตภัณฑ์เหล่านี้มอบให้จริงๆ พวกมันถูกสร้างขึ้นตั้งแต่ต้นเพื่อแก้ปัญหาประเภทที่ผู้ดูแล สถาปัตยกรรม microservice ต้องรับมือ

Figure 1-9. A distributed trace shown in Honeycomb, allowing you to identify where time is being spent for operations that can span multiple microservices (distributed trace ที่แสดงใน Honeycomb ช่วยให้คุณระบุได้ว่าเวลาถูกใช้ไปที่ไหนสำหรับ operation ที่อาจครอบคลุมหลาย microservice)

Containers and Kubernetes (Container และ Kubernetes)

โดยอุดมคติแล้ว คุณต้องการรัน microservice instance แต่ละตัวแบบแยกโดดเดี่ยว สิ่งนี้ทำให้แน่ใจว่าปัญหาใน microservice หนึ่งจะไม่ส่งผลกระทบต่อ microservice อื่น—ตัวอย่างเช่น การใช้ CPU ทั้งหมดจนหมด Virtualization เป็นวิธีหนึ่งในการสร้างสภาพแวดล้อมการทำงานที่แยกโดดเดี่ยวบน hardware ที่มีอยู่ แต่เทคนิค virtualization แบบปกติอาจหนักมากเมื่อพิจารณาจากขนาดของ microservice ของเรา Container ในทางกลับกัน ให้วิธีที่เบากว่ามากในการจัดสรร execution environment ที่แยกโดดเดี่ยวสำหรับ service instance ส่งผลให้เวลาในการ spin up container instance ใหม่เร็วขึ้น พร้อมทั้งคุ้มค่ากว่ามากสำหรับหลายสถาปัตยกรรม

หลังจากคุณเริ่มลองเล่นกับ container คุณจะตระหนักด้วยว่าคุณต้องการบางสิ่งที่ช่วยให้คุณจัดการ container เหล่านี้ข้ามเครื่องพื้นฐานจำนวนมากได้ Container orchestration platform อย่าง Kubernetes ทำสิ่งนั้นได้พอดี ช่วยให้คุณกระจาย container instance ในลักษณะที่ให้ความทนทานและ throughput ที่ service ของคุณต้องการ ใน ขณะที่ยังคงใช้เครื่องพื้นฐานได้อย่างมีประสิทธิภาพ ใน Chapter 8 เราจะสำรวจแนวคิดของ operational isolation, container และ Kubernetes

อย่ารู้สึกว่าต้องรีบรับ Kubernetes หรือแม้แต่ container มาใช้ พวกมันมอบข้อได้เปรียบสำคัญเหนือเทคนิคการ deploy แบบดั้งเดิมกว่าอย่างแน่นอน แต่การรับมาใช้ยากที่จะให้เหตุผลสนับสนุนได้ หากคุณมี microservice เพียง ไม่กี่ตัว หลังจากภาระในการจัดการการ deploy เริ่มกลายเป็นปัญหาปวดหัวสำคัญ จึงเริ่มพิจารณา containerize service ของคุณและใช้ Kubernetes แต่หากคุณตัดสินใจทำแบบนั้น จงพยายามอย่างเต็มที่ให้แน่ใจว่ามีคนอื่นเป็นคน รัน Kubernetes cluster ให้คุณ อาจโดยการใช้ managed service จาก public cloud provider การรัน Kubernetes cluster ของคุณเองอาจเป็นงานจำนวนมหาศาล!

Streaming (Streaming)

แม้ว่าด้วย microservices เรากำลังก้าวออกห่างจากฐานข้อมูล monolithic แต่เรายังคงต้องหาวิธีแชร์ข้อมูล ระหว่าง microservice สิ่งนี้เกิดขึ้นในเวลาเดียวกับที่องค์กรต่างๆ ต้องการก้าวออกห่างจากการ report แบบ batch และมุ่งสู่ feedback แบบ real-time มากขึ้น ทำให้พวกเขาตอบสนองได้เร็วขึ้น ผลิตภัณฑ์ที่ช่วยให้ stream และ ประมวลผลข้อมูลปริมาณมากได้อย่างง่ายดายจึงได้รับความนิยมในหมู่ผู้ใช้สถาปัตยกรรม microservice

สำหรับหลายคน Apache Kafka กลายเป็นตัวเลือกโดยพฤตินัยสำหรับ streaming ข้อมูลในสภาพแวดล้อม microservice และก็มีเหตุผลที่ดี ความสามารถอย่างความคงทนของ message, การ compaction และความสามารถในการ scale เพื่อรองรับ message ปริมาณ มากล้วนมีประโยชน์อย่างมาก Kafka เริ่มเพิ่มความสามารถ stream-processing ในรูปแบบของ KSQLDB แต่คุณก็สามารถ ใช้มันร่วมกับ solution stream-processing เฉพาะทางอย่าง Apache Flink ได้เช่นกัน Debezium เป็นเครื่องมือ open source ที่พัฒนาขึ้นเพื่อช่วย stream ข้อมูลจากแหล่งข้อมูล ที่มีอยู่แล้ว ผ่าน Kafka ช่วยให้แน่ใจว่าแหล่งข้อมูลแบบดั้งเดิมสามารถกลายเป็นส่วนหนึ่งของสถาปัตยกรรมที่อิง stream ได้ ใน Chapter 4 เราจะดูว่าเทคโนโลยี streaming มีบทบาทอย่างไรในการ integrate microservice

Public Cloud and Serverless (Public Cloud และ Serverless)

public cloud provider หรือให้เจาะจงกว่านั้นคือสามผู้ให้บริการหลัก—Google Cloud, Microsoft Azure และ Amazon Web Services (AWS)—มอบ managed service และตัวเลือกการ deploy มากมายสำหรับจัดการแอปพลิเคชันของคุณ เมื่อสถาปัตยกรรม microservice ของคุณเติบโตขึ้น งานมากขึ้นเรื่อยๆ จะถูกผลักเข้าไปในพื้นที่ operational Public cloud provider มอบ managed service มากมาย ตั้งแต่ managed database instance หรือ Kubernetes cluster ไปจนถึง message broker หรือ distributed filesystem ด้วยการใช้ managed service เหล่านี้ คุณกำลังยกภาระงานจำนวนมากนี้ให้บุคคลที่สามที่อาจสามารถจัดการงานเหล่านี้ได้ดีกว่า

สิ่งที่น่าสนใจเป็นพิเศษในบรรดา offering ของ public cloud คือผลิตภัณฑ์ที่อยู่ภายใต้ชื่อ serverless ผลิตภัณฑ์เหล่านี้ซ่อนเครื่องพื้นฐานไว้ ช่วยให้คุณทำงานในระดับ abstraction ที่สูงขึ้น ตัวอย่างของผลิตภัณฑ์ serverless ได้แก่ message broker, storage solution และฐานข้อมูล Function as a Service (FaaS) platform น่าสนใจเป็นพิเศษเพราะพวกมันมอบ abstraction ที่ดีรอบๆ การ deploy โค้ด แทนที่จะกังวลว่าคุณต้องการ server กี่เครื่องเพื่อรัน service ของคุณ คุณแค่ deploy โค้ดของคุณและให้ platform พื้นฐานจัดการการ spin up instance ของโค้ดคุณตามความต้องการ เราจะดู serverless ในรายละเอียด เพิ่มเติมใน Chapter 8