การเปลี่ยนเป็นไมโครไซต์ช่วยสร้างปัญหารันไทม์อย่างไร

104

Microservices เปลี่ยนความผิดปกติขององค์กรของคุณจากปัญหาเวลารวบรวมเป็นปัญหาเวลาทำงาน

คุณสมบัติไม่ได้เป็นข้อบกพร่อง ปัญหารันไทม์ => prod problems => แข็งแกร่งและรวดเร็วยิ่งขึ้นเกี่ยวกับความผิดปกติของผู้ที่รับผิดชอบ

ตอนนี้ฉันเข้าใจแล้วด้วยmicroservices you:

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

คำถามของฉันคืออะไรการเปลี่ยนเป็นไมโครไซต์ทำให้เกิดปัญหาในเวลาทำงาน

microservices runtime compile-time

— ฮ็อค
แหล่งที่มา

13

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

— Richard Tingle

หากคุณกำลังศึกษาปัญหาเกี่ยวกับการใช้ microservices บทความ Fowler เป็นสิ่งที่ต้องอ่าน martinfowler.com/articles/microservices.html ฉันเชื่อว่าไม่เพียง แต่เป็นกรณีของการรวบรวมเวลาและรันไทม์เป็น @Richard Tingle กล่าว และไม่เห็นด้วยอย่างแท้จริงว่าการมีปัญหาด้านการผลิตนั้นดีกว่าเรื่องหนึ่งในการพัฒนา แต่บริการขนาดเล็กอาจช่วยขยายโครงการขนาดใหญ่ด้วยวิธีอื่น (และเป็น overkill สำหรับโครงการขนาดเล็กที่สุด)

— Borjab

2

ผู้วิจารณ์คนนั้นสายตาสั้น ปัญหารันไทม์ => prod problems => ผู้ใช้ที่ไม่มีความสุข => สูญเสียเงิน

— Philipp

@ ฟิลิป: นั่นคือจุด รวบรวมปัญหาเวลาที่เกิดจากความผิดปกติขององค์กร => ไม่มีใครใส่ใจ สูญเสียเงินที่เกิดจากความผิดปกติขององค์กร => เจ็บอย่างแน่นอนว่าผู้ที่รับผิดชอบในความผิดปกติขององค์กรดังกล่าว ความหวัง: ความผิดปกติขององค์กรได้รับการแก้ไขเร็วขึ้น

— Jörg W Mittag

194

ฉันมีปัญหา. มาใช้ Microservices กันเถอะ! ตอนนี้ฉันมีปัญหากระจาย 13 ครั้ง

การแบ่งระบบของคุณออกเป็นองค์ประกอบที่หุ้มห่อหุ้มแน่นและแยกส่วนเป็นความคิดที่ดี ช่วยให้คุณจัดการปัญหาต่าง ๆ แยกกัน แต่คุณสามารถทำได้อย่างสมบูรณ์แบบในการปรับใช้แบบเสาหิน (ดูFowler: Microservice Premium ) ท้ายที่สุดนี่คือสิ่งที่ OOP ได้สอนมานานหลายสิบปี! หากคุณตัดสินใจที่จะเปลี่ยนส่วนประกอบของคุณให้เป็นไมโครไซต์คุณจะไม่ได้รับผลประโยชน์ทางสถาปัตยกรรมใด ๆ คุณได้รับความยืดหยุ่นเกี่ยวกับการเลือกเทคโนโลยีและอาจเป็นไปได้ (แต่ไม่จำเป็น!!) แต่คุณรับประกันได้ว่าจะมีอาการปวดหัวอันเนื่องมาจาก (a) ลักษณะการกระจายของระบบและ (b) การสื่อสารระหว่างส่วนประกอบ การเลือก microservices หมายความว่าคุณมีปัญหาอื่น ๆ ที่กดดันให้คุณยินดีที่จะใช้ microservices แม้จะมีปัญหาเหล่านี้

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

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

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

— อมร
แหล่งที่มา

13

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

— amon

10

"เสาหินที่แบ่งออกเป็นส่วน ๆ ได้อย่างหมดจด" - นั่นมันหมายถึงอะไร?

10

และไม่พูดถึงการกำหนดรุ่นของอินเทอร์เฟซ (อินเทอร์เฟซที่เปลี่ยนแปลงตลอดเวลา)

— ปีเตอร์มอร์เทนเซ่น

12

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

— อมร

7

@ มอนได้ยินคำว่าโมโนลิ ธ ไม่คิดในใจทันทีว่า "ไม่มีสถาปัตยกรรม" อาคารส่วนใหญ่เป็นเสาหินเช่นเดียวกับมหาปิรามิดแห่งอียิปต์และสิ่งอื่น ๆ อีกมากมาย เห็นได้ชัดว่าพวกเขาถูกออกแบบและส่งมอบโดยรวม ระบบซอฟต์แวร์จำนวนมากขาดสถาปัตยกรรมที่ดี แต่ดูเหมือนว่าการขาดสถาปัตยกรรมที่ดีจะไม่ขึ้นอยู่กับการปรับใช้ คุณสามารถยืมโครงยกพื้นของโครงการอื่นและเรียกมันว่าสถาปัตยกรรม (3 ชั้น, 2 ชั้น, n-tier, microservice ฯลฯ ) แต่การทำเช่นนั้นไม่ได้รับประกันว่าคุณจะทำได้ดี

— Edwin Buck

215

ทวีตแรกเป็นของฉันดังนั้นฉันจะขยาย:

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

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

น่าเสียดายที่มันกลายเป็น "ปัญหาเวลาทำงาน" เพราะเมื่อซอฟต์แวร์ทำงานในการผลิตการสื่อสารที่ดีก็สำคัญเช่นกัน ปัญหาเกี่ยวกับองค์กร - ทีมและวิธีการจัดแนวและการสื่อสาร - รายการที่ "เวลาทำงาน"

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

— Paul Stovell
แหล่งที่มา

67

+1 นี่เป็นคำตอบที่ดีกว่าการแลกเปลี่ยนซ้อนมากกว่าทวีต :-)

— ruakh

3

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

— Luaan

2

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

— luk32

10

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

— ต. Sar

18

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

— Robert Harvey

43

คำถามของฉันคืออะไรการเปลี่ยนเป็นไมโครไซต์ทำให้เกิดปัญหาในเวลาทำงาน

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

และพวกเขาวางข้อ จำกัด ตามบริบทในการยืนยันของพวกเขาคือองค์กรของคุณผิดปกติ

ดังนั้นสิ่งที่ทวีตแรกพูดโดยทั่วไปก็คือสองสิ่ง:

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

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

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

— Jörg W Mittag
แหล่งที่มา

6

@Michael ถ้าคุณไม่สามารถดูว่าพวกเขาส่งผลกระทบต่อคุณภาพของรหัสที่อาจจะพิจารณาสิ่งที่ส่งผลกระทบต่อ - ถ้ามี - การบริหารจัดการที่มีต่อใดส่วนหนึ่งของคุณภาพของผลิตภัณฑ์ธุรกิจของพวกเขาสร้าง

— wjl

30

@Michael: ทุกอย่างเกิดจากการบริหารระดับสูงในท้ายที่สุด คุณภาพของรหัสต่ำเกิดจากวันครบกำหนดที่เป็นไปไม่ได้หรือไม่? ใครเป็นคนกำหนดเส้นตายเหล่านั้น ใครบอกคนที่ตั้งกำหนดเวลาเหล่านั้นเพื่อกำหนดเวลาเหล่านั้น? คุณภาพของรหัสต่ำเกิดจากนักพัฒนาที่ไม่มีความสามารถหรือไม่ ใครจ้างนักพัฒนาที่ไร้ความสามารถเหล่านั้น ใครว่าจ้างผู้ที่จ้างนักพัฒนาที่ไร้ความสามารถเหล่านั้น มันเกิดจากการใช้เครื่องมือไม่เพียงพอหรือไม่? ซื้อเครื่องมือเหล่านั้นใคร ใครอนุมัติงบประมาณในการซื้อเครื่องมือเหล่านั้น มันเกิดจากสถาปัตยกรรมโง่ ๆ ? ใครจ้างสถาปนิก? ใครทำให้เขารับผิดชอบ? ทวีตเหล่านั้นมีเฉพาะในบริบท ...

— Jörg W Mittag

13

…ความผิดปกติขององค์กร กันทำให้การทำงานขององค์กรคือสวยมากงานของการจัดการระดับสูง นั่นคือสิ่งที่จัดการคือ

— Jörg W Mittag

4

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

— Stijn de Witt

1

@ JörgWMittagฉันไม่คิดว่ามันสมเหตุสมผลที่จะอ้างว่ารหัสไม่ดีที่เขียนโดยนักพัฒนาที่ไม่ดีนั้นเป็นความผิดของคนที่จ้างนักพัฒนาที่ไม่ดีเหล่านั้นและไม่ใช่นักพัฒนาที่ไม่ดีเอง ในที่สุดมันอาจจะเป็นความรับผิดชอบของการจัดการ แต่มันเกิดจากนักพัฒนา

— เส้นทาง Miles Rout

9

มันจะสร้างปัญหาเวลาทำงานตรงข้ามกับการรวบรวมปัญหาเรียลไทม์

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

— Kilian Foth
แหล่งที่มา

9

สิ่งนี้ดูเหมือนว่าจะถือว่าแอพพลิเคชั่น "เสาหิน" พิมพ์แบบคงที่เสมอ แล้วภาษาที่พิมพ์แบบไดนามิกล่ะ แล้วอินเตอร์เฟสเซอร์วิสที่พิมพ์แบบสแตติกล่ะ

— JacquesB

1

@JacquesB OTOH ฉันสามารถนึกถึงภาษาที่คอมไพล์ด้วยการพิมพ์แบบไดนามิก

— immibis

2

@JacquesB JavaScript และ Python ไม่ได้รับการรวบรวม หากคุณไม่นับโครงสร้างล่ามภายในเป็นเป้าหมายของการรวบรวมซึ่งในกรณีนี้ทุกภาษาจะถูกรวบรวม

— immibis

3

@immibis: ทุกการใช้งาน ECMAScript ที่มีอยู่ในปัจจุบันมีคอมไพเลอร์อย่างน้อยหนึ่งรายการ ยกตัวอย่างเช่น V8 มีคอมไพเลอร์สองตัวและล่ามเป็นศูนย์แน่นอนมันไม่เคยตีความมันจะคอมไพล์รหัสไบนารี่ดั้งเดิมของเครื่องเสมอ SpiderMonkey มีคอมไพเลอร์สี่ตัวฉันเชื่อและตัวแปลหนึ่งตัว แต่ล่ามนั้นไม่ได้แปล ECMAScript SpiderMonkey ไม่เคยตีความ ECMAScript มันมักจะรวบรวมมันเพื่อ SpiderMonkey bytecode ก่อนซึ่งมันอาจจะรวบรวมต่อไปเป็นรหัสเครื่องฐานไบนารี การปรับใช้ Python, Ruby และ PHP ที่มีอยู่ในปัจจุบันทั้งหมดมีคอมไพเลอร์

— Jörg W Mittag

12

@LieRyan คุณสับสนอย่างมากถ้าคุณคิดว่าการอนุมานแบบนั้นเหมือนกับการพิมพ์แบบไดนามิกและ / หรือHaskellนั้นถูกพิมพ์แบบไดนามิก

— Derek Elkins

2

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

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

หากอินเทอร์เฟซไม่ได้รับการออกแบบอย่างถูกต้องคุณจะได้รับปัญหา runtime สองชนิด:

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

ฉันคิดว่าการผลิตปัญหา runtime ไม่ใช่วิธีการที่ถูกต้องในการสื่อสารปัญหาองค์กรให้กับผู้ที่รับผิดชอบ

— เบอร์นี
แหล่งที่มา