The Required Standard (มาตรฐานที่จำเป็น)

เมื่อ คุณกำลังทำงานผ่านแนวปฏิบัติของคุณและคิดถึง trade-off ที่คุณต้องตัดสินใจ หนึ่งในความสมดุลที่สำคัญที่สุดที่ต้องหาคือควรอนุญาตให้ระบบของคุณมีความหลากหลายมากแค่ไหน หนึ่งในวิธีสำคัญในการระบุว่าอะไรควรคงที่จากไมโครเซอร์วิสหนึ่งไปอีกตัวหนึ่งคือการกำหนดว่าไมโครเซอร์วิสที่ดีและมีพฤติกรรมเหมาะสมนั้นหน้าตาเป็นอย่างไร อะไรคือไมโครเซอร์วิสที่เป็น "good citizen" ในระบบของคุณ มันต้องมีความสามารถอะไรบ้างเพื่อมั่นใจว่าระบบของคุณจัดการได้ และไมโครเซอร์วิสตัวเดียวที่ทำงานผิดปกติจะไม่ทำให้ทั้งระบบล่ม เช่นเดียวกับคน สิ่งที่เป็น "good citizen" microservice ในบริบทหนึ่งอาจไม่สะท้อนหน้าตาของมันในอีกที่หนึ่ง ถึงกระนั้นก็มีคุณลักษณะร่วมบางอย่างของไมโครเซอร์วิสที่มีพฤติกรรมดีที่ผมคิดว่าค่อนข้างสำคัญที่จะปฏิบัติตาม นี่คือพื้นที่สำคัญไม่กี่แห่งที่การปล่อยให้แตกต่างกันมากเกินไปอาจส่งผลให้เกิดช่วงเวลาที่เลวร้ายมาก อย่างที่ Ben Christensen จาก Facebook พูดไว้ เมื่อคุณคิดถึงภาพรวม "มันต้องเป็นระบบที่เป็นเนื้อเดียวกัน ประกอบขึ้นจากส่วนเล็กๆ จำนวนมากที่มีวงจรชีวิตเป็นอิสระ แต่มารวมกันเป็นหนึ่งเดียว" ดังนั้นคุณต้องหาสมดุลที่คุณ optimize ความเป็นอิสระของไมโครเซอร์วิสแต่ละตัว โดยไม่ละสายตาจากภาพรวมที่ใหญ่กว่า การกำหนดคุณลักษณะที่ชัดเจนว่าไมโครเซอร์วิสแต่ละตัวควรมี เป็นวิธีหนึ่งที่จะชี้ให้เห็นชัดว่าสมดุลนั้นอยู่ตรงไหน มาดูคุณลักษณะบางส่วนเหล่านั้นกัน

Monitoring (การเฝ้าติดตาม)

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

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

Interfaces (อินเทอร์เฟซ)

การเลือกเทคโนโลยีอินเทอร์เฟซจำนวนน้อยที่ชัดเจนช่วยให้การผสานรวมผู้บริโภครายใหม่ง่ายขึ้น การมีมาตรฐานเดียวเป็นเรื่องดี สองแบบก็ยังไม่แย่นัก แต่การมีรูปแบบการผสานรวมถึงยี่สิบแบบไม่ใช่เรื่องดี นี่ไม่ใช่แค่เรื่องการเลือกเทคโนโลยีและโปรโตคอลเท่านั้น ถ้าคุณเลือก HTTP/REST ตัวอย่างเช่น คุณจะใช้ verb หรือ noun คุณจะจัดการการแบ่งหน้า (pagination) ของทรัพยากรอย่างไร คุณจะจัดการการทำ versioning ของ endpoint อย่างไร

Architectural Safety (ความปลอดภัยเชิงสถาปัตยกรรม)

เรา ไม่มีทางยอมให้ไมโครเซอร์วิสที่มีพฤติกรรมแย่ตัวเดียวทำลายบรรยากาศให้ทุกคนได้ เราต้องมั่นใจว่าไมโครเซอร์วิสของเราป้องกันตัวเองจากการเรียกไปยังปลายทางที่ไม่แข็งแรงได้อย่างเหมาะสม ยิ่งเรามีไมโครเซอร์วิสจำนวนมากที่ไม่จัดการความล้มเหลวที่อาจเกิดขึ้นของการเรียกปลายทางอย่างเหมาะสม ระบบของเราก็จะยิ่งเปราะบาง สิ่งนี้อาจหมายความว่าคุณต้องการบังคับใช้แนวปฏิบัติบางอย่าง เกี่ยวกับการสื่อสารระหว่างเซอร์วิส เช่น การกำหนดให้ใช้ circuit breaker (หัวข้อที่เราสำรวจใน "Stability Patterns" )

การเล่นตามกฎก็สำคัญเรื่อง response code เช่นกัน ถ้า circuit breaker ของคุณพึ่งพารหัส HTTP และไมโครเซอร์วิสตัวหนึ่งตัดสินใจส่งรหัส 2XX กลับมาสำหรับข้อผิดพลาด หรือสับสนระหว่างรหัส 4XX กับ 5XX มาตรการความปลอดภัยเหล่านี้ก็อาจล้มเหลวได้ ข้อกังวลที่คล้ายกันก็ยังใช้ได้แม้คุณจะไม่ได้ใช้ HTTP เราต้องรู้ความแตกต่างระหว่างคำขอที่โอเคและประมวลผลได้ถูกต้อง คำขอที่ผิดพลาดจนทำให้ไมโครเซอร์วิสไม่สามารถทำอะไรกับมันได้ และคำขอที่อาจโอเคแต่เราบอกไม่ได้เพราะเซิร์ฟเวอร์ล่ม การรู้สิ่งเหล่านี้เป็นกุญแจสำคัญในการทำให้เรา fail fast และตามหาต้นตอของปัญหาได้ ถ้าไมโครเซอร์วิสของเราไม่เคร่งครัดกับกฎเหล่านี้ เราก็จะได้ระบบที่เปราะบางกว่า