در ساعت ۹:۲۹:۵۵ یک روز معاملاتی بازار سهام آمریکا، تعدادی از مهندسان سیستمهای توزیعشده در صرافیهای بزرگ و هر بانک درجه یک به داشبوردهایی خیره شدهاند که احتمالاً سالهاست به آنها نگاه میکنند. پنج ثانیه بعد، بازارهای سهام کشور جریان سفارش اوج را جذب میکنند که میتواند از پانصد هزار پیام در ثانیه در نوار تلفیقی فراتر رود. سیستمهایی که این موج را جذب میکنند از دقیقترین نرمافزارهای مهندسیشده در استفاده تجاری هستند و الگوهایی که به آنها متکیاند اکنون بیشتر بخشهای دیگر امور مالی آمریکا را نیز تغذیه میکنند.
معنای واقعی «توزیعشده» در زمینه مالی آمریکا
یک سیستم توزیعشده، به معنای کتاب درسی، مجموعهای از فرآیندهایی است که از طریق یک شبکه ارتباط برقرار میکنند تا یک سرویس واحد و منسجم ارائه دهند. در زمینه مالی آمریکا، این تعریف محدودتر میشود. به این معناست که سرویسی که در آن وضعیت در مکانهای متعدد وجود دارد، تاخیر بر حسب میکروثانیه اندازهگیری میشود، و حالتهای خرابی نظری نیستند زیرا نهاد نظارتی میتواند ظرف چهل و هشت ساعت درخواست گزارش پس از وقوع حادثه دهد.
نمونههای کلاسیک عبارتند از موتور تطبیق صرافی، سوئیچ پرداخت بلادرنگ، سرویس امتیازدهی تقلب، و شبکه توزیع دادههای بازار. هر کدام از اینها نیازمندیهای یکپارچگی کمی متفاوتی دارند. موتور تطبیق خواهان ترتیب دقیق است. سیستم تقلب سرعت را بر کاملبودن ترجیح میدهد. توزیع دادههای بازار به توان عملیاتی نیاز دارد. انتخابهای مهندسی از این محدودیتها ناشی میشوند.
دلیل اهمیت این موضوع در سال ۲۰۲۶ این است که همان الگوهای معماری از میزهای معاملاتی به بقیه فینتک آمریکا منتقل شدهاند. یک اپلیکیشن پرداخت مصرفکننده، یک پلتفرم بانک حامی BaaS، و یک محصول بازده خزانهداری اکنون همه روی طراحیهای توزیعشدهای اجرا میشوند که ده سال پیش عجیب به نظر میرسیدند.
چگونگی ساخت بزرگترین سیستمهای مالی آمریکا امروز
سه الگوی معماری در تقریباً هر سیستم توزیعشده مالی جدی آمریکا تکرار میشوند. اول event sourcing است، که در آن هر تغییر وضعیت ابتدا در یک لاگ append-only نوشته میشود و نماهای تجسمیافته از آن لاگ مشتق میشوند. Kafka، AWS Kinesis و Confluent Cloud اکنون زیر بیشتر بکاندهای بزرگ فینتک قرار دارند، با پنجرههای نگهداری به اندازه کافی طولانی برای بازپخش روزها یا هفتهها فعالیت. مزایای حسابرسی و تطابق ترکیب میشوند؛ برای بسیاری از مسئولان انطباق، لاگ منبع حقیقت است.
دومی اجماع و تکثیر است. اکثر پایگاههای داده فینتک اکنون روی پروتکلهایی اجرا میشوند که از Raft یا Paxos مشتق شدهاند. CockroachDB، FoundationDB، Spanner و دفترهای کل اصلی بومی ابری همه از نسخههای مختلف استفاده میکنند. اثر عملی این است که یک تراکنش واحد در یک فینتک آمریکایی میتواند از دست دادن یک ناحیه در دسترس بودن کامل را بدون از دست دادن داده و با چند ثانیه خرابی تحمل کند، که قبلاً به ماهها کار مهندسی نیاز داشت.
سومی service mesh و مسیریابی آگاه از نرخ است. Envoy، Istio و Linkerd اکنون استاندارد هستند، و پیکربندیهای مورد استفاده در امور مالی بر circuit-breaking، بودجههای retry و الگوهای bulkhead به ارث رسیده از دستورالعمل Netflix تکیه میکنند. ریلهای پرداخت آمریکا که فینتکها روی آنها سوار هستند بیشتر اوقات پشت این meshها قرار دارند.
تابلوی امتیاز عملکرد سیستمهای توزیعشده در امور مالی آمریکا
اعداد زیر از ترکیبی از وبلاگهای مهندسی عمومی، گزارشهای SOC 2 فروشندگان و تاریخچههای حوادث افشاشده به دست آمدهاند. آنها یک خط پایه مفید برای آنچه سیستمهای توزیعشده تولیدی در امور مالی آمریکا واقعاً به دست میآورند ترسیم میکنند.
گویاترین رقم خط تاخیر p99 است. یک دهه پیش، یک p99 زیر میلیثانیه عددی مربوط به معاملات بود. امروز، چندین فینتک آمریکایی رو به مصرفکننده تاخیرهای p99 تکرقمی میلیثانیهای را برای جریانهای احراز هویت اصلی و شروع پرداختها منتشر میکنند. هزینه رسیدن به آنجا قابل توجه است، اما هزینه عملیاتی ماندن در آنجا کمتر از هزینه اجرای یک سیستم کندتر است، زیرا حوادث در تاخیرهای مالی گران تمام میشوند.
در دیوارهای تنظیمشده یک بانک آمریکایی، تیم سیستمهای توزیعشده معمولاً به دو ارباب پاسخ میدهد. سازمان پلتفرم به uptime، توان عملیاتی و هزینه عملیاتی اهمیت میدهد. سازمان ریسک و انطباق به قابلیت حسابرسی، تغییرناپذیری و قابلیت اثبات اهمیت میدهد. معماریهایی که پدیدار میشوند معمولاً یک مصالحه هستند: لاگهای رویداد append-only برای راضی کردن ارباب دوم، نماهای پرسوجوی تجسمیافته و کشها برای راضی کردن اول.
حالتهای خرابی که هنوز فینتک آمریکا را در تولید میگزند
سه حالت خرابی بیشتر حوادث تولیدی فینتک آمریکا در دو سال گذشته را به خود اختصاص میدهند، بر اساس گزارشهای حوادث افشاشده و خلاصههای پس از وقوع حادثه. اول retryهای آبشاری است. یک timeout در پاییندست یک طوفان retry در سرویس بالادست راهاندازی میکند، که connection pool را تخلیه میکند، که به عنوان یک قطع قابل مشاهده برای مشتری برمیگردد. بودجههای retry و circuit breakerها کاهش استاندارد هستند، اما هر تیم مهندسی این را حداقل یک بار به سختی یاد میگیرد.
دومی split-brain چند منطقهای است. وقتی یک پارتیشن شبکه منطقه اصلی یک فینتک را از replica آن جدا میکند، کد failover سادهلوحانه میتواند هر دو طرف را به leader ارتقا دهد. نتیجه نوشتههای واگرا هستند که باید به صورت دستی آشتی داده شوند. طراحیهای مبتنی بر CRDT و مبتنی بر اجماع درمان هستند، اما پذیرش ناهموار است.
سومی شکافهای مشاهدهپذیری است. بیشتر قطعیهای فینتک ناشی از خرابی یک مؤلفه واحد به تنهایی نیستند؛ ناشی از زنجیرهای از کاهشهای کوچک هستند که هیچ داشبورد واحدی آنها را نشان نمیدهد. تیمهایی که جدی در distributed tracing، همبستگی لاگ و معیارهای آگاه از cardinality سرمایهگذاری میکنند تمایل دارند حوادث را دو تا سه برابر سریعتر از تیمهایی که این کار را نمیکنند شناسایی و حل کنند. انضباط پیرامون لولهکشی پرداخت مبتنی بر ACH اغلب این بلوغ را اجبار میکند، زیرا تطابق بخشنده نیست.
جنبه فرهنگی اجرای سیستمهای توزیعشده در امور مالی کمارزش تلقی میشود. تیمهایی که نرخ حوادث پایین را حفظ میکنند تقریباً همیشه post-mortemهای بدون سرزنش اجرا میکنند، runbookهایی که مهندسان واقعاً میخوانند منتشر میکنند، و شیفتهای on-call را میچرخانند که از مهندسان ارشد در برابر از دست دادن خواب مزمن محافظت میکند. ابزارسازی به تنهایی هرگز جبران یک فرهنگ on-call شکننده نمیکند؛ بسیاری از برجستهترین قطعیهای فینتک آمریکا در سه سال گذشته خیلی قبل از اینکه هشدار ارسال شود به یک مشکل فرهنگی برمیگشتند.
معنای این موضوع برای بنیانگذاران فینتک که امروز زیرساخت میسازند
برای بنیانگذاران فینتک آمریکا، پیامد عملی این است که هزینه اشتباه کردن در سیستمهای توزیعشده تنها در مرحله بسیار اولیه کاهش یافته است. یک نمونه اولیه pre-seed روی Postgres مدیریتشده و یک منطقه AWS واحد مناسب است. لحظهای که محصول دلارهای واقعی مشتری در پرواز دارد، سطح مهندسی به شدت بالا میرود، و تیمهایی که این مکالمه را به تأخیر میاندازند یا uptime یا مشتریان یا هر دو را از دست میدهند.
سه سوال که هر بنیانگذار فینتک باید بتواند درباره معماری خود تا زمان رسیدن به تامین مالی سری آ پاسخ دهد: اگر پایگاه داده اصلی ده دقیقه در دسترس نباشد چه اتفاقی میافتد؛ اگر یک شریک پاییندست سی ثانیه ۵۰۰ برگرداند چه اتفاقی میافتد؛ و سیستم چگونه برای این سناریوها آزمایش میشود. بنیانگذارانی که میتوانند هر سه را به وضوح پاسخ دهند تمایل دارند از نقاط عطفی که همتایانشان را میشکند عبور کنند.
جنبه استخدامی این موضوع نیز ملموس است. یک مهندس ارشد سیستمهای توزیعشده در یک فینتک آمریکایی در سال ۲۰۲۶ یک بسته جبران خسارت کل در بالای بازار فناوری آمریکا را فرمان میدهد، که اغلب برای کسی با تجربه پرداخت یا معاملات بیش از سیصد و پنجاه هزار دلار است. عرضه محدود است زیرا ساخته شدن مجموعه تجربه یک دهه طول میکشد. نوآوری بانکی که در سطح جهانی مقیاس میشود تقریباً همیشه حداقل یک چنین مهندسی در اولین ده استخدام خود دارد.
تمرکز جغرافیایی محاسبات یک ریسک آرام دیگری است. تعداد شگفتانگیزی از فینتکهای آمریکایی بارکاری اصلی خود را در یک منطقه AWS واحد (اغلب us-east-1) اجرا میکنند، که به این معناست که یک قطع آمازون در شمال ویرجینیا مستقیماً به یک قطع فینتک آمریکایی تبدیل میشود. Multi-region active-active از نظر فنی پرتقاضا و گران است، اما تیمهایی که در آن سرمایهگذاری کردهاند پروفایل حوادث متفاوتی دارند.
سطح فروشندهای که از همه اینها پشتیبانی میکند تجمیع یافته است. ارائهدهندگان ابری بزرگ (AWS، Google Cloud و Azure) اکنون معماریهای مرجع مخصوص خدمات مالی ارائه میدهند، و بانکهای حامی منطقهای شروع به انتشار موارد خود کردهاند. چشمانداز منبع باز (Kafka، Redis، ClickHouse، Postgres، Temporal) به اندازه کافی بالغ است که یک فینتک جدید میتواند V1 خود را روی یک stack ارسال کند که در سال ۲۰۱۸ نیاز به ساخت سفارشی داشت.
باز شدن ساعت ۹:۳۰ صبح همچنان یک آزمون استرس برای نرمافزار پرتقاضاترین کشور خواهد بود. توسعه جالب این است که همان دقت مهندسی اکنون در داخل فینتکهایی که هرگز به صرافی نزدیک نمیشوند نیز قابل مشاهده است.
برای یک نمونه از پروتکلهای سیم توصیفشده در بالا، مشخصات مشترک کلاینت NYSE Pillar را ببینید.
