maani
digital signature
تجربیات بدست اومده
-
اولین سرویس جدی بود که خودم از lagacy جداش کردم
-
برای دریافت امضا نیاز به چندین استپ بود ، باید به کلاینت هام getState میدادم
-
برای ساخت امضا ۵ api داشتیم که یک امضا رو تکمیل میکردن ، برای جلو گیری از خراب کاری باید ترتیب درخواست ها کنترل میشد و قبل هر درخواست checkState میکردم،
-
ما برای دریافت و پاسخ درخواست ها از kafka request handler استفاده کردیم ، و یه ساختاری چیدیم ، اما برخی usecase ها هستند که از این قاعده پیروی نمی کنند ، و بایددر ساختار پاسخ یا درخواست دست ببریم
-
اولین سرویس بود که هم apk , ios استیت فول بود ، هم سرویس من ریپو داشت ، هم پروایدر باید سینک میبود . و برای مدیریت این پاره شدم ، مثلا من هیچ وقت نمیدونستم apk چه داده ای داره چون درخواست کننده همیشه اون بود ، و طبق سناریو قدیمی ، تنها موقع ساخت داکیومنت به من میگفت درون sdk امضا داره یا نه ، مثلا گوشی اگه clear cache میکرد ، من و پروایدر نمی دونستیم ، یا اگه امضا
-
فهمیدم باید همون اول ساختار log stash رو
بگیریم و بدونیم لاگ ها توی dev می افته یا نه
-
فهمیدم هر جا که i/o داریم باید لاگ بزاریم
-
قدر git flow رو دونستم ، چون هنوز کد من تست نشده بود ، ولی چون کلاینتم با این متودولوژی جلو نرفته بود و هر شب با dev مرج میکرد ، مجبور شدیم کد من رو با دردسر روی پروداکت ببریم
-
فهمیدم اپ چقدر میتونه state less باشه ، چون شرکت ها نمی خوان همش force update بدن. در نتیجه هیچ متن و هیچ کارتی رو خودشون ندارن و از بک اند میگیرن ، همچنین سینک کردن چند استیت فول سخته ، فرض کنیم سینک کردن استیت در بک اند و اپ گوشی خیلی پیچیده میکنه
، به این رسیدم که اپ ها حقیقتا فقط تمپلیت هستن ، و اینجا بار می افته رو دوش ادمین پنل ، چون ترتیب و کاشی های اپ اونجا چیده میشه
- فهمیدم بالاخره ، بهتره از همون gorm خودمون استفاده کرد ( کم کم دارم قدر django رو میدونم :) چون ورودی ها و خروجی ها رو میشه داینامیک کرد ،
میشه برای تست از sqlite استفاده کرد و در نهایت در صورت change تنها بر روی استراکت تغییر اعمال میکنیم
-
تیبل های لگسی ، خوشبختانه زیاد join نداشتن ولی من status داشتم اما کد قدیمی چند تا boolian داشت و seed که نوشتم کمی تغییر داشت
-
و data migration و ddl migration رو با پایتون نوشتم
هنوز جدول کانفیگ برای این سرویس رو ننوشتم اما قیمت امضا ، اولین چیز بود که منو اذییت کرد ، توی dev امضا قیمت واقعیه و باید ۱۰۰۰تومن بکنم تا تست انجام شه
قوانین
Ca سرتیفیکته آتوریتی
مثل اعتماد هوشمند یا مرکز اعتماد یا بانک ملی
Ra مرکز میانی
قانونه هر شخص با یک مرکز امضا داشته باشه ولی شاید مانی یا دیجی پی از ایران ساین بگیرن در این حالت مرکز میانی میاد
Open Banking
-
به صورت حرفه ای استراتجی پترن رو پیاده کردیم و برای ئرداخت از شاهین و سداد استفاده کردیم
-
به بهترین ارور هندل تو گولنگ - البته تا اینجای کار - رسیدیم ، به طوری که توی هر لایه - ریپوزیتوری یا درخواست از بانک - همون جا ارور کامل میشه - متن فارسی - استتوس - دیسکریپشن که می تونه یا بادی پاسخ باشه و یا خطای پستگرس باشه - و در نهایت استک که از ران تایم میزاریم توش - و همچنین در موارد استسنا از لایه درونی مانند ریپازیتوری تا یوز کیس اگر خطا این بود که در مخزن یافت نشد - باید در لایه پایانی overwrite شه به خطای داخلی 500 رخ داده ، اما استک و دیسکریپشن تغییری نکنه
-
برای اولین بار به صورت حرفه ای explain توی دیتابیس ها رو استفده کردم و کوییری ها رو ایندکس کردم
-
به این نتیجه رسیدم که گیت وی باید دست خودم باشه و یه تیم وظیفش نباشه که ئروکسی من باشه
promissory
یه موضیع مبهم برام اینه که گاهی توی میکرو سرویس ها ، یه سرویس می نویسم که مثلن توی پروایدر یه Item Draft (like signature digital or promissory note) می سازیم ، یعنی پیش نویس یه چیزی و قراره تو مراحل ( …استپ ) بعد کامل شه ، در این حالت اگر سرویس درخواست کنند برای هر درخواست شناسه داشته باشه ، حتی بعد قطع ارتباط ، دوباره در خواست با شناسه می ده ، اگه جدید بود یعنی در خواست جدیده اما اگر قدیمی بود ، ادامه ی داستان رو میریم
حالا فرض کنیم کلاینت ما stateLess هست و حاضر نیست شناسه جنریت و قبل درخواست ذخیره کنه
حال ما مشکلمون اینه که نمی دونم درخواست برای بار اوله یا یه بار درخواست هندل شده ولی ریسپانس به کلاینت نرسیده در نتیجه درخواست تکراریه ، ۲ راه داریم :
-
با فرض اینکه می تونه تکراری باشه ، بسازیم ، استتوس draft بدیم و اگر دوباره درخواست اومد ، ادامه ی همین رو بریم ، در اینجا چون شناسه خاصی نداریم باید find کنیم آخرین درخواست با استتوس مورد نظر
-
حتی اگر بار اول بود یا تکراری ، تاجایی که هزینه ی زیادی نداره ، ما هم استیت لس باشیم و تا چیزی قطعی نشده ، چیزی ثبت نکنیم
اینجاست که باید بررسی کنیم هر پیش نویس آیا هزینه داره ، آیا پردازش سنگین داره ، یا پرایدر در پایان روز پیش نویس رو حذف می کنه یا تعداد محدودی پیش نویس می تونیم تولید کنیم
match engine
order book
یه کتابخونه ی خوبه که الان 500 استار داره و چند تا متد محدود داره
- ProcessLimitOrder
یه سفارش می گیره ، و با توجه به این که خریده ، یا فروش ، میزان کف قیمت برای فروش و یا سقف مبلغ خرید رو می گیره ، و در پاسخ سفارشات کامل شده ، سفارشات بخشی کامل شده رو می ده
به نظرم مشکلش اینه که هم await داره و هم پاسخ کامل شده ها و بخشی تکمیل شده رو همین جا خروجی می ده و دیگه جایی نمی شه بازیابی کرد
باید یه پترن داشته باشیم که این خروجی رو از دست ندیم
- ProcessMarketOrder
این متد خیلی عجیبه ، میگه تو بازار یه تعداد می خوام بفروشم یا بخرم ، دیگه قیمت نمیده و خروجی تقریبا شبیه به متد بالایی هست و یه فیلد هم میده که چند تا هنوز مونده
- CancelOrder
مشخصه دیگه فقط می دونم کوینکس
sarmayex
-
توی اینجا اولش لاگ کامل نزاشتن ، به این صورت که درخواستی که میاد داخل رو فکر کنم اصلا لاگ نمی کنن ، درخواستی ، یعنی request-id نداره و نمی دونی مشکل به خاطر چه درخواستی بوده ، تازه بر این باور بودن پاسخ هایی که موفق بودن یا رنج 400 هستن ، دیگه نیازی به لاگ نیست
-
در حقیقت اینا فقط سیستم لاگشون قراره تنها خطا ها رو لاگ کنه ، و الان رو پروداکشن خطا خوردن می گن درستش کن ، و خمتن خطایی که دادن خیلی یتیمیه ، تقریبا هیچ چی معلوم نیست
-
اینجاست که قدر لاگ لول رو فهمیدم ، تو لاجیک نوشتن ایف خطا این بود لاگ نکن ، خیلی کثیف
-
همچنین چون از استک خود لاگروس استفاده کردن ، عملا استک یه جای مسخره رو نشون میده ، و دقیق نشون نمیده خطا کجا رخ داده
-
اینجا تقریبا هر لاگی که می افته میره تو تلگرام ، در نتیجه خیلی خساست می کنن تو لاگ و تریس نوشتن
-
به نظرم راه حل اینه لاگ بیفته ، ولی لاگ استش فقط اونایی رو اورو هستن رو بیش از چند ساعت نیگه داره
-
فهمیدم هر جا که نتونستیم آنمارشال کنیم ، بهتره حداقل ۲۰۰ کارکتر اول آنمارشال رو کنار خطای آنمارشال بندازیم بیاد بالا