اینم یه تجربه پراکنده دیگه

این مطلب رو من بخاطر اینکه این اصول در طراحی نرم‌افزارهایی که من تاکنون دیدم رعایت نشده مینویسم پس امیدوارم اول خودم و شاید هم دیگران بهش عمل کنیم.

در مجموع این اصول برای طراحی «نرم‌افزار به عنوان سرویس» مورد استفاده قرار میگیره که:

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

این دوازده اصل از این قرارند

  1. داشتن یک منبع کد و چندین deploy: هر نرم افزار در یک منبع کد  همانند git، mercurial و subversion وجود دارد و یک ارتباط یک به یک میان نرم‌افزارهای و منبع کد وجود دارد. بدین منظور که اگر چند منبع کد وجود دارد، اینها هریک یک سیستم نرم‌افزاری مجزا هستند
  2. تمامی وابستگی‌های نرم افزار بصورت صریحی در تعریف نرم‌افزار وجود داشته و یک نرم‌افزار هیچ‌گاه به دنبال نیازمندی‌های اجرایی خود بصورت global در سیستم عامل اجرایی خود نیست
  3. تمامی اطلاعات مرتبط با پیکربندی در متغیرهای محیطی ذخیره می شوند از قبیل نحوه ارتباط با پایگاه داده، یوزر نیم و پسورد ارتباط با سرویسهای خارجی و …
  4. سرویسهای پشتیبان سرویسهایی هستند که نرم‌افزار آنها از طریق شبکه مورد استفاده قرار می‌دهد همانند سوریس پایگاه داده، سرویس ارسال ایمیل و یا سرویس صف هستند. هیچ تفاوتی میان سوریسهای پشتیبان داخلی و یا خارجی وجود نداشته و تمامی اطلاعات مرتبط با آنها در پیکربندی ذخیره می شوند.
  5. منبع کد بایستی بصورت صریحی مراحل build، release و run را از یکدیگر جدا کند. بدین معنا که تغییرات هیچگاه روی محیط run اعمال نشده بلکه ابتدا در محیط توسعه پیاده سازی و تست شده سپس مرحله build توسط توسعه دهنده اجرا شده و سپس محیط عملیاتی (run) بصورت اتوماتیک بروزرسانی میشود
  6. هریک از بخش‌های نرم‌افزار در یک پروسه بدون حالت(stateless) اجرا شوند. این بذین معناست که هیچ اطلاعاتی در پروسه در زمان اجرا ذخیره نشده و در صورت نیاز در یک سیستم ذخیره سازی مجزا ذخیره می‌شود
  7. برای اجرا نرم افزارها معمولا نیاز به یک وب سرور همانند apache است اما یکی از اصول طراحی اینجا عدم اعتماد به وجود سرویسهایی از قبیل apache بوده و استفاده از وب سرورهای موجود در زبان های برنامه نویسی همانند tornado و … بوده و ارائه سرویس‌ها از طریق استفاده از پورتهای مجزا است.
  8. از افزایش حجم عرضی برای افزایش کارایی سیستم استفاده شود بدین صورت که از چندین پروسه استفاده شود.
  9. هریک از روندهای یک نرم‌افزار بایستی با سرعت لود شده و بصورت دقیق و قابل اعتماد خارج شوند
  10. محیطهای توسعه، پایلوت و عملیاتی بایستی کاملا به یکدیگر شبیه باشند.
  11. لاگها یک جریان از داده‌های زماندار هستند که نرم افزار آنها را در جایی ذخیره نکرده بلکه آنها را بصورت ساده در stdout نوشته و سرویسهای دیگر مسئول ذخیره‌سازی، نگهداری و بازیابی لاگ ها هستند.
  12. عملیات مرتبط به نصب و راه‌اندازی سیستم که معمولا تنها یک بار اجرا می شوند همانند بروزرسانی ساختار پایگاه داده و یا درست کردن اطلاعات ناقص در پایگاه داده بخاطر یک باگ سیستم بایستی در همان محیط اجرا شوند که پروسه‌های اصلی سیستم اجرا می‌شوند.

همین

منبع

اینم یه تجربه پراکنده دیگه

قبلا در مورد استاندارد iso 8583 نوشته بودم و الان میخوام یکمی با جزئیات بیشتر در این مورد بنویسم. مطلب اینجا ترکیبی از اونچیزیه که توی صفحه ویکپدیا اومده و اونچیزیه که من به تجربه یاد گرفتمسی و امیدوارم به درد کسی بخوره. سعی میکنم  کوتاه بنویسم که کسی حوصلش سر نره سر خوندن این مطالب

اولین و مهمترین بخش فیلدها، فیلد مشخصه پیغامه که یک عدد ۴ رقمیه که معنای هریک از رقم ها به این صورته که:

  • اولین رقم (۰xxx) : نشان دهنده نسخه استاندارده
  • دومین رقم (x1xx) : دسته پیغام رو نشون میده
  • سومین رقم (xx0x): نوع پیغام که درخواست یا پاسخ باشه رو نشون میده
  • چهارمین رقم(xxx0): نشان دهنده اینه که این پیغام رو چه کسی فرستاده (شروع کننده تراکنش، پاسخ دهنده تراکنش و …)

دسته پیغام های مهم هم عبارتند از :

  • پیغام احراز هویت(۱): مثلا وقتی که نام صاحب کارت توی انتقال کارت استعلام میشه
  • پیغام مالی (۲): مثلا وقتی شما از دستگاه خرید میکنید
  • پیغام فایل(۳): مثلا وقتی قرار فایلهای دستگاه کارتخوان بروزرسانی بشن
  • پیغام تسویه(۵): وقتی که تراکنش موفق بوده و دستگاه میخواد اعلام کنه پول رو به فروشنده تحویل بدید
  • پیغام شبکه(۸): وقتی دستگاه میخواد اطلاعات مرتبط با اتصالش به شبکه از قبیل شماره تلفن و … رو از سرور مرکزی که همون سوئیچ بانکی باشه بگیره استفاده میشه

فعلا همین تا اگه عمری بود یکم دیگه در این مورد بنویسم

redis

اینم یه تجربه پراکنده دیگه!

معمولا یکی از مشکلات سیستم‌های تحت وب وجود داره اینه که سرعت دسترسی به دیتابیس بسیار کمتر تعداد درخواستهایی است که برای دسترسی به وب وجود داره و راه‌های بسیاری برای افزایش این سرعت وجود داره. یکی از راه‌ها استفاده از cache هاست که خب در سطوح مختلفی وجود داره. اما یکی از راه‌ها استفاده از redis‌ هست که یک دیتابیس key-value است. بدین صورت که توی redis نتایج تمامی query ها به پایگاه داده ذخیره میشه و این باعث میشه که کارایی سیستم افزایش پیدا کنه.

این دیتابیس جزء پایگاه‌های noSQL هست که فقط یک سری ساختمان داده رو بجای جداول و ستون‌ها دخیره میکنه و کل پایگاه داده توی حافظه است و بصورت متناوب روی دیسک نوشته میشه بدون اینکه در عملکرد پایگاه داده اختلالی حاصل بشه. بخاطر قرار گرفتن پایگاه داده توی حافظه سرعتش خیلی بالاست و کارهای زیادی رو هم میتونه انجام بده. یکی دیگه از ویژگی‌هاش اینه که عملیات‌هاش اتمیک هستن. یعنی اینکه هریک از عملیات‌های پایگاه داده به همدیگه گیر نمیکنن و همدیگه رو بلاک نمی‌کنن و این هم باعث میشه یه عملیات وقت گیر وجود نداشته باشه. همین ویژگی‌ حتی باعث میشه که از اون به عنوان یک message broker هم بشه استفاده کرد بدین صورت که برنامه‌های مختلف اطلاعات رو بصورت کلیدهای مختلف روی این پایگاه قرار میدن و یا برمیدارن اما این عملیات‌ها بدون اختلال ایجاد کردن در کار همدیگه انجام میشه و پایگاه داده تضمین میکنه که کسی که اطلاعات رو پردازش میکنه قطعا به اطلاعات درست دسترسی داره و کارش رو درست انجام میده.

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

همین!