اوبر قصد دارد حجم کاری stateful مانند پردازش دستهای، Cassandra، etcd، M3، MySQL و Redis را برای اجرا روی نمونههای Arm بازسازی کند.
این اقدام پس از موفقیت سختکوشانه این شرکت در انتقال 2800 سرویس بدون وضعیت مبتنی بر Go به میزبانهای مبتنی بر Arm در OCI انجام میشود.
همانطور که قبلاً توسط The Stack پوشش داده شد، اوبر اکنون پس از تصمیمگیری به دلایل بهرهوری انرژی و هزینه، برای ساخت Arm و همچنین x86، 400000 ساخت تصویر کانتینری در هفته تولید میکند که نیاز به چند معماری دارند.
اوبر در اولین قسمت از یک سری وبلاگ دو قسمتی در مورد این تغییر، توضیح داد که این حجم کاری را روی نمونههای Oracle Ampere اجرا میکند. این شرکت در دومین وبلاگ خود، جاهطلبیهای مداوم خود را برای گرفتن حجم کاری بسیار بیشتر به صورت چند معماری و همچنین جزئیات مربوط به مهاجرت، که مهندسان آن با تیمهای محصول برای اجرای تستهای بار مصنوعی روی Arm همکاری کردند، فاش کرد.
همچنین ببینید: مایکروسافت کارخانه داده مصنوعی را منتشر میکند
کار انجام شده تا به امروز روی سرویسهای مبتنی بر Go با مشکلاتی روبرو بوده است.
تیم اوبر گفت: "ما با وابستگیهای قدیمی تصویر کانتینری و سایر ناسازگاریهایی که نیاز به رفع شدن در Arm داشتند، مواجه شدیم."
"برخی از مسائل رایجتر شامل تصاویر پایه قدیمی و بستههای منسوخ شده Debian بود. برخی از سرویسها به تصاویر پایه تک معماری قدیمی وابسته بودند. ما اینها را با نسخههای چند معماری بهروزرسانی شده جایگزین کردیم. برخی دیگر به بستههای Debian متکی بودند که هرگز برای Arm ساخته نشده بودند. ما اینها را یکی یکی حل کردیم، و در صورت امکان آنها را بازسازی یا جایگزین کردیم، که بسیار وقتگیر بود."
تیم آن در اواخر فوریه در وبلاگی گفت: "این پاکسازی کار پر زرق و برقی نبود، اما بدون شک ضروری بود. هر تصویر پایه جایگزین شده، هر بسته بازسازی شده و هر وابستگی مرتب شده، ما را به دنیایی نزدیکتر میکرد که ساختهای چند معماری پیشفرض بودند و نه استثنا."
اوبر گفت، سرویسهای Java امسال سرویسهای Go خود را به Arm دنبال خواهند کرد.
"ما همچنین در حال آماده شدن برای مقابله با قلمرو پیچیدهتری هستیم: حجم کاری stateful مانند Redis، etcd، Apache Cassandra و MySQL، و M3، پردازش دستهای و کارهای یادگیری ماشین." بسیاری دیگر نیز تماشا خواهند کرد.
آن یادگیریها را ادامه دهید!