Bắt đầu từ năm ngoái, công ty chúng tôi bắt đầu tổ chức hackathons. Cuộc thi đầu tiên như vậy đã rất thành công, chúng tôi đã viết về nó trong . Hackathon thứ hai diễn ra vào tháng 2019/XNUMX và thành công không kém. Về mục tiêu nắm giữ sau này cách đây không lâu người tổ chức.
Những người tham gia được giao một nhiệm vụ khá thú vị và hoàn toàn tự do lựa chọn nhóm công nghệ để triển khai. Cần phải triển khai một nền tảng ra quyết định để triển khai thuận tiện các chức năng chấm điểm khách hàng có thể hoạt động với luồng ứng dụng nhanh, chịu được tải nặng và bản thân hệ thống có thể dễ dàng mở rộng.
Nhiệm vụ này không hề tầm thường và có thể được giải quyết theo nhiều cách, như chúng tôi đã bị thuyết phục trong quá trình trình diễn phần trình bày cuối cùng về dự án của những người tham gia. Có 6 đội gồm 5 người tại hackathon, tất cả những người tham gia đều có dự án tốt, nhưng nền tảng của chúng tôi hóa ra lại có tính cạnh tranh cao nhất. Chúng tôi có một dự án rất thú vị mà tôi muốn nói đến trong bài viết này.
Giải pháp của chúng tôi là một nền tảng dựa trên kiến trúc Serverless bên trong Kubernetes, giúp giảm thời gian đưa các tính năng mới vào sản xuất. Nó cho phép các nhà phân tích viết mã trong một môi trường thuận tiện cho họ và triển khai nó vào sản xuất mà không cần sự tham gia của các kỹ sư và nhà phát triển.
ghi điểm là gì
Tinkoff.ru, giống như nhiều công ty hiện đại, có tính điểm của khách hàng. Chấm điểm là một hệ thống đánh giá khách hàng dựa trên các phương pháp phân tích dữ liệu thống kê.
Ví dụ: một khách hàng liên hệ với chúng tôi với yêu cầu cấp một khoản vay hoặc mở tài khoản doanh nhân cá nhân với chúng tôi. Nếu chúng tôi dự định cấp cho anh ta một khoản vay thì chúng tôi cần đánh giá khả năng thanh toán của anh ta và nếu tài khoản là một doanh nhân cá nhân thì chúng tôi cần chắc chắn rằng khách hàng sẽ không thực hiện các giao dịch gian lận.
Cơ sở để đưa ra những quyết định như vậy là các mô hình toán học phân tích cả dữ liệu từ chính ứng dụng và dữ liệu từ bộ lưu trữ của chúng tôi. Ngoài việc chấm điểm, các phương pháp thống kê tương tự cũng có thể được sử dụng để tạo ra các đề xuất riêng lẻ về sản phẩm mới cho khách hàng của chúng tôi.
Phương pháp đánh giá như vậy có thể chấp nhận nhiều loại dữ liệu đầu vào. Và tại một thời điểm nào đó, chúng tôi có thể thêm một tham số mới vào đầu vào, dựa trên kết quả phân tích dữ liệu lịch sử, tham số này sẽ làm tăng tỷ lệ chuyển đổi khi sử dụng dịch vụ.
Chúng tôi nắm giữ rất nhiều dữ liệu về mối quan hệ khách hàng và khối lượng thông tin này không ngừng tăng lên. Để tính điểm có hiệu quả, quá trình xử lý dữ liệu cũng yêu cầu các quy tắc (hoặc mô hình toán học) cho phép bạn nhanh chóng quyết định ai sẽ phê duyệt đơn đăng ký, ai từ chối và ai sẽ cung cấp thêm một vài sản phẩm, đánh giá mức độ quan tâm tiềm năng của họ.
Đối với nhiệm vụ hiện tại, chúng tôi đã sử dụng một hệ thống ra quyết định chuyên biệt , dựa trên các quy tắc do các nhà phân tích, nhà công nghệ và nhà phát triển đặt ra, quyết định phê duyệt hay từ chối một sản phẩm ngân hàng cụ thể cho khách hàng.
Có rất nhiều giải pháp làm sẵn trên thị trường, cả mô hình tính điểm và hệ thống ra quyết định. Chúng tôi sử dụng một trong những hệ thống này trong công ty của chúng tôi. Nhưng hoạt động kinh doanh đang phát triển, đa dạng hóa, cả số lượng khách hàng và số lượng sản phẩm được cung cấp đều tăng lên, cùng với đó, các ý tưởng về cách cải thiện quy trình ra quyết định hiện tại đang xuất hiện. Chắc chắn những người làm việc với hệ thống hiện có có nhiều ý tưởng làm sao để nó đơn giản hơn, tốt hơn, tiện lợi hơn nhưng đôi khi những ý tưởng từ bên ngoài lại hữu ích. Cuộc thi Hackathon mới được tổ chức với mục đích thu thập các ý tưởng hợp lý.
Nhiệm vụ
Hackathon được tổ chức vào ngày 23 tháng XNUMX. Những người tham gia được giao một nhiệm vụ chiến đấu: phát triển một hệ thống ra quyết định phải đáp ứng một số điều kiện.
Chúng tôi đã được biết hệ thống hiện tại hoạt động như thế nào và những khó khăn nào phát sinh trong quá trình vận hành cũng như những mục tiêu kinh doanh mà nền tảng phát triển nên theo đuổi. Hệ thống phải có thời gian tiếp thị nhanh để phát triển các quy tắc để mã làm việc của các nhà phân tích được đưa vào sản xuất nhanh nhất có thể. Và đối với luồng ứng dụng đến, thời gian đưa ra quyết định sẽ có xu hướng ở mức tối thiểu. Ngoài ra, hệ thống đang được phát triển phải có khả năng bán kèm để mang đến cho khách hàng cơ hội mua các sản phẩm khác của công ty nếu chúng được chúng tôi chấp thuận và nhận được sự quan tâm tiềm năng từ khách hàng.
Rõ ràng là không thể viết một dự án sẵn sàng phát hành trong một đêm mà chắc chắn sẽ đi vào sản xuất, và khá khó để bao quát toàn bộ hệ thống, vì vậy chúng tôi được yêu cầu thực hiện ít nhất một phần của nó. Một số yêu cầu được đặt ra mà nguyên mẫu phải đáp ứng. Có thể thử cả hai để đáp ứng toàn bộ các yêu cầu và làm việc chi tiết trên từng phần riêng lẻ của nền tảng đang được phát triển.
Về công nghệ, tất cả những người tham gia đều được hoàn toàn tự do lựa chọn. Có thể sử dụng bất kỳ khái niệm và công nghệ nào: Truyền dữ liệu, học máy, tìm nguồn cung ứng sự kiện, dữ liệu lớn và những thứ khác.
Quyết định của chúng tôi
Sau một hồi suy nghĩ, chúng tôi quyết định rằng giải pháp FaaS sẽ là giải pháp lý tưởng để hoàn thành nhiệm vụ.
Đối với giải pháp này, cần phải tìm một Serverless framework phù hợp để triển khai các quy tắc của hệ thống ra quyết định đang được phát triển. Vì Tinkoff tích cực sử dụng Kubernetes để quản lý cơ sở hạ tầng nên chúng tôi đã xem xét một số giải pháp làm sẵn dựa trên Kubernetes; tôi sẽ cho bạn biết thêm về nó sau.
Để tìm ra giải pháp hiệu quả nhất, chúng tôi xem xét sản phẩm đang được phát triển dưới góc nhìn của người dùng. Người dùng chính của hệ thống của chúng tôi là các nhà phân tích tham gia vào việc phát triển quy tắc. Các quy tắc phải được triển khai trên máy chủ hoặc như trong trường hợp của chúng tôi, được triển khai trên đám mây để đưa ra quyết định tiếp theo. Từ góc độ của một nhà phân tích, quy trình làm việc trông như thế này:
- Nhà phân tích viết tập lệnh, quy tắc hoặc mô hình ML dựa trên dữ liệu từ kho. Là một phần của hackathon, chúng tôi quyết định sử dụng Mongodb, nhưng việc lựa chọn hệ thống lưu trữ dữ liệu ở đây không quan trọng.
- Sau khi kiểm tra các quy tắc đã phát triển về dữ liệu lịch sử, nhà phân tích sẽ tải mã của mình lên bảng quản trị.
- Để đảm bảo phiên bản, tất cả mã sẽ được chuyển đến kho Git.
- Thông qua bảng quản trị, có thể triển khai mã trên đám mây dưới dạng một mô-đun Serverless chức năng riêng biệt.
Dữ liệu ban đầu từ khách hàng phải chuyển qua dịch vụ Làm giàu chuyên dụng được thiết kế để làm phong phú thêm yêu cầu ban đầu bằng dữ liệu từ kho. Điều quan trọng là phải triển khai dịch vụ này theo cách nó có thể hoạt động với một kho lưu trữ duy nhất (từ đó nhà phân tích lấy dữ liệu khi phát triển các quy tắc) để duy trì cấu trúc dữ liệu thống nhất.
Ngay cả trước cuộc thi hackathon, chúng tôi đã quyết định về khung Serverless mà chúng tôi sẽ sử dụng. Hiện nay trên thị trường có khá nhiều công nghệ áp dụng phương pháp này. Các giải pháp phổ biến nhất trong kiến trúc Kubernetes là Fission, Open FaaS và Kubless. Thậm chí có .
Sau khi cân nhắc tất cả những ưu và nhược điểm, chúng tôi đã chọn . Serverless framework này khá dễ quản lý và đáp ứng được yêu cầu của tác vụ.
Để làm việc với Fission, bạn cần hiểu hai khái niệm cơ bản: chức năng và môi trường. Hàm là một đoạn mã được viết bằng một trong các ngôn ngữ có môi trường Phân hạch. bao gồm Python, JS, Go, JVM và nhiều ngôn ngữ và công nghệ phổ biến khác.
Phân hạch cũng có khả năng thực hiện các chức năng được chia thành nhiều tệp, được đóng gói sẵn vào kho lưu trữ. Hoạt động của Fission trong cụm Kubernetes được đảm bảo bởi các nhóm chuyên dụng do chính khung quản lý. Để tương tác với các nhóm cụm, mỗi chức năng phải được chỉ định tuyến đường riêng và bạn có thể chuyển tham số GET hoặc nội dung yêu cầu trong trường hợp yêu cầu POST.
Do đó, chúng tôi đã lên kế hoạch đạt được giải pháp cho phép các nhà phân tích triển khai các tập lệnh quy tắc đã phát triển mà không cần sự tham gia của các kỹ sư và nhà phát triển. Cách tiếp cận được mô tả cũng loại bỏ nhu cầu các nhà phát triển phải viết lại mã phân tích sang ngôn ngữ khác. Ví dụ: đối với hệ thống ra quyết định hiện tại mà chúng tôi sử dụng, chúng tôi phải viết các quy tắc bằng các công nghệ và ngôn ngữ chuyên môn cao, phạm vi của chúng cực kỳ hạn chế và cũng phụ thuộc rất nhiều vào máy chủ ứng dụng, vì tất cả các quy tắc ngân hàng dự thảo đều được triển khai trong một môi trường duy nhất. Do đó, để triển khai các quy tắc mới cần phải phát hành toàn bộ hệ thống.
Trong giải pháp được đề xuất của chúng tôi, không cần phải đưa ra các quy tắc; mã có thể được triển khai dễ dàng chỉ bằng một nút bấm. Ngoài ra, quản lý cơ sở hạ tầng trong Kubernetes cho phép bạn không phải suy nghĩ về tải và mở rộng quy mô; những vấn đề như vậy sẽ được giải quyết ngay lập tức. Và việc sử dụng một kho dữ liệu duy nhất sẽ loại bỏ nhu cầu so sánh dữ liệu thời gian thực với dữ liệu lịch sử, giúp đơn giản hóa công việc của nhà phân tích.
Những gì chúng tôi có
Vì chúng tôi đến với hackathon với một giải pháp có sẵn (trong tưởng tượng của chúng tôi), tất cả những gì chúng tôi phải làm là chuyển tất cả suy nghĩ của mình thành dòng mã.
Chìa khóa thành công ở bất kỳ cuộc thi hackathon nào là sự chuẩn bị và một kế hoạch được viết tốt. Do đó, điều đầu tiên chúng tôi làm là quyết định kiến trúc hệ thống của chúng tôi sẽ bao gồm những mô-đun nào và chúng tôi sẽ sử dụng những công nghệ nào.
Kiến trúc của dự án của chúng tôi như sau:
Sơ đồ này hiển thị hai điểm vào, nhà phân tích (người dùng chính trong hệ thống của chúng tôi) và khách hàng.
Quá trình làm việc được cấu trúc như thế này. Nhà phân tích phát triển chức năng quy tắc và chức năng làm giàu dữ liệu cho mô hình của mình, lưu trữ mã của mình trong kho lưu trữ Git và triển khai mô hình của mình lên đám mây thông qua ứng dụng quản trị viên. Hãy xem xét cách gọi hàm đã triển khai và đưa ra quyết định đối với các yêu cầu đến từ khách hàng:
- Khách hàng điền vào biểu mẫu trên trang web và gửi yêu cầu của mình đến bộ điều khiển. Một ứng dụng cần đưa ra quyết định sẽ được nhập vào hệ thống và được ghi vào cơ sở dữ liệu ở dạng ban đầu.
- Tiếp theo, yêu cầu thô sẽ được gửi để làm giàu, nếu cần. Bạn có thể bổ sung yêu cầu ban đầu bằng dữ liệu từ cả dịch vụ bên ngoài và từ bộ lưu trữ. Truy vấn được bổ sung chi tiết kết quả cũng được lưu trữ trong cơ sở dữ liệu.
- Hàm phân tích được khởi chạy, hàm này lấy truy vấn được bổ sung chi tiết làm đầu vào và tạo ra giải pháp, giải pháp này cũng được ghi vào bộ lưu trữ.
Chúng tôi đã quyết định sử dụng MongoDB làm nơi lưu trữ trong hệ thống của mình do lưu trữ dữ liệu theo định hướng tài liệu dưới dạng tài liệu JSON, vì các dịch vụ làm phong phú, bao gồm cả yêu cầu ban đầu, đã tổng hợp tất cả dữ liệu thông qua bộ điều khiển REST.
Vì vậy, chúng tôi có XNUMX giờ để triển khai nền tảng này. Chúng tôi đã phân bổ các vai trò khá thành công, mỗi thành viên trong nhóm có trách nhiệm riêng trong dự án của chúng tôi:
- Bảng quản trị giao diện người dùng dành cho công việc của nhà phân tích, qua đó anh ta có thể tải xuống các quy tắc từ hệ thống kiểm soát phiên bản của các tập lệnh đã viết, chọn các tùy chọn để làm phong phú dữ liệu đầu vào và chỉnh sửa các tập lệnh quy tắc trực tuyến.
- Quản trị viên phụ trợ, bao gồm API REST cho mặt trước và tích hợp với VCS.
- Thiết lập cơ sở hạ tầng trong Google Cloud và phát triển dịch vụ làm phong phú dữ liệu nguồn.
- Một mô-đun để tích hợp ứng dụng quản trị viên với khung Serverless để triển khai các quy tắc tiếp theo.
- Tập lệnh quy tắc để kiểm tra hiệu suất của toàn bộ hệ thống và tổng hợp phân tích trên các ứng dụng sắp tới (các quyết định được đưa ra) cho lần trình diễn cuối cùng.
Hãy bắt đầu theo thứ tự.
Giao diện người dùng của chúng tôi được viết bằng Angular 7 bằng Bộ giao diện người dùng ngân hàng. Phiên bản cuối cùng của bảng quản trị trông như thế này:
Vì có ít thời gian nên chúng tôi cố gắng chỉ triển khai chức năng chính. Để triển khai một hàm trong cụm Kubernetes, cần phải chọn một sự kiện (một dịch vụ mà quy tắc cần được triển khai trên đám mây) và mã của hàm thực hiện logic ra quyết định. Đối với mỗi lần triển khai quy tắc cho dịch vụ đã chọn, chúng tôi đã viết nhật ký về sự kiện này. Trong bảng quản trị, bạn có thể xem nhật ký của tất cả các sự kiện.
Tất cả mã chức năng được lưu trữ trong kho Git từ xa, kho lưu trữ này cũng phải được đặt trong bảng quản trị. Để phiên bản mã, tất cả các chức năng được lưu trữ trong các nhánh khác nhau của kho lưu trữ. Bảng quản trị cũng cung cấp khả năng điều chỉnh các tập lệnh đã viết, để trước khi triển khai một chức năng vào sản xuất, bạn không chỉ có thể kiểm tra mã đã viết mà còn thực hiện các thay đổi cần thiết.
Ngoài các chức năng quy tắc, chúng tôi cũng triển khai khả năng làm phong phú dần dữ liệu nguồn bằng cách sử dụng các chức năng Làm giàu, mã của nó cũng là các tập lệnh trong đó có thể truy cập kho dữ liệu, gọi các dịch vụ của bên thứ ba và thực hiện các tính toán sơ bộ . Để chứng minh giải pháp của mình, chúng tôi đã tính toán cung hoàng đạo của khách hàng đã để lại yêu cầu và xác định nhà cung cấp dịch vụ di động của mình bằng dịch vụ REST của bên thứ ba.
Phần phụ trợ của nền tảng được viết bằng Java và được triển khai dưới dạng ứng dụng Spring Boot. Ban đầu, chúng tôi dự định sử dụng Postgres để lưu trữ dữ liệu quản trị viên, nhưng, như một phần của hackathon, chúng tôi quyết định giới hạn ở một H2 đơn giản để tiết kiệm thời gian. Ở phần phụ trợ, việc tích hợp với Bitbucket đã được triển khai để phiên bản các hàm làm giàu truy vấn và tập lệnh quy tắc. Để tích hợp với kho Git từ xa, chúng tôi đã sử dụng , là một loại trình bao bọc các lệnh CLI, cho phép bạn thực hiện bất kỳ lệnh git nào bằng giao diện phần mềm tiện lợi. Vì vậy, chúng tôi có hai kho lưu trữ riêng biệt dành cho các chức năng và quy tắc bổ sung, đồng thời tất cả các tập lệnh được chia thành các thư mục. Thông qua giao diện người dùng, có thể chọn cam kết mới nhất của tập lệnh của một nhánh tùy ý của kho lưu trữ. Khi thực hiện thay đổi mã thông qua bảng quản trị, các cam kết của mã đã thay đổi đã được tạo trong kho lưu trữ từ xa.
Để thực hiện ý tưởng của mình, chúng tôi cần có cơ sở hạ tầng phù hợp. Chúng tôi quyết định triển khai cụm Kubernetes trên đám mây. Lựa chọn của chúng tôi là Google Cloud Platform. Khung không máy chủ phân hạch đã được cài đặt trên cụm Kubernetes mà chúng tôi đã triển khai trong Gcloud. Ban đầu, dịch vụ làm giàu dữ liệu nguồn được triển khai dưới dạng một ứng dụng Java riêng biệt được gói trong một Pod bên trong cụm k8s. Nhưng sau khi trình diễn sơ bộ dự án của chúng tôi ở giữa cuộc thi hackathon, chúng tôi đã đề xuất làm cho dịch vụ Làm giàu linh hoạt hơn để tạo cơ hội chọn cách làm phong phú dữ liệu thô của các ứng dụng sắp tới. Và chúng tôi không có lựa chọn nào khác ngoài việc biến dịch vụ làm giàu này thành Serverless.
Để làm việc với Fission, chúng tôi đã sử dụng Fission CLI, phải được cài đặt bên trên Kubernetes CLI. Việc triển khai các chức năng vào cụm k8s khá đơn giản; bạn chỉ cần chỉ định một tuyến nội bộ và xâm nhập vào chức năng để cho phép lưu lượng truy cập đến nếu cần truy cập bên ngoài cụm. Triển khai một chức năng thường mất không quá 10 giây.
Trình bày cuối cùng và tổng kết dự án
Để chứng minh cách hệ thống của chúng tôi hoạt động, chúng tôi đã đặt một biểu mẫu đơn giản trên máy chủ từ xa nơi bạn có thể gửi đơn đăng ký một trong các sản phẩm của ngân hàng. Để yêu cầu, bạn phải nhập tên viết tắt, ngày sinh và số điện thoại của mình.
Dữ liệu từ biểu mẫu khách hàng được chuyển đến bộ điều khiển, bộ điều khiển này đồng thời gửi yêu cầu cho tất cả các quy tắc có sẵn, trước đó đã làm phong phú dữ liệu theo các điều kiện đã chỉ định và lưu chúng vào bộ lưu trữ chung. Tổng cộng, chúng tôi đã triển khai ba chức năng đưa ra quyết định về các ứng dụng sắp đến và 4 dịch vụ làm giàu dữ liệu. Sau khi nộp đơn, khách hàng nhận được quyết định của chúng tôi:
Ngoài việc từ chối hoặc chấp thuận, khách hàng còn nhận được danh sách các sản phẩm, yêu cầu khác mà chúng tôi đã gửi song song. Đây là cách chúng tôi chứng minh khả năng bán kèm trên nền tảng của mình.
Có tổng cộng 3 sản phẩm ngân hàng hư cấu có sẵn:
- Tín dụng.
- Đồ chơi
- Thế chấp.
Trong quá trình trình diễn, chúng tôi đã triển khai các chức năng đã chuẩn bị sẵn và các tập lệnh bổ sung cho từng dịch vụ.
Mỗi quy tắc yêu cầu bộ dữ liệu đầu vào riêng. Vì vậy, để phê duyệt khoản thế chấp, chúng tôi đã tính toán cung hoàng đạo của khách hàng và kết nối điều này với logic của âm lịch. Để phê duyệt một món đồ chơi, chúng tôi đã kiểm tra xem khách hàng đã đến tuổi thành niên chưa và để cấp một khoản vay, chúng tôi đã gửi yêu cầu đến một dịch vụ mở bên ngoài để xác định nhà điều hành di động và quyết định đã được đưa ra.
Chúng tôi đã cố gắng làm cho cuộc trình diễn của mình trở nên thú vị và mang tính tương tác, mọi người có mặt đều có thể truy cập biểu mẫu của chúng tôi và kiểm tra tính khả dụng của các dịch vụ hư cấu của chúng tôi dành cho họ. Và ở phần cuối của bài thuyết trình, chúng tôi đã trình bày phân tích về các đơn đăng ký đã nhận, trong đó cho thấy có bao nhiêu người đã sử dụng dịch vụ của chúng tôi, số lượng phê duyệt và từ chối.
Để thu thập số liệu phân tích trực tuyến, chúng tôi đã triển khai thêm công cụ BI nguồn mở và vặn nó vào bộ phận lưu trữ của chúng tôi. Metabase cho phép bạn xây dựng màn hình với các phân tích về dữ liệu mà chúng tôi quan tâm; bạn chỉ cần đăng ký kết nối với cơ sở dữ liệu, chọn bảng (trong trường hợp của chúng tôi là bộ sưu tập dữ liệu, vì chúng tôi đã sử dụng MongoDB) và chỉ định các trường mà chúng tôi quan tâm .
Kết quả là chúng tôi đã có được một nguyên mẫu tốt của nền tảng ra quyết định và trong quá trình trình diễn, mỗi người nghe có thể tự mình kiểm tra hiệu suất của nó. Một giải pháp thú vị, một nguyên mẫu đã hoàn thiện và một màn trình diễn thành công đã giúp chúng tôi giành chiến thắng, bất chấp sự cạnh tranh gay gắt từ các đội khác. Tôi chắc chắn rằng một bài báo thú vị cũng có thể được viết về dự án của mỗi nhóm.
Nguồn: www.habr.com