Мы сувязалі аднаструменны C++ з шматструменным Rust

Інтэрфейс аднаструменнага кода C++ з шматструменным Rust не толькі магчымы — гэта адзін з самых практычных спосабаў мадэрнізацыі старых сістэм без поўнага перапісвання. У Mewayz мы вырашылі гэтую задачу, калі маштабавалі нашу бізнес-АС з 207 модуляў для абслугоўвання 138 000 карыстальнікаў, і вынікі карэнным чынам змянілі наша стаўленне да ўзаемадзеяння сістэм.

Чаму вам спатрэбіцца ўзаемадзеянне аднаструменнага C++ з шматструменным Rust?

Большасць прадукцыйных сістэм маюць код C++, правераны гадамі. Перапісванне ўсяго ў Rust гучыць прывабна на паперы, але гэта ўводзіць вялікую рызыку і месяцы інжынернага часу. Прагматычным падыходам з'яўляецца паступовае прыняцце - абгортванне існуючай логікі C++ пры адначасовай разгрузцы цяжкіх працоўных нагрузак з паралелізмам на мадэль уласнасці Rust.

У нашым выпадку асноўныя модулі бізнес-логікі на працягу многіх гадоў надзейна працавалі ў аднаструменным C++. Яны займаліся паслядоўнай апрацоўкай задач, стварэннем дакументаў і фінансавымі разлікамі. Але паколькі наша база карыстальнікаў перавысіла 100 тыс., нам спатрэбілася паралельная апрацоўка даных, адначасовая апрацоўка API і бяспечнае кіраванне агульным станам. Асаблівасці Rust Send і Sync далі нам гарантыі паралелізму падчас кампіляцыі, якія C++ проста не мог прапанаваць без шырокага ручнога аўдыту.

Асноўная матывацыя - зніжэнне рызыкі. Вы захоўваеце тое, што працуе, і дадаяце тое, што маштабуецца, не затрачваючы ўсю кодавую базу на міграцыю, якая можа ніколі не завяршыцца.

Як насамрэч працуе мяжа FFI?

Знешні функцыянальны інтэрфейс (FFI) паміж C++ і Rust працуе праз C-сумяшчальныя сігнатуры функцый. Блокі Rust extern "C" адкрываюць функцыі, якія C++ можа выклікаць непасрэдна, і наадварот. Крытычная праблема ўзнікае, калі шматструменнаму асяроддзю выканання Rust трэба бяспечна выклікаць аднаструменны код C++.

Мы вырашылі гэта з дапамогай спецыяльнай архітэктуры:

• Абмежаваны патокам выканаўца C++: усе выклікі C++ накіроўваюцца праз адзін выдзелены паток з выкарыстаннем канала перадачы паведамленняў, гарантуючы, што інварыянт аднаго патоку ніколі не парушаецца.
• Узровень асінхроннага моста Rust: задачы Tokio адпраўляюць працу выканаўцу C++ і чакаюць вынікі праз аднаразовыя каналы, захоўваючы цалкам асінхронны бок Rust.
• Кіраванне непразрыстым паказальнікам: аб'екты C++ загорнуты ў структуры Rust, якія рэалізуюць Drop для дэтэрмінаванай ачысткі, прадухіляючы ўцечкі памяці праз межы мовы.
• Серыялізацыя на мяжы: складаныя структуры даных серыялізуюцца ў FlatBuffers на ўзроўні FFI, пазбягаючы далікатнага супадзення макета структур і забяспечваючы незалежную эвалюцыю кожнага боку.
• Панічная ізаляцыя: catch_unwind Rust ахоплівае кожную кропку ўваходу FFI, каб паніка ніколі не перасякала моўную мяжу, што было б невызначаным паводзінамі.

Гэты шаблон даў нам прапускную здольнасць шматструменнага Rust з надзейнасцю праверанай логікі C++ — без перапісвання ніводнага радка зыходных бізнес-правілаў.

Якіх падводных камянёў варта пазбягаць?

Самая небяспечная памылка - меркаваць, што код C++ паточна-бяспечны, хаця гэта не так. Глабальны стан, статычныя зменныя і нерээнтрантыўныя выклікі бібліятэк прывядуць да гонак дадзеных, якія кампілятар Rust не можа выявіць праз мяжу FFI. Гарантыі бяспекі Rust спыняюцца на блоку unsafe — за ўсё, што знаходзіцца ўнутры, вы адказваеце.

Асноўнае разуменне: Rust гарантуе бяспеку памяці ў сваім уласным кодзе, але ў той момант, калі вы перасякаеце мяжу FFI у C++, вы атрымліваеце ў спадчыну ўсе праблемы бяспекі патокаў, якія ёсць у C++. Архітэктура вакол гэтай мяжы мае большае значэнне, чым код па абодва бакі ад яе.

Яшчэ адзін распаўсюджаны падводны камень - гэта кіраванне тэрмінам службы. Аб'екты C++ не ўдзельнічаюць у праверцы запазычанняў Rust. Калі Rust выдаляе спасылку, калі C++ усё яшчэ захоўвае паказальнік, вы атрымліваеце памылкі выкарыстання пасля вызвалення, якія вельмі цяжка дыягнаставаць. Мы вырашылі гэтую праблему, прыняўшы строгую семантыку ўласнасці: аб'екты C++ заўсёды належаць роўна адной абалонцы Rust, а агульны доступ ажыццяўляецца праз падлік спасылак на аснове Arc на баку Rust.

З пункту гледжання прадукцыйнасці празмерныя выклікі FFI ствараюць дадатковыя выдаткі з-за пераключэння кантэксту і серыялізацыі. Мы пакетна выконваем аперацыі ўсюды, дзе гэта магчыма, адпраўляючы чаргу рабочых элементаў выканаўцу C++, а не робячы асобныя міжмоўныя выклікі.

Як гэты падыход спрацаваў у вытворчасці?

Пасля разгортвання гібрыднай архітэктуры на нашай платформе мы вымералі канкрэтныя паляпшэнні. Прапускная здольнасць запытаў павялічылася ў 3,4 разы для модуляў, якія раней былі вузкімі месцамі пры паслядоўнай апрацоўцы C++. Затрымка (p99) знізілася на 61%, таму што асінхроннае асяроддзе выканання Rust магло апрацоўваць незалежныя запыты адначасова, у той час як C++ апрацоўваў цяжкія вылічальныя задачы ў сваім спецыяльным патоку.

Што яшчэ больш важна, у нас не было памылак, звязаных з паралелізмам, за першыя шэсць месяцаў вытворчасці. Шаблон абмежавання патокаў зрабіў структурна немагчымым выклік кода C++ з некалькіх патокаў, у той час як сістэма тыпаў Rust прадухіляла гонкі дадзеных на сваім баку мяжы. Гэта было значным паляпшэннем у параўнанні з нашым папярэднім падыходам, калі мы спрабавалі дадаць патокі ў C++ з м'ютэксамі, што прывяло да трох інцыдэнтаў гонкі за адзін квартал.

Каманда інжынераў таксама паведаміла пра больш хуткія цыклы ітэрацыі. Новыя функцыі могуць быць створаны ў Rust з поўнай падтрымкай паралелізму, у той час як існуючыя модулі C++ працягваюць працаваць без змяненняў. Гэтая паэтапная стратэгія азначала, што ў нас ніколі не было міграцыі "вялікага выбуху" з высокай рызыкай - толькі пастаяннае, вымернае паляпшэнне.

Часта задаюць пытанні

Ці можа Rust выклікаць аднаструменныя бібліятэкі C++ без змяненняў?

Так, але вы павінны пераканацца, што ўсе выклікі гэтай бібліятэкі адбываюцца з аднаго патоку. Стандартны шаблон заключаецца ў стварэнні спецыяльнага патоку выканаўцы, які серыялізуе ўсе выклікі C++ праз канал. Асінхронныя задачы Rust адпраўляюць запыты і чакаюць адказаў, не блакуючы шматструменнае асяроддзе выканання. Сам код C++ не патрабуе ніякіх змен — абмежаванне бяспекі выконваецца цалкам на баку Rust.

Ці значныя накладныя выдаткі FFI, каб паўплываць на прадукцыйнасць прыкладання?

Асобныя выклікі FFI маюць мінімальныя накладныя выдаткі — звычайна менш за 10 нанасекунд для простага выкліку функцыі. Аднак серыялізацыя складаных структур даных і сінхранізацыя патокаў на мяжы складаюцца, калі вы робіце тысячы дэталёвых выклікаў. Пакетныя аперацыі і выкарыстанне фарматаў серыялізацыі з нулявым капіраваннем, такіх як FlatBuffers або Cap'n Proto, змяншаюць накладныя выдаткі нават у маштабе.

Ці варта нам перапісаць нашу кодавую базу C++ у Rust замест інтэрфейсу?

Для большасці каманд паступовае ўзаемадзеянне з'яўляецца больш бяспечным і хуткім шляхам. Поўнае перапісванне ўводзіць месяцы інжынерных рызык без ніякай каштоўнасці для карыстальнікаў да завяршэння. Інтэрфейс дазваляе неадкладна пастаўляць паляпшэнні, правяраць падыход Rust у вытворчасці і пераносіць модулі па адным у залежнасці ад таго, дзе паралелізм дае найбольшы эфект. Перапішыце толькі тыя модулі, у якіх кошт падтрымання мяжы FFI перавышае кошт перапісвання.

У Mewayz мы ствараем маштабаваную інфраструктуру — як у тэхнічным, так і ў эксплуатацыйным плане. Наша 207-модульная бізнес-АС дапамагае 138 000 камандам працаваць больш разумна, пачынаючы з 19 долараў у месяц. Незалежна ад таго, кіруеце вы праектамі, аўтаматызуеце аперацыі або маштабуеце свой бізнес, Mewayz адаптуецца да вашага спосабу працы. Пачніце бясплатную пробную версію на app.mewayz.com і паглядзіце, што сучасная бізнес-АС можа зрабіць для вашай каманды.