التكاليف المخفية للتحول إلى الخدمات المصغرة

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

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

لقد تحدثت عن هذا الموضوع في ArchDays 2020 . اتبع الرابط للعثور على الشرائح ومقاطع الفيديو (التي سيتم نشرها قريبًا) للخطاب https://blog.byndyu.ru/2020/12/archdays-2020.html .

# 1 تغيير نهج العمل مع البيانات الرئيسية

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

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

- - . , :

1. ,

   
   
   
   
   

2. ,

   
   
   
   
   

3. ,

   
   
   
   
   

4. - ,

   
   
   
   
   

5. "" ,

   
   
   
   
   

6. ,

   
   
   
   
   

7. .

   
   
   
   
   

- - .

9 , - .

№2

, - . , , , , .

, . - "" . .

( ), (. .4).

. , , . , , , .

№3

, -, , -. . “”:

IT-, - -. , API .

№4

. . , , :

:

1. API: , , API .. Apigee.

   
   
   
   
   

2. DevOps- IaC .

   
   
   
   
   

3. .

   
   
   
   
   

№5 SLA

SLA . . , , , API. SLA, .

SRE , SLO, SLA = SLO + .

, SLA :

SLA , SLA, , . .

№6

, , CI/CD -, . , fault tolerance : , .

, "" , :

1. -, , , chaos engineering.

   
   
   
   
   

2. , Circuit Breaker Tolerant Reader.

   
   
   
   
   

3. : service discovery, health-check,...

   
   
   
   
   

№7

-, , ""?

: - (build-and-run team) . . . :

1. . , Service per team.

   
   
   
   
   

2. InnerSource, . InnerSource .

   
   
   
   
   

3. : , , . , , . , , .

   
   
   
   
   

, . .

, , . :

, . , , . .

№8

, . , , . . , .

, . , SOAP, protobuf, WCF, .NET Core, WCF . , . , .

, .

№9

, . .

. , , "" - . , . - , . .

№10

, . . , , , .

, :

1. , .

   
   
   
   
   

2. .

   
   
   
   
   

.

, , . , :

1. -

   
   
   
   
   

2. -

   
   
   
   
   

3. IT-

   
   
   
   
   

4. 
   
   
   
   

5. SLA

   
   
   
   
   

6. fault tolerance

   
   
   
   
   

7. 
   
   
   
   

8. 
   
   
   
   

9. 
   
   
   
   

10. 
    
    
    
    

, .

, , ? , , AgileDays 2017 microservices.io. , , .

---

:

1. The Death of Microservice Madness in 2018, Dave Kerr

   
   
   
   
   

2. The hidden costs of microservices, Wayne Geils, Mike Hostetler

   
   
   
   
   

3. Microservice Trade-Offs, Martin Fowler

   
   
   
   
   

4. Pattern: Microservice Architecture, Chris Richardson

   
   
   
   
   

5. The Hidden Costs of Microservices, Justin Leitgeb

   
   
   
   
   

6. تحديات وفوائد الأسلوب المعماري للخدمة المصغرة ، الجزء 1 + الجزء 2 ، أندريه فاشات