Microservices at a Glance (Microservices โดยสังเขป)

Microservices คือ service ที่ release ได้อย่างอิสระและถูกออกแบบโมเดลขึ้นตาม business domain service แต่ละตัวห่อหุ้มฟังก์ชันการ ทำงานและทำให้ service อื่นเข้าถึงได้ผ่านเครือข่าย—คุณสร้างระบบที่ซับซ้อนมากขึ้นจากบล็อกการสร้างเหล่านี้ microservice หนึ่งอาจแทน inventory อีกตัวแทน order management และอีกตัวแทน shipping แต่รวมกันแล้วอาจ ประกอบเป็นระบบอีคอมเมิร์ซทั้งระบบ Microservices เป็นตัวเลือกสถาปัตยกรรมที่มุ่งมอบตัวเลือกมากมายให้คุณในการ แก้ปัญหาที่คุณอาจเผชิญ

พวกมันเป็น ชนิดหนึ่ง ของ service-oriented architecture แม้จะเป็นชนิดที่มีความเห็นชัดเจนว่าควรวาดขอบเขตของ service อย่างไร และเป็น ชนิดที่ independent deployability เป็นหัวใจสำคัญ พวกมันไม่ยึดติดกับเทคโนโลยี ซึ่งเป็นข้อได้เปรียบอย่างหนึ่งที่ มันมอบให้

จากภายนอก microservice หนึ่งตัวถูกมองเป็น black box มันโฮสต์ฟังก์ชันการทำงานทางธุรกิจไว้บน network endpoint หนึ่งตัวหรือมากกว่า (เช่น queue หรือ REST API ดังแสดงใน Figure 1-1 ) ผ่าน protocol ใดก็ตามที่เหมาะสมที่สุด ผู้บริโภค ไม่ว่าจะเป็น microservice อื่นหรือโปรแกรมประเภทอื่น เข้าถึง ฟังก์ชันการทำงานนี้ผ่าน networked endpoint เหล่านี้ รายละเอียดการ implement ภายใน (เช่น เทคโนโลยีที่ service ถูกเขียนขึ้นมา หรือวิธีที่ข้อมูลถูกจัดเก็บ) ถูกซ่อนไว้จากโลกภายนอกทั้งหมด นั่นหมายความว่าสถาปัตยกรรม microservice หลีกเลี่ยงการใช้ shared database ในสถานการณ์ส่วนใหญ่ แต่ละ microservice จะห่อหุ้มฐานข้อมูลของ ตัวเองไว้เมื่อจำเป็น

Figure 1-1. A microservice exposing its functionality over a REST API and a topic (microservice ที่เปิดเผยฟังก์ชันการทำงานผ่าน REST API และ topic)

Microservices ยึดถือแนวคิดของ information hiding 1 Information hiding หมายถึงการซ่อนข้อมูลให้ได้มากที่สุดเท่าที่จะทำได้ไว้ภายในคอมโพเนนต์ และเปิดเผยให้น้อยที่สุดผ่าน external interface สิ่งนี้ทำให้เกิดการแยกที่ชัดเจนระหว่างสิ่งที่เปลี่ยนแปลงได้ง่ายกับสิ่งที่เปลี่ยนแปลงได้ยากกว่า implementation ที่ถูกซ่อนจากภายนอกสามารถเปลี่ยนแปลงได้อย่างอิสระ ตราบใดที่ networked interface ที่ microservice เปิดเผยไม่เปลี่ยนแปลงในแบบที่ทำลาย backward compatibility การเปลี่ยนแปลงภายในขอบเขตของ microservice (ดังแสดงใน Figure 1-1 ) ไม่ควรส่งผลกระทบต่อ upstream consumer ทำให้สามารถ release ฟังก์ชันการทำงานได้อย่างอิสระ นี่คือสิ่งจำเป็นในการ ทำให้ microservice ของเราถูกพัฒนาแยกส่วนและ release ได้ตามต้องการ การมีขอบเขต service ที่ชัดเจนและมั่นคงซึ่งไม่ เปลี่ยนแปลงเมื่อ implementation ภายในเปลี่ยนไป ส่งผลให้ระบบมี coupling ที่หลวมกว่าและมี cohesion ที่แข็งแกร่งกว่า

เมื่อพูดถึงการซ่อนรายละเอียด implementation ภายใน ผมคงพลาดไม่กล่าวถึงแพทเทิร์น Hexagonal Architecture ที่ Alistair Cockburn อธิบายไว้เป็นคนแรก 2 แพทเทิร์นนี้อธิบายความสำคัญของการรักษา implementation ภายในให้แยกจาก external interface โดยมีแนวคิดว่าคุณอาจ ต้องการโต้ตอบกับฟังก์ชันการทำงานเดียวกันผ่าน interface หลายประเภท ผมวาด microservice ของผมเป็นรูปหกเหลี่ยม ส่วนหนึ่งเพื่อแยกความแตกต่างจาก service "ปกติ" แต่ก็เพื่อเป็นการยกย่องผลงานชิ้นนี้ด้วย

Are Service-Oriented Architecture and Microservices Different Things? (Service-Oriented Architecture กับ Microservices ต่างกันหรือไม่)

Service-oriented architecture (SOA) คือแนวทางการออกแบบที่ service หลายตัวร่วมมือกันเพื่อมอบชุดความสามารถสุดท้ายชุดหนึ่ง ( service ที่นี่มักหมายถึง operating system process ที่แยกออกจากกันอย่างสมบูรณ์) การสื่อสารระหว่าง service เหล่านี้ เกิดขึ้นผ่านการเรียกข้ามเครือข่าย แทนที่จะเป็นการเรียก method ภายในขอบเขตของ process เดียว

SOA เกิดขึ้นมาเป็นแนวทางเพื่อรับมือกับความท้าทายของแอปพลิเคชัน monolithic ขนาดใหญ่ แนวทางนี้มุ่งส่งเสริม การนำซอฟต์แวร์กลับมาใช้ซ้ำ ตัวอย่างเช่น แอปพลิเคชันสำหรับผู้ใช้ปลายทางสองตัวหรือมากกว่าอาจใช้ service เดียวกันได้ SOA มุ่งทำให้การดูแลรักษาหรือเขียนซอฟต์แวร์ใหม่ง่ายขึ้น เพราะในทางทฤษฎีเราสามารถแทนที่ service หนึ่งด้วยอีกตัวหนึ่งได้โดยไม่มีใครรู้ ตราบใดที่ semantic ของ service ไม่เปลี่ยนแปลงมากเกินไป

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

ปัญหาหลายอย่างที่ถูกโยนความผิดให้ SOA แท้จริงแล้วเป็นปัญหาของสิ่งต่างๆ เช่น communication protocol (เช่น SOAP) vendor middleware การขาดคำแนะนำเรื่อง granularity ของ service หรือคำแนะนำที่ผิดเกี่ยวกับ จุดที่ควรแยกระบบของคุณ คนที่มองโลกในแง่ร้ายอาจบอกว่า vendor ฉวยโอกาส (และในบางกรณีก็ผลักดัน) กระแส SOA เพื่อขายสินค้ามากขึ้น และผลิตภัณฑ์เหล่านั้นเองในท้ายที่สุดก็บั่นทอนเป้าหมายของ SOA

ผมเคยเห็นตัวอย่าง SOA มากมายที่ทีมพยายามทำให้ service เล็กลง แต่ก็ยังคง coupled กับฐานข้อมูลทั้งหมด และ ต้อง deploy ทุกอย่างพร้อมกัน Service oriented ใช่ไหม? ใช่ แต่นั่นไม่ใช่ microservices

แนวทาง microservice เกิดขึ้นจากการใช้งานจริงในโลกจริง โดยนำความเข้าใจที่ดีขึ้นของเราเกี่ยวกับระบบและ สถาปัตยกรรมมาทำ SOA ให้ดี คุณควรมองว่า microservices เป็นแนวทางเฉพาะสำหรับ SOA ในแบบเดียวกับที่ Extreme Programming (XP) หรือ Scrum เป็นแนวทางเฉพาะสำหรับการพัฒนาซอฟต์แวร์แบบ Agile