สวัสดีทุกคน! เรามีข่าวดี OTUS จะเปิดตัวหลักสูตรอีกครั้งในเดือนมิถุนายน ในส่วนที่เกี่ยวข้องกับการที่เราแบ่งปันเนื้อหาที่เป็นประโยชน์กับคุณตามธรรมเนียม
หากคุณเจอไมโครเซอร์วิสทั้งหมดนี้โดยไม่มีบริบทใดๆ คุณจะได้รับการอภัยที่คิดว่ามันแปลกนิดหน่อย การแยกแอปพลิเคชันออกเป็นส่วนย่อยที่เชื่อมต่อกันด้วยเครือข่ายจำเป็นต้องหมายถึงการเพิ่มโหมดความทนทานต่อข้อผิดพลาดที่ซับซ้อนให้กับระบบแบบกระจายที่เกิดขึ้น
แม้ว่าแนวทางนี้จะเกี่ยวข้องกับการแยกบริการออกเป็นบริการอิสระต่างๆ มากมาย แต่เป้าหมายสุดท้ายมีมากกว่าแค่การให้บริการเหล่านั้นทำงานบนเครื่องที่แตกต่างกัน เรากำลังพูดถึงปฏิสัมพันธ์กับโลกภายนอกซึ่งกระจายอยู่ในสาระสำคัญเช่นกัน ไม่ใช่ในแง่เทคนิค แต่ในแง่ของระบบนิเวศที่ประกอบด้วยคน ทีมงาน โปรแกรม และแต่ละส่วนเหล่านี้จำเป็นต้องทำงานของมัน
ตัวอย่างเช่น บริษัทต่างๆ คือกลุ่มของระบบแบบกระจายที่ร่วมกันมีส่วนช่วยให้บรรลุเป้าหมายบางอย่าง เราเพิกเฉยต่อข้อเท็จจริงนี้มานานหลายทศวรรษ โดยพยายามบรรลุการรวมเป็นหนึ่งโดยการถ่ายโอนไฟล์ผ่าน FTP หรือการใช้เครื่องมือบูรณาการระดับองค์กร ในขณะเดียวกันก็มุ่งเน้นไปที่เป้าหมายที่แยกจากกันของเราเอง แต่ด้วยการมาถึงของบริการทุกอย่างก็เปลี่ยนไป บริการช่วยให้เรามองไปไกลกว่าขอบฟ้าและมองเห็นโลกแห่งโปรแกรมที่พึ่งพาซึ่งกันและกันซึ่งทำงานร่วมกัน อย่างไรก็ตาม เพื่อให้ทำงานได้อย่างประสบความสำเร็จ จำเป็นต้องจดจำและออกแบบโลกสองใบที่แตกต่างกันโดยพื้นฐาน ได้แก่ โลกภายนอกที่เราอาศัยอยู่ในระบบนิเวศของบริการอื่นๆ มากมาย และโลกส่วนตัวภายในของเราที่เราปกครองโดยลำพัง
โลกที่กระจัดกระจายนี้แตกต่างจากโลกที่เราเติบโตมาและคุ้นเคย หลักการสร้างสถาปัตยกรรมเสาหินแบบดั้งเดิมไม่สามารถต้านทานการวิพากษ์วิจารณ์ได้ ดังนั้นการทำให้ระบบเหล่านี้ถูกต้องนั้นเป็นมากกว่าการสร้างไดอะแกรมไวท์บอร์ดเจ๋งๆ หรือการพิสูจน์แนวคิดที่ยอดเยี่ยม ประเด็นก็คือเพื่อให้แน่ใจว่าระบบดังกล่าวทำงานได้สำเร็จในระยะเวลาอันยาวนาน โชคดีที่บริการเหล่านี้มีมาระยะหนึ่งแล้ว แม้ว่าจะดูแตกต่างออกไปก็ตาม ยังคงมีความเกี่ยวข้องแม้จะปรุงรสด้วย Docker, Kubernetes และเคราฮิปสเตอร์โทรมเล็กน้อย
ดังนั้นวันนี้เราจะมาดูว่ากฎมีการเปลี่ยนแปลงอย่างไร เหตุใดเราจึงต้องคิดใหม่เกี่ยวกับวิธีเข้าถึงบริการและข้อมูลที่พวกเขาส่งต่อถึงกัน และเหตุใดเราจึงต้องมีเครื่องมือที่แตกต่างกันโดยสิ้นเชิงในการดำเนินการ
การห่อหุ้มจะไม่ใช่เพื่อนของคุณเสมอไป
ไมโครเซอร์วิสสามารถทำงานแยกจากกันได้ คุณสมบัตินี้เองที่ทำให้พวกเขามีคุณค่าสูงสุด คุณสมบัติเดียวกันนี้ช่วยให้บริการสามารถขยายขนาดและเติบโตได้ ไม่มากในแง่ของการขยายขนาดเป็นสี่ล้านล้านผู้ใช้หรือข้อมูลหลายเพตะไบต์ (แม้ว่าจะสามารถช่วยได้เช่นกัน) แต่ในแง่ของการขยายขนาดในแง่ของคนในขณะที่ทีมและองค์กรเติบโตอย่างต่อเนื่อง
อย่างไรก็ตาม ความเป็นอิสระเป็นดาบสองคม นั่นคือตัวบริการสามารถทำงานได้ง่ายและเป็นธรรมชาติ แต่หากมีการใช้งานฟังก์ชันภายในบริการที่ต้องใช้บริการอื่น เราก็จะต้องทำการเปลี่ยนแปลงกับบริการทั้งสองแทบจะพร้อมกัน ในหินใหญ่ก้อนนี้ทำได้ง่ายคุณเพียงแค่ทำการเปลี่ยนแปลงและส่งไปเผยแพร่ แต่ในกรณีของการซิงโครไนซ์บริการอิสระจะมีปัญหามากขึ้น การประสานงานระหว่างทีมและรอบการเปิดตัวจะทำลายความคล่องตัว
ในฐานะที่เป็นส่วนหนึ่งของแนวทางมาตรฐาน พวกเขาพยายามหลีกเลี่ยงการเปลี่ยนแปลงตั้งแต่ต้นทางถึงปลายทางที่น่ารำคาญ โดยแบ่งการทำงานระหว่างบริการต่างๆ อย่างชัดเจน บริการลงชื่อเพียงครั้งเดียวสามารถเป็นตัวอย่างที่ดีได้ที่นี่ มีบทบาทที่กำหนดไว้อย่างชัดเจนซึ่งทำให้แตกต่างจากบริการอื่นๆ การแบ่งแยกที่ชัดเจนนี้หมายความว่าในโลกที่ความต้องการบริการต่างๆ รอบตัวเปลี่ยนแปลงไปอย่างรวดเร็ว บริการ single sign-on ไม่น่าจะเปลี่ยนแปลง มันมีอยู่ในบริบทที่จำกัดอย่างเคร่งครัด
ปัญหาคือในโลกแห่งความเป็นจริง การบริการทางธุรกิจไม่สามารถรักษาการแบ่งแยกบทบาทที่บริสุทธิ์เหมือนเดิมได้ตลอดเวลา ตัวอย่างเช่น บริการทางธุรกิจเดียวกันจะทำงานในระดับที่มากขึ้นกับข้อมูลที่มาจากบริการอื่นที่คล้ายคลึงกัน หากคุณมีส่วนร่วมในการขายปลีกออนไลน์ การประมวลผลขั้นตอนการสั่งซื้อ แค็ตตาล็อกผลิตภัณฑ์ หรือข้อมูลผู้ใช้จะกลายเป็นข้อกำหนดสำหรับบริการหลายอย่างของคุณ แต่ละบริการจะต้องเข้าถึงข้อมูลนี้เพื่อดำเนินการ
บริการทางธุรกิจส่วนใหญ่ใช้กระแสข้อมูลเดียวกัน ดังนั้นงานของพวกเขาจึงมีความเกี่ยวพันกันอย่างสม่ำเสมอ
ดังนั้นเราจึงมาถึงประเด็นสำคัญที่ควรค่าแก่การพูดถึง แม้ว่าบริการต่างๆ จะทำงานได้ดีสำหรับส่วนประกอบโครงสร้างพื้นฐานที่ทำงานแบบแยกส่วนเป็นส่วนใหญ่ แต่บริการทางธุรกิจส่วนใหญ่กลับมีความเกี่ยวพันกันอย่างใกล้ชิดมากขึ้น
การแบ่งแยกข้อมูล
แนวทางการบริการอาจมีอยู่แล้ว แต่ยังขาดข้อมูลเชิงลึกเกี่ยวกับวิธีการแบ่งปันข้อมูลจำนวนมากระหว่างบริการต่างๆ
ปัญหาหลักคือข้อมูลและบริการแยกจากกันไม่ได้ ในแง่หนึ่ง การห่อหุ้มสนับสนุนให้เราซ่อนข้อมูลเพื่อให้สามารถแยกบริการออกจากกัน และอำนวยความสะดวกในการเติบโตและการเปลี่ยนแปลงเพิ่มเติม ในทางกลับกัน เราจำเป็นต้องสามารถแบ่งและพิชิตข้อมูลที่ใช้ร่วมกันได้อย่างอิสระ เช่นเดียวกับข้อมูลอื่นๆ ประเด็นก็คือสามารถเริ่มทำงานได้ทันทีได้อย่างอิสระเหมือนกับในระบบสารสนเทศอื่นๆ
อย่างไรก็ตาม ระบบสารสนเทศแทบไม่เกี่ยวข้องกับการห่อหุ้มเลย ในความเป็นจริงมันค่อนข้างตรงกันข้าม ฐานข้อมูลทำทุกอย่างเท่าที่ทำได้เพื่อให้สามารถเข้าถึงข้อมูลที่จัดเก็บได้ มาพร้อมกับอินเทอร์เฟซการประกาศที่ทรงพลังซึ่งช่วยให้คุณแก้ไขข้อมูลได้ตามที่คุณต้องการ ฟังก์ชั่นดังกล่าวมีความสำคัญในขั้นตอนการวิจัยเบื้องต้น แต่ไม่ใช่สำหรับการจัดการความซับซ้อนที่เพิ่มขึ้นของบริการที่มีการพัฒนาอย่างต่อเนื่อง
และนี่ก็เกิดภาวะที่กลืนไม่เข้าคายไม่ออก ความขัดแย้ง. การแบ่งขั้ว ท้ายที่สุดแล้ว ระบบสารสนเทศเกี่ยวข้องกับการให้ข้อมูล และบริการเกี่ยวกับการซ่อน
พลังทั้งสองนี้เป็นพื้นฐาน พวกเขาสนับสนุนงานส่วนใหญ่ของเรา และต่อสู้อย่างต่อเนื่องเพื่อความเป็นเลิศในระบบที่เราสร้าง
เมื่อระบบบริการเติบโตและพัฒนา เราก็เห็นผลที่ตามมาของการแบ่งแยกข้อมูลในหลายๆ ด้าน อินเทอร์เฟซบริการจะเติบโตขึ้น โดยมีฟังก์ชันการทำงานที่เพิ่มมากขึ้นเรื่อยๆ และเริ่มดูเหมือนฐานข้อมูลพื้นบ้านที่สวยงามมาก หรือเราจะรู้สึกหงุดหงิดและใช้วิธีการบางอย่างในการดึงหรือย้ายชุดข้อมูลทั้งหมดจากบริการหนึ่งไปยังอีกบริการหนึ่ง
ในทางกลับกัน การสร้างสิ่งที่ดูเหมือนฐานข้อมูลพื้นบ้านที่หรูหราจะนำไปสู่ปัญหามากมาย เราจะไม่ลงรายละเอียดว่าทำไมมันถึงเป็นอันตราย ฐานข้อมูลที่ใช้ร่วมกันสมมติว่ามันแสดงถึงวิศวกรรมและการปฏิบัติการที่มีค่าใช้จ่ายสูง สำหรับบริษัทที่พยายามจะใช้งาน
ที่แย่กว่านั้นคือปริมาณข้อมูลขยายปัญหาขอบเขตการบริการ ยิ่งมีการแบ่งปันข้อมูลภายในบริการมากเท่าไร อินเทอร์เฟซก็จะยิ่งซับซ้อนมากขึ้นเท่านั้น และการรวมชุดข้อมูลที่มาจากบริการต่างๆ ก็ยิ่งยากขึ้นเท่านั้น
แนวทางอื่นในการแยกและย้ายชุดข้อมูลทั้งหมดก็มีปัญหาเช่นกัน แนวทางทั่วไปสำหรับคำถามนี้ดูเหมือนเพียงแค่ดึงข้อมูลและจัดเก็บชุดข้อมูลทั้งหมด จากนั้นจัดเก็บไว้ในเครื่องในแต่ละบริการที่ใช้งาน
ปัญหาคือบริการต่างๆ ตีความข้อมูลที่ใช้แตกต่างกัน ข้อมูลนี้อยู่ในมือเสมอ มีการแก้ไขและประมวลผลภายในเครื่อง อย่างรวดเร็วพวกเขาหยุดมีอะไรที่เหมือนกันกับข้อมูลในแหล่งที่มา
ยิ่งสำเนาไม่แน่นอน ข้อมูลก็จะเปลี่ยนแปลงไปตามกาลเวลามากขึ้นเท่านั้น
ที่แย่กว่านั้นคือข้อมูลดังกล่าวยากต่อการแก้ไขย้อนหลัง ( นี่จะช่วยได้จริงๆ นะ) ในความเป็นจริง ปัญหาด้านเทคโนโลยีที่ยากจะแก้ไขที่ธุรกิจต้องเผชิญนั้นเกิดขึ้นจากข้อมูลที่แตกต่างกันซึ่งทวีคูณจากแอปพลิเคชันหนึ่งไปยังอีกแอปพลิเคชันหนึ่ง
หากต้องการค้นหาวิธีแก้ไขปัญหานี้ เราต้องคิดให้แตกต่างเกี่ยวกับข้อมูลที่แบ่งปัน พวกเขาจะต้องกลายเป็นวัตถุชั้นหนึ่งในสถาปัตยกรรมที่เราสร้างขึ้น เรียกข้อมูลดังกล่าวว่า "ภายนอก" และนี่คือคุณลักษณะที่สำคัญมาก เราจำเป็นต้องมีการห่อหุ้มเพื่อที่เราจะได้ไม่เปิดเผยการทำงานภายในของบริการ แต่เราจำเป็นต้องทำให้บริการต่างๆ สามารถเข้าถึงข้อมูลที่ใช้ร่วมกันได้อย่างง่ายดาย เพื่อให้พวกเขาสามารถทำงานได้อย่างถูกต้อง
ปัญหาคือในปัจจุบันไม่มีแนวทางใดที่เกี่ยวข้อง เนื่องจากทั้งอินเทอร์เฟซบริการ การรับส่งข้อความ และฐานข้อมูลที่ใช้ร่วมกันต่างก็เสนอโซลูชันที่ดีสำหรับการทำงานกับข้อมูลภายนอก อินเทอร์เฟซบริการไม่เหมาะกับการแลกเปลี่ยนข้อมูลในทุกระดับ ข้อความจะย้ายข้อมูลแต่ไม่ได้เก็บประวัติไว้ ดังนั้นข้อมูลจึงเสียหายเมื่อเวลาผ่านไป ฐานข้อมูลที่ใช้ร่วมกันมุ่งเน้นไปที่จุดเดียวมากเกินไป ซึ่งขัดขวางความคืบหน้า เราติดอยู่ในวงจรของความล้มเหลวของข้อมูลอย่างหลีกเลี่ยงไม่ได้:
วงจรของความล้มเหลวของข้อมูล
สตรีม: แนวทางการกระจายอำนาจสำหรับข้อมูลและบริการ
ตามหลักการแล้ว เราจำเป็นต้องเปลี่ยนวิธีการทำงานของบริการกับข้อมูลที่แชร์ เมื่อถึงจุดนี้ วิธีใดวิธีหนึ่งต้องเผชิญกับการแบ่งขั้วที่กล่าวมาข้างต้น เนื่องจากไม่มีฝุ่นวิเศษที่สามารถโปรยลงไปเพื่อทำให้หายไปได้ อย่างไรก็ตาม เราสามารถคิดใหม่เกี่ยวกับปัญหาและประนีประนอมได้
การประนีประนอมนี้เกี่ยวข้องกับการรวมศูนย์ในระดับหนึ่ง เราสามารถใช้กลไกบันทึกแบบกระจายได้เนื่องจากมีสตรีมที่เชื่อถือได้และปรับขนาดได้ ตอนนี้เราต้องการให้บริการต่างๆ สามารถเข้าร่วมและดำเนินการบนเธรดที่แชร์เหล่านี้ได้ แต่เราต้องการหลีกเลี่ยงบริการพระเจ้าแบบรวมศูนย์ที่ซับซ้อนซึ่งทำการประมวลผลนี้ ดังนั้นตัวเลือกที่ดีที่สุดคือการสร้างการประมวลผลสตรีมในบริการผู้บริโภคแต่ละราย ด้วยวิธีนี้ บริการต่างๆ จะสามารถรวมชุดข้อมูลจากแหล่งต่างๆ และทำงานร่วมกับชุดเหล่านั้นได้ตามที่คุณต้องการ
วิธีหนึ่งในการบรรลุแนวทางนี้คือการใช้แพลตฟอร์มสตรีมมิ่ง มีตัวเลือกมากมาย แต่วันนี้เราจะมาดูที่ Kafka เนื่องจากการใช้ Stateful Stream Processing ช่วยให้เราสามารถแก้ไขปัญหาที่นำเสนอได้อย่างมีประสิทธิภาพ
การใช้กลไกการบันทึกแบบกระจายช่วยให้เราสามารถปฏิบัติตามเส้นทางที่ได้รับการเหยียบย่ำและใช้การส่งข้อความเพื่อทำงานด้วย . แนวทางนี้ถือว่าให้การปรับขนาดและการแบ่งพาร์ติชันที่ดีกว่ากลไกการตอบกลับคำขอ เนื่องจากให้การควบคุมโฟลว์ไปยังผู้รับมากกว่าผู้ส่ง อย่างไรก็ตาม คุณต้องจ่ายสำหรับทุกสิ่งในชีวิตนี้ และที่นี่คุณต้องมีนายหน้า แต่สำหรับระบบขนาดใหญ่ การแลกเปลี่ยนก็คุ้มค่า (ซึ่งอาจไม่ใช่กรณีของเว็บแอปพลิเคชันทั่วไปของคุณ)
หากนายหน้ามีหน้าที่รับผิดชอบในการบันทึกแบบกระจายมากกว่าระบบส่งข้อความแบบเดิม คุณสามารถใช้ประโยชน์จากคุณสมบัติเพิ่มเติมได้ การขนส่งสามารถปรับขนาดเชิงเส้นได้เกือบเท่ากับระบบไฟล์แบบกระจาย ข้อมูลสามารถเก็บไว้ในบันทึกได้ค่อนข้างนาน ดังนั้นเราจึงไม่เพียงได้รับการแลกเปลี่ยนข้อความเท่านั้น แต่ยังรวมถึงการจัดเก็บข้อมูลด้วย พื้นที่จัดเก็บข้อมูลที่ปรับขนาดได้โดยไม่ต้องกลัวว่าสถานะที่ใช้ร่วมกันจะเปลี่ยนแปลงไม่ได้
จากนั้นคุณสามารถใช้การประมวลผลสตรีมแบบ stateful เพื่อเพิ่มเครื่องมือฐานข้อมูลที่ประกาศไปยังบริการที่ใช้บริการ นี่เป็นแนวคิดที่สำคัญมาก แม้ว่าข้อมูลจะถูกจัดเก็บไว้ในสตรีมที่ใช้ร่วมกันซึ่งบริการทั้งหมดสามารถเข้าถึงได้ การรวมและการประมวลผลที่บริการทำนั้นเป็นแบบส่วนตัว พวกเขาพบว่าตัวเองโดดเดี่ยวในบริบทที่จำกัดอย่างเคร่งครัด
กำจัดการแบ่งแยกข้อมูลโดยการแยกสตรีมสถานะที่ไม่เปลี่ยนรูปออก จากนั้นเพิ่มฟังก์ชันการทำงานนี้ให้กับทุกบริการที่ใช้การประมวลผล Stateful Stream
ดังนั้น หากบริการของคุณจำเป็นต้องทำงานร่วมกับคำสั่งซื้อ แค็ตตาล็อกผลิตภัณฑ์ คลังสินค้า บริการนั้นจะสามารถเข้าถึงได้โดยสมบูรณ์ มีเพียงคุณเท่านั้นที่จะตัดสินใจว่าจะรวมข้อมูลใด สถานที่ประมวลผลที่ไหน และควรเปลี่ยนแปลงอย่างไรเมื่อเวลาผ่านไป แม้ว่าจะมีการแบ่งปันข้อมูล แต่การทำงานกับข้อมูลนั้นมีการกระจายอำนาจอย่างสมบูรณ์ มันถูกสร้างขึ้นในแต่ละบริการ ในโลกที่ทุกอย่างเป็นไปตามกฎเกณฑ์ของคุณ
แบ่งปันข้อมูลโดยไม่กระทบต่อความสมบูรณ์ของข้อมูล สรุปฟังก์ชัน ไม่ใช่แหล่งที่มา ในทุกบริการที่ต้องการ
มันเกิดขึ้นว่าข้อมูลจำเป็นต้องถูกย้ายจำนวนมาก บางครั้งบริการจำเป็นต้องมีชุดข้อมูลประวัติในเครื่องในกลไกฐานข้อมูลที่เลือก เคล็ดลับก็คือ คุณสามารถรับประกันได้ว่าหากจำเป็น สำเนาสามารถกู้คืนได้จากแหล่งที่มาโดยการเข้าถึงกลไกการบันทึกแบบกระจาย ตัวเชื่อมต่อใน Kafka ทำงานได้ดีมาก
ดังนั้นแนวทางที่กล่าวถึงในวันนี้จึงมีข้อดีหลายประการ:
- ข้อมูลถูกใช้ในรูปแบบของสตรีมทั่วไปซึ่งสามารถเก็บไว้ในบันทึกได้เป็นเวลานาน และกลไกในการทำงานกับข้อมูลทั่วไปนั้นเดินสายในแต่ละบริบท ซึ่งช่วยให้บริการทำงานได้ง่ายและรวดเร็ว ด้วยวิธีนี้ การแบ่งขั้วของข้อมูลจึงมีความสมดุล
- ข้อมูลที่มาจากบริการต่างๆ สามารถนำมารวมกันเป็นชุดได้อย่างง่ายดาย สิ่งนี้ช่วยลดความยุ่งยากในการโต้ตอบกับข้อมูลที่แชร์และไม่จำเป็นต้องรักษาชุดข้อมูลในเครื่องในฐานข้อมูล
- การประมวลผล Stateful Stream จะแคชเฉพาะข้อมูลเท่านั้น และแหล่งที่มาที่แท้จริงยังคงเป็นบันทึกทั่วไป ดังนั้นปัญหาความเสียหายของข้อมูลเมื่อเวลาผ่านไปจึงไม่รุนแรงนัก
- โดยหัวใจหลัก บริการต่างๆ ขับเคลื่อนด้วยข้อมูล ซึ่งหมายความว่าถึงแม้ปริมาณข้อมูลจะเพิ่มขึ้นเรื่อยๆ แต่บริการต่างๆ ก็ยังสามารถตอบสนองเหตุการณ์ทางธุรกิจได้อย่างรวดเร็ว
- ปัญหาเรื่องความสามารถในการปรับขนาดตกอยู่ที่นายหน้า ไม่ใช่บริการ สิ่งนี้ช่วยลดความซับซ้อนในบริการการเขียนได้อย่างมาก เนื่องจากไม่จำเป็นต้องคำนึงถึงความสามารถในการขยายขนาด
- การเพิ่มบริการใหม่ไม่จำเป็นต้องเปลี่ยนบริการเก่า ดังนั้นการเชื่อมต่อบริการใหม่จึงง่ายขึ้น
อย่างที่คุณเห็น นี่เป็นมากกว่า REST เราได้รับชุดเครื่องมือที่ช่วยให้คุณทำงานกับข้อมูลที่แบ่งปันในลักษณะที่มีการกระจายอำนาจ
บทความของวันนี้ไม่ได้ครอบคลุมทุกด้าน เรายังคงต้องหาวิธีสร้างสมดุลระหว่างกระบวนทัศน์การตอบกลับคำขอและกระบวนทัศน์ที่ขับเคลื่อนด้วยเหตุการณ์ แต่เราจะจัดการกับเรื่องนี้ในครั้งต่อไป มีหัวข้อต่างๆ ที่คุณต้องเรียนรู้ให้มากขึ้น เช่น เหตุใด Stateful Stream Processing จึงดีมาก เราจะพูดถึงเรื่องนี้ในบทความที่สาม และยังมีโครงสร้างที่ทรงพลังอื่น ๆ ที่เราสามารถใช้ประโยชน์ได้หากเราใช้มัน เช่น . มันเป็นตัวเปลี่ยนเกมสำหรับระบบธุรกิจแบบกระจายเนื่องจากมีการรับประกันการทำธุรกรรม ในรูปแบบที่ปรับขนาดได้ เราจะพิจารณาเรื่องนี้ในบทความที่สี่ สุดท้ายนี้ เราจะต้องดูรายละเอียดการดำเนินการตามหลักการเหล่านี้
แต่สำหรับตอนนี้ โปรดจำไว้ว่า การแบ่งขั้วข้อมูลเป็นพลังที่เราเผชิญในการสร้างบริการทางธุรกิจ และเราต้องจำสิ่งนี้ไว้ เคล็ดลับคือการพลิกสถานการณ์ทุกอย่างและเริ่มปฏิบัติต่อข้อมูลที่แชร์เสมือนเป็นออบเจ็กต์ชั้นหนึ่ง การประมวลผล stateful Stream มอบการประนีประนอมที่ไม่เหมือนใครสำหรับสิ่งนี้ มันหลีกเลี่ยง "ส่วนประกอบของพระเจ้า" ที่รวมศูนย์ซึ่งขัดขวางความก้าวหน้า นอกจากนี้ยังรับประกันความคล่องตัว ความสามารถในการปรับขนาด และความยืดหยุ่นของไปป์ไลน์การสตรีมข้อมูล และเพิ่มเข้าไปในทุกบริการ ดังนั้นเราจึงสามารถมุ่งเน้นไปที่กระแสจิตสำนึกทั่วไปที่บริการใด ๆ สามารถเชื่อมต่อและทำงานกับข้อมูลของตนได้ ทำให้บริการต่างๆ สามารถปรับขนาด ใช้แทนกันได้ และเป็นอิสระมากขึ้น ดังนั้นพวกเขาจะไม่เพียงดูดีบนไวท์บอร์ดและการทดสอบสมมติฐานเท่านั้น แต่ยังใช้งานได้ดีและพัฒนามานานหลายทศวรรษอีกด้วย
ที่มา: will.com