🙁 🦎 🍻 ترى العمارة؟ وأنا لا أرى ، لكنها هي 👩🏻‍🎤 👩🏼‍🤝‍👨🏿 🔍

في تطوير hh.ru اليوم حوالي 150 شخصًا. لدينا العديد من الفرق الشيقة ، وكل فريق يقدم مساهمة كبيرة. ولكن في هذه المقالة سأخبر فقط عن واحد منهم.

~~لأنني قائد فريقها~~ ، وهناك عدة أسباب لذلك:

في كثير من الأحيان لا يفهم المرشحون ما نقوم به ؛
في بعض الأحيان ، حتى الموظفون داخل الشركة لا يعرفون ذلك ، لأن فريقنا ليس لديه مدير منتجات ، ومجال وظيفته التجارية الخاصة وقائمة الخدمات التي ندعمها ...
غالبًا ما تظل مزايانا في الظل ؛
في النهاية ، "إذا كنت تريد معرفة ذلك ، حاول شرحه لشخص ما" :)

لذلك ، سأحاول أن أفهم بأمثلة مفهومة ما يتكون عملنا في الواقع.

لنبدأ بالأكثر عمومية ، أي بالأولويات ، هناك اثنان منها:

دعم النظام لموثوقية ومرونة نظامنا الأساسي. هنا يجدر الانتباه إلى كلمة "نظام" - وهذا يعني أننا لن نقوم بإصلاح عيوب الأداء المحددة ، ولكننا نطور قواعد وأنماط عامة ، ونصلحها في أطر عمل ، وعمليات فحص تلقائية ، وما إلى ذلك حتى تعمل مع الجميع.
التركيز على تطوير منطق الأعمال. أي أنه أقل مما يفكر المطور في دعم الموثوقية ، والهندسة المعمارية ، وما إلى ذلك. - كل خير. من الواضح أن تخليص الزملاء تمامًا من هذه الأفكار ضار إلى حد ما ، ولكن الحفاظ على توازن معقول أمر منطقي.

من هذه الأولويات ، تتبع الاتجاهات الرئيسية لعملنا:

0. دعم وتطوير العمارة

hh.ru هو 5-6k rps من المستخدمين ، في الذروة التي تصل إلى 10k ، والتي تنمو بأمر من الحجم ، تصل إلى الخلفية. هذا هو أكثر من 1500 حالة ، تدور حوالي 150 خدمة في 3 DC. لذا نعم ، أولاً وقبل كل شيء ، هذه مخططات متفرعة جدًا ذات مربعات وبنوك وسهام: من يذهب إلى أين وأين يجب أن يكون. بالطبع ، نحن لا نرسم المخططات - نحن نغطي الاحتياجات بالأتمتة والتسجيل والمراقبة ، لكننا نخاف طلابنا ، على سبيل المثال ، مع مثل هذه الأشياء:

نحن مسؤولون حقًا عن العثور على الاختناقات والحلول غير المرنة وإزالتها في الهندسة المعمارية وتطويرها وفقًا للاحتياجات.

سوف أعطي مثالا على ذلك:

كانت hh.ru تعمل بعيدًا عن السنة الأولى ، وبمجرد أن يبدو أنها فكرة جيدة أن يكون لديك جهاز منفصل لأداء مهام الخلفية وفقًا لجدول زمني - يمكنك تخصيص المزيد من الموارد لذلك ولن تكون هناك سباقات عليه. لكن ماذا لدينا في النهاية:

نقطة الفشل لجميع المهام
استنساخ التكوين الفريد فقط في همز
المهام التي تم تصميم منطقها لإطلاق مخصص على جهاز جريء منفصل ولا يتغير أفقياً

عندما فهمنا ذلك ، تأكدنا من أن لدينا جميع الوسائل لنقل مهام التاج إلى أمثلة عامة ، وبدأنا مهمة كبيرة في فئة الديون الفنية - والآن بعد أن حان الوقت لسداد الديون ، فإن الزملاء يتخلصون تدريجياً من هذه المشكلة.

1. توحيد العكازات

أولا وقبل كل شيء، وهذه هي لدينا الأطر والأدوات اللازمة لتطوير السريع للخدمات: المكسرات والبراغي و frontik . على أي حال ، نشأت jclient والعديد من المكتبات الأخرى التي تم فتحها على github لدينا من فكرة أنه من المنطقي تجميع تجربة تشغيل التقنيات المختلفة. هذا يسمح لنا بتنمية القيود وأنماط التصميم والسلوك التي عملنا عليها في المعركة ، ونعتبرها الأكثر ملاءمة ومفهومة وموثوق بها.

بالإضافة إلى مثل هذه الأمثلة الواضحة للتوحيد القياسي ، هناك تلك التي يكون من المنطقي تعميم حلول معينة.

على سبيل المثال ، في مرحلة ما ، بدأنا نحتاج بشكل دوري إلى إرسال رسائل إلى rabbitmq (مرة واحدة على الأقل). تم حل المهام بشكل متكرر من خلال قوائم انتظار مكتوبة ذاتيًا في القاعدة ، وقال dba مرارًا وتكرارًا عن مدى حب قوائم الانتظار في القاعدة بشدة ، خاصة تلك المحملة. في النهاية ، أصبح من الواضح أن هناك حاجة إلى حل قياسي يكون مقبولًا لـ dba ، ويضمن التسليم الموثوق به ويكون مناسبًا للتطوير - هذه هي الطريقة التي كتبنا بها مكتبتنا لدمج pgq و rabbitmq. الآن هناك احتمال كبير بأن نستخدم pgq أيضًا بالاقتران مع الكافكا.

1.0. البق

البق عالمية أيضا. على سبيل المثال ، في مرحلة ما ، اكتشفنا أن إطار عمل الثعبان الخاص بنا مسجل في القنصل في كل عامل تصنيع ، وحتى يفعل ذلك قبل أن يكون التطبيق جاهزًا لقبول الطلبات. بعد الإصلاح في الإطار ، ستصل التغييرات تدريجيًا إلى جميع الخدمات عند تحديثها.

تحدثت عن خطأ عام آخر يتعلق بإعدادات jvm في المرحلة التجريبية jpoint 2019 .

وماذا ، على سبيل المثال ، ما يجب القيام به مع خطأ يتم إعادة إنتاجه مرة واحدة أسبوعيًا في إحدى الحالات ، يتم التعامل معه من خلال إعادة التشغيل ، ولكن لا يتم تحميله ولا تركيبه؟

, java- . nuts-and-bolts:

"qtp1778300121-22" #22 prio=5 os_prio=0 cpu=797.67ms elapsed=11737.06s tid=0x00007f5890139000 nid=0x26 waiting for monitor entry [0x00007f58922c7000]
java.lang.Thread.State: BLOCKED (on object monitor)
at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:63)
- waiting to lock <0x00000000e86acad0> (a ru.hh.nab.logging.HhSyslogAppender)
at ru.hh.nab.logging.HhMultiAppender.doAppend(HhMultiAppender.java:47)
at ru.hh.nab.logging.HhMultiAppender.doAppend(HhMultiAppender.java:21)
at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51)

"qtp1778300121-22" #22 prio=5 os_prio=0 cpu=5718.81ms elapsed=7767.14s tid=0x00007f1537dba000 nid=0x24 waiting for monitor entry [0x00007f153d2b9000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(java.base@11.0.4/ConcurrentHashMap.java:1723)
- waiting to lock <0x00000000e976a668> (a java.util.concurrent.ConcurrentHashMap$Node)
at org.springframework.beans.factory.BeanFactoryUtils.transformedBeanName(BeanFactoryUtils.java:86)

jackson:

"qtp1778300121-23" #23 prio=5 os_prio=0 cpu=494.19ms elapsed=7234.32s tid=0x00007f6c01218800 nid=0x25 waiting for monitor entry [0x00007f6c07cfa000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.glassfish.jersey.jackson.internal.jackson.jaxrs.base.ProviderBase._endpointForWriting(ProviderBase.java:711)
- waiting to lock <0x00000000e9f94c38> (a org.glassfish.jersey.jackson.internal.jackson.jaxrs.util.LRUMap)
at org.glassfish.jersey.jackson.internal.jackson.jaxrs.base.ProviderBase.writeTo(ProviderBase.java:588)

Code Cache:

java . java, , - . , .

1.1. قرارات عامة

في بعض الأحيان يكون من الممكن التوصل إلى حلول قياسية قبل أن يصبح هذا مشكلة خطيرة. كأمثلة ، يمكننا الاستشهاد بمهمة معالجة السجلات التي تحدث عنها فلاد سينين في نفس النقطة 2019 ، أو مهمة إدارة المهلات في عميل http الخاص بنا.

معناه أنه من المفيد تحديد مهلة معقولة ليس من جانب العميل ، ولكن من جانب الخادم. بالنسبة للخادم ، لدينا بيانات حول مدى سرعة استجابته لنقاط النهاية الخاصة به. الآن يدعم عميلنا مهلة واحدة للخدمة. ولكن من الواضح أنه ليست كل نقاط نهاية الخدمة تستجيب بنفس الطريقة - بعضها أطول وبعضها أسرع. أود أن أتمكن من استخدام مهلات مختلفة. خلاف ذلك ، ينشأ وضع مشابه لهذا:

حتى الآن ، تظهر مثل هذه المواقف فقط تحت اختبار الإجهاد ، لكني أريد حلها قبل أن تصبح هذه مشكلة.

1.2. القضايا المفتوحة

ولكن لا يتم تفسير جميع المشاكل من خلال بعض الأماكن المهمة والعمليات اليدوية المعقدة. علاوة على ذلك ، سأعطي بعض الأمثلة على القضايا التي تقع أيضًا في مجال أولوياتنا ، ولكن في الوقت نفسه أقل حتمية بكثير. لذلك ، سأصف البيانات الأولية فقط ، ويمكننا مناقشة الحلول إذا رغبت في التعليقات.

لذا ، المثال الأول: الآن أصبح من الواضح أن هناك مشكلة في دمج خدماتنا فيما بينها. قد يستغرق تكامل مقبض الموقع في واجهة برمجة التطبيقات ، على سبيل المثال ، وقتًا أطول من تطويره الأولي.

مثال آخر ، ربما مألوف للكثيرين ، مثال لمشكلة مماثلة هو رؤية متجانسة. يدرك الجميع أن متراصة ، متضخمة مع عدد كبير من التراث ، تعقد التطور والتشغيل. ولكن من يستطيع أن يقول كم؟ هل يستحق التضحية بمهام أخرى من الدين التقني لصالح النشر ، كل قطعة منها ذات قيمة صغيرة تتلاشى بشكل فردي؟

حجم هذه المشاكل وما شابهها هو أنه من أجل حلها ، يجب على المرء في بعض الأحيان أن يتجاوز الإطار الفني ويغرق في مجالات جديدة تمامًا من عملية العمل. هذا مخيف من ناحية ، ولكن من ناحية أخرى يعطي حرية لا تصدق في اختيار القرارات.

2. كيف نعمل

ستكون القصة حول اتجاهات عملنا غير مكتملة بدون وصف لكيفية عملنا مع كل هذا.

بادئ ذي بدء ، ما جذبني للعمل في "الهندسة المعمارية" وما يحفزنا جميعًا: نحن نعمل حقًا من أجل الجودة.

وقبل أن تطيرني الأحجار ، سأحاول شرح ما أعنيه. أعتقد أنه لا يوجد مطور يسجل عمدا على الجودة. تكمن النقطة في الدين التقني: إذا كنا نتحدث عن قسم من منطق الأعمال لا يُخطط لإعادة استخدامه ، فمن المرجح أن ينمو مقدار الدين من حل غير مثالي ببطء مع مرور الوقت ، إذا كان على الإطلاق.

هذا يسمح لك بتهدئة الكمالية الخاصة بك قليلاً - بدء مهمة للديون والوصول إلى التكرار التالي. ولكن إذا كنا نتحدث عن إطار عمل أو أداة إعداد تكوين عالمية يتم استخدامها في مئات التطبيقات ودمج أنماط معينة من التصميم أو التسمية ، فإن معدل نمو الديون من قرارها غير الناجح يمكن أن يمنع أي مكاسب على الإطلاق. من الواضح أن هناك حالات عندما يكشف أفضل حل عن نقاط الضعف عند استخدامه ، ولكن هذا لا يحدث في كثير من الأحيان ...

أقرب إلى الانتهاء ، أود أن أتحدث عن العقبات التي لا تزال تنشأ في طريقنا. بدون هذا ، ستكون قصة عملنا غير شريفة. وبالتالي.

2.0. مهام تقييم الصعوبة

كما قلت أعلاه ، لا يمكننا تقييم التأثير المفيد لجميع المهام. إلى أي مدى ستنخفض مدة تحرير المهمة عندما يخرج الحل "المعبأ" لبعض الوظائف؟ أي من القسمين الإشكاليين من التعليمات البرمجية يجب إعادة بنائهما أولاً؟ من أجل تطوير نظام مناسب لتقييم المهام ، التقينا عدة مرات في الأسبوع لعدة أشهر ، ولكن هذا موضوع منشور منفصل.

2.1. اللاوعي الجماعي

إن تنسيق شيء لـ 150 شخصًا ليس بالمهمة السهلة. غالبًا ما يتجلى هيكلنا التنظيمي اللامركزي للغاية مع أفضل جوانبه ، ولكن بالنسبة لـ "الهندسة المعمارية" ، فإنه في بعض الأحيان عقبة خطيرة. هناك عدد قليل جدًا من الاتفاقات التي يمكن من خلالها التوصل إلى اتفاق ، حتى عدد أقل من تلك التي يمكن مراقبة امتثالها.

ويجب أن تدحرج جميع التغييرات بسلاسة. قد لا يتم تحديث الخدمة لأشهر ، ولكن لا يزال هناك متراصة ... حسنًا ، حزين جدًا.

لذا تحدثنا

آمل أن أوضحت بعد قصتي قليلاً ما تفعله "الهندسة المعمارية" في hh.ru. وإذا تمكنت من إثارة اهتمامك بعملنا ، فهذا رائع بشكل عام. علاوة على ذلك ، فقط الآن شاغر مفتوح في فريقنا . سنكون سعداء للغاية بالأفكار الجديدة التي ستساعدنا على تحقيق نظراتنا الخفية عن الخمول ، ولكن مثل هذه الانتصارات الهامة.

ملاحظة اتضح أن KDPV الأصلي هو مثال على هذا الرجل . آمل ألا يكون ضد استخدام صوره ك KDPV

ترى العمارة؟ وأنا لا أرى ، لكنها هي