Go. Exchange یک تبادل رمزنگاری با هدف داشتن یک بستر امن و پایدار است. با این حال ، به دلیل تنظیم فشرده در منطقه رمزنگاری. متأسفانه ، Go. Exchange در 15 مارس 2020 بسته شد.

من تقریباً 2 سال در Go. Exchange به عنوان یک توسعه دهنده کار کردم و از ابتدا ساخت محصول را شروع کردم. ما Elixir را به عنوان یک زبان برنامه نویسی اتخاذ می کنیم و از آن در تولید استفاده می کنیم. دلیل انتخاب Elixir به دلیل داشتن یک مدل همزمانی خوب ، عملکرد بسیار خوب ، نحو خوب و قابل خواندن است.

من فکر می کنم برای به اشتراک گذاشتن موارد فنی که در این سفر با خودم و همچنین همراه با تیم آموخته ام ، به اشتراک می گذارم.

فرآیندهای اکسیر

فرآیندهای اکسیر بسیار مفید هستند و بهره وری ما را افزایش می دهند. فرآیندهای اکسیر به 2 دلیل در بخش های اصلی بازی شده است.

به عنوان یک کار دوره ایکتابخانه های منبع باز زیادی وجود دارد. به عنوان مثال: کوانتومی ، محبوب ترین. با این حال ، ما تصمیم گرفتیم که توسط خودمان پیاده سازی کنیم که برای موارد استفاده ما مناسب تر است. این یک تصمیم خوب بود که در حال حاضر ما انعطاف پذیری زیادی برای رسیدگی به بسیاری از موارد استفاده را بر اساس نیازهای تجاری داریم.

به عنوان یک کنترل قوام ، به منظور جلوگیری از هزینه های مضاعف و شرایط مسابقه در مبادله. این یک رفتار فرایند/صندوق پستی را در اکسیر اعمال می کند. مکانیزم صندوق پستی ارائه شده از نبرد است که ما را بسیار مطمئن می کند. ما از فرآیندهای بسیار زیادی در زیر منطق اصلی تجارت در داخل ماژول موتور تطبیق استفاده می کنیم ، که ماژولی است که سفارشات خرید و فروش ورودی را انجام می دهد. هنگامی که قیمت بین خرید و فروش با هم مطابقت دارد. این سفارشات به عنوان تجارت اجرا می شوند. منطق موتور تطبیق مانند مطابق با سفارشات محدودیت ، سفارشات بازار یا سفارشات لغو. چالش این است که چگونه فرایندهایی را برای همکاری با هم طراحی کنیم. روش های زیادی برای انجام این کار با جوانب مثبت و منفی وجود دارد. به عنوان مثال: ما می توانیم فقط در هر موتور تطبیق یک فرآیند را طراحی کنیم. این تضمین می کند که هر سفارش به ترتیب انجام می شود ، بدون هزینه مضاعف در حالی که می توانیم کد را ساده نگه داریم. با این حال ، این می تواند باعث ایجاد تنگنا بزرگی در برنامه شود. ما می توانیم فرایندهای بیشتری مانند هر جفت معاملاتی یا در هر سطح قیمت را ارائه دهیم.(سطح قیمت چیست؟ اگر می خواهید اطلاعات بیشتری کسب کنید ، می توانید این صحبت را بررسی کنید) این باعث کاهش تنگناها می شود اما پیچیدگی بیشتری را به کد و نکات بیشتر از خرابی معرفی می کند. پردازش دسته ای و فشار کمر نیز می تواند معرفی شود. آن ایده ای که من ذکر کردم فقط نمونه هایی هستند. روشهای خلاقانه زیادی وجود دارد که می توانیم با فرآیندهای اکسیر انجام دهیم. و تصمیم طراحی ممکن است به عوامل زیادی مانند رفتار تجارت کاربران ، تجربه کاربر یا نیازهای تجاری بستگی داشته باشد.

استفاده از یک فرآیند برای رسیدگی به سفارشات ورودی. این ممکن است باعث تنگنا در موتور تطبیق شود.

استفاده از چندین فرآیند برای رسیدگی به سفارشات ورودی بر اساس سطح جفت و قیمت. این باعث کاهش تنگنا خواهد شد. اما پایگاه کد می تواند بسیار پیچیده باشد

ما زمان زیادی را برای بهبود تنگنا صرف کردیم. و روش مؤثر برای یافتن تنگنا ، تحقیق در مورد رفتار واقعی تجارت از طرف کاربران بود. با ساخت مبادله ، ما در مورد عملکرد بسیار جدی بودیم. با این حال ، در همان زمان ما باید تعادل بین عملکرد و نه بیش از مهندسی را حفظ کنیم. کار آسانی نیست. لحظه ای بود که ما باید تیم را تقسیم کنیم تا به پیشرفت مداوم در تنگناها و مناطق عملکرد اختصاص دهیم.

استفاده از این فرآیند به برخی از منحنی های یادگیری نیاز دارد. همچنین ، این می تواند باعث رفتارهای غیر منتظره هنگام تصادف شود. حتی ما همیشه در مورد "اجازه می دهد سقوط کند" در ذهن خود نگه می داریم ، همیشه موارد لبه ای وجود دارد که باعث سردرد ما می شود. در یک وضعیت جدی ، می تواند کل برنامه را پایین بیاورد.

زمینه چارچوب ققنوس

زمینه ققنوس برای من بسیار گیج کننده است و همیشه هستم. درست کردن آن در وهله اول دشوار است و برای درست کردن آن نیاز به اصلاح مجدد دارد. یکی از خدمات میکروسنجی ما ، ما زمینه را در ساختار برنامه حذف کردیم و این کمک کرد زیرا لازم نیست وقت خود را صرف فکر کردن در مورد آن کنیم. حتی در آینده می توانم ببینم که باید آن را معرفی کنیم. اما من فکر می کنم معرفی زمینه در مرحله دوم ساده تر از معرفی آن در وهله اول است که ما درک خوبی در مورد دامنه خود داشته باشیم.

حسابی اعشاری دقیق دلخواه

مبادله باید با تعداد با دقت طولانی مقابله کند. به عنوان مثال 0. 0000000001eth. ما فقط نمی توانیم از نوع اصلی شناور در اکسیر استفاده کنیم زیرا نمی تواند تعداد دقیق دقت را محاسبه کند. من مدت طولانی در دنیای یاقوت بودم که Bigdecimal یا Gem Money بسیار مفید است. در اکسیر ، ما از کتابخانه اعشاری برای مقابله با مکان های اعشاری استفاده می کنیم. به اندازه روبی ساده نیست. مفهومی از زمینه معرفی شده وجود دارد که باعث می شود کد در بعضی از مواقع کمی پیچیده تر شود.

آزمایش کردن

تست واحد: در ابتدا از MOX استفاده شد. حتی جامعه Elixir آن را دوست دارد ، من شخصاً احساس نمی کنم که تولید کننده باشد و محدودیت هایی وجود دارد. به عنوان مثال: همه توابع که به راحتی به آنها تزریق می شود ، آسان نیست. به نظر نمی رسد هنگام عبور از پارامترهای وابستگی به اطراف ، خواندن کد آسان باشد. پس از مدتی تصمیم گرفتیم که به تقلید تغییر کنیم. زندگی ما بهتر است. MIMIC کتابخانه تست بسیار هوشمند است. آنچه من در مورد MIMIC دوست دارم این است: 1) ما فقط نمی توانیم با رفتار تصادفی/ناشناخته مسخره کنیم. رفتارها باید وجود داشته باشد. 2) با تزریق وابستگی کمتر ، پایگاه کد بسیار تمیزتر است. 3) TDD آسان تر است

آزمون قرارداد: آزمایش همکاری بین خدمات در دنیای میکروسرویس آسان نیست. آزمایش قرارداد محور مصرف کننده یکی از تکنیک های تست است که به شما کمک زیادی می کند. PACT یکی از چارچوبی است که در بسیاری از زبان های برنامه نویسی مانند Ruby ، JavaScript ، Go موجود است. متأسفانه ، برای اکسیر هنوز در مرحله قبل از آلفا است.(pact_elixir) چه حیف!

تست درخواست: ما از آن برای آزمایش درخواست های API به عنوان سطح بالاتر از آزمون کنترل کننده استفاده می کنیم. این با ققنوس پیش فرض نیست. ما فقط آن را تنظیم کردیم. آزمون درخواست به ما امکان می دهد تا روی پارامتر درخواست ، مسیر مسیر و پاسخ تمرکز کنیم و اجازه دهید تست های کنترلر و سایر تست های واحد بقیه را کنترل کنند. در سطح تست های درخواست ، واقعاً با تولید اسناد API خوب کار می کند. ما همچنین از بوروکرات برای تولید سند استفاده کردیم. بوروکرات توضیحات آزمون ، پارامترهای درخواست ، پاسخ و نقشه را به سند API می برد. ما لازم نیست که اسناد API خود را حفظ کنیم ، فقط باید هنگام انجام آزمایشات آن را تولید کنیم. واقعاً مفید استما همچنین می توانیم قالب خروجی مانند API Blueprint ، OpenAPI Spec ، Markdown و ETC را تنظیم کنیم.

برنامه های چتر

ما از یک برنامه شروع کردیم و چه زمانی بزرگ شد. ما سعی داشتیم آن را به برنامه های چتر تقسیم کنیم. نکته خوب در مورد برنامه های چتر این است که می توانیم ببینیم که جفت دامنه در برنامه ما چقدر است. این تیم هنگام جستجوی کد ، مجازی خوبی خواهد داشت تا در مورد راه حل های جداشدگی بحث کند. سپس می توانیم تصمیم بهتری بگیریم تا بتوانیم به میکروسروس ها برویم یا نه.

با این حال ، همچنین برخی از موضوعات چالش در رابطه با نحوه استقرار هر برنامه چتر به طور جداگانه وجود دارد. به عنوان مثال: چگونه می توانیم تغییراتی را که برنامه های چتر اصلاح شده و به طور خاص مستقر می شوند ، تشخیص دهیم؟چگونه می توانیم اطمینان حاصل کنیم که برنامه چتر با سایر برنامه های چتر سازگار است؟

کتابخانه

Elixir یک زبان جدید است و جامعه در مقایسه با سایر زبانهای برنامه نویسی چندان بزرگ نیست. ما اغلب با موضوعات مربوط به کتابخانه ها روبرو بودیم. مانند خارج از کشور ، با سایر اشکالات سازگار نیست. BTW ، من معتقدم وقتی پذیرش اکسیر بیشتری وجود دارد ، بهتر و بهتر می شود. همچنین از برخی از کتابخانه های ارلانگ استفاده کردیم. به عنوان مثال: گلدان ، برای دستیابی به تأیید اعتبار چند عاملی. این واقعاً یکپارچه کار کرد و احساس نمی کرد که من زبان دیگری را در داخل اکسیر نوشتم یا کد را کثیف کردم.

کرکی

ما همچنین چندین کتابخانه اتریوم مانند Ethereumex ، Eth را ارزیابی کردیم. آن کتابخانه ها همانطور که انتظار می رود کار می کنند. با این حال ، ما تصمیم گرفتیم که به دلیل کنترل بهتر کیفیت کد و دلایل امنیتی ، اجرای خودمان را بنویسیم

گسترش

ما به ترتیب از نسخه 1 ، 2 و انتشار مخلوط با استفاده از تقطیر ایجاد کردیم. از آنجا که ، ما تمام تلاش خود را می کنیم تا برنامه 12 فاکتور را دنبال کنیم. یک نسخه باید بتواند در برابر هر محیط ، آزمایش ، مرحله بندی ، تولید اجرا شود. این باعث می شود که ما واقعاً باید از متغیرهای محیط دویدن آگاهی داشته باشیم. ما اشتباهاتی را انجام دادیم که متغیرهای محیط هنگام جمع آوری زمان به جای آن انجام شد. خوشبختانه این مسئله که پیدا کردیم یک مسئله جزئی بود. با این حال ، این می تواند بسیار خطرناک باشد زیرا ما نمی توانیم به راحتی تشخیص دهیم. راه حل ما در حال راه اندازی یک کنوانسیون در تیم ، با استفاده از آنالایزر استاتیک کد ، آزمایش دستی نسخه داخل Docker را برای اطمینان از همه چیز انجام داد.

خوشه ارلانگ در بالای غلاف Kubeetes نیز یک چالش بود. برخی از تنظیمات وجود دارد که تیم بین DevOps و توسعه دهندگان باید بسیار نزدیک کار کنند. من از Peerage برای مدیریت آن استفاده کردم. چرا ما به خوشه نیاز داریم؟در واقع ، اگر برنامه ساده و بدون تابعیت باشد ، به آن احتیاج نداریم. با این حال ، اگر می خواهیم از قدرت فرآیندهای اکسیر استفاده کنیم ، بیشتر اوقات به آن احتیاج خواهیم داشت. یک مثال بارز برنامه ریزی مشاغل در برنامه است. بیایید بگوییم که ما 3 غلاف در حال اجرا هستیم. اگر ما خوشه را تنظیم نکنیم ، تمام غلاف ها همان کار را انجام می دهند. با خوشه ، این 3 غلاف راهی برای برقراری ارتباط بین آنها خواهند داشت تا اطمینان حاصل کنند که تنها 1 روند اجرای کار را انجام می دهد. قضیه کلاه از آنجا که اکنون در مورد سیستم توزیع شده صحبت می کنیم ، اهمیت پیدا می کند.

آخرین موضوع ولی به همان اهمیت

من هنوز معتقدم که پذیرش اکسیر در Go. Exchange یک تصمیم خوب بود. استخدام توسعه دهندگان که تجربه ای در اکسیر دارند بسیار سخت و نادر است. در نتیجه آن ، ما تمایل داشتیم که توسعه دهندگان خوبی را استخدام کنیم و آنها را به جای آن به توسعه دهندگان Elixir تبدیل کنیم. بیش از نیمی از تیم قبل از پیوستن به تیم ، اکسیر را نمی شناسند و با موفقیت JavaScript Devs یا Ruby Devs را به Elixir Devs تبدیل کرد. در واقع ، اکسیر زبان برنامه نویسی خوشبختی است. برخی از ما نمی خواهیم دوباره به روز قدیمی جاوا اسکریپت برگردیم. استراتژی ترید...