Uber की Domain-Oriented Microservice Architecture

DOMA वह तरीका है जिसे 2200 microservices वाले Uber ने MSA की flexibility बनाए रखते हुए complexity कम करने के लिए अपनाया

• इसे DDD, SOA, OO, CA आदि से लेकर बड़े संगठनों के large-scale distributed systems के हिसाब से डिज़ाइन किया गया है

• लंबे समय तक MSA चलाने के Uber के गहरे अनुभव का सार इस लेख में समाहित है

DOMA के मूल सिद्धांत

1. microservices को Domain इकाइयों के अनुसार collections में समूहित करना

2. domain collections से Layer कहलाने वाले समूह बनाना, ताकि हर layer के भीतर dependencies रखी जा सकें → Layer Design

3. हर collection के लिए single entry-point के रूप में साफ interface देने वाला Gateway बनाना

4. हर domain को दूसरे domains से स्वतंत्र होना चाहिए। लेकिन अक्सर दूसरे domain की logic शामिल करनी पड़ती है, इसलिए इसे अच्छे से support करने वाली Extension architecture दी जाती है

** Uber का implementation

• Domains

→ एक या अधिक microservices का logically grouped संग्रह।

→ किसी domain में 10 से अधिक services हो सकती हैं, या सिर्फ एक भी हो सकती है

→ उदाहरण) map search, fares, matching platform (rider और driver) आदि एक-एक domain हैं

→ यह कंपनी की organizational structure का पालन नहीं करता, इसलिए Uber की maps-संबंधित organization 3 domains, 80 microservices, और 3 gateways से बनी है

• Layer Design

→ “कौन-सी service दूसरी services को call कर सकती है?” का उत्तर

→ “separation of concerns at scale” या “dependency management at scale”

→ Uber में 5 layers हैं

1. Infrastructure : वे capabilities जिन्हें सभी organizations उपयोग कर सकें। जैसे storage/networking आदि

2. Business : वे capabilities जिन्हें business स्तर पर उपयोग किया जा सके। यह किसी specific product category या Rides, Eats, Freight जैसी LOB(Line Of Business) तक सीमित नहीं है

3. Product : specific product category और LOB से जुड़ी capabilities, लेकिन “Request a ride” जैसी चीज़ें भी शामिल हो सकती हैं जिन्हें कई apps मिलकर इस्तेमाल करते हैं

4. Presentation : user-facing applications से संबंधित capabilities (mobile / web)

5. Edge : Uber services को बाहर सुरक्षित रूप से expose करना। mobile applications से भी integration

• Gateways

→ microservices के API Gateway से बहुत अलग नहीं। लेकिन इसे Domain से जुड़ने वाले single entry-point के रूप में समझना चाहिए

→ अंदरूनी तौर पर यह बाहरी दुनिया के साथ single dependency बनाता है, इसलिए migration, discovery, और overall system complexity कम हो जाती है

• Extensions

→ service implementation बदले बिना या stability को प्रभावित किए बिना domain को extend करने का mechanism

1. Logic extension : Provider या Plugin pattern का उपयोग करके service logic को extend करना

2. Data extension : core data को अनावश्यक रूप से बढ़ने से रोकने के लिए arbitrary data जोड़ने का mechanism। Protobuf के Any type का उपयोग

3. Custom extension : domain के हिसाब से हर team अपने उपयुक्त pattern से extension करे

onboarding time में 25~50% तक कमी का प्रभाव

2200 microservices को 70 domains में विभाजित किया गया।

Uber में microservices की half-life 1.5 साल आंकी गई। यानी हर 1.5 साल में 50% microservices गायब हो जाती हैं

अगर gateways न हों, तो हर बार इनके खत्म होने पर migration hell शुरू हो जाएगा।

Uber में DOMA के साथ डिज़ाइन किए गए platforms के बारे में साबित हुआ कि वे कहीं ज़्यादा आसानी से scale होते हैं और maintain करना भी आसान है।

दूसरी कंपनियों के लिए व्यावहारिक सलाह

• startup :

→ “हमें MSA कब अपनाना चाहिए?” “क्या यह हमारी organization के लिए उपयोगी होगा?” जैसे सवाल महत्वपूर्ण हैं।

→ MSA, बहुत से engineers वाली organizations को operational लाभ देता है, लेकिन complexity भी बढ़ाता है और feature development को कठिन बना सकता है

→ छोटे organizations में यह operational फायदों से अधिक architecture complexity बढ़ा सकता है, और लागत भी बढ़ा सकता है।

→ इसे धीरे-धीरे अपनाना भी बिल्कुल ठीक है, और अगर MSA अपनाने का निर्णय लें तो इसे “large-scale distributed program” की तरह सोचकर microservices के बीच स्पष्ट separation करना चाहिए।

→ शुरुआती microservices वे होने चाहिए जो business की core capabilities को दर्शाएँ, महत्वपूर्ण हों, और लंबे समय तक टिकें

• mid-size company :

→ जब कंपनी कई teams में बँटने लगे और platforms के बीच concerns अलग-अलग होने लगें, तब MSA अधिक उपयोगी हो जाता है

→ इस चरण में microservices के बीच hierarchy पर विचार किया जा सकता है, और जैसे-जैसे अधिक services उपयोग में आती हैं, dependency management महत्वपूर्ण हो जाता है

→ अभी microservices की संख्या बहुत अधिक नहीं होती, इसलिए clustering का अर्थ कम हो सकता है, लेकिन domain-oriented सोच उपयोगी रहती है

• बड़ी कंपनी :

→ large-scale engineering organizations में सैकड़ों engineers, microservices और dependencies होती हैं, इसलिए DOMA पूरी तरह उपयोगी है

→ domains को gateways के साथ आसानी से group किया जा सकता है, और legacy को refactor या rewrite करते समय भी gateways उपयोगी होते हैं

Uber में भी DOMA को धीरे-धीरे अधिक teams अपना रही हैं। (बताया गया है कि Uber की अलग-अलग organizations से लगभग 60 लोगों ने मिलकर इसे 2 साल में बनाया)

[algedian]

https://eng.uber.com/microservice-architecture/

अभी तो यह ठीक से दिख रहा है.. लेकिन लगता है कि wayback मशीन में जो है, उसमें चित्र थोड़ा अलग है

[xguru]

अरे, यह फिर से ठीक हो गया है, हाहा.

लगता है जिस चित्र में विस्तृत service name दिख रहा था, वही समस्या थी.

[jaeyeonling]

लगता है पोस्ट डिलीट हो गई है T.T

[xguru]

अरे, सही कहा। फिलहाल इसे Wayback Machine में देखा जा सकता है.

https://web.archive.org/web/20200803012939/…

[jaeyeonling]

धन्यवाद :)