CodeCrafters
فصل اول 2- بلاکچین چگونه کار میکند؟ بلاکچین را مجموعهای از بلاکها تصور کنید که به صورت زنجیرهوار به یکدیگر متصلاند. 1- ساختار هر بلاک هر بلاک در زنجیره شامل 3 بخش اصلی است: 1.1- داده (Data): این بخش شامل اطلاعاتی است که بلاک ذخیره میکند. برای نمونه،…
فصل اول
3-کاربردهای بلاکچین
بلاکچین به دلیل ویژگیهای منحصر به فرد خود، کاربردهای متنوعی در صنایع و حوزههای مختلف دارد. در این درس به بررسی برخی از مهمترین کاربردهای بلاکچین میپردازیم.
1- ارزهای دیجیتال
2- قراردادهای هوشمند
3- زنجیره تأمین
4- رأیگیری الکترونیکی
5- بهداشت و درمان
6- مدیریت
نتیجهگیری
@code_craftesr
3-کاربردهای بلاکچین
بلاکچین به دلیل ویژگیهای منحصر به فرد خود، کاربردهای متنوعی در صنایع و حوزههای مختلف دارد. در این درس به بررسی برخی از مهمترین کاربردهای بلاکچین میپردازیم.
1- ارزهای دیجیتال
اولین و معروفترین کاربرد بلاکچین، ارزهای دیجیتال یا رمزارزها هستند. بیتکوین و اتریوم به عنوان نمونههای اصلی این دسته، توانستهاند با استفاده از بلاکچین، پرداختها و تراکنشهای مالی را به صورت امن و غیرمتمرکز انجام دهند.
- بیتکوین: به عنوان اولین ارز دیجیتال، بیتکوین امکان انجام تراکنشهای همتا به همتا را بدون نیاز به واسطهها فراهم کرده است.
- اتریوم: علاوه بر قابلیتهای بیتکوین، اتریوم پلتفرمی برای اجرای قراردادهای هوشمند و توسعه برنامههای غیرمتمرکز ارائه میدهد.
2- قراردادهای هوشمند
قراردادهای هوشمند (Smart Contracts) برنامههایی هستند که بر روی بلاکچین اجرا میشوند و شرایط قراردادی را به صورت خودکار و بدون نیاز به واسطههای سنتی اجرا میکنند.
- مزایا: حذف واسطهها، کاهش هزینهها و افزایش سرعت اجرای قراردادها.
- مثال: میتوان از قراردادهای هوشمند برای اتوماسیون فرآیندهای حقوقی، بیمه و معاملات املاک استفاده کرد.
3- زنجیره تأمین
بلاکچین میتواند شفافیت و کارایی زنجیره تأمین را بهبود بخشد. از تولید تا مصرف، هر مرحله از زنجیره تأمین میتواند به صورت امن و قابل ردیابی در بلاکچین ثبت شود.
- مزایا: افزایش شفافیت، کاهش تقلب و بهبود مدیریت موجودی.
- مثال: پیگیری محصولات غذایی از مزرعه تا فروشگاه برای اطمینان از کیفیت و اصالت کالا.
4- رأیگیری الکترونیکی
استفاده از بلاکچین در سیستمهای رأیگیری الکترونیکی میتواند شفافیت و امنیت انتخابات را افزایش دهد.
- مزایا: جلوگیری از تقلب، افزایش شفافیت و امکان رأیگیری از راه دور.
- مثال: پیادهسازی سیستمهای رأیگیری برای انتخابات ملی و محلی با استفاده از بلاکچین
5- بهداشت و درمان
در حوزه بهداشت و درمان، بلاکچین میتواند به اشتراکگذاری امن و کارآمد اطلاعات پزشکی بین بیماران، پزشکان و مراکز درمانی کمک کند.
- مزایا: افزایش امنیت و حریم خصوصی، بهبود هماهنگی بین مراکز درمانی و کاهش هزینهها.
- مثال: ایجاد پروندههای پزشکی الکترونیکی بر روی بلاکچین که تنها توسط افراد مجاز قابل دسترسی باشد
6- مدیریت
هویت
بلاکچین میتواند به ایجاد سیستمهای مدیریت هویت دیجیتال امن و غیرمتمرکز کمک کند.
- مزایا: افزایش امنیت اطلاعات شخصی، کاهش تقلب و سوء استفاده از هویت.
- مثال: ایجاد شناسههای دیجیتال برای افراد که به صورت امن در بلاکچین ذخیره میشوند و در دسترسی به خدمات مختلف مورد استفاده قرار میگیرند
نتیجهگیری
بلاکچین با ویژگیهای منحصر به فرد خود، کاربردهای فراوانی در صنایع و حوزههای مختلف دارد. این فناوری میتواند به بهبود شفافیت، امنیت و کارایی فرآیندها کمک کرده و نوآوریهای جدیدی را در دنیای دیجیتال به ارمغان آورد. در درسهای بعدی، به بررسی عمیقتر سایر مفاهیم و کاربردهای بلاکچین خواهیم پرداخت.#blockchain
@code_craftesr
🔥6
عالی
CodeCraftersChat
گپ فنی و خودمونی گروه بابت امشب
با تشکر از سعیدجان
موضوع راجب اسکیل کردن پروژههای بزرگ و چگونه کار کردن اونها بود
به زودی میتهای تخصصیش هم راه میندازیم
@code_crafters
با تشکر از سعیدجان
موضوع راجب اسکیل کردن پروژههای بزرگ و چگونه کار کردن اونها بود
به زودی میتهای تخصصیش هم راه میندازیم
@code_crafters
🔥11👍1
فصل اول
4-اولین و معروف ترین بلاکچین ها
1-اولین بلاکچین ها:
1.1-بیتکوین(Bitcoin):
1.2-لایتکوین(litecoin):
2-معروفترین بلاکچین ها
2.1-اتریوم (Ethereum):
2.2-ریپل (Ripple):
2.3-هایپرلجر (Hyperledger):
2.4-کاردانو (Cardano):
2.5-ایاس (EOS):
نکته هیچ ترتیبی در میزان معروفیت نیست صرفا معروفترین بلاکچین ها ذکر شده.
بیشتر بخوانید:
بیتکوین (Bitcoin)
لایتکوین(litecoin)
اتریوم (Ethereum)
ریپل (Ripple)
هایپرلجر (Hyperledger)
کاردانو (Cardano)
ایاس (EOS)
#blockchain
#web3
@code_crafters
4-اولین و معروف ترین بلاکچین ها
1-اولین بلاکچین ها:
1.1-بیتکوین(Bitcoin):
بیتکوین اولین و معروف ارز دیجیتالی و بلاکچین غیر متمرکزی است که توسط ساتوشی ناکوموتو در سال 2008 معرفی و در سال 2009 عملی شد.
سازنده: ساتوشی ناکاموتو
سال راه اندازی: 2009
کاربرد اصلی: ارز دیجیتال
ویژگی: اولین بلاکچین غیر متمرکز و آغازگر انقلاب ارزهای دیجیتال.
1.2-لایتکوین(litecoin):
زمان راهاندازی: 2011
سازنده: چارلی لی
کاربرد اصلی: ارز دیجیتال برای پرداختهای سریعتر و ارزانتر
ویژگیها: تأیید سریعتر تراکنشها، الگوریتم Scrypt، کارمزد پایین.
2-معروفترین بلاکچین ها
2.1-اتریوم (Ethereum):
زمان راهاندازی: 2015
سازنده: ویتالیک بوترین
کاربرد اصلی: قراردادهای هوشمند و اپلیکیشنهای غیرمتمرکز (DApps)
ویژگیها: قابلیت اجرای قراردادهای هوشمند و اپلیکیشنهای متنوع.
2.2-ریپل (Ripple):
زمان راهاندازی: 2012
سازنده: کریس لارسن و جد مککالب
کاربرد اصلی: سیستم پرداخت بینالمللی
ویژگیها: انتقال سریع و ارزان پول، استفاده توسط بانکها.
2.3-هایپرلجر (Hyperledger):
زمان راهاندازی: 2015
سازنده: بنیاد لینوکس
کاربرد اصلی: بلاکچینهای خصوصی و کنسرسیومی برای کسبوکارها.
ویژگیها: پلتفرم منعطف برای صنایع مختلف
2.4-کاردانو (Cardano):
زمان راهاندازی: 2017
سازنده: چارلز هاسکینسون
کاربرد اصلی: قراردادهای هوشمند و اپلیکیشنهای غیرمتمرکز
ویژگیها: امنیت و مقیاسپذیری بالا.
2.5-ایاس (EOS):
زمان راهاندازی: 2018
سازنده: بلاکوان
کاربرد اصلی: قراردادهای هوشمند و اپلیکیشنهای غیرمتمرکز
ویژگیها: سرعت و کارایی بالا، کاهش کارمزدها.
نکته هیچ ترتیبی در میزان معروفیت نیست صرفا معروفترین بلاکچین ها ذکر شده.
بیشتر بخوانید:
بیتکوین (Bitcoin)
لایتکوین(litecoin)
اتریوم (Ethereum)
ریپل (Ripple)
هایپرلجر (Hyperledger)
کاردانو (Cardano)
ایاس (EOS)
#blockchain
#web3
@code_crafters
👍6
بارگذاری فایل بزرگ
CodeCraftersChat
گپ فنی امشب داخل گروه با سعید جان ، در خصوص استوریج فایلهای حجیم در بستر وب
به زودی میتهای تخصصی رو مجدد شروع میکنیم و با همون قدرت ماه های اول گپ برمیگردیم و چندین ساعت با حضور سعید کد میبینیم و گفتگو خواهیم کرد
@code_crafters
به زودی میتهای تخصصی رو مجدد شروع میکنیم و با همون قدرت ماه های اول گپ برمیگردیم و چندین ساعت با حضور سعید کد میبینیم و گفتگو خواهیم کرد
@code_crafters
❤🔥9👍4❤1
CodeCrafters
CodeCraftersChat – بارگذاری فایل بزرگ
در پیرو گپ دیشب در گروه بابت minio مقاله زیر رو بخونید
https://blog.min.io/selecting-hardware-for-minio-deployment/
https://blog.min.io/selecting-hardware-for-minio-deployment/
AIStor Object Store Documentation
Install AIStor
Install on Kubernetes Deploy AIStor on Kubernetes
👍4
طراحی سرویس پرداخت و خرید و چالش های آن
CodeCraftersChat
گپ امشب گروه با سعید جان
موضوع گپ:
تحلیل و بررسی فنی سرویس هایی مانند پرداخت، سفارش، سبد خرید و چالش های یک سیستم فروشگاهی چند منطوره با تجربه های شخصی
برخی از مباحث گفته شده:
- چگونگی عملکرد درگاه های پرداخت انلاین
- چگونگی و چالش های طراحی سرویس فروشگاهی، خرید، سبد خرید و انبار داری
- صحبت در باره retry handling و rollback تغییرات و Saga state machine
- بررسی زنده یک اپلیکیشن دارای فروشگاه، تحلیل محصولات و اپلیکیشن های مشابه
- توضیح درباره کیف پول مجازی، روش های پرداخت، پرداخت
- بحث مدیریت همزمانی، اعتبار سنجی خرید ها، کنترل و رزرو موجودی و Checkout
- پرسش و پاسخ سوالات مرتبط دوستان
بزودی میتهای تخصصی رو مجدد شروع میکنیم
@code_crafters
موضوع گپ:
تحلیل و بررسی فنی سرویس هایی مانند پرداخت، سفارش، سبد خرید و چالش های یک سیستم فروشگاهی چند منطوره با تجربه های شخصی
برخی از مباحث گفته شده:
- چگونگی عملکرد درگاه های پرداخت انلاین
- چگونگی و چالش های طراحی سرویس فروشگاهی، خرید، سبد خرید و انبار داری
- صحبت در باره retry handling و rollback تغییرات و Saga state machine
- بررسی زنده یک اپلیکیشن دارای فروشگاه، تحلیل محصولات و اپلیکیشن های مشابه
- توضیح درباره کیف پول مجازی، روش های پرداخت، پرداخت
- بحث مدیریت همزمانی، اعتبار سنجی خرید ها، کنترل و رزرو موجودی و Checkout
- پرسش و پاسخ سوالات مرتبط دوستان
بزودی میتهای تخصصی رو مجدد شروع میکنیم
@code_crafters
❤8
Screenshot from 2024-06-20 22-37-03.png
40.7 KB
در بخشی از گپ امشب
سوالی مطرح شد که هندل کردن اون وابسته به معماری ما داشت و طی توضیحات گفتم معماری رو براتون میزارم
این بیس معماری سرویس پرداخت هستش که به شدت منعطف میباشد و در مقابل تغییرات و بزرگ شدن و افزودن هر نوع دیگری از فروش به آن قابلیت ارجاعی داره و به راحتی میتونید سایر موارد و بخشهای خودتون رو بهش اضافه کرده و گستردهترش کنید
تحلیل خودتون رو راجبش در کامنتها بزارید تا حرف بزنیم و نسبت بهش بیشتر شناخت پیدا کنید
@code_crafters
سوالی مطرح شد که هندل کردن اون وابسته به معماری ما داشت و طی توضیحات گفتم معماری رو براتون میزارم
این بیس معماری سرویس پرداخت هستش که به شدت منعطف میباشد و در مقابل تغییرات و بزرگ شدن و افزودن هر نوع دیگری از فروش به آن قابلیت ارجاعی داره و به راحتی میتونید سایر موارد و بخشهای خودتون رو بهش اضافه کرده و گستردهترش کنید
تحلیل خودتون رو راجبش در کامنتها بزارید تا حرف بزنیم و نسبت بهش بیشتر شناخت پیدا کنید
@code_crafters
❤6👍3
CodeCrafters
خیلی از مواقع اون چیزی که ذهنمون رو درگیر میکنه در حین کدنویسی و برنامه نویسی مباحث مربوط به clean بودن هست چه نکاتی رو باید رعایت کنیم یا به چه شکلی کد نوشته بشه که تمام نکات clean رعایت بشه و قابلیت خواندن برای دیگر برنامه نویسها رو هم داشته باشه علاوه…
مقاله زیر رو در خصوص رعایت یکسری اصول کدزنی در پایتون بخونید ،سازمانهای بزرگ خروجی همچین چیزی ازتون انتظار دارن
@code_crafters
https://google.github.io/styleguide/pyguide.html
@code_crafters
https://google.github.io/styleguide/pyguide.html
👏6👍2🥰1
#مقیاس_پذیری و چالش های آن - پارت 1
Horizontal & Vertical #Scaling ⚖️
زمانی که فرآیند تولید نرم افزار به مرحله Production میرسد و اپلیکیشن روی سرور میرود، چالشها و مخاطرات جدیدی برای صاحبان آن ایجاد میشود. ما در عصری هستیم که استفاده از اینترنت به سبک زندگیمان تبدیل شده. بنابراین پس از معرفی اپلیکیشن یا وبسایت، کاربران آن به سرعت افزایش پیدا میکند.
زمانی فرا میرسد که سیستم دیگر توان هندل کردن حجم بازدیدکنندگان و پردازش درخواست ها را ندارد.
در مواردی هم حجم دیتا به حدی میرسد که سیستم نمیتواند آن را در پایگاه داده خود ذخیره کند. در این گونه موارد، زمان آن فرا رسیده که محصول Scale یا مقیاس پذیر شود.
معمول ترین راهکار، مقیاس پذیری عمودی یعنی افزایش منابع سخت افزاری مانند RAM, CPU است اما در نرمافزار های بزرگتر، مقیاس پذیری عمودی تا حدی کارساز است.
از یک حدی به بعد تک سرور شما قادر به افزایش منابع نخواهد بود و یا صرفه اقتصادی نخواهد داشت. کما اینکه vertical Scaling محدودیت هایی مانند دیسک و شبکه را مقیاس پذیر نمیکند. (به خصوص پهنای باند در سرور های داخل که سرشار از اختلال و از نسل 3G است!)
بنابراین مقیاس پذیری افقی با افزودن سرور های بیشتر (که زین پس به آنها Node خواهیم گفت) و تقسیم بار بین انها ( Load Balanacing) راه حل بهتری خواهد بود. چرا که هم افزایش سرور ها ارزان تر خواهد بود (به نسبت خرید منابع حافظه و پردازنده بیشتر) و هم هر سرور مستقلا میتواند به مقدار نیاز مقیاس پذیری عمودی هم داشته باشد (هر سرور منابع اختصاصی متفاوتی از حافظه ram، پردازنده، iops دیسک و پهنای باند / پورت شبکه داشته باشد)
تا به اینجا اصلی ترین تفاوت های دو مدل مقیاس پذیری را بررسی کردیم. اما همیشه چالش ها، مزایا و معایبی هم وجود دارد که در جایگاه یک مهندس نرم افزار حرفه ای و معمار سیستم، ما باید با علم به این مباحث برای یک کسب و کار تصمیم بگیریم.
یکی از چهار هدف اصلی مقیاس پذیری، توسعه پذیر تر کردن یک نرم افزار است.
در مقیاس پذیری افقی مهمترین و اصلی ترین چالش های پیش رو مباحثی مانند همزمانی در عملیات ها، یکپارچگی داده ها، از بین بردن Single point of failure و کاهش گلوگاه ها است.
همانطور که در بالاتر اشاره شد در مقیاس پذیری افقی ما بجای تکیه بر سخت افزار محدود یک سرور، به طرف توزیع بار و کلاستر سرویس ها بر روی چند سرور (نود) متعدد میرویم.
فرض کنید نرم افزاری دارید که متشکل از ده ها میکروسرویس و ده ها دیتابیس و ابزار مختلف میباشد. هر کدام ازین میکروسرویس ها بر روی سرور های 1 الی 5 در حال اجرا هستند. همچنین ممکن است هر یک ازین سرویس ها نیاز به replication و load balancing پیدا کنند (هدف از مقیاس پذیری افقی).
در اینصورت علاوه بر این که کلاستر سرور های شما میبایستی در یک شبکه داخلی یا خصوصی پایدار و قابل اتکا با هم در ارتباط باشند، بایستی بتوانند بصورت پایدار عملیات های خود را انجام دهند.
برخی از پارامتر های پایداری:
- درخواست های همزمان متعدد نباید منجر به پاسخ های مختلف شوند.
- داده های خروجی باید جدیدترین داده های موجود باشند.
به عنوان مثال، سرویس سفارش یا احراز هویت مان را مقیاس پذیر کردیم و لود بالانسینگ تعیین میکند هر بار درخواست ها به کدام node / سرور ارسال شود.
در صورتی که دو یا چند کاربر بطور همزمان قصد دسترسی به یک ریسورس مشترک (فایل / دیتابیس / etc) داشته باشند مشکلاتی همچون همزمانی یا concurrency و شرایط مسابقه یا race conditions پدیدار خواهد شد.
علاوه بر همزمانی، حفظ یکپارچگی داده ها و جلوگیری از بروز رفتارهای نادرست در سیستم بسیار مهم است.
در مطلب بعدی (پارت 2 مقیاس پذیری)، به برخی شیوه های مدیریت این چالش ها و تجربه های شخصی میپردازیم.
بیشتر بخوانید (مقالات / مفاهیم مرتبط):
دسترسی پذیری بالا HA
گلوگاه Bottleneck
خوشه ها Cluster
تئوری CAP
مقیاس پذیری Scalability
سیستم های توزیع شده Distributed Systems
#مهندسی_نرمافزار #معماری
#software_engineering #architecture #Scalability #distributed_systems #devops #infrastructure
@csharpfriends @Code_Crafters
Horizontal & Vertical #Scaling ⚖️
زمانی که فرآیند تولید نرم افزار به مرحله Production میرسد و اپلیکیشن روی سرور میرود، چالشها و مخاطرات جدیدی برای صاحبان آن ایجاد میشود. ما در عصری هستیم که استفاده از اینترنت به سبک زندگیمان تبدیل شده. بنابراین پس از معرفی اپلیکیشن یا وبسایت، کاربران آن به سرعت افزایش پیدا میکند.
زمانی فرا میرسد که سیستم دیگر توان هندل کردن حجم بازدیدکنندگان و پردازش درخواست ها را ندارد.
در مواردی هم حجم دیتا به حدی میرسد که سیستم نمیتواند آن را در پایگاه داده خود ذخیره کند. در این گونه موارد، زمان آن فرا رسیده که محصول Scale یا مقیاس پذیر شود.
معمول ترین راهکار، مقیاس پذیری عمودی یعنی افزایش منابع سخت افزاری مانند RAM, CPU است اما در نرمافزار های بزرگتر، مقیاس پذیری عمودی تا حدی کارساز است.
از یک حدی به بعد تک سرور شما قادر به افزایش منابع نخواهد بود و یا صرفه اقتصادی نخواهد داشت. کما اینکه vertical Scaling محدودیت هایی مانند دیسک و شبکه را مقیاس پذیر نمیکند. (به خصوص پهنای باند در سرور های داخل که سرشار از اختلال و از نسل 3G است!)
بنابراین مقیاس پذیری افقی با افزودن سرور های بیشتر (که زین پس به آنها Node خواهیم گفت) و تقسیم بار بین انها ( Load Balanacing) راه حل بهتری خواهد بود. چرا که هم افزایش سرور ها ارزان تر خواهد بود (به نسبت خرید منابع حافظه و پردازنده بیشتر) و هم هر سرور مستقلا میتواند به مقدار نیاز مقیاس پذیری عمودی هم داشته باشد (هر سرور منابع اختصاصی متفاوتی از حافظه ram، پردازنده، iops دیسک و پهنای باند / پورت شبکه داشته باشد)
تا به اینجا اصلی ترین تفاوت های دو مدل مقیاس پذیری را بررسی کردیم. اما همیشه چالش ها، مزایا و معایبی هم وجود دارد که در جایگاه یک مهندس نرم افزار حرفه ای و معمار سیستم، ما باید با علم به این مباحث برای یک کسب و کار تصمیم بگیریم.
یکی از چهار هدف اصلی مقیاس پذیری، توسعه پذیر تر کردن یک نرم افزار است.
در مقیاس پذیری افقی مهمترین و اصلی ترین چالش های پیش رو مباحثی مانند همزمانی در عملیات ها، یکپارچگی داده ها، از بین بردن Single point of failure و کاهش گلوگاه ها است.
همانطور که در بالاتر اشاره شد در مقیاس پذیری افقی ما بجای تکیه بر سخت افزار محدود یک سرور، به طرف توزیع بار و کلاستر سرویس ها بر روی چند سرور (نود) متعدد میرویم.
فرض کنید نرم افزاری دارید که متشکل از ده ها میکروسرویس و ده ها دیتابیس و ابزار مختلف میباشد. هر کدام ازین میکروسرویس ها بر روی سرور های 1 الی 5 در حال اجرا هستند. همچنین ممکن است هر یک ازین سرویس ها نیاز به replication و load balancing پیدا کنند (هدف از مقیاس پذیری افقی).
در اینصورت علاوه بر این که کلاستر سرور های شما میبایستی در یک شبکه داخلی یا خصوصی پایدار و قابل اتکا با هم در ارتباط باشند، بایستی بتوانند بصورت پایدار عملیات های خود را انجام دهند.
برخی از پارامتر های پایداری:
- درخواست های همزمان متعدد نباید منجر به پاسخ های مختلف شوند.
- داده های خروجی باید جدیدترین داده های موجود باشند.
به عنوان مثال، سرویس سفارش یا احراز هویت مان را مقیاس پذیر کردیم و لود بالانسینگ تعیین میکند هر بار درخواست ها به کدام node / سرور ارسال شود.
در صورتی که دو یا چند کاربر بطور همزمان قصد دسترسی به یک ریسورس مشترک (فایل / دیتابیس / etc) داشته باشند مشکلاتی همچون همزمانی یا concurrency و شرایط مسابقه یا race conditions پدیدار خواهد شد.
علاوه بر همزمانی، حفظ یکپارچگی داده ها و جلوگیری از بروز رفتارهای نادرست در سیستم بسیار مهم است.
در مطلب بعدی (پارت 2 مقیاس پذیری)، به برخی شیوه های مدیریت این چالش ها و تجربه های شخصی میپردازیم.
بیشتر بخوانید (مقالات / مفاهیم مرتبط):
دسترسی پذیری بالا HA
گلوگاه Bottleneck
خوشه ها Cluster
تئوری CAP
مقیاس پذیری Scalability
سیستم های توزیع شده Distributed Systems
#مهندسی_نرمافزار #معماری
#software_engineering #architecture #Scalability #distributed_systems #devops #infrastructure
@csharpfriends @Code_Crafters
👍5❤1
CodeCrafters
#مقیاس_پذیری و چالش های آن - پارت 1 Horizontal & Vertical #Scaling ⚖️ زمانی که فرآیند تولید نرم افزار به مرحله Production میرسد و اپلیکیشن روی سرور میرود، چالشها و مخاطرات جدیدی برای صاحبان آن ایجاد میشود. ما در عصری هستیم که استفاده از اینترنت به سبک…
Example of Microservices System design template overview
#microservices #Scaling #bestpractice #architecture #distributed_systems #مهندسی_نرمافزار
- برخی از شماتیک معماری دیگر پروژه های معروف در کامنت ها
@csharpfriends @Code_Crafters
#microservices #Scaling #bestpractice #architecture #distributed_systems #مهندسی_نرمافزار
- برخی از شماتیک معماری دیگر پروژه های معروف در کامنت ها
@csharpfriends @Code_Crafters
👍4❤2
CodeCrafters
#مقیاس_پذیری و چالش های آن - پارت 1 Horizontal & Vertical #Scaling ⚖️ زمانی که فرآیند تولید نرم افزار به مرحله Production میرسد و اپلیکیشن روی سرور میرود، چالشها و مخاطرات جدیدی برای صاحبان آن ایجاد میشود. ما در عصری هستیم که استفاده از اینترنت به سبک…
دورنمای بسیار ساده و خلاصه لودبالانسینگ در معماری و طراحی میکروسرویس ها
در مطالب آینده درباره لودبالانسینگ یا توزیع بار صحبت خواهیم کرد
#microservices #load_balancing #api_gateway #Scaling #architecture #مهندسی_نرمافزار
@csharpfriends @Code_Crafters
در مطالب آینده درباره لودبالانسینگ یا توزیع بار صحبت خواهیم کرد
#microservices #load_balancing #api_gateway #Scaling #architecture #مهندسی_نرمافزار
@csharpfriends @Code_Crafters
👍4❤3👏1
میکروسرویس و حکمرانی soa، در ادامه مباحث مربوط به سیاستهای سازمانی soa در ادامه میریم به سراغ سیاستهای امنیتی
امنیت بخش جدا ناپذیر دنیای امروزی هست و مشتریان ما خواهان امن بودن اطلاعات حساس خود در سامانه شما هستند برای مثال اطلاعات شخصی و موارد مالی افراد، مشتریان انتظار دارن که شما امنیت اطلاعات رو محفوظ تضمین کنید
سیاستهای امنیتی
یک کانال ارتباطی را برای داده های حساس رمزگذاری کنید: هنگامی که یک مصرف کنندهش به سرویسی دسترسی پیدا می کند که حاوی اطلاعات حساس است یا به آن نیاز دارد (به عنوان مثال، اطلاعات کارت اعتباری یا جزئیات شخصی)، این سرویس باید ارتباطات را به صورت ایمن مدیریت کند. این سیاست برای شروع خوب است. با استفاده از آن می توانید مطمئن شوید که ارتباطات را در سطح جابجایی رمزگذاری می کنید.
یکپارچگی و عدم انکار پیام را تأیید کنید: مهم است که بتوانید تشخیص دهید که آیا مشکلی در پیام وجود دارد. ممکن است در حین جابجایی تغییر داده شود، یا ممکن است شخصی جعل هویت شخص دیگری باشد. اگر مطمئن هستید که خدمات شما با این خطمشی مطابقت دارد، میتوانید تضمین کنید که فقط پیامهایی را پردازش میکنید که میدانید معتبر هستند.
از یک سیستم هویت متمرکز برای احراز هویت استفاده کنید: احراز هویت مصرف کنندگان (یا کاربران داخلی شما) چیزی است که تقریباً همه خدمات به آن نیاز دارند. اغلب این برای هر سرویس دوباره اختراع می شود. با استفاده از یک سیستم هویت متمرکز، می توانید مطمئن شوید که هر سرویس از سیاست های سختگیرانه ای که در مورد شناسایی تعیین شده است پیروی می کند.
از یک سیستم هویت متمرکز برای مجوز استفاده کنید: قوانین مشابهی برای مجوز اعمال می شود. این اغلب چیزی است که در گذشته به برنامه ها اضافه می شود و نگهداری از آن اغلب دشوار است. با متمرکز کردن مجوز می توانید مطمئن شوید که همه سرویس ها از دستورالعمل های مجوز یکسانی که در سازمان تعریف شده است پیروی می کنند.
وب سرویس خود را بشناسید و یکپارچگی پیام را در آن رعایت و پیاده سازی کنید (SOAP, REST, ...) برای مثال در REST این مسئله با https فراهم گشته اما اگر جایی این پروتکل نبود میتوانید از HMAC استفاده کنید، کمپانی های بزرگی مانند azure, aws, ... از این موضوع برای سرویس REST خود استفاده میکنند و عموما یک رویکرد مشابه دارن، یک سرویس تولید HMAC بالا بیاورید کاربر قبل از ارسال پیام به شما یک کلید گرفته و همراه پیام برای شما ارسال میکند شما پیام را گرفته و بر اساس پارامترهای خود از سرویس HMAC کلید رو میگیرید حالا دو کلید HMAC رو باهم مقایسه کرده و یکپارچگی و یا عدم یکپارچگی رو تایید کنید، اما سوال پارامترهای ورودی ما چه چیزهایی باشد، AWS به شکل زیر عمل میکند
یک سیستم احرازهویت مرکزی و مجوزدهی (authentication, authorization) راه اندازی کنید SSO (دقت کنید ممکن سیستم مجوز هی شما متفاوت از هویت سنجی باشد این بستگی به سیستم شما دارد) (در کتاب که بر اساس جاوا نوشته شده، پلتفرم openam را معرفی و پیش برده، در پستهای قبلی کانال راجب keycloak صحبت شد)
#microservice
#soa
@code_crafters
امنیت بخش جدا ناپذیر دنیای امروزی هست و مشتریان ما خواهان امن بودن اطلاعات حساس خود در سامانه شما هستند برای مثال اطلاعات شخصی و موارد مالی افراد، مشتریان انتظار دارن که شما امنیت اطلاعات رو محفوظ تضمین کنید
سیاستهای امنیتی
یک کانال ارتباطی را برای داده های حساس رمزگذاری کنید: هنگامی که یک مصرف کنندهش به سرویسی دسترسی پیدا می کند که حاوی اطلاعات حساس است یا به آن نیاز دارد (به عنوان مثال، اطلاعات کارت اعتباری یا جزئیات شخصی)، این سرویس باید ارتباطات را به صورت ایمن مدیریت کند. این سیاست برای شروع خوب است. با استفاده از آن می توانید مطمئن شوید که ارتباطات را در سطح جابجایی رمزگذاری می کنید.
یکپارچگی و عدم انکار پیام را تأیید کنید: مهم است که بتوانید تشخیص دهید که آیا مشکلی در پیام وجود دارد. ممکن است در حین جابجایی تغییر داده شود، یا ممکن است شخصی جعل هویت شخص دیگری باشد. اگر مطمئن هستید که خدمات شما با این خطمشی مطابقت دارد، میتوانید تضمین کنید که فقط پیامهایی را پردازش میکنید که میدانید معتبر هستند.
از یک سیستم هویت متمرکز برای احراز هویت استفاده کنید: احراز هویت مصرف کنندگان (یا کاربران داخلی شما) چیزی است که تقریباً همه خدمات به آن نیاز دارند. اغلب این برای هر سرویس دوباره اختراع می شود. با استفاده از یک سیستم هویت متمرکز، می توانید مطمئن شوید که هر سرویس از سیاست های سختگیرانه ای که در مورد شناسایی تعیین شده است پیروی می کند.
از یک سیستم هویت متمرکز برای مجوز استفاده کنید: قوانین مشابهی برای مجوز اعمال می شود. این اغلب چیزی است که در گذشته به برنامه ها اضافه می شود و نگهداری از آن اغلب دشوار است. با متمرکز کردن مجوز می توانید مطمئن شوید که همه سرویس ها از دستورالعمل های مجوز یکسانی که در سازمان تعریف شده است پیروی می کنند.
وب سرویس خود را بشناسید و یکپارچگی پیام را در آن رعایت و پیاده سازی کنید (SOAP, REST, ...) برای مثال در REST این مسئله با https فراهم گشته اما اگر جایی این پروتکل نبود میتوانید از HMAC استفاده کنید، کمپانی های بزرگی مانند azure, aws, ... از این موضوع برای سرویس REST خود استفاده میکنند و عموما یک رویکرد مشابه دارن، یک سرویس تولید HMAC بالا بیاورید کاربر قبل از ارسال پیام به شما یک کلید گرفته و همراه پیام برای شما ارسال میکند شما پیام را گرفته و بر اساس پارامترهای خود از سرویس HMAC کلید رو میگیرید حالا دو کلید HMAC رو باهم مقایسه کرده و یکپارچگی و یا عدم یکپارچگی رو تایید کنید، اما سوال پارامترهای ورودی ما چه چیزهایی باشد، AWS به شکل زیر عمل میکند
روش HTTP:
با REST نوعی از روش HTTP که اجرا می کنید رفتار سمت سرور را مشخص می کند. DELETE به یک URL خاص به طور متفاوتی با GET به آن URL مدیریت می شود
هدر Content-MD5:
این هدر HTTP یک هدر استاندارد HTTP است.این یک هش MD5 از بدنه درخواست است.اگر این هدر را در تولید کد HMAC قرار دهید، یک مقدار HMAC دریافت می کنید که با تغییر بدنه درخواست تغییر می کند
هدر Content-Type:
هدر Content-Type یک هدر مهم هنگام برقراری تماس های REST است. بسته به نوع رسانه، سرور می تواند به یک درخواست پاسخ متفاوتی بدهد.بنابراین باید در HMAC گنجانده شود.
هدر تاریخ:
شما همچنین تاریخ ایجاد درخواست برای محاسبه HMAC را درج می کنید. در سمت سرور می توانید مطمئن شوید که تاریخ در حین انتقال تغییر نکرده است. علاوه بر این می توانید قابلیت انقضای پیام را در سرور اضافه کنید.
مسیر روش HTTP:
بخشی از مسیر URL که فراخوانی شده است نیز در محاسبه HMAC استفاده می شود، زیرا یک URI منبعی را در REST شناسایی می کند.
یک سیستم احرازهویت مرکزی و مجوزدهی (authentication, authorization) راه اندازی کنید SSO (دقت کنید ممکن سیستم مجوز هی شما متفاوت از هویت سنجی باشد این بستگی به سیستم شما دارد) (در کتاب که بر اساس جاوا نوشته شده، پلتفرم openam را معرفی و پیش برده، در پستهای قبلی کانال راجب keycloak صحبت شد)
#microservice
#soa
@code_crafters
👍4👏2
چهل نکته درباره Linux Server Hardening
۱. رمزنگاری ارتباطات در سرور لینوکس:
تمام دادههایی که از شبکه ارسال میشوند، قابل شنود هستند. بهتر است همیشه دادههای ارسالی را با رمزنگاری کردن، محافظت کنیم.
برای انتقال فایل میتوان از scp, ssh, rsync و sftp استفاده کرد که همگی رمزنگاری دارند. همچنین میتوان درایو سرور دیگر یا home کاربری خود را با استفاده از sshfs یا fuse محافظت شده مانت کرد.
برای رمزنگاری دادههای خروجی، میتوان از گنوپیجی استفاده کرد. همچنین برای اتصالات شبکهای میتوان از اپنویپیان یا تینک استفاده کرد که ارتباطات شبکهای را رمزنگاری میکنند.
برای رمزنگاری وبسرورها نیز میتوان از الایتتیپیدی، آپاچی و انجیناکس با استفاده از SSL استفاده کرد.
۲. از استفاده از سرویسهای FTP، Telnet و Rlogin/Rsh در لینوکس خودداری کنید!!
از استفاده از سرویسهای FTP، Telnet و Rlogin/Rsh در لینوکس خودداری کنید.
در بسیاری از تنظیمات شبکه، نام کاربریها، رمزهای عبور، دستورات FTP/telnet/rsh و فایلهای انتقالی توسط هر فردی که در همان شبکه حضور دارد، با استفاده از یک برنامه (Packet Sniffer)، قابل ضبط میباشند. راه حل معمول برای این مشکل استفاده از OpenSSH، SFTP یا FTPS (FTP over SSL) است که به FTP رمزنگاری SSL یا TLS را اضافه میکنند.
برای حذف سرویسهای قدیمی و غیرمطمئن مانند NIS، rsh و سایر سرویسها، دستور yum زیر را وارد کنید:
yum erase xinetd ypserv tftp-server telnet-server rsh-server
اگر از سرور مبتنی بر دبیان/اوبونتو استفاده میکنید، از دستور apt-get/apt برای حذف سرویسهای ناامن استفاده کنید.
sudo apt-get --purge remove xinetd nis yp-tools tftpd atftpd tftpd-hpa telnetd rsh-server rsh-redone-server
توضیح:
این بخش از متن به شما هشدار میدهد که استفاده از سرویسهای FTP، Telnet و Rlogin/Rsh در لینوکس باعث بروز ریسک امنیتی میشود. در شبکههای عمومی، اطلاعات کاربران، رمزهای عبور، دستورات و فایلهای انتقالی به راحتی توسط افرادی که در همان شبکه حضور دارند قابل ضبط و دسترسی هستند. برای حل این مشکل، توصیه میشود از سرویسهای امنتر مانند OpenSSH، SFTP و FTPS استفاده کنید. همچنین، دستورات لازم برای حذف سرویسهای قدیمی و غیرمطمئن از سیستمعامل لینوکس نیز در اینجا آورده شده است.
packet sniffer:
برنامه (Packet Sniffer) یک نوع نرمافزار یا دستگاه است که بستههای دادهای که در یک شبکه عبور میکنند را ضبط و تجزیه میکند. هدف اصلی این برنامهها، مشاهده و آنالیز ترافیک شبکه است.
وقتی دادهها در یک شبکه ارسال میشوند، آنها به شکل بستههای کوچکتر تقسیم میشوند که حاوی اطلاعات مانند آدرس مبدأ و مقصد، داده اصلی و سایر اطلاعات مربوطه هستند. برنامههای packet sniffer این بستهها را دریافت کرده و میتوانند اطلاعات مفیدی مانند نام کاربری، رمز عبور، دستورات ارسالی و فایلهای انتقالی را از آنها استخراج کنند.
استفاده از برنامههای packet sniffer در شبکههای عمومی یا شبکههایی که به آنها دسترسی عمومی دارید، ممکن است برای جاسوسی یا به دست آوردن اطلاعات حساس به کار گرفته شود. با استفاده از این برنامه ها، فرد مورد نظر میتواند بستههای شبکه را ضبط کند و اطلاعات را بررسی کند، حتی اگر این اطلاعات به طور عادی رمزنگاری شده باشند.
از طرف دیگر، برنامههای packet sniffer نیز میتوانند به عنوان ابزارهای مفیدی برای آنالیز و عیبیابی شبکه استفاده شوند. با استفاده از این برنامهها، میتوانید ترافیک شبکه را بررسی کنید، مشکلات را تشخیص دهید و عملکرد بهتری را برای شبکه خود فراهم کنید.
برنامههای packet sniffer معمولاً در قالب نرمافزارهای مختلفی مانند Wireshark، tcpdump، WinPcap و Capsa قابل دسترسی هستند و در سیستمعاملهای مختلفی مانند لینوکس و ویندوز قابل استفاده هستند.
۳. کاهش نرم افزار های نصب شده به منظور کاهش آسیب پذیری در لینوکس:
آیا واقعا نیاز به همه نوع سرویس هایی که نصب شده اند دارید؟ با حذف نرم افزار های اضافی امنیت و عملکرد سرور خودتون رو بهبود ببخشید.
از مدیر بسته RPM مانند yum یا apt-get و/یا dpkg استفاده کنید تا مجموعهای از نرمافزارهای نصب شده روی سیستم را بررسی کنید. تمامی بستههای ناخواسته را حذف کنید.
yum list installed
yum list packageName
yum remove packageName
یا
dpkg --list
dpkg --info packageName
apt-get remove packageName
#linux
#hardning
@code_crafters
۱. رمزنگاری ارتباطات در سرور لینوکس:
تمام دادههایی که از شبکه ارسال میشوند، قابل شنود هستند. بهتر است همیشه دادههای ارسالی را با رمزنگاری کردن، محافظت کنیم.
برای انتقال فایل میتوان از scp, ssh, rsync و sftp استفاده کرد که همگی رمزنگاری دارند. همچنین میتوان درایو سرور دیگر یا home کاربری خود را با استفاده از sshfs یا fuse محافظت شده مانت کرد.
برای رمزنگاری دادههای خروجی، میتوان از گنوپیجی استفاده کرد. همچنین برای اتصالات شبکهای میتوان از اپنویپیان یا تینک استفاده کرد که ارتباطات شبکهای را رمزنگاری میکنند.
برای رمزنگاری وبسرورها نیز میتوان از الایتتیپیدی، آپاچی و انجیناکس با استفاده از SSL استفاده کرد.
۲. از استفاده از سرویسهای FTP، Telnet و Rlogin/Rsh در لینوکس خودداری کنید!!
از استفاده از سرویسهای FTP، Telnet و Rlogin/Rsh در لینوکس خودداری کنید.
در بسیاری از تنظیمات شبکه، نام کاربریها، رمزهای عبور، دستورات FTP/telnet/rsh و فایلهای انتقالی توسط هر فردی که در همان شبکه حضور دارد، با استفاده از یک برنامه (Packet Sniffer)، قابل ضبط میباشند. راه حل معمول برای این مشکل استفاده از OpenSSH، SFTP یا FTPS (FTP over SSL) است که به FTP رمزنگاری SSL یا TLS را اضافه میکنند.
برای حذف سرویسهای قدیمی و غیرمطمئن مانند NIS، rsh و سایر سرویسها، دستور yum زیر را وارد کنید:
yum erase xinetd ypserv tftp-server telnet-server rsh-server
اگر از سرور مبتنی بر دبیان/اوبونتو استفاده میکنید، از دستور apt-get/apt برای حذف سرویسهای ناامن استفاده کنید.
sudo apt-get --purge remove xinetd nis yp-tools tftpd atftpd tftpd-hpa telnetd rsh-server rsh-redone-server
توضیح:
این بخش از متن به شما هشدار میدهد که استفاده از سرویسهای FTP، Telnet و Rlogin/Rsh در لینوکس باعث بروز ریسک امنیتی میشود. در شبکههای عمومی، اطلاعات کاربران، رمزهای عبور، دستورات و فایلهای انتقالی به راحتی توسط افرادی که در همان شبکه حضور دارند قابل ضبط و دسترسی هستند. برای حل این مشکل، توصیه میشود از سرویسهای امنتر مانند OpenSSH، SFTP و FTPS استفاده کنید. همچنین، دستورات لازم برای حذف سرویسهای قدیمی و غیرمطمئن از سیستمعامل لینوکس نیز در اینجا آورده شده است.
packet sniffer:
برنامه (Packet Sniffer) یک نوع نرمافزار یا دستگاه است که بستههای دادهای که در یک شبکه عبور میکنند را ضبط و تجزیه میکند. هدف اصلی این برنامهها، مشاهده و آنالیز ترافیک شبکه است.
وقتی دادهها در یک شبکه ارسال میشوند، آنها به شکل بستههای کوچکتر تقسیم میشوند که حاوی اطلاعات مانند آدرس مبدأ و مقصد، داده اصلی و سایر اطلاعات مربوطه هستند. برنامههای packet sniffer این بستهها را دریافت کرده و میتوانند اطلاعات مفیدی مانند نام کاربری، رمز عبور، دستورات ارسالی و فایلهای انتقالی را از آنها استخراج کنند.
استفاده از برنامههای packet sniffer در شبکههای عمومی یا شبکههایی که به آنها دسترسی عمومی دارید، ممکن است برای جاسوسی یا به دست آوردن اطلاعات حساس به کار گرفته شود. با استفاده از این برنامه ها، فرد مورد نظر میتواند بستههای شبکه را ضبط کند و اطلاعات را بررسی کند، حتی اگر این اطلاعات به طور عادی رمزنگاری شده باشند.
از طرف دیگر، برنامههای packet sniffer نیز میتوانند به عنوان ابزارهای مفیدی برای آنالیز و عیبیابی شبکه استفاده شوند. با استفاده از این برنامهها، میتوانید ترافیک شبکه را بررسی کنید، مشکلات را تشخیص دهید و عملکرد بهتری را برای شبکه خود فراهم کنید.
برنامههای packet sniffer معمولاً در قالب نرمافزارهای مختلفی مانند Wireshark، tcpdump، WinPcap و Capsa قابل دسترسی هستند و در سیستمعاملهای مختلفی مانند لینوکس و ویندوز قابل استفاده هستند.
۳. کاهش نرم افزار های نصب شده به منظور کاهش آسیب پذیری در لینوکس:
آیا واقعا نیاز به همه نوع سرویس هایی که نصب شده اند دارید؟ با حذف نرم افزار های اضافی امنیت و عملکرد سرور خودتون رو بهبود ببخشید.
از مدیر بسته RPM مانند yum یا apt-get و/یا dpkg استفاده کنید تا مجموعهای از نرمافزارهای نصب شده روی سیستم را بررسی کنید. تمامی بستههای ناخواسته را حذف کنید.
yum list installed
yum list packageName
yum remove packageName
یا
dpkg --list
dpkg --info packageName
apt-get remove packageName
#linux
#hardning
@code_crafters
❤3👍3
اجرا هر سرویس در یک سیستم نمونه مجازی:
اجرای سرویسهای شبکه مختلف را در سرورها یا نمونههای مجازی جداگانه انجام دهید. این محدودیت تعداد سرویسهای دیگری که ممکن است قربانی شود را محدود میکند. به عنوان مثال، اگر یک حملهکننده قادر به بهرهبرداری موفق از یک نرمافزار مانند Apache شود، او میتواند به تمامی سرور شامل سرویسهای دیگری مانند MySQL/MariaDB/PGSql، سرور ایمیل و غیره دسترسی پیدا کند.
مثال:
فرض کنید شما یک سرور لینوکس دارید که شامل سرویسهای Apache و MySQL است. به جای اجرای هر دو سرویس روی یک سرور، شما میتوانید سرور Apache را روی یک سیستم مجازی و سرور MySQL را روی یک سیستم مجازی جداگانه اجرا کنید. اینکار به شما امکان میدهد که سرویسهای مختلف را در محیطی مستقل و جداگانه اجرا کنید. در نتیجه، اگر سرویس Apache مورد عنایت قرار گیرد، دسترسی به سرویس MySQL در سیستم مجازی جداگانه محدود خواهد شد و امنیت سیستم شما حفظ خواهد شد.
استفاده از کانتینر داکر میتواند یک روش مناسب برای پیادهسازی این رویکرد باشد. با استفاده از کانتینرها، شما میتوانید هر سرویس شبکه را در یک کانتینر جداگانه اجرا کنید. این کانتینرها محیطی مستقل از یکدیگر ایجاد میکنند و از هم جدا بوده و امکان دسترسی به سرویسهای دیگر را محدود میکنند.
برای پیادهسازی این رویکرد با استفاده از کانتینر داکر، شما میتوانید به شکل زیر عمل کنید:
1. ایجاد یک تصویر داکر برای هر سرویس شبکه: شما باید یک تصویر داکر برای هر سرویس شبکه مورد نظر ایجاد کنید. این تصویر شامل تنظیمات و پیکربندیهای مربوط به سرویس شبکه خاص است.
2. اجرای کانتینرها: با استفاده از ابزار داکر، شما میتوانید کانتینرهای مربوط به هر سرویس را بر اساس تصاویر داکر ایجاد شده، اجرا کنید. هر کانتینر در یک محیط مجازی جداگانه اجرا میشود و از هم جدا است.
3. پیکربندی شبکه: برای ارتباط بین کانتینرها و اجرای سرویسهای شبکه، شما میتوانید شبکههای داکر را پیکربندی کنید. این شبکهها به کانتینرها امکان میدهند تا از طریق شبکه با یکدیگر ارتباط برقرار کنند.
با این رویکرد، شما هر سرویس شبکه را در یک کانتینر جداگانه اجرا میکنید و از ارتباط مستقیم بین سرویسها جلوگیری میکنید. اگر یک سرویس تحت حمله قرار بگیرد، تأثیر آن روی سایر سرویسها محدود خواهد بود و امنیت سیستم شما حفظ میشود.
۵. نگهداری از هسته لینوکس و بروز بودن نرم افزار ها:
اعمال پچهای امنیتی بخش مهمی از نگهداری سرور لینوکس است. لینوکس ابزارهای لازم برای بهروزرسانی سیستم شما را فراهم میکند و همچنین امکان بهروزرسانی آسان بین نسخهها را فراهم میکند. تمامی بروزرسانیهای امنیتی باید اعمال شوند. از مدیر بسته RPM مانند yum و/یا apt-get و/یا dpkg برای اعمال تمامی بروزرسانیهای امنیتی استفاده کنید.
# yum update
یا
# apt-get update && apt-get upgrade
شما میتوانید Red Hat / CentOS / Fedora Linux را بهگونهای پیکربندی کنید که از طریق ایمیل اطلاعیههای بروزرسانی بسته yum را دریافت کند. یک گزینه دیگر نیز استفاده از کرون جاب برای اعمال تمامی بروزرسانیهای امنیتی است. در Debian / Ubuntu Linux میتوانید از apticron برای ارسال اطلاعیههای امنیتی استفاده کنید. همچنین امکان پیکربندی بروزرسانیهای بدون نیاز به تداخل برای سرور Debian / Ubuntu Linux با استفاده از دستور apt-get/apt نیز وجود دارد:
$ sudo apt-get install unattended-upgrades apt-listchanges bsd-mailx
نحوه پیکربندی apticron:
برای استفاده از apticron در سرور Debian/Ubuntu Linux و ارسال اطلاعیههای امنیتی، میتوانید مراحل زیر را دنبال کنید:
1. نصب apticron: ابتدا باید برنامه apticron را در سیستم خود نصب کنید. برای این کار، از دستور زیر استفاده کنید:
sudo apt-get install apticron
2. پیکربندی apticron: پس از نصب، باید فایل تنظیمات apticron را پیکربندی کنید. فایل پیکربندی برای apticron در مسیر /etc/apticron/apticron.conf قرار دارد. باز کنید و ویرایش کنید:
sudo nano /etc/apticron/apticron.conf
3. تنظیمات ایمیل: در فایل تنظیمات، بخشی با عنوان EMAIL وجود دارد. در این بخش، آدرس ایمیل خود را به جای [email protected] قرار دهید. برای مثال:
EMAIL="[email protected]"
4. تنظیمات بستههای اطلاعیههای امنیتی: در فایل تنظیمات، بخشی با عنوان PACKAGE_NAMES وجود دارد. در این بخش، باید نام بستههایی که میخواهید اطلاعیههای امنیتی آنها را دریافت کنید را مشخص کنید. برای مثال:
PACKAGE_NAMES="apache2 mysql-server php"
5. ذخیره و بستن فایل تنظیمات: پس از اعمال تغییرات، فایل را ذخیره کنید و ببندید
#linux
#hardning
@code_crafters
اجرای سرویسهای شبکه مختلف را در سرورها یا نمونههای مجازی جداگانه انجام دهید. این محدودیت تعداد سرویسهای دیگری که ممکن است قربانی شود را محدود میکند. به عنوان مثال، اگر یک حملهکننده قادر به بهرهبرداری موفق از یک نرمافزار مانند Apache شود، او میتواند به تمامی سرور شامل سرویسهای دیگری مانند MySQL/MariaDB/PGSql، سرور ایمیل و غیره دسترسی پیدا کند.
مثال:
فرض کنید شما یک سرور لینوکس دارید که شامل سرویسهای Apache و MySQL است. به جای اجرای هر دو سرویس روی یک سرور، شما میتوانید سرور Apache را روی یک سیستم مجازی و سرور MySQL را روی یک سیستم مجازی جداگانه اجرا کنید. اینکار به شما امکان میدهد که سرویسهای مختلف را در محیطی مستقل و جداگانه اجرا کنید. در نتیجه، اگر سرویس Apache مورد عنایت قرار گیرد، دسترسی به سرویس MySQL در سیستم مجازی جداگانه محدود خواهد شد و امنیت سیستم شما حفظ خواهد شد.
استفاده از کانتینر داکر میتواند یک روش مناسب برای پیادهسازی این رویکرد باشد. با استفاده از کانتینرها، شما میتوانید هر سرویس شبکه را در یک کانتینر جداگانه اجرا کنید. این کانتینرها محیطی مستقل از یکدیگر ایجاد میکنند و از هم جدا بوده و امکان دسترسی به سرویسهای دیگر را محدود میکنند.
برای پیادهسازی این رویکرد با استفاده از کانتینر داکر، شما میتوانید به شکل زیر عمل کنید:
1. ایجاد یک تصویر داکر برای هر سرویس شبکه: شما باید یک تصویر داکر برای هر سرویس شبکه مورد نظر ایجاد کنید. این تصویر شامل تنظیمات و پیکربندیهای مربوط به سرویس شبکه خاص است.
2. اجرای کانتینرها: با استفاده از ابزار داکر، شما میتوانید کانتینرهای مربوط به هر سرویس را بر اساس تصاویر داکر ایجاد شده، اجرا کنید. هر کانتینر در یک محیط مجازی جداگانه اجرا میشود و از هم جدا است.
3. پیکربندی شبکه: برای ارتباط بین کانتینرها و اجرای سرویسهای شبکه، شما میتوانید شبکههای داکر را پیکربندی کنید. این شبکهها به کانتینرها امکان میدهند تا از طریق شبکه با یکدیگر ارتباط برقرار کنند.
با این رویکرد، شما هر سرویس شبکه را در یک کانتینر جداگانه اجرا میکنید و از ارتباط مستقیم بین سرویسها جلوگیری میکنید. اگر یک سرویس تحت حمله قرار بگیرد، تأثیر آن روی سایر سرویسها محدود خواهد بود و امنیت سیستم شما حفظ میشود.
۵. نگهداری از هسته لینوکس و بروز بودن نرم افزار ها:
اعمال پچهای امنیتی بخش مهمی از نگهداری سرور لینوکس است. لینوکس ابزارهای لازم برای بهروزرسانی سیستم شما را فراهم میکند و همچنین امکان بهروزرسانی آسان بین نسخهها را فراهم میکند. تمامی بروزرسانیهای امنیتی باید اعمال شوند. از مدیر بسته RPM مانند yum و/یا apt-get و/یا dpkg برای اعمال تمامی بروزرسانیهای امنیتی استفاده کنید.
# yum update
یا
# apt-get update && apt-get upgrade
شما میتوانید Red Hat / CentOS / Fedora Linux را بهگونهای پیکربندی کنید که از طریق ایمیل اطلاعیههای بروزرسانی بسته yum را دریافت کند. یک گزینه دیگر نیز استفاده از کرون جاب برای اعمال تمامی بروزرسانیهای امنیتی است. در Debian / Ubuntu Linux میتوانید از apticron برای ارسال اطلاعیههای امنیتی استفاده کنید. همچنین امکان پیکربندی بروزرسانیهای بدون نیاز به تداخل برای سرور Debian / Ubuntu Linux با استفاده از دستور apt-get/apt نیز وجود دارد:
$ sudo apt-get install unattended-upgrades apt-listchanges bsd-mailx
نحوه پیکربندی apticron:
برای استفاده از apticron در سرور Debian/Ubuntu Linux و ارسال اطلاعیههای امنیتی، میتوانید مراحل زیر را دنبال کنید:
1. نصب apticron: ابتدا باید برنامه apticron را در سیستم خود نصب کنید. برای این کار، از دستور زیر استفاده کنید:
sudo apt-get install apticron
2. پیکربندی apticron: پس از نصب، باید فایل تنظیمات apticron را پیکربندی کنید. فایل پیکربندی برای apticron در مسیر /etc/apticron/apticron.conf قرار دارد. باز کنید و ویرایش کنید:
sudo nano /etc/apticron/apticron.conf
3. تنظیمات ایمیل: در فایل تنظیمات، بخشی با عنوان EMAIL وجود دارد. در این بخش، آدرس ایمیل خود را به جای [email protected] قرار دهید. برای مثال:
EMAIL="[email protected]"
4. تنظیمات بستههای اطلاعیههای امنیتی: در فایل تنظیمات، بخشی با عنوان PACKAGE_NAMES وجود دارد. در این بخش، باید نام بستههایی که میخواهید اطلاعیههای امنیتی آنها را دریافت کنید را مشخص کنید. برای مثال:
PACKAGE_NAMES="apache2 mysql-server php"
5. ذخیره و بستن فایل تنظیمات: پس از اعمال تغییرات، فایل را ذخیره کنید و ببندید
#linux
#hardning
@code_crafters
❤4👍1
در ادامه حکمرانی soa میرسیم به سراغ تست نویسی ،اما چرا این بخش وجود دارد، سوا از اینکه تست نویسی در قلمرو soa نمیگنجد، اما این یک الزام همیشگی میباشد که باید در تمام نقاط و کدهای خود انجام دهید تا از درستی و سلامت کار کرد کدهای خود آگاه شوید و سرویسهای خود را از راه دور فرا بخوانید تا مطمئن شوید به درستی کار میکنن
سیاستهای تست نویسی:
در بخش مربوط به لایه منطقی و لایه داده اگر شما unittest نوشته باشید حجت رو تموم کردهاید، اما میتوانید و بهتر است با mock نیز تست کنید
در تست لایه ارتباطی خود(لایه راه دور) دو موضوع اهمیت دارد، یک تست پروتکل ارتباطی بین سرور و مشتری، دو تست تبدیل دادههای بین سرور و مستری و جاساز آن به درستی(در این تست شما به ذخیره سازی داده اهمیت نمیدهید)
تست ادغام(integration): سرویس های شما با هم در ارتباط هستند و این نیازمند تست می باشد تا مطمئن شوید جریان شما صحیح و به درستی کار میکند
در ادامه مبحث این تستهای شما نیست که تنها اهمیت دارد بلکه کیفیت کدها نیز اهمیت بالای دارد، که کدام بخش از کد شما در سطح بهتری کار میکند(در کتاب از ابزار sonar برای بررسی کیفیت کد اسم برده) معیارهای خروجی این برنامه میتواند نقطه شروع سیاست گذاری ما باشد:
مورد بعدی توسعه برای cloud می باشد که در پستهای قبلی در خصوص صفات و ویژگیهای آن کامل توضیح داده شده است
لینک تکمیلی پست
#microservice
#soa
@code_crafters
سیاستهای تست نویسی:
لایه ادغام:
تست کنید تا ببینید آیا تمام اجزای مختلف همانطور که انتظار می رود با هم کار می کنند یا خیر. این ممکن است شامل تماس هایی با استفاده از چندین سرویس باشد.
لایه سرویس از راه دور:
تست کنید تا ببینید آیا می توانید با لایه راه دور سرویس تماس بگیرید و آیا این لایه به درستی تبدیل داده ها از فرمت راه دور به فرمت داخلی را انجام می دهد یا خیر. برای این کار باید یک الگو از لایه سرویس خود بسازید، اما بعداً در مورد آن بیشتر توضیح دهید.
لایه منطقی:
در اینجا شما تست می کنید که آیا منطق تجاری لایه سرویس و مدل به درستی پیاده سازی شده است یا خیر. برای آزمایش این لایه، دوباره باید از اشیاء ساختگی، این بار برای لایه داده استفاده کنید.
لایه داده:
در لایه داده شما آزمایش می کنید که آیا اطلاعات به درستی باقی می مانند یا خیر.
در بخش مربوط به لایه منطقی و لایه داده اگر شما unittest نوشته باشید حجت رو تموم کردهاید، اما میتوانید و بهتر است با mock نیز تست کنید
در تست لایه ارتباطی خود(لایه راه دور) دو موضوع اهمیت دارد، یک تست پروتکل ارتباطی بین سرور و مشتری، دو تست تبدیل دادههای بین سرور و مستری و جاساز آن به درستی(در این تست شما به ذخیره سازی داده اهمیت نمیدهید)
تست ادغام(integration): سرویس های شما با هم در ارتباط هستند و این نیازمند تست می باشد تا مطمئن شوید جریان شما صحیح و به درستی کار میکند
در ادامه مبحث این تستهای شما نیست که تنها اهمیت دارد بلکه کیفیت کدها نیز اهمیت بالای دارد، که کدام بخش از کد شما در سطح بهتری کار میکند(در کتاب از ابزار sonar برای بررسی کیفیت کد اسم برده) معیارهای خروجی این برنامه میتواند نقطه شروع سیاست گذاری ما باشد:
بیانیه:
ما می خواهیم خدمات ما حداقل سطح کیفی قابل اندازه گیری داشته باشد. سرویس ها باید به خوبی تست شده و استانداردهای کدگذاری را که ما تعریف کرده ایم تایید کنند. ما سطوح زیر را از انطباق تعریف می کنیم:
پوشش کد: حداقل 80% .موفقیت در تست: 100% .مسائل امنیتی: 0 .رعایت قوانین: 90%
منطق:
در سازمان ما برنامه ها و خدمات مختلفی داریم. آنها توسط افراد مختلف و تیم های مختلف ایجاد و نگهداری می شوند. برای اینکه افراد بتوانند کد دیگران را بخوانند و آن را حفظ کنند، میخواهیم مطمئن شویم که کد بهصورت یکسان ایجاد شده است.
علاوه بر این، ما می خواهیم سطح خاصی از کیفیت را در خدمات خود داشته باشیم. این به حفظ یک پایه کد با کیفیت بالا کمک می کند و منجر به صرف زمان کمتری برای کار مجدد و رفع اشکال می شود
پیامدها:
کد باید به طور گسترده آزمایش شود تا مطابق با خواسته های کیفیت خاص باشد. یک ساخت با کیفیت باید برای بررسی خودکار کیفیت کد تنظیم شود.
مورد بعدی توسعه برای cloud می باشد که در پستهای قبلی در خصوص صفات و ویژگیهای آن کامل توضیح داده شده است
لینک تکمیلی پست
#microservice
#soa
@code_crafters
❤2👍1👏1
در ادامه مباحث حاکمیت soa میرسیم به سیاستهای زمان اجرا، بعد از اتمام و اجرا کردن سرویس وقت آن فرا رسیده که نظارت جامعی بر روی انها و بررسی مطابقت آن با سیاستهای تعریف شده برسیم و چرخه عمر سرویس مشخص گردد، جهت نظارت بر زمان اجرا شما اینکار رو با ابزارهای مختلفی انجام میدهید و گزارشات آنرا بررسی میکنید(در کتاب در این فصل به پلتفرم BAMOS پرداخته و راجب آن صحبت میکند) و از سرویسهای مانیتورینگ استفاده نموده و رویدادهای خاصی رو تعریف کرده تا سیستم برای شما طبق آن گزارش تهیه کند
چرخه عمر سرویس به دلایل زیر قابل اهمیت میباشد:
چرخه عمر سرویس معمولاً در چهار فاز متمایز شناسایی میشوند: مدلسازی، مونتاژ، استقرار و مدیریت
فاز مدل:
در این فاز شما دو مرحله دارید، یک به الزامات تجاری که باید برآورده شود نگاه کنید(بررسی درخواست مشتریان و آنچه که انها نیاز دارند) دو شناسایی خدمات مورد نیاز برای ارائه این قابلیت تجاری(آیا این قابلیت از قبل در سیستم ما و سرویسهای ما وجود دارد؟؟؟آیا نیاز به توسعه یک سرویس جدید داریم؟؟؟آیا میشه یکی رو تمدید کرد؟؟)
فاز مونتاژ:
در این مرحله شما الزامات خدمات تجاری در فاز قبل رو دریافت کرده و آنرا به یک سرویس تبدیل میکنید و منتشر میسازید
فاز استقرار:
پس از ایجاد سرویس آن را در یک ظرف گذاشته و مستقر میکنید تا شروع به تبادل با سیستم نموده و یکپارچه گردد
فاز مدیریت:
مرحله نهایی مرحله مدیریت است. در این مرحله به نحوه عملکرد سرویس در زمان اجرا نگاه می کنید. شما تعیین میکنید که آیا خطمشیهایی که برای این سرویس تعریف کردهاید برآورده میشوند، آیا ممکن است به عملکرد جدیدی نیاز باشد یا خیر، و آیا همه خدماتی که تعریف کردهاید با اهداف تجاری تعیینشده در مرحله مدل مطابقت دارند یا خیر. اگر نیازهای جدیدی وجود داشته باشد یا اگر باید تغییراتی در سرویس موجود شما ایجاد شود، چرخه جدیدی را در فاز مدل شروع می کنید
سیاستهای چرخه عمر سرویس:
#microservice
#soa
@code_crafters
چرخه عمر سرویس به دلایل زیر قابل اهمیت میباشد:
■ به شناسایی خدماتی که نیاز به ایجاد یا بهروزرسانی دارند کمک میکند، زیرا یک نمای کلی از تمام سرویسهایی که در حال حاضر در حال تولید هستند را ارائه میدهد
■ کمک می کند تا مطمئن شوید که تمام اقدامات لازم قبل از تولید یا منسوخ شدن یک سرویس انجام شده است
■ تعیین خط مشی هایی که در هر مرحله باید رعایت شود استفاده کرد.
چرخه عمر سرویس معمولاً در چهار فاز متمایز شناسایی میشوند: مدلسازی، مونتاژ، استقرار و مدیریت
فاز مدل:
در این فاز شما دو مرحله دارید، یک به الزامات تجاری که باید برآورده شود نگاه کنید(بررسی درخواست مشتریان و آنچه که انها نیاز دارند) دو شناسایی خدمات مورد نیاز برای ارائه این قابلیت تجاری(آیا این قابلیت از قبل در سیستم ما و سرویسهای ما وجود دارد؟؟؟آیا نیاز به توسعه یک سرویس جدید داریم؟؟؟آیا میشه یکی رو تمدید کرد؟؟)
فاز مونتاژ:
در این مرحله شما الزامات خدمات تجاری در فاز قبل رو دریافت کرده و آنرا به یک سرویس تبدیل میکنید و منتشر میسازید
فاز استقرار:
پس از ایجاد سرویس آن را در یک ظرف گذاشته و مستقر میکنید تا شروع به تبادل با سیستم نموده و یکپارچه گردد
فاز مدیریت:
مرحله نهایی مرحله مدیریت است. در این مرحله به نحوه عملکرد سرویس در زمان اجرا نگاه می کنید. شما تعیین میکنید که آیا خطمشیهایی که برای این سرویس تعریف کردهاید برآورده میشوند، آیا ممکن است به عملکرد جدیدی نیاز باشد یا خیر، و آیا همه خدماتی که تعریف کردهاید با اهداف تجاری تعیینشده در مرحله مدل مطابقت دارند یا خیر. اگر نیازهای جدیدی وجود داشته باشد یا اگر باید تغییراتی در سرویس موجود شما ایجاد شود، چرخه جدیدی را در فاز مدل شروع می کنید
سیاستهای چرخه عمر سرویس:
شناسایی فرآیند کسب و کار:
در این مرحله شما تعریف میکنید که اگر میخواهید الزامات تجاری جدید را برآورده کنید، کدام فرآیندهای تجاری ممکن است نیاز به تغییر داشته باشند. این مرحله چرخه عمر قبل از تعریف هر سرویسی رخ می دهد، بنابراین در چرخه عمر سرویسی که در مخزن تعریف می کنید گنجانده نمی شود
شناسایی خدمات مورد نیاز:
پس از شناسایی فرآیندهای تجاری که درگیر هستند، میتوانید از آنها برای شناسایی خدماتی که ممکن است نیاز به بروزرسانی یا ایجاد جدید داشته باشند استفاده کنید. مانند مرحله قبل، این مرحله نیز خارج از رجیستری WSO2 نگه داشته می شود، زیرا در این مرحله منابعی را در مخزن ایجاد نکرده اید
قرارداد را تعریف کنید در این مرحله شما خدماتی که باید ایجاد کنید را می شناسید. در این مرحله شما قرارداد را تعریف خواهید کرد (یک WSDL در مورد WS-* و مجموعه ای از اسناد در مورد REST)
ثبت قرارداد:
بعد از اینکه قرارداد را تعریف کردید، می توانید آن را در مخزن WSO2 ثبت کنید
تحقق سرویس:
با قرارداد موجود در مخزن، می توانید اجرای سرویس را آغاز کنید. در این مرحله ممکن است تغییرات کوچکی در قراردادی که قبلاً در مخزن ذخیره شده است ایجاد کنید
سرویس را آزمایش کنید:
قبل از اینکه سرویس را اجرا کنید تا مصرف کنندگان سرویس شما بتوانند از آن استفاده کنند، ابتدا باید سرویس را آزمایش کنید.
استقرار سرویس:
پس از آزمایش، در نهایت می توانید سرویس را در یک کانتینر مستقر کنید و به مصرف کنندگان سرویس اطلاع دهید که می توانند از آن استفاده کنند
سرویس در دسترس:
پس از استقرار، سرویس در دسترس است. در این مرحله سرویس نظارت خواهد شد تا ببینیم آیا با سیاست های زمان اجرا مطابقت دارد یا خیر
سرویس منسوخ شده:
هنگامی که سرویس دیگر استفاده نمی شود یا نسخه جدیدی مستقر می شود، این سرویس می تواند به عنوان منسوخ شده علامت گذاری شود. در این صورت، مصرف کنندگان خدمات همچنان می توانند از این سرویس استفاده کنند اما باید به سرویس دیگری منتقل شوند، زیرا این سرویس به زودی بازنشسته خواهد شد
سرویس بازنشسته شد:
پس از اینکه یک سرویس منسوخ شد و باید حذف شود، سرویس را بازنشسته میکنید. اگر سرویسی بازنشسته شود، مصرف کنندگان خدمات دیگر نمی توانند به آن دسترسی داشته باشند.
#microservice
#soa
@code_crafters
❤2👍2
سوالات مربوط به سیاستهای بالا:
علاوه بر سرویسهای ما که دارای چرخه عمر هستند، برخی از سیاستهای ما نیز دارای یک عمر هستند و این ممکن است به دلایل مختلی از قبیل اعمال سیاست جدید، ایجاد خط مشی صنعتی جدید، تغییر خواستههای مشتریان و عدم سنجیده شدن سیاست ابلاغ شده و ... صورت گیرد
یک مخزن قابل جستجو و مشاهده سیاستهای خود بالا بیاورید و همچنین برای خدمات خود و توضیح مختصر آن تا بتوانید سریعا به اطلاعاتی در مورد آنها دست پیدا کنید
به انتهای کتاب حکمرانی soa رسیدیم ، سیاستهای آنرا مطالعه و جامعیت عملکردی آن را فهمیدیم، اکنون با دانش به این مسائل و موضوعات درک بهتر و پایه مقدماتی رو برای معماریهای جدیدی از قبیل microservice, DDD و .... و همچنین آمادگی اولیه برای زبان مدلسازی BPM را داریم
#microservice
#soa
@code_crafters
اولیه:
آیا قراردادی تعریف شده است؟
آیا مستندات نوشته شده است؟
ثبت شده:
آیا سرویس ایجاد شده است؟
آیا کیفیت کد و پوشش آزمایشی با خط مشی مطابقت دارد؟
در تست:
آیا تست ادغام با سایر اجزا به پایان رسیده است؟
آیا تست ادغام با مصرف کننده خدمات به پایان رسیده است؟
آیا سرویس در محیط تولید مستقر شده است؟
آیا پیکربندی سرویس به روز شده است؟
موجود:
آیا مصرف کنندگان در مورد استهلاک مطلع شده اند؟
آیا پیکربندی سرویس به روز شده است؟
منسوخ شده:
آیا مصرف کنندگان در مورد بازنشستگی خدمات مطلع شده اند؟
بازنشستگی:
چرخه عمر پایان سرویس
علاوه بر سرویسهای ما که دارای چرخه عمر هستند، برخی از سیاستهای ما نیز دارای یک عمر هستند و این ممکن است به دلایل مختلی از قبیل اعمال سیاست جدید، ایجاد خط مشی صنعتی جدید، تغییر خواستههای مشتریان و عدم سنجیده شدن سیاست ابلاغ شده و ... صورت گیرد
یک مخزن قابل جستجو و مشاهده سیاستهای خود بالا بیاورید و همچنین برای خدمات خود و توضیح مختصر آن تا بتوانید سریعا به اطلاعاتی در مورد آنها دست پیدا کنید
به انتهای کتاب حکمرانی soa رسیدیم ، سیاستهای آنرا مطالعه و جامعیت عملکردی آن را فهمیدیم، اکنون با دانش به این مسائل و موضوعات درک بهتر و پایه مقدماتی رو برای معماریهای جدیدی از قبیل microservice, DDD و .... و همچنین آمادگی اولیه برای زبان مدلسازی BPM را داریم
#microservice
#soa
@code_crafters
❤4
ثبت، نمایش بازدید محتوا ها در مقیاس بالا
CodeCraftersChat
فایل صوتی گپ امشب سعید جان با مشارکت و گفتگوی اعضا عزیز، درباره راه و روش های تشخیص، ذخیره و پردازش بازدید های کاربران از محتوا ها (پست ها، فایل ها، مدیا ها) در مقیاس اپلیکیشن های بزرگ و تعداد کاربر همزمان بالا بود.
* خلاصه مطالبی که در این میت مورد بحث قرار گرفت:
گفتیم با چه روش هایی میتوانیم بازدید هر کاربر از محتواها را بصورت یکتا (هر کاربر یک view برای هر محتوا)،
بدون کاهش پرفورمنس و افزایش زمان ریسپانس ها،
با کمترین فشار به دیتابیس ها و بهترین بازدهی،
و با گارانتی معتبر بودن بازدید ها، ثبت و رصد کنیم.
تکنولوژی و ابزار های بحث شده:
- RabbitMQ Message BUS
- Redis distributed caching
- Background Job Services and Queues
- Databases and storages differences
@code_crafters
* خلاصه مطالبی که در این میت مورد بحث قرار گرفت:
گفتیم با چه روش هایی میتوانیم بازدید هر کاربر از محتواها را بصورت یکتا (هر کاربر یک view برای هر محتوا)،
بدون کاهش پرفورمنس و افزایش زمان ریسپانس ها،
با کمترین فشار به دیتابیس ها و بهترین بازدهی،
و با گارانتی معتبر بودن بازدید ها، ثبت و رصد کنیم.
تکنولوژی و ابزار های بحث شده:
- RabbitMQ Message BUS
- Redis distributed caching
- Background Job Services and Queues
- Databases and storages differences
@code_crafters
❤7🔥2
زبان های معروف بلاکچین
خب تو این پست قراره با زبان های برنامه نویسی که در بلاکچین کاربرد زیادی داشتند و دارند اشنا بشیم و همچنین در پست بعدی مریم سراغ پیاده سازی بلاکچین و الگورتیم های مربوطه با پایتون🥸🥸
برای توسعهی بلاک چین زبانهای مختلفی وجود دارند، اما برخی محبوبتر و برخی دیگر ناشناختهتر باقیماندهاند.
1-سی پلاس پلاس (C++)
2-سالیدیتی (Solidity)
6-گولنگ (Golang)
سایر زبانهای برنامهنویسی بلاکچین:
(C#)
(Java Script)
(Simplicity)
(Rholang)
(PHP)
(Ruby)
(Rust)
(Erlang)
(CX)
#blockchain
#web3
@code_crafters
خب تو این پست قراره با زبان های برنامه نویسی که در بلاکچین کاربرد زیادی داشتند و دارند اشنا بشیم و همچنین در پست بعدی مریم سراغ پیاده سازی بلاکچین و الگورتیم های مربوطه با پایتون🥸🥸
برای توسعهی بلاک چین زبانهای مختلفی وجود دارند، اما برخی محبوبتر و برخی دیگر ناشناختهتر باقیماندهاند.
1-سی پلاس پلاس (C++)
C++ یک زبان برنامه نویسی شیگرا است که در فناوری بلاک چین برای اولین بار توسط بنیانگذاران بیت کوین استفاده شد
2-سالیدیتی (Solidity)
این زبان برنامه نویسی بلاکچین توسط اتریوم توسعه داده شد و هدف اصلی آن کمک به توسعهدهندگان برای ایجاد شبکههای بلاک چین بر روی پلتفرم خود بود. از آنجاییکه Solidity به توسعهدهندگان بلاک چین اختصاص داده شده است
از Solidity میتوان برای ایجاد قراردادهای هوشمند جهت رای دادن، تامین مالی جمعی و کیف پولهای چند امضایی استفاده کرد. همچنین این زبان برنامه نویسی بلاکچین یکی از سریعترینهای حوزهی خود شناخته میشود.
3-پایتون (Python)
برای تازهکارهای در حوزهی زبان برنامه نویسی بلاکچین، پایتون یکی از انتخابهای عالی محسوب میشود. البته بسیاری معتقدند زبان پایتون حتی از سی پلاس پلاس هم مناسبتر و بهتر است. بهعنوان یک توسعهدهنده مبتدی، میتوانید از پایتون برای ایجاد نمونههای اولیه بدون نیاز به کدهای طولانی استفاده کنید
تنها یک مشکل به پایتون، این زبان برنامه نویسی بلاکچین وارد بوده که آن هم مفسری بودن این زبان است. این موضوع مشکلاتی برای عملیات رمزنگاری پیچیده در بلاک چین ایجاد میکند.
4-وایپر (Vyper)
زبان برنامه نویسی وایپر یکی تازه نفسها در زمینهی توسعه بلاک چین به حساب میآید که از پایتون ۳ مشتق شده است. با اینکه Vyper تمام ویژگیهای پایتون را ندارد، بهعنوان جایگزینی برای Solidity ساخته میشود. از این زبان برنامه نویسی بلاکچین معمولاً مانند Solidity برای ماشین مجازی اتریوم (EVM) استفاده میشود. با این حال، Vyper ساختارهای کنترلی متفاوتی نسبت به Solidity دارد و همچنین مسائل امنیتی را به طور متفاوتی مدیریت میکند.
اگر یک زبان توسعه بلاک چین برای نوشتن قراردادهای هوشمند می خواهید، وایپر را نیز در لیست برترینهای زبان برنامه نویسی بلاکچین قرار دهید.
5-جاوا (Java)
جاوا از نظر محبوبیت و مزایا، رقابت سختی را با C++ ایجاد کرده است که در فناوری بلاک چین نیز این رقابت دیده میشود.
برنامههای جاوا را میتوان بر روی پلتفرمهای مختلف اجرا کرد چرا که از ویژگی عملکرد WORA به معنای یک بار بنویس، در هر جایی اجرا کن (Write once, run anywhere) برخوردار است. از طرفی، این برنامهها به معماری
خاص سیستم وابسته نیستند؛ زیرا از JVM جهانی (ماشین مجازی جاوا) برای اجرا استفاده میکنند. همین ویژگی کافیست تا توسعهدهندگان، جاوا را یک زبان برنامه نویسی بلاکچین بینظیر بدانند.
6-گولنگ (Golang)
گو یا گولنگ یکی دیگر از زبانهای برنامهنویسی است که بهراحتی میتوان از آن برای توسعه بلاک چین استفاده کرد. GO توسط تیم گوگل توسعه داده شده است و در درجه اول برای ساخت سیستمهای غیرمتمرکز کاربرد دارد. علت اصلی استفادهی توسعهدهندگان از GO سادگی و سهولت مقیاسپذیری آن است.
از آنجاییکه زبان برنامه نویسی Go به صورت ایستا تایپ شده و یک زبان برنامه نویسی کامپایل شده است، برای برنامه نویسی بلاک چین عالی است.
سایر زبانهای برنامهنویسی بلاکچین:
(C#)
(Java Script)
(Simplicity)
(Rholang)
(PHP)
(Ruby)
(Rust)
(Erlang)
(CX)
#blockchain
#web3
@code_crafters
🔥11👎2👍1