ไมโครเซอร์วิส 101: ความดี ความชั่ว และสิ่งที่น่าเกลียด

เนื่องจากไมโครเซอร์วิสกำลังได้รับความนิยม ผู้ที่มีความทรงจำสั้นๆ อาจมองข้ามไป แนวทางดังกล่าวมีความคล้ายคลึงกับสถาปัตยกรรมเชิงบริการที่โดดเด่น ซึ่งเกิดขึ้นครั้งแรกเมื่อสองทศวรรษ ที่ผ่านมา.

แต่มิดเดิลแวร์ฝ่ายวิศวกรรมของ Red Hat VP ดร. มาร์ค ลิตเติ้ลชอบมองว่าไมโครเซอร์วิสเป็นข้อดี สถาปัตยกรรมที่มุ่งเน้นการบริการ ซึ่งได้รับแรงหนุนจากการมาถึงของเทคโนโลยีด้านวิศวกรรมและการดำเนินงานที่ซับซ้อนมากขึ้น และเทคนิค

"ความแตกต่างก็คือสิ่งนี้ได้รับแรงผลักดันอย่างมากจากแนวทางใหม่ในการพัฒนาซอฟต์แวร์และซอฟต์แวร์แบบกระจาย สิ่งต่าง ๆ เช่นคอนเทนเนอร์ Linux - Docker เป็นตัวอย่างที่สำคัญ ตอนนี้คุณได้รับบริการที่ไม่เปลี่ยนรูปแล้ว คุณมีหลายอย่างเช่น Kubernetes สำหรับการประสานงานบริการเหล่านั้น และแน่นอนว่าคุณมี DevOps ซึ่งได้รับอิทธิพลอย่างมากจาก Agile” Little กล่าว

“สิ่งเหล่านี้ทำให้ผู้คนมองย้อนกลับไปถึงวิธีการที่เราเคยทำระบบแบบกระจายในอดีต - และสถาปัตยกรรมเชิงบริการเป็นตัวอย่าง - และเลือกบิตที่ดีที่สุดที่ตรงกับสิ่งเหล่านั้น เทคโนโลยี หรือในทางกลับกัน การค้นหาเทคโนโลยีเหล่านั้นที่ตรงกับสถาปัตยกรรมเชิงบริการที่ดีบางส่วน นั่นอาจเป็นความแตกต่าง แนวทางสถาปัตยกรรมไม่ได้แตกต่างกัน แต่เทคโนโลยีที่อยู่เบื้องหลังนั้นแตกต่างจริงๆ"

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

ท่ามกลางข้อบกพร่องทางประวัติศาสตร์ของสถาปัตยกรรมเชิงบริการ Little อ้างถึงความล้มเหลวในการให้คำจำกัดความสัญญาที่ดีระหว่าง ลูกค้าและบริการ และข้อบกพร่องของ WSDL - หรือภาษาคำอธิบายบริการเว็บ - ซึ่งไม่ดีสำหรับการเชื่อมต่อและการกระจายแบบหลวมๆ ระบบ

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

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

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

หากคุณกำลังพิจารณาไมโครเซอร์วิส จุดเริ่มต้นที่ดีที่สุดคือแนวปฏิบัติด้านวิศวกรรมซอฟต์แวร์ที่ดี

"โดยพื้นฐานแล้ว นั่นคือสิ่งที่อยู่เบื้องหลังสถาปัตยกรรมเชิงบริการอยู่แล้ว และถ้าคุณไม่เริ่มต้นตรงนั้น ไม่สำคัญว่าคุณจะใช้ Docker หรือ virtualization หรือ Java virtual machine หรืออะไรก็ตาม เครื่องมือที่เหมาะสมจะไม่ช่วยแก้ปัญหาสถาปัตยกรรมของคุณ" เล็กๆ น้อยๆ พูดว่า.

ที่ซึ่งไมโครเซอร์วิส - หรือแม้แต่สถาปัตยกรรมเชิงบริการ - เข้ามาอยู่ในตัวมันเองจริงๆ ก็คือบริการลอจิกที่ควรจะเป็น สามารถปรับใช้แยกจากกันได้ โดยปรับขนาดได้อย่างอิสระจากบริการอื่นๆ และมีความสามารถในการเฟลโอเวอร์โดยอิสระ

“สิ่งหนึ่งที่ทำให้ฉันกังวลเกี่ยวกับไมโครเซอร์วิสก็คือคุณมีหินใหญ่ก้อนเดียวและสมมติว่าคุณเริ่มแยกย่อยมันเป็นบริการ และคุณทำแบบนั้นโดยพลการ คุณอาจจบลงที่การสลายตัวมากเกินไป และจบลงด้วยไมโครเซอร์วิส 10 หรือ 100 หรือ 1,000 รายการ" พูดว่า.

“แต่พวกมันทั้งหมดต้องพึ่งพาอาศัยกันมาก ถึงขนาดที่ถ้าตัวใดตัวหนึ่งล้มลง ตัวที่เหลือก็อาจจะลงเช่นกัน” ซึ่งในกรณีนี้คุณไม่ได้ซื้ออะไรเลยให้ตัวเองเลย คุณมีบริการ 999 รายการรอให้บริการอีกรายการหนึ่งกลับมา"

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

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

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

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

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

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

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

“ถ้าคุณมีบางอย่างที่ใช้งานไม่ได้ คุณยังควรดูว่ามีบางอย่างที่คุณสามารถแกะออกและเก็บไว้ได้หรือไม่ โดยเฉพาะอย่างยิ่งถ้า คุณใช้งานมันมา 20 หรือ 30 ปีแล้ว และมีผู้คนจำนวนมากใช้มัน และโดยเฉพาะอย่างยิ่งถ้ามันถูกนำไปใช้ในภาษาโคบอล แสดงว่ามันถูกทดสอบแล้ว" ลิตเติ้ล พูดว่า.

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

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

“สัญญาดังกล่าวจะรวมอินเทอร์เฟซไว้ด้วย: ฉันจะเรียกใช้จากระยะไกลได้อย่างไร ฉันจะเรียกใช้จากระยะไกลด้วยอะไร? ผู้คนจำนวนมากพูดถึงไมโครเซอร์วิสและ REST [Representational State Transfer] และแน่นอนว่า REST เป็นแนวทางพื้นฐานสำหรับไมโครเซอร์วิส แต่นั่นไม่ใช่วิธีเดียวที่คุณอาจต้องการพูดคุยกับบริการของคุณ” ลิตเติ้ลกล่าว

“คุณอาจต้องการพูดคุยกับมันโดยใช้โปรโตคอลไบนารี่ คุณอาจไม่มีทางเลือกอื่นนอกจากต้องพูดคุยโดยใช้โปรโตคอลแบบเดิม ด้วย COBOL แม้ว่าคุณจะเปลี่ยนไปใช้ไมโครเซอร์วิส แต่คุณยังคงมีสถาปัตยกรรมจำนวนมากที่ยังคงเชื่อมโยงกับ CORBA [Common Object Request Broker Architecture] อาจไม่ใช่วิธีพิเศษในการพูดคุยกับไมโครเซอร์วิสของคุณ แต่คุณอาจต้องมีอะแดปเตอร์ CORBA อยู่ในนั้นที่ไหนสักแห่ง"

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

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

“เพราะฉันอาจต้องการไมโครเซอร์วิสจริงๆ แต่น่าเสียดายจนกว่าพวกเขาจะสร้างเครือข่ายที่ใช้ tachyons เพื่อส่งข้อความไปรอบ ๆ ฉันไม่สามารถเรียกอะไรได้จริง ๆ เพราะฉันไม่สามารถปฏิบัติตามสัญญาของฉันได้ ภาระผูกพัน ฉันต้องมีทุกอย่างอยู่ในกองโคลนลูกใหญ่”

ข้อมูลเพิ่มเติมเกี่ยวกับไมโครเซอร์วิส

• Mashape บริษัท Kong เปิดตัวการวิเคราะห์แบบเรียลไทม์สำหรับ API และไมโครเซอร์วิส
• รองรับ Linux, Java และคอนเทนเนอร์สำหรับแพลตฟอร์มไมโครเซอร์วิส Azure ของ Microsoft
• Kong ก้าวสู่โอเพ่นซอร์ส: Mashape ขนานนามว่าเป็นเลเยอร์การจัดการไมโครเซอร์วิสชั้นแรก
• Microsoft เตรียมแสดงตัวอย่างแรกของนักพัฒนาสำหรับ microservices Service Fabric ใหม่
• Microsoft เตรียมเปิดตัว 'PowerApps' มือถือระบบคลาวด์รุ่นใหม่
• กองกำลังสามประการกำลังขับเคลื่อนสถาปัตยกรรมไมโครเซอร์วิส
• บริการกลายเป็นเสาหินใหม่หรือไม่? กรณีสำหรับไมโครเซอร์วิส
• ไมโครเซอร์วิสมีจริงหรือเป็นเพียงคำศัพท์ล่าสุด?
• วิสัยทัศน์ไมโครเซอร์วิสของ Microsoft สำหรับ Azure เริ่มเป็นรูปเป็นร่าง
• ผ่านไมโครเซอร์วิส การผลักดันใหม่เพื่อความเรียบง่ายและความเรียบง่ายด้านไอที
• ไมโครเซอร์วิสเสนอให้เป็นวิธีที่ดีกว่าในการรันระบบคลาวด์