Microservices: สถาปัตยกรรมซอฟต์แวร์สมัยใหม่
ต่อด้วย รูปแบบของวิวัฒนาการและการเปลี่ยนแปลงกระบวนทัศน์และวิธีการทำงาน เกิดขึ้นในด้านการพัฒนาซอฟต์แวร์ซึ่งเราเพิ่งได้สัมผัสในบทความที่ชื่อว่า "การพัฒนาซอฟต์แวร์: การทบทวนประวัติศาสตร์จนถึงปัจจุบัน", "การทำงานร่วมกันผ่านระบบคลาวด์: จะบรรลุได้อย่างไร" y "XaaS: Cloud Computing - ทุกอย่างเป็นบริการ"วันนี้เราจะมาพูดถึง ไมโครเซอร์วิส.
Microservices เป็นสถาปัตยกรรมซอฟต์แวร์ที่ทันสมัยไม่ใช่ API (Application Programming Interface) หรือเทคโนโลยีซึ่งสามารถติดตั้งและใช้งานได้ สถาปัตยกรรมซอฟต์แวร์หรือที่เรียกว่ารูปแบบซอฟต์แวร์นั้นต่างจากภาษาการเขียนโปรแกรมโดยสิ้นเชิงเนื่องจากเป็นเพียงการกำหนดวิธีการที่เทคโนโลยีควรใช้งานได้ไม่ใช่วิธีการนำไปใช้
การแนะนำ
Microservices ถือได้ว่าเป็นวิวัฒนาการของ SOA Architecture (Service-Oriented Architecture)ซึ่งแนะนำให้นักพัฒนาสร้างแอปพลิเคชันแบบแยกส่วนมากขึ้นซึ่งใช้งานได้และเป็นอิสระโดยมีความจุสูงที่จะนำกลับมาใช้ใหม่ได้อย่างมีประสิทธิภาพเช่นเดียวกับที่ทำในลักษณะเดียวกันเมื่อเราปรับการใช้ฮาร์ดแวร์บางตัวให้เหมาะสมซึ่งจะขยายออกเท่านั้น สิ่งที่จำเป็นจริงๆแทนที่จะเปิดเผยศักยภาพทั้งหมดโดยไม่จำเป็น
สถาปัตยกรรมของไมโครเซอร์วิสในทางปฏิบัติยังไม่แพร่หลายเท่าในทางทฤษฎีกล่าวคือ เป็นที่รู้จักกันดีกว่าใช้. อย่างไรก็ตามทุกๆวันมีนักพัฒนาจำนวนมากนำมาใช้เนื่องจากเป็นรูปแบบการพัฒนาซอฟต์แวร์ที่ ปรับปรุงเวลาตัวแปรประสิทธิภาพและความเสถียรภายในโครงการที่นำไปใช้ นอกจากนี้ของเขา ความสามารถในการปรับขนาดที่เกี่ยวข้องอย่างง่าย ทำให้เหมาะอย่างยิ่งในการพัฒนาที่ความเข้ากันได้ข้ามแพลตฟอร์ม (เว็บ, มือถือ, อุปกรณ์สวมใส่, IoT) เป็นสิ่งสำคัญ
แต่ ในขณะที่ SOA เป็นสถาปัตยกรรมระดับสูงกว่านั่นคือสถาปัตยกรรมที่สร้างแอปพลิเคชันตามบริการโดยที่บริการเป็นหน่วยงานที่เล็กที่สุดและทำงานได้ดีที่สุดภายในแอปพลิเคชันที่สร้างขึ้น สถาปัตยกรรมไมโครเซอร์วิส ด้วย ช่วยให้เราสร้างบริการแต่บริการเหล่านี้ได้รับการออกแบบ ด้วยวิธีที่เล็กมากและเฉพาะเจาะจง เพื่อให้พวกเขาตอบสนองการทำงานที่แม่นยำและตรงต่อเวลาในลักษณะที่สามารถแยกออกจากส่วนที่เหลือของแอปพลิเคชันและฟังก์ชันได้อย่างอิสระทั้งหมดจากแอปพลิเคชันที่เหลือที่สร้างขึ้น
สถาปัตยกรรมซอฟต์แวร์ (รูปแบบ) คืออะไร?
เพื่อให้เข้าใจสถาปัตยกรรมซอฟต์แวร์ของ Microservices เป็นอย่างดีควรทราบข้อมูลเล็กน้อยเกี่ยวกับสถาปัตยกรรมซอฟต์แวร์ที่มีอยู่ซึ่งเป็นที่รู้จักกันดีทั้งหมด มีอยู่มากมายดังที่เห็นได้จากเว็บไซต์ของ oodesign หรือเพียงแค่ใน วิกิพีเดียแต่ตามหนังสือชื่อดังชื่อ "หนังสือออกแบบลวดลาย" (รูปแบบการออกแบบหนังสือ) รูปแบบที่มีอยู่สามารถแบ่งได้เป็น:
สร้างสรรค์
ผู้ที่จัดการกับวิธีการสร้างอินสแตนซ์อ็อบเจ็กต์และเป้าหมายคือการทำให้กระบวนการสร้างอินสแตนซ์เป็นนามธรรมและซ่อนรายละเอียดเกี่ยวกับวิธีสร้างหรือเริ่มต้นอ็อบเจ็กต์ ในคลาสนี้มีดังต่อไปนี้:
- โรงงานนามธรรม
- ผู้ก่อสร้าง
- วิธีการโรงงาน
- ต้นแบบ
- ซิงเกิล
โครงสร้าง
สิ่งที่อธิบายว่าคลาสและอ็อบเจ็กต์ (แบบง่ายหรือแบบผสม) สามารถรวมเข้าด้วยกันเพื่อสร้างโครงสร้างขนาดใหญ่และให้ฟังก์ชันใหม่ได้อย่างไร ในคลาสนี้มีดังต่อไปนี้:
- อะแดปเตอร์
- สะพาน
- ประกอบด้วย
- มัณฑนากร
- หน้าตึก
- ฟลายเวท
- หนังสือมอบฉันทะ
พฤติกรรม
สิ่งที่ช่วยให้เรากำหนดการสื่อสารและการวนซ้ำระหว่างออบเจ็กต์ของระบบ จุดประสงค์ของรูปแบบนี้คือเพื่อลดการมีเพศสัมพันธ์ระหว่างวัตถุ ในคลาสนี้มีดังต่อไปนี้:
- ห่วงโซ่แห่งความรับผิดชอบ
- คำสั่ง
- ล่าม
- ตัววนซ้ำ
- สื่อกลาง
- ของที่ระลึก
- นักสังเกตการณ์
- สถานะ
- กลยุทธ์
- วิธีเทมเพลต
- ผู้มาเยือน
คนอื่น ๆ
รูปแบบการออกแบบก่อนหน้านี้แสดงสคีมาที่กำหนดโครงสร้างการออกแบบที่จะสร้างระบบซอฟต์แวร์ แต่เมื่อเราต้องการแสดงโครงร่างพื้นฐานขององค์กรและโครงสร้างสำหรับระบบซอฟต์แวร์ที่สร้างขึ้นเรามักจะพบการจำแนกประเภทอื่น ๆ นี้:
- สถาปัตยกรรมกระดานชนวน
- DAO: วัตถุการเข้าถึงข้อมูล
- DTO: วัตถุการถ่ายโอนข้อมูล
- EDA: สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์
- การวิงวอนโดยปริยาย
- วัตถุเปล่า
- การเขียนโปรแกรมแบบเลเยอร์
- Peer-to-peer
- ท่อ
- SOA: สถาปัตยกรรมเชิงบริการ
- สามระดับ
นอกจากนี้ยังมี "โมเดลมุมมองคอนโทรลเลอร์" ซึ่งเป็นที่รู้จักและใช้กันดีและแบ่งออกเป็น:
- รุ่น / ดู / คอนโทรลเลอร์
- นางแบบ / ดู / ผู้นำเสนอ
- Model / View / Presenter กับ Model Presenter
- รุ่น / View / View-Model
- Model / View / Presenter with Passive View
- Model / View / Presenter พร้อม Supervisor Controller
กำลัง "Controller View Model" ซึ่งเป็นที่รู้จักและนำไปใช้งานได้ดีที่สุดในปัจจุบันไม่เพียงพอที่จะมอบฟังก์ชันที่จำเป็นให้กับแอปพลิเคชันขององค์กรและนี่คือหนึ่งในเหตุผลหลักว่าทำไม Microservices Architecture กำลังแทนที่ Model-View-Controller (MVC)
ข้อดีของสถาปัตยกรรมไมโครเซอร์วิส
เมื่อแพลตฟอร์มเว็บใช้ประโยชน์จากสถาปัตยกรรมไมโครเซอร์วิสโดยทั่วไปจะมีข้อดีดังต่อไปนี้:
- แก้ แต่ละปัญหาหรือปัญหาที่นำเสนอได้อย่างง่ายดายโดยการจัดการกับ Microservice ขนาดเล็กแต่ละรายการที่เกี่ยวข้องกับสถานการณ์เฉพาะ
- เพื่อบรรเทา ความล้มเหลวทั่วไปหรือทั่วโลกของบริการเนื่องจากเมื่อ Microservice ล้มเหลวจะไม่ส่งผลกระทบต่อผู้อื่นเนื่องจากเป็นอิสระโดยสิ้นเชิง
- เพื่อความสะดวก การเปิดตัวและการรวมฟังก์ชันหรือบริการที่สมบูรณ์หรือเฉพาะเนื่องจาก Microservice แต่ละตัวสามารถเพิ่มหรือลบและอัปเดตแยกกันและก้าวหน้า
- ให้ดีขึ้น เข้าถึงแอพพลิเคชั่นหรือบริการที่สร้างจากอุปกรณ์และแพลตฟอร์มทุกประเภท
- เพิ่ม ความเก่งกาจของแพลตฟอร์มเนื่องจาก Microservices สามารถกระจายในเซิร์ฟเวอร์ที่แตกต่างกันและเขียนในภาษาที่แตกต่างกัน
กรอบงานโอเพนซอร์ส
มีมากมาย ตัวเลือกโอเพ่นซอร์ส ที่นักพัฒนาซอฟต์แวร์สามารถใช้เพื่อพัฒนาโซลูชันที่เป็นส่วนหนึ่งของ Microservices Architectures โดยเฉพาะสำหรับ Java ซึ่งเป็นเทคโนโลยีที่ใช้กันอย่างแพร่หลายมีดังต่อไปนี้:
- จิ้งหรีด
- ตัวช่วยสร้าง
- คราสไมโครโปรไฟล์
- เฮลิดอน
- นิวเจอร์ซีย์
- ปายาราไมโคร
- เล่น
- ที่พักพิง
- จุดประกาย
- สปริงบูต
- สควอช
- กรีดกราย
- ทางไกล
- หางหนาม WildFly
- zipkin
ตัวอย่างเว็บที่มีสถาปัตยกรรมไมโครเซอร์วิส
ในบรรดาเว็บไซต์จำนวนมากที่ให้บริการแอพพลิเคชั่นขนาดใหญ่และได้นำ Microservices Architecture ไปใช้อย่างต่อเนื่องเพื่อปรับปรุงการบำรุงรักษาและความสามารถในการปรับขนาดของแพลตฟอร์มบริการและผลิตภัณฑ์ของพวกเขาทำให้ง่ายมีประสิทธิภาพและรวดเร็วเราสามารถพูดถึงสามหลักในอุตสาหกรรม พวกเขาคืออะไร:
- อเมซอน
- อีเบย์
- Netflix
ข้อสรุป
เป็นที่ชัดเจนว่า Microservices มีส่วนช่วยอย่างมากในการพัฒนาซอฟต์แวร์บนเว็บสมัยใหม่แต่ยังหมายถึงการจัดการกับความท้าทายใหม่ ๆ อีกมากมายเพื่อแก้ไข ปัญหาที่ไม่เพียงเกี่ยวข้องกับการเรียนรู้ Framework และการทำงานอย่างมีประสิทธิภาพ แต่ยังรวมถึงการพัฒนาใหม่เหล่านี้เสริมและนำไปใช้ในแผนกไอทีซึ่งท้ายที่สุดคือคนที่ทำให้พวกเขาออนไลน์และจัดการพวกเขาและได้รับการโหวต น้ำหนักในการตัดสินใจขั้นสุดท้ายเกี่ยวกับการพัฒนาแต่ละครั้ง แต่ สถาปัตยกรรมนี้อยู่ที่นี่และมีมาอย่างยาวนาน