Microservices: หินใหญ่ก้อนแรก?

ฉันค้นคว้าสถาปัตยกรรมไมโครเซอร์วิสที่พยายามรับภาพรวมในระดับสูงถึงข้อดีและข้อเสียทั้งหมดและข้อมูล ฯลฯ ข้อมูลมากมายที่ฉันอ่าน / ดูมาจาก ThoughtWorks (Martin Fowler, Neal Ford, et อัล)

งานส่วนใหญ่ของมาร์ตินฟาวเลอร์ในเรื่องนี้มีอายุเพียงไม่กี่ปีเมื่อ Microservices (เป็นชื่อครัวเรือนในการเขียนโปรแกรมหากไม่ใช่ในทางปฏิบัติทั่วไป) ยังเด็กอยู่ดังนั้นฉันจึงใช้เกลือเม็ดเล็ก ๆ

สิ่งหนึ่งที่พิเศษคือ:

เมื่อฉันได้ยินเรื่องราวเกี่ยวกับทีมที่ใช้สถาปัตยกรรมไมโครไซต์ฉันสังเกตเห็นรูปแบบทั่วไป

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

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

(อ้างอิง: https://martinfowler.com/bliki/MonolithFirst.html - เน้นพวกเขา)

ตอนนี้ 3 ปีต่อมาและด้วย microservices คำที่แพร่หลายมากขึ้นมันเป็นที่ยอมรับกันโดยทั่วไปว่าระบบใหม่มักจะให้บริการที่ดีขึ้นโดยมีบริการที่ใหญ่กว่า (-than-microservice มันละเอียดยิ่งขึ้นซึ่งเป็นส่วนหนึ่งของมาตรการวิวัฒนาการใช่หรือไม่

หรือมีบรรทัดฐานในการเริ่มต้นโครงการตั้งแต่เริ่มต้นด้วยสถาปัตยกรรมไมโครบริการแบบตรงข้ามกับข้อความข้างต้นหรือไม่?

ดูเหมือนว่าวิธีการทั่วไปมีเหตุผล แต่อยากรู้อยากเห็นความคิดของชุมชน

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

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

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

โดยทั่วไป:

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

บ่อยครั้งที่เราได้ยินคำแนะนำที่เป็นประโยชน์จากคนฉลาดที่มีชื่อเสียงที่ดีเช่น Martin Fowler แล้วเปลี่ยนเป็นหลักคำสอนที่ยากที่ไม่สามารถถูกครอบงำได้

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

ประโยชน์ที่มีค่าที่สุดของ microservices ในทันทีสามารถทำได้โดยการทำให้เป็นโมดูลแบบง่าย ๆ คุณสามารถแยกกลุ่มคุณสมบัติออกเป็นโมดูลโดยใช้ระบบโมดูลอะไรก็ได้ที่คุณมี (maven, npm, nuget หรืออะไรก็ตาม) แต่ละโมดูลสามารถตอบสนองวัตถุประสงค์เดียวนั่งเป็น repo ของตัวเองใช้ schema DB ของตัวเองจัดการการกำหนดค่าของตัวเองมี backlog ของคุณสมบัติและกำหนดการปล่อย พวกเขายังสามารถใช้งานร่วมกันบนหินใหญ่ก้อนเดียว นี่เป็นค่าใช้จ่ายที่สามารถจัดการได้มากและให้ประโยชน์ที่ดี ค่าใช้จ่ายที่ใหญ่กว่านั้นมาจากการแยกการปรับใช้ซึ่งมีคุณค่าจริง ๆ เมื่อคุณมีขนาดเพียงพอที่จะทำให้จำเป็น หากรหัสของคุณเป็นแบบโมดูลาร์แล้วมันจะเป็นการย้ายข้อมูลที่ง่ายขึ้นเมื่อถึงเวลา

ในความคิดของฉันมันจะเป็นประโยชน์ในการพัฒนาเสาหินก้อนแรก (หรือดีกว่า: เพื่อพัฒนาส่วนของใบสมัครของคุณเป็นเสาหิน)

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

คุณควรหยุดทำสิ่งนี้หากคุณต้องการนำเทคโนโลยีที่แตกต่างเข้ามาในส่วนผสม (เช่นชิ้นส่วนที่มีอยู่ของคุณเขียนด้วยภาษา C # แต่ปัญหาใหม่ของปีก่อนจำเป็นต้องเรียนรู้ด้วยเครื่อง โครงการหรือเสาหินขนาดใหญ่ของคุณจะทำการชุบเคลือบผิวเช่นทุกคนเพียงแค่สร้างเสาหินนี้และทำลายแนวคิดของบริการแยกต่างหาก

ฉันค่อนข้างมั่นใจว่ามีคำถามสองสามข้อเกี่ยวกับบทความที่แน่นอนนี้จาก MF

สิ่งที่ฉันทำคือ:

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

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

ในทางกลับกันโครงการใหม่ใด ๆ ก็ตามที่ไม่คำนึงถึงสถาปัตยกรรมที่เลือกนั้นจะเสี่ยงต่อการไม่บรรลุความคาดหวังดังนั้นโดยปกติคุณจะคาดหวังว่าอัตราความสำเร็จจะลดลง นอกจากนี้หากคุณเริ่มต้นจากการตั้งเป้าหมายที่จะทำให้ 'Best Practice Microservice Architecture' ทั้งหมดขึ้นมาจากพื้นดินคุณก็อาจจะลงทุนในเทคโนโลยีใหม่ ๆ

นอกจากนี้เราต้องจำไว้ว่า MF เขียนจากมุมมอง OOP ที่ยิ่งใหญ่ เขาเป็นคนไม่เชื่อในแนวทางการกระจายที่ทันสมัยกว่า

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

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

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