ตั้งแต่ปีที่แล้ว บริษัทของเราเริ่มจัดงานแฮ็กกาธอน การแข่งขันครั้งแรกประสบความสำเร็จอย่างมาก เราเขียนถึงเรื่องนี้ในนั้น . Hackathon ครั้งที่สองเกิดขึ้นในเดือนกุมภาพันธ์ 2019 และประสบความสำเร็จไม่น้อย เกี่ยวกับเป้าหมายของการถือครองหลังไม่นานมานี้ ออแกไนเซอร์
ผู้เข้าร่วมได้รับงานที่ค่อนข้างน่าสนใจและมีอิสระอย่างเต็มที่ในการเลือกกลุ่มเทคโนโลยีสำหรับการนำไปใช้งาน จำเป็นต้องใช้แพลตฟอร์มการตัดสินใจเพื่อความสะดวกในการใช้งานฟังก์ชันการให้คะแนนลูกค้า ซึ่งสามารถทำงานกับแอปพลิเคชันที่ไหลลื่นอย่างรวดเร็ว ทนทานต่องานหนัก และระบบเองก็ปรับขนาดได้ง่าย
งานนี้ไม่สำคัญและสามารถแก้ไขได้หลายวิธี เนื่องจากเรามั่นใจในระหว่างการสาธิตการนำเสนอโครงการของผู้เข้าร่วมขั้นสุดท้าย Hackathon มี 6 ทีม ทีมละ 5 คน ผู้เข้าร่วมทุกคนมีโปรเจ็กต์ที่ดี แต่แพลตฟอร์มของเรามีการแข่งขันสูงที่สุด เรามีโครงการที่น่าสนใจมากซึ่งฉันอยากจะพูดถึงในบทความนี้
โซลูชันของเราคือแพลตฟอร์มที่ใช้สถาปัตยกรรมแบบไร้เซิร์ฟเวอร์ภายใน Kubernetes ซึ่งช่วยลดเวลาที่ใช้ในการนำคุณลักษณะใหม่ๆ ไปสู่การใช้งานจริง ช่วยให้นักวิเคราะห์เขียนโค้ดในสภาพแวดล้อมที่สะดวกสำหรับพวกเขา และปรับใช้ในการผลิตโดยไม่ต้องมีส่วนร่วมของวิศวกรและนักพัฒนา
คะแนนคืออะไร
Tinkoff.ru ก็เหมือนกับบริษัทสมัยใหม่อื่นๆ ที่มีการให้คะแนนจากลูกค้า การให้คะแนนคือระบบการประเมินลูกค้าตามวิธีการวิเคราะห์ข้อมูลทางสถิติ
ตัวอย่างเช่น ลูกค้าหันมาหาเราเพื่อขอให้ออกเงินกู้ให้เขา หรือเปิดบัญชีผู้ประกอบการรายบุคคลกับเรา หากเราวางแผนที่จะออกเงินกู้ให้เขา เราจำเป็นต้องประเมินความสามารถในการละลายของเขา และหากบัญชีนั้นเป็นผู้ประกอบการรายบุคคล เราต้องแน่ใจว่าลูกค้าจะไม่ทำธุรกรรมที่ฉ้อโกง
พื้นฐานในการตัดสินใจดังกล่าวคือแบบจำลองทางคณิตศาสตร์ที่วิเคราะห์ทั้งข้อมูลจากแอปพลิเคชันเองและข้อมูลจากที่เก็บข้อมูลของเรา นอกเหนือจากการให้คะแนนแล้ว ยังสามารถใช้วิธีการทางสถิติที่คล้ายกันในการให้บริการสร้างคำแนะนำส่วนบุคคลสำหรับผลิตภัณฑ์ใหม่สำหรับลูกค้าของเราอีกด้วย
วิธีการประเมินดังกล่าวสามารถรับข้อมูลอินพุตได้หลากหลาย และเมื่อถึงจุดหนึ่ง เราก็สามารถเพิ่มพารามิเตอร์ใหม่ลงในอินพุตได้ ซึ่งจะขึ้นอยู่กับผลการวิเคราะห์ข้อมูลในอดีต จะเพิ่มอัตราการแปลงของการใช้บริการ
เรามีข้อมูลมากมายเกี่ยวกับความสัมพันธ์กับลูกค้า และปริมาณของข้อมูลนี้ก็เพิ่มขึ้นอย่างต่อเนื่อง เพื่อให้การให้คะแนนได้ผล การประมวลผลข้อมูลยังจำเป็นต้องมีกฎ (หรือแบบจำลองทางคณิตศาสตร์) ที่ช่วยให้คุณตัดสินใจได้อย่างรวดเร็วว่าใครจะอนุมัติใบสมัคร ใครจะปฏิเสธ และใครจะเสนอผลิตภัณฑ์เพิ่มเติมสองสามรายการ เพื่อประเมินความสนใจที่อาจเกิดขึ้น
สำหรับงานปัจจุบัน เราใช้ระบบการตัดสินใจแบบพิเศษอยู่แล้ว ซึ่งตามกฎที่กำหนดโดยนักวิเคราะห์ นักเทคโนโลยี และนักพัฒนา จะตัดสินใจว่าจะอนุมัติหรือปฏิเสธผลิตภัณฑ์ด้านการธนาคารบางอย่างให้กับลูกค้า
มีโซลูชันสำเร็จรูปมากมายในตลาด ทั้งแบบจำลองการให้คะแนนและระบบการตัดสินใจในตัวมันเอง เราใช้หนึ่งในระบบเหล่านี้ในบริษัทของเรา แต่ธุรกิจกำลังเติบโต มีความหลากหลาย ทั้งจำนวนลูกค้าและจำนวนผลิตภัณฑ์ที่นำเสนอเพิ่มขึ้น และด้วยเหตุนี้ จึงมีแนวคิดเกี่ยวกับวิธีการปรับปรุงกระบวนการตัดสินใจที่มีอยู่ แน่นอนว่าคนที่ทำงานกับระบบที่มีอยู่มีแนวคิดมากมายในการทำให้ง่ายขึ้น ดีขึ้น สะดวกยิ่งขึ้น แต่บางครั้งแนวคิดจากภายนอกก็มีประโยชน์ New Hackathon จัดขึ้นโดยมีวัตถุประสงค์เพื่อรวบรวมแนวคิดที่เป็นประโยชน์
งาน
Hackathon จัดขึ้นเมื่อวันที่ 23 กุมภาพันธ์ ผู้เข้าร่วมได้รับมอบหมายภารกิจการต่อสู้: เพื่อพัฒนาระบบการตัดสินใจที่ต้องตรงตามเงื่อนไขหลายประการ
เราได้รับแจ้งว่าระบบที่มีอยู่ทำงานอย่างไร และมีปัญหาใดเกิดขึ้นระหว่างการดำเนินงาน รวมถึงเป้าหมายทางธุรกิจที่แพลตฟอร์มที่พัฒนาขึ้นควรดำเนินการ ระบบจะต้องมีเวลาออกสู่ตลาดที่รวดเร็วสำหรับการพัฒนากฎเพื่อให้รหัสการทำงานของนักวิเคราะห์ได้รับการผลิตโดยเร็วที่สุด และสำหรับกระแสการสมัครที่เข้ามา เวลาในการตัดสินใจควรมีแนวโน้มน้อยที่สุด นอกจากนี้ ระบบที่กำลังพัฒนาจะต้องมีความสามารถในการขายต่อเนื่อง เพื่อให้ลูกค้ามีโอกาสซื้อผลิตภัณฑ์อื่นๆ ของบริษัท หากได้รับการอนุมัติจากเราและมีความสนใจจากลูกค้า
เห็นได้ชัดว่าเป็นไปไม่ได้ที่จะเขียนโปรเจ็กต์ที่พร้อมเผยแพร่ในชั่วข้ามคืนซึ่งจะเข้าสู่การผลิตอย่างแน่นอน และเป็นการยากที่จะครอบคลุมทั้งระบบ ดังนั้นเราจึงถูกขอให้ดำเนินการอย่างน้อยบางส่วน มีการกำหนดข้อกำหนดจำนวนหนึ่งว่าต้นแบบต้องเป็นไปตามนั้น เป็นไปได้ที่จะพยายามให้ครอบคลุมข้อกำหนดทั้งหมดอย่างครบถ้วน และทำงานโดยละเอียดในแต่ละส่วนของแพลตฟอร์มที่กำลังพัฒนา
ในด้านเทคโนโลยี ผู้เข้าร่วมทุกคนได้รับอิสระในการเลือกอย่างเต็มที่ คุณสามารถใช้แนวคิดและเทคโนโลยีใดก็ได้ เช่น การสตรีมข้อมูล การเรียนรู้ของเครื่อง การจัดหาเหตุการณ์ ข้อมูลขนาดใหญ่ และอื่นๆ
ทางออกของเรา
หลังจากการระดมความคิดเล็กน้อย เราก็ตัดสินใจว่าโซลูชัน FaaS จะเหมาะสมอย่างยิ่งสำหรับการทำงานให้สำเร็จ
สำหรับโซลูชันนี้ จำเป็นต้องค้นหาเฟรมเวิร์ก Serverless ที่เหมาะสมเพื่อใช้กฎของระบบการตัดสินใจที่กำลังพัฒนา เนื่องจาก Tinkoff ใช้ Kubernetes อย่างจริงจังสำหรับการจัดการโครงสร้างพื้นฐาน เราจึงพิจารณาโซลูชันสำเร็จรูปหลายประการตามนั้น ฉันจะบอกคุณเพิ่มเติมเกี่ยวกับเรื่องนี้ในภายหลัง
เพื่อค้นหาวิธีแก้ปัญหาที่มีประสิทธิภาพสูงสุด เราได้พิจารณาผลิตภัณฑ์ที่ได้รับการพัฒนาผ่านสายตาของผู้ใช้ ผู้ใช้หลักของระบบของเราคือนักวิเคราะห์ที่เกี่ยวข้องกับการพัฒนากฎ กฎจะต้องปรับใช้กับเซิร์ฟเวอร์ หรือในกรณีของเรา ปรับใช้ในระบบคลาวด์ เพื่อการตัดสินใจในภายหลัง จากมุมมองของนักวิเคราะห์ ขั้นตอนการทำงานจะเป็นดังนี้:
- นักวิเคราะห์เขียนสคริปต์ กฎ หรือโมเดล ML ตามข้อมูลจากคลังข้อมูล ในฐานะส่วนหนึ่งของแฮ็กกาธอน เราตัดสินใจใช้ Mongodb แต่การเลือกระบบจัดเก็บข้อมูลไม่สำคัญที่นี่
- หลังจากทดสอบกฎที่พัฒนาแล้วเกี่ยวกับข้อมูลประวัติ นักวิเคราะห์จะอัปโหลดโค้ดของเขาไปยังแผงผู้ดูแลระบบ
- เพื่อให้แน่ใจว่าเป็นเวอร์ชัน โค้ดทั้งหมดจะไปที่ที่เก็บ Git
- ผ่านแผงควบคุมของผู้ดูแลระบบ คุณจะสามารถติดตั้งโค้ดในระบบคลาวด์เป็นโมดูล Serverless ที่ทำงานแยกต่างหากได้
ข้อมูลเริ่มต้นจากลูกค้าจะต้องผ่านบริการเสริมข้อมูลพิเศษที่ออกแบบมาเพื่อเพิ่มคุณค่าให้กับคำขอเริ่มต้นด้วยข้อมูลจากคลังสินค้า สิ่งสำคัญคือต้องใช้บริการนี้ในลักษณะที่จะทำงานร่วมกับพื้นที่เก็บข้อมูลเดียว (ซึ่งนักวิเคราะห์ใช้ข้อมูลเมื่อพัฒนากฎ) เพื่อรักษาโครงสร้างข้อมูลที่เป็นหนึ่งเดียว
แม้กระทั่งก่อนแฮ็กกาธอน เราก็ตัดสินใจเลือกเฟรมเวิร์กไร้เซิร์ฟเวอร์ที่เราจะใช้ ปัจจุบันมีเทคโนโลยีมากมายในตลาดที่ใช้แนวทางนี้ โซลูชันที่ได้รับความนิยมมากที่สุดภายในสถาปัตยกรรม Kubernetes ได้แก่ Fission, Open FaaS และ Kubeless มีแม้กระทั่ง .
หลังจากชั่งน้ำหนักข้อดีข้อเสียทั้งหมดแล้ว เราก็เลือก . เฟรมเวิร์กไร้เซิร์ฟเวอร์นี้ค่อนข้างง่ายต่อการจัดการและตรงตามข้อกำหนดของงาน
หากต้องการทำงานกับ Fission คุณต้องเข้าใจแนวคิดพื้นฐานสองประการ: ฟังก์ชันและสภาพแวดล้อม ฟังก์ชั่นคือโค้ดชิ้นหนึ่งที่เขียนด้วยภาษาใดภาษาหนึ่งซึ่งมีสภาพแวดล้อมแบบฟิชชัน รวมถึง Python, JS, Go, JVM และภาษาและเทคโนโลยียอดนิยมอื่น ๆ อีกมากมาย
ฟิชชันยังสามารถทำหน้าที่ที่แบ่งออกเป็นหลายไฟล์ โดยบรรจุไว้ล่วงหน้าในไฟล์เก็บถาวร การทำงานของฟิชชันในคลัสเตอร์ Kubernetes ได้รับการรับประกันโดยพ็อดพิเศษ ซึ่งได้รับการจัดการโดยเฟรมเวิร์กเอง หากต้องการโต้ตอบกับพ็อดคลัสเตอร์ แต่ละฟังก์ชันจะต้องได้รับการกำหนดเส้นทางของตัวเอง และคุณสามารถส่งพารามิเตอร์ GET หรือเนื้อหาคำขอได้ในกรณีของคำขอ POST
ด้วยเหตุนี้ เราจึงวางแผนที่จะได้รับโซลูชันที่จะช่วยให้นักวิเคราะห์ปรับใช้สคริปต์กฎที่พัฒนาแล้วได้โดยไม่ต้องมีส่วนร่วมของวิศวกรและนักพัฒนา แนวทางที่อธิบายไว้ยังช่วยลดความจำเป็นสำหรับนักพัฒนาในการเขียนโค้ดนักวิเคราะห์ใหม่เป็นภาษาอื่น ตัวอย่างเช่น สำหรับระบบการตัดสินใจในปัจจุบันที่เราใช้ เราต้องเขียนกฎในเทคโนโลยีและภาษาที่มีความเชี่ยวชาญสูง ซึ่งมีขอบเขตจำกัดอย่างยิ่ง และยังต้องอาศัยเซิร์ฟเวอร์แอปพลิเคชันอย่างมากอีกด้วย เนื่องจากกฎเกณฑ์ของธนาคารฉบับร่างทั้งหมด ถูกปรับใช้ในสภาพแวดล้อมเดียว ด้วยเหตุนี้ หากต้องการปรับใช้กฎใหม่ จึงจำเป็นต้องเผยแพร่ทั้งระบบ
ในโซลูชันที่เรานำเสนอ ไม่จำเป็นต้องเผยแพร่กฎ เนื่องจากโค้ดสามารถนำไปใช้งานได้อย่างง่ายดายด้วยการคลิกปุ่มเพียงปุ่มเดียว นอกจากนี้ การจัดการโครงสร้างพื้นฐานใน Kubernetes ยังช่วยให้คุณไม่ต้องคำนึงถึงโหลดและการปรับขนาด ปัญหาดังกล่าวได้รับการแก้ไขทันที และการใช้คลังข้อมูลแห่งเดียวช่วยลดความจำเป็นในการเปรียบเทียบข้อมูลแบบเรียลไทม์กับข้อมูลในอดีต ซึ่งช่วยให้การทำงานของนักวิเคราะห์ง่ายขึ้น
สิ่งที่เราได้รับ
ตั้งแต่เรามาถึงงาน Hackathon ด้วยโซลูชั่นสำเร็จรูป (ในจินตนาการของเรา) สิ่งที่เราต้องทำคือแปลงความคิดทั้งหมดของเราให้เป็นบรรทัดของโค้ด
กุญแจสู่ความสำเร็จในงานแฮ็กกาธอนคือการเตรียมการและแผนที่เขียนไว้อย่างดี ดังนั้น สิ่งแรกที่เราทำคือตัดสินใจว่าสถาปัตยกรรมระบบของเราจะประกอบด้วยโมดูลใด และเทคโนโลยีใดที่เราจะใช้
สถาปัตยกรรมของโครงการของเรามีดังนี้:
แผนภาพนี้แสดงจุดเริ่มต้นสองจุด ได้แก่ นักวิเคราะห์ (ผู้ใช้หลักของระบบของเรา) และลูกค้า
กระบวนการทำงานมีโครงสร้างเช่นนี้ นักวิเคราะห์พัฒนาฟังก์ชันกฎและฟังก์ชันเสริมข้อมูลสำหรับโมเดลของเขา จัดเก็บโค้ดของเขาในพื้นที่เก็บข้อมูล Git และปรับใช้โมเดลของเขากับระบบคลาวด์ผ่านแอปพลิเคชันผู้ดูแลระบบ ลองพิจารณาว่าฟังก์ชันที่ปรับใช้จะถูกเรียกใช้และตัดสินใจเกี่ยวกับคำขอที่เข้ามาจากไคลเอนต์อย่างไร:
- ลูกค้ากรอกแบบฟอร์มบนเว็บไซต์และส่งคำขอไปยังผู้ควบคุม แอปพลิเคชันที่ต้องตัดสินใจจะเข้าสู่อินพุตของระบบและบันทึกไว้ในฐานข้อมูลในรูปแบบดั้งเดิม
- ถัดไป คำขอดิบจะถูกส่งไปเพื่อเพิ่มคุณค่า หากจำเป็น คุณสามารถเสริมคำขอเริ่มแรกด้วยข้อมูลทั้งจากบริการภายนอกและจากที่เก็บข้อมูล แบบสอบถามที่ได้รับการเสริมสมรรถนะที่ได้จะถูกจัดเก็บไว้ในฐานข้อมูลด้วย
- มีการเปิดตัวฟังก์ชันนักวิเคราะห์ ซึ่งรับการสืบค้นที่สมบูรณ์เป็นอินพุตและสร้างโซลูชัน ซึ่งจะถูกเขียนไปยังที่จัดเก็บข้อมูลด้วย
เราตัดสินใจใช้ MongoDB เป็นที่จัดเก็บข้อมูลในระบบของเรา เนื่องจากการจัดเก็บข้อมูลเชิงเอกสารในรูปแบบของเอกสาร JSON เนื่องจากบริการเสริมข้อมูล รวมถึงคำขอดั้งเดิม ได้รวบรวมข้อมูลทั้งหมดผ่านตัวควบคุม REST
ดังนั้นเราจึงมีเวลา XNUMX ชั่วโมงในการปรับใช้แพลตฟอร์ม เรากระจายบทบาทได้สำเร็จสมาชิกในทีมแต่ละคนมีความรับผิดชอบของตนเองในโครงการของเรา:
- แผงผู้ดูแลระบบส่วนหน้าสำหรับงานของนักวิเคราะห์ ซึ่งเขาสามารถดาวน์โหลดกฎจากระบบควบคุมเวอร์ชันของสคริปต์ที่เขียนขึ้น เลือกตัวเลือกเพื่อเพิ่มคุณค่าให้กับข้อมูลอินพุต และแก้ไขสคริปต์กฎออนไลน์
- ผู้ดูแลระบบแบ็กเอนด์ รวมถึง REST API สำหรับส่วนหน้าและการผสานรวมกับ VCS
- การตั้งค่าโครงสร้างพื้นฐานใน Google Cloud และพัฒนาบริการเพื่อเพิ่มคุณค่าแหล่งข้อมูล
- โมดูลสำหรับการรวมแอปพลิเคชันผู้ดูแลระบบเข้ากับเฟรมเวิร์กแบบไร้เซิร์ฟเวอร์สำหรับการปรับใช้กฎในภายหลัง
- สคริปต์กฎสำหรับการทดสอบประสิทธิภาพของทั้งระบบและการรวมการวิเคราะห์เกี่ยวกับแอปพลิเคชันขาเข้า (การตัดสินใจ) สำหรับการสาธิตขั้นสุดท้าย
เริ่มกันเลย
ส่วนหน้าของเราเขียนด้วย Angular 7 โดยใช้ Banking UI Kit แผงผู้ดูแลระบบเวอร์ชันสุดท้ายมีลักษณะดังนี้:
เนื่องจากมีเวลาน้อย เราจึงพยายามใช้เฉพาะฟังก์ชันหลักเท่านั้น หากต้องการปรับใช้ฟังก์ชันในคลัสเตอร์ Kubernetes จำเป็นต้องเลือกเหตุการณ์ (บริการที่จำเป็นต้องปรับใช้กฎในระบบคลาวด์) และโค้ดของฟังก์ชันที่ใช้ตรรกะการตัดสินใจ สำหรับการปรับใช้กฎแต่ละครั้งสำหรับบริการที่เลือก เราได้เขียนบันทึกของเหตุการณ์นี้ ในแผงผู้ดูแลระบบ คุณสามารถดูบันทึกของกิจกรรมทั้งหมดได้
โค้ดฟังก์ชันทั้งหมดถูกจัดเก็บไว้ในที่เก็บ Git ระยะไกล ซึ่งต้องตั้งค่าในแผงผู้ดูแลระบบด้วย หากต้องการกำหนดเวอร์ชันของโค้ด ฟังก์ชันทั้งหมดจะถูกจัดเก็บไว้ในสาขาต่างๆ ของพื้นที่เก็บข้อมูล แผงผู้ดูแลระบบยังให้ความสามารถในการปรับเปลี่ยนสคริปต์ที่เขียน ดังนั้นก่อนที่จะปรับใช้ฟังก์ชันกับการผลิต คุณไม่เพียงแต่สามารถตรวจสอบโค้ดที่เขียนเท่านั้น แต่ยังทำการเปลี่ยนแปลงที่จำเป็นอีกด้วย
นอกเหนือจากฟังก์ชันกฎแล้ว เรายังนำความสามารถในการค่อยๆ เพิ่มคุณค่าให้กับข้อมูลต้นฉบับโดยใช้ฟังก์ชันการเพิ่มคุณค่า ซึ่งเป็นโค้ดที่เป็นสคริปต์ที่สามารถไปที่คลังข้อมูล เรียกใช้บริการของบุคคลที่สาม และทำการคำนวณเบื้องต้นได้ . เพื่อสาธิตโซลูชันของเรา เราได้คำนวณราศีของลูกค้าที่ออกจากคำขอ และกำหนดผู้ให้บริการมือถือของเขาโดยใช้บริการ REST ของบริษัทอื่น
แบ็กเอนด์ของแพลตฟอร์มเขียนด้วยภาษา Java และนำไปใช้เป็นแอปพลิเคชัน Spring Boot ในตอนแรกเราวางแผนที่จะใช้ Postgres เพื่อจัดเก็บข้อมูลผู้ดูแลระบบ แต่ในฐานะส่วนหนึ่งของแฮ็กกาธอน เราตัดสินใจจำกัดตัวเองไว้ที่ H2 แบบธรรมดาเพื่อประหยัดเวลา ในส่วนแบ็กเอนด์ มีการผสานรวมกับ Bitbucket เพื่อกำหนดเวอร์ชันของฟังก์ชันเสริมคุณค่าการสืบค้นและสคริปต์กฎ สำหรับการผสานรวมกับที่เก็บ Git ระยะไกล เราใช้ ซึ่งเป็น wrapper ชนิดหนึ่งบนคำสั่ง CLI ซึ่งช่วยให้คุณสามารถดำเนินการคำสั่ง git ใดๆ ได้โดยใช้อินเทอร์เฟซซอฟต์แวร์ที่สะดวกสบาย ดังนั้นเราจึงมีที่เก็บข้อมูลสองแห่งแยกกันสำหรับฟังก์ชันและกฎการตกแต่ง และสคริปต์ทั้งหมดถูกแบ่งออกเป็นไดเร็กทอรี ผ่าน UI คุณสามารถเลือกการคอมมิตล่าสุดของสคริปต์ของสาขาที่ต้องการของที่เก็บได้ เมื่อทำการเปลี่ยนแปลงโค้ดผ่านแผงผู้ดูแลระบบ คอมมิตของโค้ดที่เปลี่ยนแปลงจะถูกสร้างขึ้นในที่เก็บข้อมูลระยะไกล
เพื่อนำแนวคิดของเราไปใช้ เราจำเป็นต้องมีโครงสร้างพื้นฐานที่เหมาะสม เราตัดสินใจปรับใช้คลัสเตอร์ Kubernetes ของเราในระบบคลาวด์ ตัวเลือกของเราคือแพลตฟอร์ม Google Cloud เฟรมเวิร์กแบบไร้เซิร์ฟเวอร์แบบฟิชชันได้รับการติดตั้งบนคลัสเตอร์ Kubernetes ซึ่งเราปรับใช้ใน Gcloud เริ่มแรก บริการเสริมข้อมูลต้นทางถูกนำมาใช้เป็นแอปพลิเคชัน Java ที่แยกต่างหากใน Pod ภายในคลัสเตอร์ k8s แต่หลังจากการสาธิตเบื้องต้นของโครงการของเราในช่วงกลางของแฮ็กกาธอน เราได้รับการแนะนำให้ทำให้บริการ Enrichment มีความยืดหยุ่นมากขึ้น เพื่อให้โอกาสในการเลือกวิธีเพิ่มคุณค่าข้อมูลดิบของแอปพลิเคชันที่เข้ามา และเราไม่มีทางเลือกนอกจากสร้างบริการเสริมสมรรถนะแบบไร้เซิร์ฟเวอร์ด้วย
ในการทำงานกับฟิชชัน เราใช้ Fission CLI ซึ่งต้องติดตั้งไว้บน Kubernetes CLI การปรับใช้ฟังก์ชันต่างๆ ในคลัสเตอร์ k8s นั้นค่อนข้างง่าย คุณเพียงแค่ต้องกำหนดเส้นทางภายในและเข้าสู่ฟังก์ชันเพื่ออนุญาตการรับส่งข้อมูลขาเข้าหากจำเป็นต้องเข้าถึงภายนอกคลัสเตอร์ โดยปกติแล้วการปรับใช้งานหนึ่งฟังก์ชันจะใช้เวลาไม่เกิน 10 วินาที
การนำเสนอโครงการขั้นสุดท้ายและการสรุปผล
เพื่อสาธิตวิธีการทำงานของระบบ เราได้วางแบบฟอร์มง่ายๆ บนเซิร์ฟเวอร์ระยะไกล ซึ่งคุณสามารถส่งใบสมัครผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่งของธนาคารได้ หากต้องการขอ คุณจะต้องกรอกชื่อย่อ วันเกิด และหมายเลขโทรศัพท์
ข้อมูลจากแบบฟอร์มไคลเอนต์ไปที่ตัวควบคุม ซึ่งส่งคำขอสำหรับกฎที่มีอยู่ทั้งหมดพร้อมกัน โดยก่อนหน้านี้ได้เพิ่มข้อมูลตามเงื่อนไขที่ระบุ และบันทึกไว้ในที่จัดเก็บข้อมูลทั่วไป โดยรวมแล้ว เราได้ปรับใช้ฟังก์ชัน 4 ฟังก์ชันที่ใช้ในการตัดสินใจเกี่ยวกับแอปพลิเคชันขาเข้าและบริการเสริมข้อมูล XNUMX รายการ หลังจากส่งใบสมัคร ลูกค้าได้รับการตัดสินใจของเรา:
นอกเหนือจากการปฏิเสธหรือการอนุมัติแล้ว ลูกค้ายังได้รับรายการผลิตภัณฑ์อื่นๆ ซึ่งเป็นคำขอที่เราส่งไปพร้อมกัน นี่คือวิธีที่เราแสดงให้เห็นถึงความเป็นไปได้ของการขายต่อในแพลตฟอร์มของเรา
มีผลิตภัณฑ์ธนาคารปลอมทั้งหมด 3 รายการ:
- เครดิต.
- ของเล่น
- จำนอง.
ในระหว่างการสาธิต เราได้ปรับใช้ฟังก์ชันที่เตรียมไว้และสคริปต์เสริมสำหรับแต่ละบริการ
แต่ละกฎต้องมีชุดข้อมูลอินพุตของตัวเอง ดังนั้น เพื่ออนุมัติการจำนอง เราได้คำนวณราศีของลูกค้าและเชื่อมโยงสิ่งนี้เข้ากับตรรกะของปฏิทินจันทรคติ ในการอนุมัติของเล่น เราได้ตรวจสอบว่าลูกค้ามีอายุถึงเกณฑ์บรรลุนิติภาวะแล้ว และในการออกเงินกู้ เราได้ส่งคำขอไปยังบริการแบบเปิดภายนอกเพื่อพิจารณาผู้ให้บริการโทรศัพท์มือถือ และได้มีการตัดสินใจแล้ว
เราพยายามทำให้การสาธิตของเราน่าสนใจและโต้ตอบได้ ทุกคนสามารถไปที่แบบฟอร์มของเราและตรวจสอบความพร้อมใช้งานของบริการสมมติของเราให้พวกเขาได้ และในตอนท้ายของการนำเสนอ เราได้สาธิตการวิเคราะห์ใบสมัครที่ได้รับ ซึ่งแสดงจำนวนคนที่ใช้บริการของเรา จำนวนการอนุมัติ และการปฏิเสธ
เพื่อรวบรวมการวิเคราะห์ออนไลน์ เราได้ปรับใช้เครื่องมือ BI แบบโอเพ่นซอร์สเพิ่มเติม และขันเข้ากับหน่วยเก็บข้อมูลของเรา Metabase ช่วยให้คุณสร้างหน้าจอพร้อมการวิเคราะห์ข้อมูลที่เราสนใจ คุณเพียงแค่ต้องลงทะเบียนการเชื่อมต่อกับฐานข้อมูล เลือกตาราง (ในกรณีของเราคือการรวบรวมข้อมูลเนื่องจากเราใช้ MongoDB) และระบุฟิลด์ที่เราสนใจ .
เป็นผลให้เราได้ต้นแบบที่ดีของแพลตฟอร์มการตัดสินใจ และในระหว่างการสาธิต ผู้ฟังแต่ละคนสามารถตรวจสอบประสิทธิภาพของแพลตฟอร์มได้ด้วยตนเอง โซลูชันที่น่าสนใจ การสร้างต้นแบบที่เสร็จสมบูรณ์ และการสาธิตที่ประสบความสำเร็จทำให้เราได้รับชัยชนะ แม้ว่าจะมีการแข่งขันที่รุนแรงจากทีมอื่นก็ตาม ฉันมั่นใจว่าสามารถเขียนบทความที่น่าสนใจเกี่ยวกับโครงการของแต่ละทีมได้
ที่มา: will.com