Apache Ignite Zero Deployment: เป็นศูนย์จริงหรือ?

เราเป็นแผนกพัฒนาเทคโนโลยีของเครือข่ายการค้าปลีก วันหนึ่ง ฝ่ายบริหารมอบหมายงานในการเร่งความเร็วการคำนวณขนาดใหญ่โดยใช้ Apache Ignite ร่วมกับ MSSQL และแสดงเว็บไซต์ที่มีภาพประกอบที่สวยงามและตัวอย่างโค้ด Java ฉันชอบไซต์นี้ทันที การปรับใช้เป็นศูนย์คำอธิบายที่สัญญาว่าจะเกิดปาฏิหาริย์: คุณไม่จำเป็นต้องปรับใช้โค้ด Java หรือ Scala ของคุณด้วยตนเองในแต่ละโหนดในกริดและปรับใช้ใหม่ทุกครั้งที่มีการเปลี่ยนแปลง เมื่องานดำเนินไป ปรากฏว่า Zero Deployment มีการใช้งานเฉพาะ ซึ่งเป็นฟีเจอร์ที่ฉันต้องการแชร์ ด้านล่างคือแนวคิดและรายละเอียดการนำไปปฏิบัติ

1. คำชี้แจงของปัญหา

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

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

2. ศึกษาวรรณคดี

ฉันยังไม่มีประสบการณ์เลยเริ่มเต้นจากเตา นั่นก็คือจากการทบทวนสิ่งพิมพ์

บทความ 2016 ขอแนะนำ Apache Ignite: ขั้นตอนแรก มีลิงก์ไปยังเอกสารประกอบของโครงการ Apache Ignite และในขณะเดียวกันก็มีการตำหนิต่อความคลุมเครือของเอกสารนี้ ฉันอ่านซ้ำสองสามครั้งความชัดเจนไม่เกิดขึ้น ฉันอ้างถึงกวดวิชาอย่างเป็นทางการ เริ่มต้นซึ่ง
สัญญาในแง่ดีว่า "คุณจะพร้อมใช้งานได้ในระยะเวลาอันสั้น!" ฉันกำลังค้นหาการตั้งค่าตัวแปรสภาพแวดล้อมโดยดูวิดีโอ Apache Ignite Essentials สองรายการ แต่ไม่มีประโยชน์สำหรับงานเฉพาะของฉันมากนัก ฉันเปิดใช้ Ignite จากบรรทัดคำสั่งด้วยไฟล์มาตรฐาน “example-ignite.xml” ได้สำเร็จ โดยสร้างแอปพลิเคชันแรก แอปพลิเคชันคำนวณ โดยใช้มาเวน แอปพลิเคชันทำงานและใช้ Zero Deployment ช่างสวยงามจริงๆ!

ฉันอ่านเพิ่มเติมและมีตัวอย่างที่ใช้ affinityKey ทันที (สร้างก่อนหน้านี้ผ่านการสืบค้น SQL) และยังใช้ BinaryObject ลึกลับ:

IgniteCache<BinaryObject, BinaryObject> people 
        = ignite.cache("Person").withKeepBinary(); 

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

ฉันกำลังสร้างแอปพลิเคชัน Compute ใหม่เพื่อให้เหมาะกับกรณีของฉัน คีย์หลักของไดเรกทอรีของจุดขายใน MSSQL ถูกกำหนดเป็น [id] [int] NOT NULL ฉันสร้างแคชโดยการเปรียบเทียบ

IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")

ในการกำหนดค่า xml ฉันระบุว่าแคชถูกแบ่งพาร์ติชัน

<bean class="org.apache.ignite.configuration.CacheConfiguration">
    <property name="name" value="spCache"/>
    <property name="cacheMode" value="PARTITIONED"/>
</bean>

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

ฉันกำลังอ่านบทช่วยสอน แอปพลิเคชัน Ignite Compute ครั้งแรกฉันทำโดยการเปรียบเทียบ ในแต่ละโหนดคลัสเตอร์ ฉันเรียกใช้ IgniteRunnable() บางอย่างเช่นนี้:

  @Override
  public void run() {
    SalesPoint sp=salesPointCache.get(spId);
    sp.calculateSalesPointCount();
    ..
  }

ฉันเพิ่มตรรกะการรวมและการอัปโหลด และรันบนชุดข้อมูลทดสอบ ทุกอย่างทำงานภายในเครื่องบนเซิร์ฟเวอร์การพัฒนา

ฉันเปิดตัวเซิร์ฟเวอร์ทดสอบ CentO สองเครื่อง ระบุที่อยู่ IP ใน default-config.xml และดำเนินการในแต่ละเซิร์ฟเวอร์

./bin/ignite.sh config/default-config.xml

โหนด Ignite ทั้งสองกำลังทำงานอยู่และสามารถมองเห็นซึ่งกันและกันได้ ฉันระบุที่อยู่ที่ต้องการในการกำหนดค่า xml ของแอปพลิเคชันไคลเอนต์ มันเริ่มต้น เพิ่มโหนดที่สามให้กับโทโพโลยี และทันทีที่มีสองโหนดอีกครั้ง บันทึกแสดง "ClassNotFoundException: model.SalesPoint" ในบรรทัด

SalesPoint sp=salesPointCache.get(spId);

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

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

วาเลนติน คูลิเชนโก, หัวหน้าสถาปนิกที่ GridGain Systems, ตอบ บน StackOverflow เมษายน 2016:

Model classes are not peer deployed, but you can use withKeepBinary() flag
on the cache and query BinaryObjects. This way you will avoid deserialization
on the server side and will not get ClassNotFoundException.

ความคิดเห็นที่เชื่อถือได้อื่น: เดนิส แมกด้า, ผู้อำนวยการฝ่ายบริหารผลิตภัณฑ์, GridGain Systems

บทความเกี่ยวกับฮาเบร เกี่ยวกับไมโครเซอร์วิส อ้างอิงสามบทความโดย Denis Magda: ไมโครเซอร์วิส ตอนที่ XNUMX, ไมโครเซอร์วิส ตอนที่ XNUMX, ไมโครเซอร์วิส ตอนที่ XNUMX 2016-2017. ในบทความที่สอง Denis แนะนำให้เริ่มต้นโหนดคลัสเตอร์ผ่าน MaintenanceServiceNodeStartup.jar คุณยังสามารถใช้การเรียกใช้งานด้วยการกำหนดค่า xml และบรรทัดคำสั่งได้ แต่คุณจะต้องใส่คลาสแบบกำหนดเองบนแต่ละโหนดคลัสเตอร์ที่ปรับใช้ด้วยตนเอง:

That's it. Start (..)  node using MaintenanceServiceNodeStartup file or pass
maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts.
If you prefer the latter then make sure to build a jar file that will contain
all the classes from java/app/common and java/services/maintenance directories.
The jar has to be added to the classpath of every node where the service
might be deployed.

จริงอยู่นั่นแหละ ปรากฎว่าเหตุใดรูปแบบไบนารี่ลึกลับนี้!

3.โถเดียว

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

ฉันทำแบบเดียวกันและได้รับไฟล์ jar ไฟล์เดียวที่เรียกใช้ "data node" หรือ "client node" ขึ้นอยู่กับอาร์กิวเมนต์บรรทัดคำสั่ง การประกอบเริ่มต้นและทำงาน Zero Deployment พ่ายแพ้แล้ว

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

4. บทสรุป

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

จากผลงานที่ทำเสร็จแล้ว ความประทับใจก็คือ Zero Deployment ทำงานได้ แต่ในระดับระบบเท่านั้น บางสิ่งเช่นนี้: BinaryObject ใช้เพื่อสอนโหนดคลัสเตอร์ระยะไกลให้ทำงานกับคลาสที่กำหนดเอง Zero Deployment - กลไกภายใน
Apache Ignite เองและกระจายอ็อบเจ็กต์ระบบทั่วทั้งคลัสเตอร์

ฉันหวังว่าประสบการณ์ของฉันจะเป็นประโยชน์กับผู้ใช้ Apache Ignite รายใหม่

ที่มา: will.com