دعونا نتذكر الخطة التي نتحرك بها:
جزء واحد . قررنا المهمة التقنية وبنية الحل ، وكتبنا تطبيقًا بلغة golang.
الجزء 2 (أنت هنا الآن). نطلق تطبيقنا للإنتاج ، ونجعله قابلاً للتطوير ونختبر الحمل.
الجزء 3. دعنا نحاول معرفة سبب حاجتنا إلى تخزين الرسائل في مخزن مؤقت ، وليس في ملفات ، وكذلك مقارنة خدمة kafka و rabbitmq و yandex queue.
الجزء الرابع. سنقوم بنشر مجموعة Clickhouse ، وكتابة الدفق لنقل البيانات من المخزن المؤقت هناك ، وإعداد التصور في البيانات.
الجزء الخامس.دعنا نضع البنية التحتية بأكملها في الشكل المناسب - قم بتكوين ci / cd باستخدام gitlab ci ، وقم بتوصيل المراقبة واكتشاف الخدمة باستخدام consul و prometheus.
حسنًا ، دعنا ننتقل إلى مهامنا.
نحن نصب في الإنتاج
في الجزء الأول ، قمنا بتجميع التطبيق ، واختباره ، وتحميل الصورة أيضًا إلى سجل الحاوية الخاص ، وهو جاهز للنشر.
بشكل عام ، يجب أن تكون الخطوات التالية واضحة تقريبًا - نقوم بإنشاء أجهزة افتراضية ، وإعداد موازن تحميل وكتابة اسم DNS مع وكيل لـ cloudflare. لكنني أخشى أن هذا الخيار لا يتطابق بشكل وثيق مع اختصاصاتنا. نريد أن نكون قادرين على توسيع نطاق خدمتنا في حالة زيادة الحمل والتخلص من العقد المعطلة التي لا يمكنها تلبية الطلبات منها.
للقياس ، سنستخدم مجموعات المثيل المتاحة في سحابة الحوسبة. إنها تسمح لك بإنشاء أجهزة افتراضية من قالب ، ومراقبة مدى توفرها باستخدام الفحوصات الصحية ، وكذلك زيادة عدد العقد تلقائيًا في حالة زيادة الحمل.مزيد من التفاصيل هنا .
هناك سؤال واحد فقط - ما هو النموذج الذي يجب استخدامه للجهاز الظاهري؟ بالطبع ، يمكنك تثبيت نظام لينكس وتكوينه وإنشاء صورة وتحميلها على تخزين الصور في Yandex.Cloud. لكنها بالنسبة لنا رحلة طويلة وصعبة. أثناء مراجعة الصور المختلفة المتاحة عند إنشاء جهاز افتراضي ، صادفنا مثيلًا مثيرًا للاهتمام - صورة محسّنة للحاوية ( https://cloud.yandex.ru/docs/cos/concepts/ ). يسمح لك بتشغيل حاوية عامل إرساء واحدة في مضيف وضع الشبكة. أي عند إنشاء جهاز افتراضي ، يشار تقريبًا إلى المواصفات التالية للصورة المحسّنة للحاوية:
spec:
containers:
- name: api
image: vozerov/events-api:v1
command:
- /app/app
args:
- -kafka=kafka.ru-central1.internal:9092
securityContext:
privileged: false
tty: false
stdin: false
restartPolicy: Alwaysوبعد بدء تشغيل الجهاز الظاهري ، سيتم تنزيل هذه الحاوية وتشغيلها محليًا.
المخطط ممتع للغاية:
- نقوم بإنشاء مجموعة مثيل بمقياس تلقائي عند تجاوز 60٪ من استخدام وحدة المعالجة المركزية.
- كقالب ، نحدد آلة افتراضية مع صورة حاوية محسّنة ومعلمات لتشغيل حاوية Docker الخاصة بنا.
- نقوم بإنشاء موازن تحميل ينظر إلى مجموعة المثيلات الخاصة بنا ويتم التحديث تلقائيًا عند إضافة أو إزالة الأجهزة الافتراضية.
- ستتم مراقبة التطبيق كمجموعة مثيل ومن قبل الموازن نفسه ، مما سيؤدي إلى إخراج الأجهزة الظاهرية التي يتعذر الوصول إليها من الموازنة.
تبدو كخطة!
دعنا نحاول إنشاء مجموعة مثيل باستخدام terraform. الوصف الكامل يكمن في ملف example-group.tf ، سأعلق على النقاط الرئيسية:
- سيتم استخدام معرف حساب الخدمة لإنشاء وحذف الأجهزة الافتراضية. بالمناسبة ، سيتعين علينا إنشائه.
service_account_id = yandex_iam_service_account.instances.id - spec.yml, , . registry , - — docker hub. , —
metadata = { docker-container-declaration = file("spec.yml") ssh-keys = "ubuntu:${file("~/.ssh/id_rsa.pub")}" } - service account id, container optimized image, container registry . registry , :
service_account_id = yandex_iam_service_account.docker.id - Scale policy. :
autoscale { initialsize = 3 measurementduration = 60 cpuutilizationtarget = 60 minzonesize = 1 maxsize = 6 warmupduration = 60 stabilizationduration = 180 }
. — fixed_scale , auth_scale.
:
initial size — ;
measurement_duration — ;
cpu_utilization_target — , ;
min_zone_size — — , ;
max_size — ;
warmup_duration — , , ;
stabilization_duration — — , .
. 3 (initial_size), (min_zone_size). cpu (measurement_duration). 60% (cpu_utilization_target), , (max_size). 60 (warmup_duration), cpu. 120 (stabilization_duration), 60% (cpu_utilization_target).
— https://cloud.yandex.ru/docs/compute/concepts/instance-groups/policies#auto-scale-policy - Allocation policy. , , — .
allocationpolicy { zones = ["ru-central1-a", "ru-central1-b", "ru-central1-c"] } - :
deploy_policy { maxunavailable = 1 maxcreating = 1 maxexpansion = 1 maxdeleting = 1 }
max_creating — ;
max_deleting — ;
max_expansion — ;
max_unavailable — RUNNING, ;
— https://cloud.yandex.ru/docs/compute/concepts/instance-groups/policies#deploy-policy - :
load_balancer { target_group_name = "events-api-tg" }
عند إنشاء مجموعة مثيل ، يمكنك أيضًا إنشاء مجموعة مستهدفة لموازنة التحميل. ستستهدف الأجهزة الافتراضية المرتبطة. إذا تم حذف العقد ، فستتم إزالتها من الموازنة ، وعند الإنشاء ، ستتم إضافتها إلى الموازنة بعد اجتياز اختبارات الحالة.
يبدو أن كل شيء أساسي - فلنقم بإنشاء حساب خدمة لمجموعة المثيل ، وفي الواقع المجموعة نفسها.
vozerov@mba:~/events/terraform (master *) $ terraform apply -target yandex_iam_service_account.instances -target yandex_resourcemanager_folder_iam_binding.editor
... skipped ...
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
vozerov@mba:~/events/terraform (master *) $ terraform apply -target yandex_compute_instance_group.events_api_ig
... skipped ...
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.تم إنشاء المجموعة - يمكنك عرض والتحقق من:
vozerov@mba:~/events/terraform (master *) $ yc compute instance-group list
+----------------------+---------------+------+
| ID | NAME | SIZE |
+----------------------+---------------+------+
| cl1s2tu8siei464pv1pn | events-api-ig | 3 |
+----------------------+---------------+------+
vozerov@mba:~/events/terraform (master *) $ yc compute instance list
+----------------------+---------------------------+---------------+---------+----------------+-------------+
| ID | NAME | ZONE ID | STATUS | EXTERNAL IP | INTERNAL IP |
+----------------------+---------------------------+---------------+---------+----------------+-------------+
| ef3huodj8g4gc6afl0jg | cl1s2tu8siei464pv1pn-ocih | ru-central1-c | RUNNING | 130.193.44.106 | 172.16.3.3 |
| epdli4s24on2ceel46sr | cl1s2tu8siei464pv1pn-ipym | ru-central1-b | RUNNING | 84.201.164.196 | 172.16.2.31 |
| fhmf37k03oobgu9jmd7p | kafka | ru-central1-a | RUNNING | 84.201.173.41 | 172.16.1.31 |
| fhmh4la5dj0m82ihoskd | cl1s2tu8siei464pv1pn-ahuj | ru-central1-a | RUNNING | 130.193.37.94 | 172.16.1.37 |
| fhmr401mknb8omfnlrc0 | monitoring | ru-central1-a | RUNNING | 84.201.159.71 | 172.16.1.14 |
| fhmt9pl1i8sf7ga6flgp | build | ru-central1-a | RUNNING | 84.201.132.3 | 172.16.1.26 |
+----------------------+---------------------------+---------------+---------+----------------+-------------+
vozerov@mba:~/events/terraform (master *) $ثلاث عقد بأسماء ملتوية هي مجموعتنا. نتحقق من توفر التطبيقات لهم:
vozerov@mba:~/events/terraform (master *) $ curl -D - -s http://130.193.44.106:8080/status
HTTP/1.1 200 OK
Date: Mon, 13 Apr 2020 16:32:04 GMT
Content-Length: 3
Content-Type: text/plain; charset=utf-8
ok
vozerov@mba:~/events/terraform (master *) $ curl -D - -s http://84.201.164.196:8080/status
HTTP/1.1 200 OK
Date: Mon, 13 Apr 2020 16:32:09 GMT
Content-Length: 3
Content-Type: text/plain; charset=utf-8
ok
vozerov@mba:~/events/terraform (master *) $ curl -D - -s http://130.193.37.94:8080/status
HTTP/1.1 200 OK
Date: Mon, 13 Apr 2020 16:32:15 GMT
Content-Length: 3
Content-Type: text/plain; charset=utf-8
ok
vozerov@mba:~/events/terraform (master *) $بالمناسبة ، يمكنك الانتقال إلى الأجهزة الافتراضية باستخدام تسجيل الدخول إلى ubuntu ومشاهدة سجلات الحاوية وكيفية بدء تشغيلها.
تم أيضًا إنشاء مجموعة مستهدفة للميزان والتي يمكن إرسال الطلبات إليها:
vozerov@mba:~/events/terraform (master *) $ yc load-balancer target-group list
+----------------------+---------------+---------------------+-------------+--------------+
| ID | NAME | CREATED | REGION ID | TARGET COUNT |
+----------------------+---------------+---------------------+-------------+--------------+
| b7rhh6d4assoqrvqfr9g | events-api-tg | 2020-04-13 16:23:53 | ru-central1 | 3 |
+----------------------+---------------+---------------------+-------------+--------------+
vozerov@mba:~/events/terraform (master *) $لنقم بالفعل بإنشاء موازن ونحاول إرسال حركة المرور إليه! يتم وصف هذه العملية في load-balancer.tf ، النقاط الرئيسية:
- نشير إلى المنفذ الخارجي الذي سيستمع إليه الموازن والمنفذ الذي سيرسل طلبًا إلى الأجهزة الافتراضية. نشير إلى نوع العنوان الخارجي - ip v4. في الوقت الحالي ، يعمل موازن التحميل على مستوى النقل ، لذلك يمكنه فقط موازنة اتصالات tcp / udp. لذلك سيتعين عليك تثبيت SSL إما على أجهزتك الافتراضية ، أو على خدمة خارجية يمكنها التعامل مع https ، على سبيل المثال ، cloudflare.
listener { name = "events-api-listener" port = 80 target_port = 8080 external_address_spec { ipversion = "ipv4" } } healthcheck { name = "http" http_options { port = 8080 path = "/status" } }
فحوصات طبية. نحدد هنا معلمات فحص العقد - نتحقق من عنوان url / الحالة http على المنفذ 8080. إذا فشل الفحص ، فسيتم طرد الجهاز من الموازنة.
مزيد من المعلومات حول موازن التحميل - cloud.yandex.ru/docs/load-balancer/concepts . ومن المثير للاهتمام ، أنه يمكنك توصيل خدمة حماية DDOS على الموازن. ثم ستأتي حركة المرور التي تم تنظيفها بالفعل إلى خوادمك.
نخلق:
vozerov@mba:~/events/terraform (master *) $ terraform apply -target yandex_lb_network_load_balancer.events_api_lb
... skipped ...
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.نخرج IP الخاص بالموازن الذي تم إنشاؤه ونختبر العمل:
vozerov@mba:~/events/terraform (master *) $ yc load-balancer network-load-balancer get events-api-lb
id:
folder_id:
created_at: "2020-04-13T16:34:28Z"
name: events-api-lb
region_id: ru-central1
status: ACTIVE
type: EXTERNAL
listeners:
- name: events-api-listener
address: 130.193.37.103
port: "80"
protocol: TCP
target_port: "8080"
attached_target_groups:
- target_group_id:
health_checks:
- name: http
interval: 2s
timeout: 1s
unhealthy_threshold: "2"
healthy_threshold: "2"
http_options:
port: "8080"
path: /statusالآن يمكننا ترك رسائل فيه:
vozerov@mba:~/events/terraform (master *) $ curl -D - -s -X POST -d '{"key1":"data1"}' http://130.193.37.103/post
HTTP/1.1 200 OK
Content-Type: application/json
Date: Mon, 13 Apr 2020 16:42:57 GMT
Content-Length: 41
{"status":"ok","partition":0,"Offset":1}
vozerov@mba:~/events/terraform (master *) $ curl -D - -s -X POST -d '{"key1":"data1"}' http://130.193.37.103/post
HTTP/1.1 200 OK
Content-Type: application/json
Date: Mon, 13 Apr 2020 16:42:58 GMT
Content-Length: 41
{"status":"ok","partition":0,"Offset":2}
vozerov@mba:~/events/terraform (master *) $ curl -D - -s -X POST -d '{"key1":"data1"}' http://130.193.37.103/post
HTTP/1.1 200 OK
Content-Type: application/json
Date: Mon, 13 Apr 2020 16:43:00 GMT
Content-Length: 41
{"status":"ok","partition":0,"Offset":3}
vozerov@mba:~/events/terraform (master *) $رائع ، كل شيء يعمل. هناك لمسة أخيرة متبقية حتى نتمكن من الوصول إليها عبر https - سنقوم بتوصيل cloudflare بالبروكسي. إذا قررت الاستغناء عن cloudflare ، فيمكنك تخطي هذه الخطوة.
vozerov@mba:~/events/terraform (master *) $ terraform apply -target cloudflare_record.events
... skipped ...
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.الاختبار عبر HTTPS:
vozerov@mba:~/events/terraform (master *) $ curl -D - -s -X POST -d '{"key1":"data1"}' https://events.kis.im/post
HTTP/2 200
date: Mon, 13 Apr 2020 16:45:01 GMT
content-type: application/json
content-length: 41
set-cookie: __cfduid=d7583eb5f791cd3c1bdd7ce2940c8a7981586796301; expires=Wed, 13-May-20 16:45:01 GMT; path=/; domain=.kis.im; HttpOnly; SameSite=Lax
cf-cache-status: DYNAMIC
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 5836a7b1bb037b2b-DME
{"status":"ok","partition":0,"Offset":5}
vozerov@mba:~/events/terraform (master *) $كل شيء يعمل في النهاية.
اختبار الحمل
ربما تُترك لنا الخطوة الأكثر إثارة للاهتمام - لإجراء اختبار تحميل لخدمتنا والحصول على بعض الأرقام - على سبيل المثال ، 95 بالمائة من وقت المعالجة لطلب واحد. سيكون من الجيد أيضًا اختبار القياس التلقائي لمجموعة العقد الخاصة بنا.
قبل بدء الاختبار ، يجدر القيام بشيء واحد بسيط - إضافة عقد التطبيق الخاصة بنا إلى بروميثيوس لتتبع عدد الطلبات ووقت معالجة طلب واحد. نظرًا لأننا لم نقم بإضافة أي اكتشاف للخدمة حتى الآن (سنقوم بذلك في المقالة 5 من هذه السلسلة) ، فسنكتب ببساطة static_configs على خادم المراقبة الخاص بنا. يمكنك معرفة عنوان IP الخاص به بالطريقة القياسية من خلال قائمة مثيل حساب yc ، ثم إضافة الإعدادات التالية إلى /etc/prometheus/prometheus.yml:
- job_name: api
metrics_path: /metrics
static_configs:
- targets:
- 172.16.3.3:8080
- 172.16.2.31:8080
- 172.16.1.37:8080يمكن أيضًا الحصول على عناوين IP الخاصة بأجهزتنا من قائمة مثيلات yc. أعد تشغيل بروميثيوس عبر systemctl ، أعد تشغيل بروميثيوس وتحقق من أن العقد يتم استطلاعها بنجاح من خلال الانتقال إلى واجهة الويب المتاحة على المنفذ 9090 (84.201.159.71:9090).
دعنا نضيف لوحة تحكم إلى grafana من مجلد grafana. نذهب إلى Grafana على المنفذ 3000 (84.201.159.71:3000) وبتسجيل الدخول / كلمة المرور - admin / Password. بعد ذلك ، أضف بروميثيوس محليًا واستورد لوحة القيادة. في الواقع ، في هذه المرحلة ، اكتمل الإعداد - يمكنك طرح الطلبات عند التثبيت لدينا.
للاختبار ، سنستخدم خزان yandex ( https://yandex.ru/dev/tank/ ) مع مكون إضافي لـ overload.yandex.netمما سيتيح لنا تصور البيانات التي يتلقاها الخزان. كل ما تحتاجه للعمل موجود في مجلد التحميل الخاص بمستودع git الأصلي.
قليلا عما هو موجود:
- token.txt - ملف به مفتاح API من overload.yandex.net - يمكنك الحصول عليه من خلال التسجيل في الخدمة.
- load.yml - ملف تكوين للخزان ، يوجد مجال للاختبار - events.kis.im ، نوع تحميل rps وعدد الطلبات 15000 في الثانية لمدة 3 دقائق.
- data - ملف خاص لإنشاء تهيئة بتنسيق ammo.txt. نكتب فيه نوع الطلب وعنوان url والمجموعة لعرض الإحصائيات والبيانات الفعلية التي يجب إرسالها.
- makeammo.py - برنامج نصي لتوليد ملف ammo.txt من ملف البيانات. المزيد حول البرنامج النصي - yandextank.readthedocs.io/en/latest/ammo_generators.html
- ammo.txt - ملف الذخيرة الناتج الذي سيتم استخدامه لإرسال الطلبات.
للاختبار ، أخذت جهازًا افتراضيًا خارج Yandex.Cloud (للحفاظ على صدق كل شيء) وأنشأت سجل DNS من أجل تحميله. kis.im. قمت بتدوير عامل الإرساء هناك ، لأننا سنبدأ الخزان باستخدام الصورة https://hub.docker.com/r/direvius/yandex-tank/ .
حسنًا ، لنبدأ. انسخ مجلدنا إلى الخادم ، وأضف رمزًا وابدأ الخزان:
vozerov@mba:~/events (master *) $ rsync -av load/ cloud-user@load.kis.im:load/
... skipped ...
sent 2195 bytes received 136 bytes 1554.00 bytes/sec
total size is 1810 speedup is 0.78
vozerov@mba:~/events (master *) $ ssh load.kis.im -l cloud-user
cloud-user@load:~$ cd load/
cloud-user@load:~/load$ echo "TOKEN" > token.txt
cloud-user@load:~/load$ sudo docker run -v $(pwd):/var/loadtest --net host --rm -it direvius/yandex-tank -c load.yaml ammo.txt
No handlers could be found for logger "netort.resource"
17:25:25 [INFO] New test id 2020-04-13_17-25-25.355490
17:25:25 [INFO] Logging handler <logging.StreamHandler object at 0x7f209a266850> added
17:25:25 [INFO] Logging handler <logging.StreamHandler object at 0x7f209a20aa50> added
17:25:25 [INFO] Created a folder for the test. /var/loadtest/logs/2020-04-13_17-25-25.355490
17:25:25 [INFO] Configuring plugins...
17:25:25 [INFO] Loading plugins...
17:25:25 [INFO] Testing connection to resolved address 104.27.164.45 and port 80
17:25:25 [INFO] Resolved events.kis.im into 104.27.164.45:80
17:25:25 [INFO] Configuring StepperWrapper...
17:25:25 [INFO] Making stpd-file: /var/loadtest/ammo.stpd
17:25:25 [INFO] Default ammo type ('phantom') used, use 'phantom.ammo_type' option to override it
... skipped ...هذا كل شيء ، العملية جارية. في وحدة التحكم ، يبدو الأمر كالتالي:
ونحن ننتظر اكتمال العملية ونراقب وقت الاستجابة وعدد الطلبات وبالطبع التحجيم التلقائي لمجموعتنا من الأجهزة الافتراضية. يمكنك مراقبة مجموعة من الأجهزة الافتراضية عبر واجهة الويب ؛ في إعدادات مجموعة من الأجهزة الافتراضية توجد علامة تبويب "المراقبة".
كما ترى ، فإن العقد الخاصة بنا لم يتم تحميل حتى 50٪ من وحدة المعالجة المركزية ، لذلك يجب إعادة اختبار القياس التلقائي. في الوقت الحالي ، دعنا نلقي نظرة على وقت معالجة الطلب في Grafana:
لم يتم تحميل عدد الطلبات - حوالي 3000 لكل عقدة - قليلاً إلى 10000. يرضي وقت الاستجابة - حوالي 11 مللي ثانية لكل طلب. الشخص الوحيد المتميز - 172.16.1.37 - لديه نصف الوقت لمعالجة الطلب. لكن هذا أمر منطقي أيضًا - فهو موجود في نفس منطقة ru-central1 - منطقة توافر مثل kafka ، التي تخزن الرسائل.
بالمناسبة ، التقرير عن الإطلاق الأول متاح على الرابط: https://overload.yandex.net/265967 .
لذلك دعونا نجري اختبارًا أكثر متعة - أضف الحالات: 2000 للحصول على 15000 طلب في الثانية وزيادة وقت الاختبار إلى 10 دقائق. سيبدو الملف الناتج كما يلي:
overload:
enabled: true
package: yandextank.plugins.DataUploader
token_file: "token.txt"
phantom:
address: 130.193.37.103
load_profile:
load_type: rps
schedule: const(15000, 10m)
instances: 2000
console:
enabled: true
telegraf:
enabled: falseسيلاحظ القارئ اليقظ أنني قمت بتغيير العنوان إلى IP الخاص بالموازن - ويرجع ذلك إلى حقيقة أن cloudflare بدأت في حظري لعدد كبير من الطلبات من عنوان IP واحد. اضطررت إلى ضبط الخزان مباشرة على موازن Yandex.Cloud. بعد الإطلاق ، يمكنك ملاحظة الصورة التالية:
زاد استخدام وحدة المعالجة المركزية ، وقرر المجدول زيادة عدد العقد في المنطقة ب ، وهو ما فعله. يمكن رؤية ذلك في سجلات مجموعة المثيل:
vozerov@mba:~/events/load (master *) $ yc compute instance-group list-logs events-api-ig
2020-04-13 18:26:47 cl1s2tu8siei464pv1pn-ejok.ru-central1.internal 1m AWAITING_WARMUP_DURATION -> RUNNING_ACTUAL
2020-04-13 18:25:47 cl1s2tu8siei464pv1pn-ejok.ru-central1.internal 37s OPENING_TRAFFIC -> AWAITING_WARMUP_DURATION
2020-04-13 18:25:09 cl1s2tu8siei464pv1pn-ejok.ru-central1.internal 43s CREATING_INSTANCE -> OPENING_TRAFFIC
2020-04-13 18:24:26 cl1s2tu8siei464pv1pn-ejok.ru-central1.internal 6s DELETED -> CREATING_INSTANCE
2020-04-13 18:24:19 cl1s2tu8siei464pv1pn-ozix.ru-central1.internal 0s PREPARING_RESOURCES -> DELETED
2020-04-13 18:24:19 cl1s2tu8siei464pv1pn-ejok.ru-central1.internal 0s PREPARING_RESOURCES -> DELETED
2020-04-13 18:24:15 Target allocation changed in accordance with auto scale policy in zone ru-central1-a: 1 -> 2
2020-04-13 18:24:15 Target allocation changed in accordance with auto scale policy in zone ru-central1-b: 1 -> 2
... skipped ...
2020-04-13 16:23:57 Balancer target group b7rhh6d4assoqrvqfr9g created
2020-04-13 16:23:43 Going to create balancer target group
قرر المجدول أيضًا زيادة عدد الخوادم في مناطق أخرى ، لكنني نفدت الحد الأقصى لعناوين IP الخارجية :) بالمناسبة ، يمكن زيادتها من خلال طلب الدعم الفني ، وتحديد الحصص والقيم المطلوبة.
خاتمة
لم تكن المقالة سهلة - سواء من حيث الحجم أو من حيث كمية المعلومات. لكننا مررنا بأصعب مرحلة وقمنا بما يلي:
- أثار الرصد والكفكة.
- , .
- load balancer’ cloudflare ssl .
في المرة القادمة ، دعنا نقارن ونختبر خدمة طابور rabbitmq / kafka / yandex.
ترقب!
* هذه المادة موجودة في تسجيل الفيديو لورشة عمل REBRAIN & Yandex.Cloud المفتوحة: نقبل 10000 طلب في الثانية على Yandex Cloud - https://youtu.be/cZLezUm0ekE
إذا كنت مهتمًا بحضور مثل هذه الأحداث عبر الإنترنت وطرح الأسئلة في الوقت الفعلي ، فاتصل بـ قناة DevOps بواسطة REBRAIN .
نود أن نتقدم بشكر خاص إلى Yandex.Cloud لإتاحة الفرصة لنا لعقد مثل هذا الحدث. اربط بهم
إذا كنت بحاجة إلى الانتقال إلى السحابة أو كانت لديك أسئلة حول بنيتك التحتية ، فلا تتردد في ترك طلب .
ملاحظة: لدينا عمليتا تدقيق مجانيتان شهريًا ، وربما يكون مشروعك من بينها.