سلام به همه. تو این نوشته میخوام در مورد اینکه Request Tracing چیه صحبت کنیم و تو ادامهش یه سرویس Jaeger راه بندازیم و Trace هارو از یه میکرو سرویس که با گولنگ نوشته شده بفرستیم به سمتش و در قدم نهایی تو Elastic search ذخیرهش بکنیم.
خب، بیایید با این شروع کنیم که Request Tracing چیه و چرا توی سیستمهای میکروسرویسی پیچیده بهش نیاز شدید داریم.
فرض کنید یه رستوران بزرگ و شلوغ داریم. چند تا سرآشپز تو آشپزخونه دارن غذا درست میکنن، گارسونا مشغول سرویس دادن و سفارش گرفتن هستن، و کلی آدم دارن سفارش میدن. حالا اگه یه مشکلی پیش بیاد مثلاً یه نفر غذای اشتباهی بگیره، چطور باید بفهمیم که این اشتباه کجا اتفاق افتاده. تقصیر آشپز بوده؟ گارسون اشتباه کرده؟ یا کسی که سفارش رو گرفته؟
اینجاست که مفهوم Request Tracing میاد وسط. ابزارهایی مثل Jaeger و ... دقیقا برای همین کار طراحی شدن. این ابزارها مثل یه دفترچه یادداشت به شدت دقیق کل مراحل سفارش رو یادداشت میکنن. یعنی نشون میدن که هر سفارش (یا Request) توی سیستم از کجا رد شده و چه اتفاقی براش افتاده یا حتی بهمون میگه هر شخص یا مرحله چقدر تایم مصرف کرده. اینجوری اگه یه جای کار مشکل داشته باشه یا سیستم کند بشه، میتونی سریع بفهمی مشکل از کجاست و درستش کنی.
به نظر من، این مفهوم یکی از چیزای خیلی مهم توی راهاندازی و اجرای سیستمهای میکروسرویسیه.
برای راهاندازی Jaeger باید دو کار اولیه رو انجام بدیم:
بیایید در مورد خود سرویس Jaeger صحبت کنیم. سرویس Jaeger چند بخش اصلی داره، مثل Jaeger Agent, Jaeger Collector, Jaeger Query , ... . توی محیطهای عملیاتی (Production)، بهتره که این بخشها رو جداگانه اجرا کنیم. این جداگانه اجرا کردن اجزا میتونه خیلی به کنترل لود سیستم کمک کنه . ما میتونیم اجزا رو جدا از هم و در هر تعدادی که میخواییم بر روی سرور های لینوکسی خام یا کلاستر های ارکسترتورمون اجرا کنیم. حالا این اجزایی که گفتیم اسمشونو، چطور کار میکنن؟ بیایین مسیر رو یه بار از اول بریم تا انتها و توضیحش بدیم.
فرض کنید درخواست میرسه به میکروسرویسی که وظیفه Insert دیتاهارو تو دیتابیس داره. کد شما طبق چیزی که شما کدشو نوشتید مدت زمانی که طول کشید این عمل Insert انجام بشه رو اندازه گیری میکنه و اینو به سمت سرویس Jaeger شما میفرسته. Jaeger Agent این داده هارو میگیره. داخل پارانتر بگم که شما میتونید این Jaeger Agent رو به صورت Side Car کنار اپ تون هم میتونه بالا بیاد. اصلا رسالت این سرویس اینه که شما درخواست هایی که داده هاش رو ذخیره کردید رو به صورت پکت های UDP بفرستید بهش. این سرویس رو TCP کار نمیکنه . اگر میخوایین با HTTP و غیره بفرستید باید مستقیم به Jaeger Collector بفرستید دیتاهاتون رو. تو قدم بعدی بخش Jaeger Collector وارد عمل میشه و دیتاها رو میگیره و یه سری کارها روش انجام میده و در نهایت یه جا باید ذخیره کنه اطلاعات رو. دو نوع روش وجود داره واسه این کار . شما میتونی دیتا رو تو خود سرویس ذخیره کنی یا بدی به یه سرویس مثل الستیک سرچ یا ... که واست دیتا هاتو نگه داره. مسلما راه کار دوم بهتره چون شما میتونید انواع روش های کلاسترینگ رو HA و FT رو روشون پیاده سازی کنید. حالا یه شناخت کلی فراهم شد. بریم خود سرویس رو بیاریمش بالا. من تو این نوشته یه docker compose فایل ساده نوشتم که بیاره سرویس رو بالا. ولی قبلش باید یه چیز رو هم بگیم . شما میتونی تک تک این کامپوننت هارو به صورت مجزا بیاری بالا یا به صورت یکجا. روش اول برای محیط پروداکشن توصیه میشه و روش دوم برای محیط تست بیشتر. ما تو این نوشته از روش دوم استفاده خواهیم کرد.
البته یه نوع معماری دیگه هم وجود داره که میان و یه چیزی مثل Kafka هم میارن وسط که اونم واقعا فوق العادهس . تو نوشته های بعدی در مورد اینکه چرا چیزی مثل کانفکا رو اصلا بازی میدیم هم صحبت میکنیم.
فایل داکرکامپوز رو میتونید از این لینک پیدا کنید.
با دستور docker compose up -d سرویس رو اجرا میکنیم و منتظر میمونیم سرویس ها بیان بالا
بیایین در مورد کامپوز فایل بالایی صحبت کنیم. این کامپوز فایل سه تا سرویس داره میاره بالا. اولی خود سرویس Jaeger هست و سرویس دومی سرویس الستیک سرچ هست که برای ذخیره دیتاهامون استفاده خواهیم کرد ازش و سومی برای بصری سازی داده های داخل الستیک سرچتون هست.
تو قدم بعدی نیاز داریم یه کدی بنویسیم که در شبیه سازی کنه یه میکروسرویس رو . من زبانی که برای این تست انتخاب کردم گولنگ هستش. ما تو این سناریوای که انتخاب کردیم، appa درخواست رو به appb میفرسته و appb درخواست رو به appc میفرسته. بیایین با کد پیاده سازی کنیم.
appa - main.go . لینک کد۱ تو گیتهاب
appb - main.go . لینک کد۲ تو گیتهاب
appc - main.go . لینک کد۳ تو گیتهاب
کد هارو بردارید و کامپایلشون کنید یا از بخش Release ها فایل آماده شو بردارید و ران کنید و دستور curl http://SERVERIP_URL:8080 رو بزنید.
الان میتونید ببینید تریس هامون دارن میان و تو الستیک سرچمون میشینن
همچنین میتونیم تو خود UI سرویس Jaeger تریس هارو به صورت خیلی خوشگل ببینیم . بر روی پورت 16686 میتونید این صفحه رو ببینید.
خب الان همونطوری که میبینید ما اومدیم به صورت میکروسرویس سه تا سرویس رو به صورت جداگانه آوردیم بالا. هر کدوم از این سرویس یه تایم رندومی رو مصرف میکنه و ریکوئست رو میفرسته به میکرو سرویس بعدی.
یه نکته کنکوری و خیلی مهم . هر کدوم از این میکروسرویس ها به صورت جداگانه تریس هارو میفرستن به سمت سرویس Jaeger . الان سرویس ما چطور میفهمه چی به چیه و ترتیب ها چطورن؟ اینجاست که کم کم دارید وارد دنیای شاهکار Jaeger میشید. بیایین یکمی موضوع رو بازش کنیم
فرض میکنیم ما درخواستی رو به میکروسرویس اولی میزنیم . اون یه Tracer واسه خودش و به نام سرویس خودش ایجاد میکنه و یه TraceID و یه SpanID جنریت میکنه واسه خودش . بعد یه کاری رو انجام میده (مثلا تو دیتابیس یه چیزی رو مینویسه) بعدش مدت زمانی که این فرآیند زمان برد رو ذخیره میکنه تو مغزش و زمانی که درخواست رو میخواد بده به میکروسرویس بعدی تو هدر های درخواستش مینویسه که ParentSpanID ایت میکروسرویس اولی هستش و TraceID رو هم بهش میده تا ما بدونیم این ادامه همونه. و این سلسله اتفاقات میافتن پشت سر هم. همه میکروسرویس ها اطلاعات تریس هاشون رو به صورت مجزی میفرستن و سرویس Jaeger اون ور با استفاده از TraceID و ParentSpanID میتونه سلسله مراتب رو تشخیص بده . این یه شاهکاره واقعا به نظرم. در نهایت هر درخواست ورودی براش همچین درختی درست میشه و میفهمه موارد مختلف رو.
تو نوشته های بعدی سعی میکنم در مورد Best Practice های این سرویس تو محیط پروداکشن بنویسم . مرسی از اینکه خوندید . عزت زیاد :)
