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 هستن ، دیگه نیازی به لاگ نیست
-
در حقیقت اینا فقط سیستم لاگشون قراره تنها خطا ها رو لاگ کنه ، و الان رو پروداکشن خطا خوردن می گن درستش کن ، و خمتن خطایی که دادن خیلی یتیمیه ، تقریبا هیچ چی معلوم نیست
-
اینجاست که قدر لاگ لول رو فهمیدم ، تو لاجیک نوشتن ایف خطا این بود لاگ نکن ، خیلی کثیف
-
همچنین چون از استک خود لاگروس استفاده کردن ، عملا استک یه جای مسخره رو نشون میده ، و دقیق نشون نمیده خطا کجا رخ داده
-
اینجا تقریبا هر لاگی که می افته میره تو تلگرام ، در نتیجه خیلی خساست می کنن تو لاگ و تریس نوشتن
-
به نظرم راه حل اینه لاگ بیفته ، ولی لاگ استش فقط اونایی رو اورو هستن رو بیش از چند ساعت نیگه داره
-
فهمیدم هر جا که نتونستیم آنمارشال کنیم ، بهتره حداقل ۲۰۰ کارکتر اول آنمارشال رو کنار خطای آنمارشال بندازیم بیاد بالا
-
داشتم سرویس لنز رو برای اولین با می خوندم ، سرویس به شدت کوچیک بود ، ولی نسبتا راحت میشه کد ها رو متوجه شد ، مهم نیست که حجم فانکشن ها کوچیک باشه یا بزرگ ، حتی مهم نیست dry رعایت شده یا نه ، چیزی که مهمه ، اینه که توی کد init (setup) توی کانستراکتور نیست ، و جداست بدیش اینه بر خلاف repository اصلا معلوم نیست که توی کافکا کی فلو شروع میشه ، کی استفاده میشه ، برای مثال یه جا همون اول داره کانسیوم می کنه و تمام ، ولی تو چند جا میبینی که استفاده میشه و واقعا گیج کنندست ، همچنین میشه از kafka ui فهمید کدوم سرویس چی ها رو داره کانسوم می کنه ، (خیلی خوبه مثلا سرویس لنز داره از فلان تاپیک کانسوم می کنه ) ولی نمی دونم کدوم سرویسا دارن پابلیش می کنن
-
بعد از چند ساعت کد خوندن دارم پاره میشم ، خیلی راحته که بفهمیم کیا توی database میریزن ، راحت با استفاده از ترک کردن create , update میشه فهمید چه لاجیکی باعث میشه داده پر شه ، اما مموری ها مانند map به دلیل نداشتن getter , setter اصلا نمیشه فهمید کدوم سرویسا دارن پر می کنن ، کدوم سرویسا استفاده می کنن
-
بعد از کلی دعوا ، فهمیدم که چجوری باید یه دیتابیس خیلی خیلی سنگین رو دست کاری کنیم ، فرض کنیم از یه دیتابیس خیلی سنگین که بعضی از ستون های شرط ایندکس نشده ، می خوایم داده رو حذف کنیم ، از طرفی می تونیم یه شرط ساده ی دیلیت بزاریم ولی ریسورس کامل درگیر میشه و شاید دان تایم زیاد شه ، اما می تونیم بچ بچ درخواست بدیم و وسطش اسلیپ بزاریم ، در این صورت هر بار که بخواد اون تعداد سطر رو پیدا کنه تا پاک کنه ، ابتدا همه ی چیزایی که یا پاک کرده یا پیموده رو دوباره می پیمایه تا شروع کنه به پاک کردن ادامه ، در این صورت با فرض این که id ایندکس شده شروع می کنیم ، حتتتتما order باید ایندکس شده باشه ، همچنین آخرین شناسه ای که پاک کردیم رو باید تو شرط بعدی بیاریم تا دوباره نره پیمایش کنه تا به شرط مربوطه برسه ، تجربه رو پورداکشن ، این بود که هر بار شرط رو میزدیم ، با فرض سلکت ، ۵ دقیقه طول میکشید و احتمالا هر بار هم بیشتر میشد ، چون که نصفه ی اول رو پاک کرده بوده ، و هر با نصفه ی اولو بررسی میکرد ، راه حل این بود که بگیم نصفه ی اولو نمی خواد بررسی کنی