https://telegra.ph/Mvc-mtv-09-28


#MTV #Django
@code_crafters

طراحی میکروسرویس در جنگو بخش اول شروع کار با جنگو

در این بخش پوشش میدیم جنگو رو و مناسب کسانی است که به تازگی باهاش آشنا شده‌اند موارد پوششی این بخش شامل ساختار جنگو، چرخه حیات درخواست (request) و پاسخ (response) ، دستورات پایه‌ای جنگو، کنترل جریان در اپلیکیشن، هندلرهای جنگو، ساخت فایلهای url و view و دانش template ها، بعد از اتمام این بخش شما توانایی دانستن دانشی از web application ها و ساخت rest api با جنگو و چگونه ارائه دادن درخواست داده و باز گرداندن پاسخ بدست خواهید آورد

نکته: دانش پایتونی در خصوص موارد بالا الزامی می‌باشد

جنگو یک فریمورک وب اپلیکیشن بر پایه پایتون هستش، که هر کاربری میتواند با استفاده از آن اقدام به ساخت web application و web api کند، که بسیار ساختارمند و سریعتر از برخی دیگر از زبانهای سمت وب(داخل کتاب اشاره به php دارد) می باشد، که میتوان پروژه‌های بزرگ را با آن به راحتی پیاده سازی کرد.جنگو، از پایتون پشتیبانی می‌کند به این معنا که میتوان از تمامی ویژگی‌های پایتون مانند objects, class, polymorphism, list, tuple, dictionary و ... را در آن استفاده کرد

پایه جنگو، پایتون می‌باشد پس تمامی سینتکس کدها و تلفیق آنها شبیه پایتون است ،جنگو از یک مفسر (interpreter) داخلی برای اجرای فایل‌ها استفاده می‌کند، ما میتونیم بصورت جداگانه اجرا کنیم فایلهای جنگو رو در یک مفسر پایتونی


ما بارها درباره طراحی الگوی ساختار MVC شنیده‌ایم، که فرم کامل آن به شکل Model, View, Controller می‌باشد این الگوی طراحی برنامه رو به سه قسمت منطقی تقسیم میکند، هر قسمت عملکرد متفاوتی دارد و هر قسمت ساخته شده برای هندل کردن جنبه‌هایی از یک برنامه هستش، به این معنا که تمام ساختار یک پروژه توزیع شده در سه بخش قرار میگیرد، جنگو هم تقریبا شبیه با MVC و از الگوی طراحی(معماری) MVT View استفاده میکند، طراحی پروژه‌های جنگو تقسیم شده در سه بخش هستش که ساخت وهندل کردن ساختار پروژه‌های بزرگ رو راحت میکنه

مفهوم MVT

بخش M مورد استفاده برای هندل کردن داده ،مانند واکشی داده از دیتابیس و انتقال داده به ویو

بخش V ویو مربوطه به ذخیره سازی و منطق تجاری(business logic) پروژه که مرتبط هست با مدل و تملیپت

بخش T فرانت، به این معنا که صفحات html و GUI مرتبط با کار، میان داخل بخش تمپلیت، که با مدل و ویو بطور مستقل ارتباط میگیرد

بیایید یک نگاه به ساختار جنگو بیاندازیم

├── first_django_project
│   ├── asgi.py
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py

1 directory, 6 files

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

در پایتون متد init (dunder init) که یک سازنده کلاس هستش، این احرا میشه وقتی یک نمونه کلاس ساخته میشه، در جنگو هم فایل (dunder init.py) در مرحله اول اجرا میشود،ما میتونیم ازین فایل استفاده کنیم برای مثال ما بسته‌هایی رو داریم که در جاهای مختلف ازش استفاده میکنیم کافیه در این فایل واردش کنیم


فایل settings.py
این فایل اصلی است، ازین جهت بسیار حائز اهمیت می‌باشد که تمامی پیکربندی‌های پروژه در آن نوشته میشود

ALLOWED_HOSTS = []

در این لیست ما میتونیم یک یا چندین ip بنویسیم که میخواهیم پروژه به آن گوش بدهد، اگر چیزی ننویسیم پیش فرض localhost رو مدنظر میگیره

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

در این لیست ما میتونیم برنامه‌های خودمون رو تعریف کنیم داخل این لیست و خود جنگو برخی برنامه‌های پیش فرض را هم داخل آن جا داده که برای اجرای پروژه ذکر شده

ROOT_URLCONF = 'first_django_project.urls'

این متغیر مسیر پیش فرض url روت پروژه رو معرفی میکنه

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

این دیکشنری برای اتصال به دیتابیس مهم است و شامل اطلاعات درایور و پارامترهای ارتباطی با دیتابیس می باشد، که جنگو بصورت پیش فرض sqlite3 رو تنظیم میکنه


فایل دیگر ما که urls.py است، ما در این فایل URRهای پروژه رو تعریف میکنیم، که مورد استفاده برای کاربران پروژه جهت پردازش request و response هستش

لینک وبسایت

#microservice
#django

@code_crafters

در این فایل است که با ویو ارتباط میگیریم و تمامی urlهای پروژه که توسط جنگو و برای کاربران تعریف شده است قرار دارد


فایل uwsgi.py وقتی استفاده میشه که ما مستقر میکنیم پروژه رو بر روی سرور برنامه، در جنگو این فایل ایجاد میکنه تنظیمات رو برای استقرار، با استفاده از این فایل وب سرور میتونه به راحتی با اپلیکیشن جنگو‌ ارتباط برقرار کند،

فایل manage.py ازین جهت حائز اهمیت است که جنگو با کمک این فایل پروژه رو استارت میکنه (به زبان دیگر setup پروژه جنگو با این فایل اجرا میشه) اگر دقت کنید پوشه داخلی (first_django_priject) با این فایل در یک سطح ساخته میشوند که نشان از اهمیت یکسان آن دو هست


برای اجرای پروژه جنگویی ما دو گام پیش رو داریم:

ابتدا با دستور 
django-admin startproject first_project_django
که ساختار اولیه پیش فرض ساخته میشود با نام مدنظر ما (first_project_django)

سپس با دستور 
python manage.py runserver 
پروژه روی ip مدنظر ما (اگر در قسمت allow host تعریف شده باشد ip مدنظر ما و در غیر این صورت در ip پیشفرض 127.0.0.1) بر روی پورت پیش فرض 8000 اجرا خواهد شد همچینین میتونیم با پاس دادن پورت مدنظرمون به دستور پورت پیشفرض رو هم تغییر داد 
python manage.py runserver 8001

اگر در مرورگر خود 127.0.0.1:8000 رو وارد کنیم خروجی رو میبینیم


جریان احرایی برنامه جنگویی
با دستور بالا پروژه جنگویی اجرا میشه

۱-درون فایل manage.py، فایل settings.py ذکر شده که به معنای فایل تنظیمات است
۲- درون فایل settings بخش‌های کدی وجود دارد که خط به خط هر بخش اجرا میشود

۱- ماژول‌های ضروری جهت اجرا رو import میکند

۲- مسیر پروژه رو میسازه

۳-در بخش allow host هر مقدار ip رو‌تعریف میکنیم و سپس پروژه در اون ip خاص استارت خواهد شد

۴-در بخش بعدی تمامی appها لود شده که ما در install app تعریف کرده‌ایم

۵-در بخش بعدی مجموعه URLها رو در بخش روت تعریف میکند، که تعریف شده داخل فایل urls.py 

۶-حالاجستجو برای پوشه templateها شروع میشه که چون تعریف نشده مقدار خالی رو تنظیم میکنه

۷-در بخش دیتابیس اجرا میکنه کد رو و با دیتابیس پروژه ارتباط برقرار میکند

۳-پس از اجرا کردن فایل settings سرور استارت زده و در ip با پورت مدنظر ما در دسترس قرار میگیرد


جنگو‌ چگونه درخواست‌هارو‌هندل میکنه
۱-متغیر ROOT_URLCONF از فایل settings رو لود میکن
۲-این منغییر را بصورت گلوبال تنظیم کرده و سپس مسیر را برای یافتن URLهای تعریف شده توسط کاربر مشخص می کند

۳-هر url تعریف شده به یک تابع نسبت داده شده است

urlpatterns = [
    path('admin/', admin.site.urls),
]

۴-که بعد از کاما مشخص شده و هنگام صدا زدن تابع مدنظر رو اجرا میکنه


شرح مراحل کنترل جریان درخواست:

وقتی URL توسط کاربر نهایی صدا زده می‌شود، درخواست از طریق سرور جنگو منتقل میشه و بررسی میکنه که URL خواسته شده در فایل موجود هست یا نه

در مرحله اول درخواست کاربر بصورت شی HttpRequest ارسال میشه، سپس برای ارسال پاسخ از یک شی HttpResponse استفاده میشه
اگر url درخواستی کاربر وجود داشته باشد تابع نسبت داده شده آن در فایل views.py فراخوانده میشود

صفحات خطای پیش فرض:

خطای 400: اگر کاربر ارسال کنه درخواستی رو و به خطا بخوره جنگو مقدار تابع django.views.defaults.bad_request()
صدا میزنه و یک استثنا پیش فرض با وضعیت رو برمیگردونه

خطای 403:اگر کاربر ارسال کنه درخواستی و اجازه دسترسی نداشته باشد مقدار تابع  django.views.defaults.permission_denied()
صدا زده میشود

خطای 404: اگر کاربر ارسال کنه درخواستی رو و با خطای نبود URL مواجه بشه مقدار django.views.defaults.page_not_found()
صدا زده میشه

خطای 500: اگر کاربر ارسال کنه درخواستی رو و با خطای سرور مواجه بشه مقدار تابع django.views.defaults.server_error()
صدا زده میشه

درخواست HTTP:
یک پکت از داده هاست که معمولا استفاده میشه برای اشتراک اطلاعات از یک ماشین به دیگری و معمولا فرمت داده‌های آن باینری هستش، به زبان ساده تر ارتباط بین کلاینت و سرور است، برای این انتقال نیاز به روش‌هایی داریم که در زیر مطرح میکنیم:

مقدار get
این روش برای دریافت داده از طریق ارسال داده‌های مرتبط به سرور استفاهده میشه، دارای طول محدود داده جهت ارسال است، اطلاعات و داده‌ها در url قابل مشاهده است و انتقال داده آن ناامن است

مقدار post
برای ارسال داده‌های حساس کاربر به سرور مناسب است، داده ها در url قابل مشاهده نیست و امنتر از get می‌باشد و محدودیت ارسال اطلاعات آن نیز بیشتر

لینک وبسایت
#microservice
#django

@code_crafters

مقدار connect
این درخواست یک خط لوله (pipline) را به سرور ایجاد خواهد کرد و بعد از احرازهویت و سنجش آن را تایید و ایجاد میکند

مقدار put
این روش شبیه به مقدار post است دقیقا با این تفاوت که اگه بارها اون رو تکرار کنیم یک مقدار یکسان به ما خواهد داد در حالیکه در post ممکن مقادیر متفاوت ایجاد گردد، این روش مناسب ایجاد یا تغییر منابع با آپلود داده است

مقدار delete
اگر کاربر بخواهد هر داده‌ای رو حذف از دیتابیس این بهترین روش است


ایجاد فایل ویو و پیکربندی url پیش تعریف کاربر
طبق الگوی MVT ،بیزنس لاجیک در فایل view تعریف میشه، و این فایل توسط URLها صدا زده میشه و همچین رابط بین مدل و تمپلیت است، پوشه داخلی و در کنار settings.py یک فایل با نام views.py میسازیم

from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello, world. this is my first URL.")

ابتدا ماژول مدنظر خودمون رو ایمپورت کرده و سپس تابع ویوی مدنظر خودمون رو میسازیم و در فایل urls.py اون رو صدا میزنیم

from . import views

urlpatterns = [
    path('admin/', admin.site.urls),
    path('polls/', views.index),
]

پایه لاگ‌ها و در دسترس بودن نوع لاگ
توسعه دهندگان سعی میکنن تمام رخ‌دادهای خطا رو در پروژه مدیریتی کنن اما گاهیی ممکن هست رخ‌دادی رو فراموش یا مدیریت نکنند، برای گرفتن جریان برنامه و اون خطا پایتون ماژولی دارد با نام logger که مصرف داخلی جنگو نیز دارد، لاگر پایتون به چهار قسمت تبدیل شده:
بخش loggers:
هنگام تعریف لاگرها باید در اولین نقطه برنامه و بالاترین قرار بگیرند، لاگرها انواع مختلفی دارند که داده‌هارو بطور متفاوتی مدیریت میکنند، در خصوص آنها بیشتر صحبت خواهیم کرد

بخش Handler:
هندلرهارو میتونیم موتور لاگرها بدونیم، که تعریف میکنند رفتار هر پیغام رو، که بستکی به نوع لاگر دارد، ما میتونیم پیغام‌ها یا ارورهارو بعنوان یک پیام به لاگر پاس دهیم، میتونیم لاگ‌هارو در کنسول چاپ یا در فایلهای مجزا در دسترس قرار دهیم

بخش Filters:
فیلتر ارائه‌دهنده‌ای است که کنترل اضافی را بر روی رکوردهای گزارش ارائه می‌کند که از لاگر به کنترل‌کننده منتقل می‌شود

بخش Formatters:
ما تعریف میکنیم فرمتی رو برای رکوردها، که چاپ کنن متن رو، همچنین میتونیم فرمت مدنظر خودمون رو تعریف کنیم برای چاپ لاگ‌ها


انواع لاگ‌ها

DEBUG:
استفاده میشه برای چاپ و نوشتن اطلاعات اندکی درباره سیستم و برنامه

INFO:
استفاده میشه برای گرفتن اطلاعاتی از سیستم

WARNING:
بیشتر استفاده میشه بوسیله سیستم ارائه دهنده اطلاعات برای مشکلات جزئی که در سیستم رخ میده

ERROR:
این لاکر اطلاعات مهم را میگیرد، که روی میدن در سیستم و برنامه

CRITICAL:
برای چاپ پیامی استفاده میشه که سیستم یا برنامه دارای مشکل جزئی است

اجرای لاگر
لاگرها به سادگی در جنگو اجرا میشن، در بخش اول ما پیکربندی میکنیم فایل settings رو و میسازیم فایل لاگ رو، و اشاره میکنیم نوع لاگ رو در کد

یک نمونه ساده از پیکربندی لاگر

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'file': {
            'level': 'DEBUG',
            'class': 'logging.FileHandler',
            'filename': '/home/debug.log',
        },
    },
    'loggers': {
        'django': {
            'handlers': ['file'],
            'level': 'DEBUG',
            'propagate': True,
        },
    },
}

برای دیدن خروجی و اجرا در برنامه هم بصورت زیر در ویو

import logging

logger = logging.getLogger(name)

logger.debug('this is example of debug logger')
logger.info('this is example of info logger')
logger.warn('this is example of warn logger')
logger.error('this is example of error logger')

و برای تغییر فرمت هم

formatters = {
'f': {'format':
'%(asctime)s %(name)-12s %(levelname)-8s %(message)s'}
},

لینک وبسایت

#microservice
#django

@code_crafters

توسعه API در جنگو

در این قسمت ما شروع میکنیم به پیاده سازی api و یادگرفتن آن در جنگو و پیاده سازی کردنش، api در میکروسرویس جایگاه بسیار حائز اهمیتی دارد

ایده اصلی API
یک api مجموعه‌ای ازعملیات‌هاست که اجرا میشه و خروجی تولید میکنه، پایه‌ترین آن انتقال داده بر روی شبکه از یک نقطه به نقطه دیگر است، برای مثال ما یک برنامه‌موبایلی داریم که کاربر با وارد کردن اطلاعات خود میتواند داخل اپ ما ثبتنام و لاگین کند و یا از طریق سایر برنامه‌های دیگر با وارد کردن اطلاعات برای مثال به داشبورد خودش منتقل بشه، از دیگر موارد مهم در api میتوان به هندل کردن موارد امنیتی اشاره کرد، امنیت داده، کنترل سخت افزار و نرم افزار و ....، امروزه با استفاده از api میتوانیم یک بخش کد یا برنامه رو توسعه داده و در جاهای مورد نیاز دیگر از آن استفاده کرد

ساخت یک اپ در جنگو
اجازه بدید یک اپ جنگو بسازیم جهت نگهداری کدها، کارایی اپ جنگو در مناسب بودن هندل کردن بخش‌های جداگانه هر ماژول است، اگر در ماژولی تغییر ایجاد کنیم نباید روی دیگر ماژول‌ها تاثیر گذار باشد، ما کار رو در یک پروژه جدید با نام django_project01 پیش میبریم و یک اپ داخل آن با نام first_app میسازیم

django-admin startproject django_project01

cd django_project01

python manage.py startapp first_app

بعد از زدن دستورات ساختار پروژه به این شکل خواهد بود

.
├── django_poject01
│   ├── asgi.py
│   ├── __init__.py
│   ├── pycache
│   │   ├── init.cpython-310.pyc
│   │   └── settings.cpython-310.pyc
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── first_app
│   ├── admin.py
│   ├── apps.py
│   ├── __init__.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
└── manage.py

4 directories, 15 files

جنگو برای اپ نیز یکسری فایل تولید میکند(که از بررسی آن سر باز میزنیم، اپ را در فایل settings به لیست install apps اضافه میکنیم)

ما میتونیم ویوهای خودمون رو به دو شکل CBV و FBV در فایل views.py بنویسیم


برای قسمت fbv(function base view)

from django.http import HttpResponse
import json


def get_method_example(request):
    userid = request.GET.get('userid', '')
    resp = {}
    if userid:
        resp['status'] = 'Success'
        resp['status_code'] = '200'
        resp['data'] = userid
        return HttpResponse(json.dumps(resp), content_type='application/json')
    
@csrf_exempt
def get_method_example(request):
    userid = request.POST.get('userid', '')
    resp = {}
    if userid:
        resp['status'] = 'Success'
        resp['status_code'] = '200'
        resp['data'] = userid
        return HttpResponse(json.dumps(resp), content_type='application/json')

دو تابع درست کرده‌ایم یکی برای درخواست‌های GET و یکی برای درخواست‌های POST، حال با اضافه کردن دوتا url به پروژه میتوانیم هر دو ویو رو با برنامه postman تست کنیم


برای قسمت cbv(class base view)

from django.http import HttpResponse
import json
from django.views import View

class ClassBaseViewExample(View):
    def get(self, request):
        userid = request.GET.get('userid', '')
        resp = {}
        if userid:
            resp['status'] = 'Success'
            resp['status_code'] = '200'
            resp['data'] = userid
            return HttpResponse(json.dumps(resp), content_type='application/json')

    def post(self, request):
        userid = request.POST.get('userid', '')
        resp = {}
        if userid:
            resp['status'] = 'Success'
            resp['status_code'] = '200'
            resp['data'] = userid
            return HttpResponse(json.dumps(resp), content_type='application/json')

برای cbv یک کلاس با دو تابع نوشته شده که مشابه کدهای قبلی می باشد و اکنون با نوشتن یک urlبرای آن میتوان هر دوتابع این ویو رو در postman تست کرد


برای مثال در قسمت url اصلی پروژه

from django.contrib import admin
from django.urls import path
from first_app import views

urlpatterns = [
    path('admin/', admin.site.urls),
    path('get_method/', views.get_method_example),
    path('post_method/', views.post_method_example),
    path('cbv_method/', views.ClassBaseViewExample.as_view()),
]

لینک وبسایت

#microservice
#django

@code_crafters

طراحی میکروسرویس با جنگو بخش دوم میکروسرویس چیست

میکروسرویس ها روندهای جدید توسعه هستند. امروزه شرکت ها معماری میکروسرویس را برای توسعه پروژه ترجیح می دهند. این یک راه حل بسیار فشرده برای یک پروژه است. مدیریت ماژول را آسان می کند و اجرای پروژه را سریعتر می کند. همچنین به توسعه سریعتر پروژه کمک می کند. این دلایل ذکر شده و بسیاری موارد دیگر باعث تقاضای میکروسرویس می شود.

معرفی میکروسرویس
برای میکروسرویس تعریف خاصی وجود ندارد و ممکن هست هر فرد به شکلی آنرا تعریف کند اما دو تعریف عمده آن به شکل زیر است
۱-میکروسرویس‌ها، سرویس‌های کوچک و مستقلی هستند که باهم کار میکنند
۲-میکروسرویس‌ها معماری سرویس گرا با زمینه‌های محدود هستند،بطور مستقل و با یک جزء دیگر در داخل ارتباط برقرار میکنند، این معماری بسیار خودکار و و سیستم‌های نرم افزاری را تکامل می‌دهد

بیایید ببینیم که آیا از معماری سرویس گرا (SOA) آگاه هستید یا خیر، سپس ماژولار بودن پروژه و ارتباط از طریق پیام را نیز می دانید. اگر از شیوه های DevOps آگاه هستید، در مورد استقرار خودکار نیز می دانید. هر دو بیشتر به رویکرد میکروسرویس نزدیک هستند.


سه اصل مهم در طراحی میکروسرویس‌ها:
۱-از میکروسرویس برای استقرار سیستم‌ها و پروژه‌های بزرگ استفاده کنید: برای تمام مقیاس‌های پروژه استفاده از میکروسرویس اشتباه است، بلکه مناسب پروژه‌های بزرگ است که مدیریت آن چالش برانگیز باشد، اما خود این موضوع هم سردرگم کننده هستش اینکه کدوم پروژه رو کوچیک، متوسط، بزرگ بنامیم، منتها اگر سیستم ما دارای بار بالایی از درخواست کاربر است و نیاز به مقیاس پذیری دارد، میتوانیم رویکرد میکروسرویس رو پیاده سازی کنیم(در حجم تعداد اپ نیز تعداد اپ بالا میتواند به این منزله باشد)

۲-این رویکرد هدف‌محور است: مهم نیست که وقتی با مشکل مواجه می‌شویم، باید از رویکرد میکروسرویس پیروی کنیم. امروزه بسیاری از متخصصان برای توسعه پروژه به این رویکرد اشاره می کنند زیرا هدف آنها تنها ارائه راه حل مشکلات نیست، همچنین برای دید بیشتر و حفظ سهولت در ماژول ها، چنین معماری را در عمل به کار می گیرند.

۳-قابلیت تعویض ماژول ها: در پروژه های توسعه یافته قبلی که با رویکرد میکروسرویس ساخته نشده اند، امکان تغییر هر جزء از پروژه کمتر است. قبل از تغییر سازنده کامپوننت باید در مورد تغییرات برنامه ریزی کند، وابستگی کد خاصی را پیدا کند، در صورت عدم موفقیت کد به هر دلیلی، مراحل بازگشت را فهرست کند و تاثیر کد را مشخص کند. پس از همه، تغییرات نیاز به انجام عملیات تست واحد و سپس آزمایش ادغام با کل محصول دارند


در برخی سناریوها، پروژه ها بسیار پیچیده هستند یا وابستگی‌های حیاتی شدیدی دارند، در چنین شرایطی در مورد مسائل آینده یا افزایش حجم بار، ما مجبوریم به جای تغییر، اجزا را حفظ کنیم، که این بزرگترین ضرر یک رویکرد است

در میکروسرویس ها، کل پروژه را بر اساس ماژول ها به یک جزء‌های کوچک تقسیم می کنیم. بطوری که امکان تکرارپذیری را بر روی هر جزء فراهم می کند که تعمیر و نگهداری پروژه رو راحتتر میکند

اپلیکیشن‌های میکروسرویس دارای بخش‌های مهم زیر هستند:
● به اندازه های کوچک تقسیم می شوند
● برای برقراری ارتباط نیازمند انتقال پیام هستند
● مقید به زمینه‌ها هستند
● توسعه انها بصورت مستقل هستش
● استقرار هر بخش مستقل هست
● متصل به کنترل کننده مرکزی نیستند
● ساخت ها توسط فرآیندهای خودکار مستقر می شوند

به شکل آرمان گرایانه به میکروسرویس‌ها نگاه نکنید و با این تصور که در دنیای واقعی قابل پیاده سازی نیست، اگر تصور میکنید که میکروسرویس‌ها توسط بانک‌ها، سیستم‌های بیمارستانی و هتلی پیاده سازی میشه سخت در اشتباه هستید هیچکدام از میکروسرویس استفاده نمیکنند بلکه بیشتر توسط شرکت‌های فعال در حوزه محتوای جریانی(stream content) مورد استفاده قرار میگیرد، استفاده و پیاده سازی میکروسرویس یک انتخاب فردی هست و محدود به دامنه‌ای نیست، اما هدف از آن دو مورد تمرکززدایی و استقلال می‌باشد

تمرکززدایی:به این معنی است کل کارهای داخلی پروژه شامل اجرای هر ماژول، مدیریت وظایف و جابجایی کامل پروژه دیگر توسط یک سیستم واحد، مدیریت و کنترل نمیشود

استقلال: به این معنی است که به تیم‌های توسعه خود برای تولید نرم افزار ایمان داشته باشیم

مزیت این دو رویکرد این است که تغییرات در نرم افزار آسانتر و سریعتر میشود و امکان تصمیم گیری سریعتر را فراهم میکند


ادامه در وبسایت

لینک وبسایت


چندتا نکته بگم
بخش دوم و سوم کتاب بشدت پربار و پر از تحربه‌هایی هست که در دنیای واقعی با اون سروکار داریم و درکی از مسائل برامون مشخص نبود، من سعی کردم در حد توان بخش‌های مهم رو برسونم

#microservice
#django

@code_crafters

طراحی میکروسرویس با جنگو بخش سوم طراحی سیستم میکروسرویس

یکی از مسایل مهم در میکروسرویس‌ها طراحی درست و دقیق ماژولهای آن است در این بخش در این خصوص صحبت خواهیم کرد، همچنین موضوعات کلیدی مانند نکات مهم برای ایجاد معماری میکروسرویس و توسعه سرویس را پوشش می‌دهیم

رویکرد میکروسرویس
در سطح اولیه توسعه دهندگان زیادی در ساخت سرویس‌ها حضور دارند، اما زمانی که به معماری میکروسرویس روی میاوریم طراحی دقیق سرویس‌ها بصورت جداگانه و بر اساس نیازها جهت توسعه حائز اهمیت هستش، همچنین باید این رو در نظر بگیریم سرویس‌ها چگونه باهم ارتباط میگیرند

اگر برای هر سرویس تصمیم درستی گرفته باشیم میتوانیم رفتار سیستم را تغییر و اصلاح کنیم، کار همزمان بر روی همه سرویس‌ها بسیار سخت می‌باشد

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

مدل طراحی میکروسرویس به پنج بخش تقسیم میشود
Service, Solution, Process, Organization, Culture

بخش service
طراحی خوب میکروسرویس ها و API های برای سیستم مهم هستند. در یک سیستم میکروسرویس، سرپیس‌ها بلوک‌های ساختمان اتمی را تشکیل می‌دهند که کل ارگانیسم از آن ساخته می‌شود.اگر بتوانیم طراحی، محدوده و مقیاس خدمات خود را تعیین کنیم، می توانیم پیچیدگی را کاهش دهیم و آن را ساده کنیم

بخش solution
این بخش ارائه میده این چنین معماری و راه حلی که برای هر سرویس متفاوت باشد و همچنین نمایی از آینده رو نشون میده. هنگامی که ما میکروسرویس را طراحی می کنیم، باید همیشه نگران هماهنگی ورودی ها و خروجی های چندین سرویس باشیم. سیستم آینده نگر سیستم مطلوب تری را ارائه می دهد. به عنوان مثال، اگر ما روی ویژگی‌های ایمنی و مسیریابی در اجرای سطح اول کار کنیم، می‌توانیم پیچیدگی هر سرویس را کاهش دهیم.

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

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

بخش culture
فرهنگ نیز عامل مهمی است. این ناملموس است اما همچنین یک عامل مهم برای معماری میکروسرویس ها است. فرهنگ مجموعه‌ای از ارزش‌هاست که بین همه کارکنان سازمان مشترک است. به عبارت ساده، اگر فرهنگ سازمانی ما خوب باشد، آنها از ایده های جدید یا استراتژی های توسعه جدید مانند سرویس خرد استقبال می کنند. با این رویکرد، سازمان بر روی محصولات خود تسلط پیدا می کند و توسط محصولات می تواند بر بازار تأثیر بگذارد.

کار روی تمامی عناصر باهم
ما زمانیکه طراحی میکنیم تمام عناصر میکروسرویس رو باهم پیش میبریم، نباید فراموش کنیم که این عناصر همه در کنار همدیگه و متصل به هم هستند و تغییر در یکی معنی دار و میتواند بر روی بقیه هم تاثیر غیر قابل پیش بینی بگذارد، به عبارت ساده، سیستم میکروسرویس پیچیده است و نتایج مطلوبی را از آن سیستم تولید می کند.کار آسانی نیست.

ادامه موضوع در وبسایت ...

لینک وبسایت

#microservice
#django

@code_crafters

در ادامه پست قبلی:
Indexing:
ایندکس ها برای بهبود عملکرد عملیات پایگاه داده، به ویژه برای مجموعه داده های بزرگ، ضروری هستند.
به عنوان مثال، فرض کنید شما یک جدول کاربران دارید و می‌خواهید بر اساس نام آن‌ها جستجو کنید. بدون ایندکس، پایگاه داده باید هر رکورد را از ابتدا تا انتها بررسی کند تا نام مورد نظر را پیدا کند. اما با ایجاد یک ایندکس بر روی فیلد نام، پایگاه داده می‌تواند به سرعت به رکوردهای مرتبط با نام مورد نظر دسترسی پیدا کند.

Example:

class User(models.Model):
    username = models.CharField(max_length=100, db_index=True)
    email = models.CharField(max_length=100)

    class Meta:
        indexes = [
            models.Index(fields=['username'], name='username_idx'),
            models.Index(fields=['email'], name='email_idx')
        ]

Overriding Model Methods:
وقتی در Django یک مدل ایجاد می‌کنید، می‌توانید رفتارهای خاصی را برای عملیات‌های مختلف مدل، مانند ذخیره‌سازی یا حذف، سفارشی‌سازی کنید. این کار به شما این امکان را می‌دهد که قبل یا بعد از انجام یک عملیات، کارهای خاصی انجام دهید. شما میتوانید عملیات save , delete ,.... رو بازنویسی کنید.

Example:

class MyModel(models.Model):
    name = models.CharField(max_length=100)

    def save(self, *args, **kwargs):
        self.name = self.name.upper()
        super().save(*args, **kwargs)

در این مثال، هر زمان که یک نمونه از MyModel ذخیره می‌شود، مقدار فیلد name به حروف بزرگ تبدیل می‌شود قبل از ذخیره‌سازی و سپس عملیات ذخیره‌سازی انجام می‌شود.


Soft Deletion:

استفاده از Soft Deletion به شما این امکان را می‌دهد که آیتم‌ها را به عنوان حذف شده علامت‌گذاری کنید، اما در واقع آن‌ها را از پایگاه داده حذف نکنید. به این تکنیک "حذف نرم" یا "حذف موقت" نیز گفته می‌شود. این روش برای نگهداری تاریخچه داده‌ها، امکان بازگردانی آیتم‌های حذف شده و همچنین حفظ ارتباطات بین آیتم‌های مختلف مفید است.
Example:

class SoftDeleteModel(models.Model):
    is_deleted = models.BooleanField(default=False)

    def delete(self, *args, **kwargs):
        self.is_deleted = True
        self.save()

هر یک از این تکنیک ها مجموعه ای از مزایای خاص خود را ارائه می دهد و می تواند به طور قابل توجهی بر کارایی و عملکرد پروژه های شما تأثیر بگذارد. با اجرای این استراتژی‌ها، می‌توانید از قابلیت‌های قدرتمند مدل‌سازی جنگو برای ساخت برنامه‌های کاربردی وب قوی‌تر و مقیاس‌پذیرتر بهره ببرید.
منبع
#python

@code_crafters

یکی از مواردی که این روزها خیلی نیازمند هستش در داخل برنامه نویسی تحت وب و وب اپلیکیشن

حضور و وجود تسک‌های ناهمگام و زمان بندی و برنامه ریزی شده هستش

اخیرا هم تو مراحل مصاحبه و استخدامی هم از این سوالات زیاد پرسیده میشه

فریمورک fastapi چون پیش فرض و در دل خودش asyncio هستش این مورد هندل میکنه اما برای django ما از ترکیب celery با (rabbitmq ، redis) استفاده میکردیم اما این خودش یکمقدار افزونه و کار بیشتر اضافه میکرد


پکیج django_q اومده و کار رو راحت کرده هم برای تسک‌ها ناهمگام و هم برای تسک‌های زمان بندی شده و برنامه ریزی شده پیش فرض و پرفورمنس اون با ردیس هستش اما توان اتصال به سایر ابزارهایی که بتونن بعنوان بروکر استفاده بشند رو هم داره (حتی بروکر کاستوم و شخصی خودتون)

خیلی راحت‌تر و سبک تر از سلری هستش و هیچگونه پیچیدگی خاص اجرایی و کار کردی نداره

میتونید باهاش در پس زمینه یا برنامه ریزی شده ارسال ایمیل و پیامک داشته باشین، تصاویر و فایل‌هارو ذخیره کنید (حتی بصورت chunk) و علاوه بر این می‌تونید لایه‌کوئری رو هم باهاش به صورت ناهمگام با orm اجرا کنید


بچه‌های جنگو کار حتما این کتابخونه رو در حد چند ساعت بخونن هم پرفورمنسی و زمانی بکارتون میاد بشدت


#django

@code_crafters

پروژه وقتی به مرحله پروداکشن میرسه، یه گام خیلی مهم داره که انجام اون الزام آوره

لاگ گرفتن و لاگ انداختن
موضوعی که تو همه پروژه‌ها از کوچیک تا بزرگش و تو هر معماری مورد نیاز هستش

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

مهمترین نوع لاگ در دنیای برنامه نویسی audit log (لاگ میمیزی) هستش که در سطح امنیتی و رهگیری تمامی رفتارهای کاربر در سیستم انجام میشه که با جزئیات کامل صورت میگیره

در جنگو کتابخونه django-auditlog با نصب و کانفیگ (تنظیماتش خیلی راحت هستش) کردنش لاگ ممیزی رو در سیستم شما پیاده سازی میکنه و فیچرهای کنترلی زیادی رو هم بهتون میده

کمتر از نیم ساعت این کتابخونه رو بخونید و خیلی راحت تو پروژه‌ها ازش بهره ببرید هم بخش امنیتی سازمان و هم پشتیبانی و مدیران رده بالا رو به رضایت از بخش لاگ گیری سیستم میرسونه

#monitoring
#django
#log
#audit_log

@code_crafters

در حیطه جستجوی متن خیلی از ما با تصور اینکه پستگرس میتونه انجام بده پیش میریم، اما حقیقت تو سازمان اصلا اینکار رو نمیکنن و سمت پلتفرم‌های مخصوص میرن که نمونه اون elasticsearch هستش (بیشتر بابت الگوریتم‌هایی که داخلشون استفاده میشه که قدرت شگرفی رو خلق میکنه، حتما راجب الگوریتم‌ها بخونید تا تفاوت رو درک کنید)

زبان کوئری خاص خودش رو داره و تو حالت‌های مختلفی هم میتونید کنار هم بچینید و باهاش یک جستجوی متن حرفه‌ای ازش در بیارید

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

خود الاستیک کار میکنه اما یکی از نکات مهم اون سینک کردنش با دیتابیس هستش که یک چالش واسه مصاحبه‌ها و شرکت‌ها هستش

دانشگاه mit یه موتور بابت این موضوع توسعه داده با اسم hystack که مخصوص جنگو هستش و علاوه بر الاستیک ، ابزارهای دیگه رو هم ساپورت میکنه، خیلی چیزهارو بهمون میده مثلا حروف اضافه رو در جستجوها و ایندکس‌ها قرار نده و بابت هر زبانی یک پکیج هم بهمون داده، نرمالایزر و ... هم بهمون میده که همه این‌هارو باید تنظیم کنید

راجبش حتما بخونید من داخل دو پروژه ازش استفاده کردم و بشکل چشم گیری قدرت سرچ رو بالا برد

#django

@code_crafters

حضور CTEs در دیتابیس و محدودیت ormها

بیایید با یک مثال براتون توضیح بدم، یک پیچیدگی نسبتا معمولی در دیتابیس و کوئری‌ها


یک مدل رو تصور کنید که دوتا فیلد داره
class Model:
id: int(PK)
name: str
parent: FK(self, null)

در نگاه اول این یک مدل کاملا ساده هستش و کاملا هم درست فکر میکنید این یه مدل ساده و ابتدایی هستش، اما منطق تجاری؟؟؟

منطق تجاری از ما میخواد که در ازای یک کوئری تمام والد‌های اون object رو بدست بیاریم، تصور کنید که ریشه‌های تو در تو داخل مدل برای یک object حدود 100 والد وجود داره و برای یک object دیگه ممکنه 1000 والد وجود داشته باشه، منطق تجاری از ما خواسته والد هر آبجکتی که درخواست میشه از مدل رو هم بهش برگردونیم، در دید اول این یک مسئله ساده هستش اما یک منطق تجاری نسبتا پیچیده هستش

خود CTEs ها در دیتابیس چیه؟
بطور خلاصه یک‌نمای جدولی موقتی هستش که فقط و فقط در طول اجرای همون کوئری وجود دارند. داخل زبان کوئری با استفاده از With همراه با join و on ما یک ساختار درختی رو متصور میشیم و داده مدنظر خودمون رو ازش میکشیم بیرون. جدول موقت اولین گام برای ورود به ادمین پایگاه داده شدن هستش شاید تعجب کنید از این حرف ولی حقیقت داره، در مثال ما یک منطق نسبتا پیچیده مطرح شد (از نوع CTE بازگشتی) کاربرد اصلی CTE در تحلیل داده و مهندسی داده خودش رو نشون میده

چرا محدودیت در orm گفتیم؟؟
در orm ها موارد cte مطرح و پیاده سازی نشده چرا که دلیل اون این هستش که orm ها طراحی شدن بابت queryset های معمولی و نه بابت انجام کوئری‌های پیچیده، اینجاست که تو مثال بالا که مطرح کردیم اگه بخوایم از orm استفاده کنیم دچار محدودیت میشیم برای مثال اگه از prefetch استفاده کنیم محدود به انتخاب سطح میشیم بصورت دستی، اگه از زبان‌های برنامه نویسی بهره ببریم کارایی و کندی میاد سراغمون، به هر حال تصور درختی دیتابیسی که چندین میلیون رکورد داخلش هست کار راحتی نیستش، به اجبار باید سراغ CTEها بریم


واسه بچه‌هایی که با جنگو کار میکنند یکم تایم بزارید و django-cte و django-treebeard رو بخونید

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


#sql
#django

@code_crafters

پیاده‌سازی الگوی مخزن (Repository) از طریق CQRS با استفاده از Python-Django-ElasticSearch


#Django
#CQRS
#ElasticSearch

@code_crafters