ݺߣ

ݺߣShare a Scribd company logo
Эксплуатация микросервисной архитектуры
в Lazada
Indonesia	 PhilippinesMalaysia ThailandSingapore Vietnam
Анатолий	Панов
1
Lazada
• Основана	в	2012	году
• Крупнейший	e-commerce в	6	
странах Юго-Восточной	Азии	с	
населением	650	млн	человек
• Более	40	млн	продуктов
• На	последней	распродаже,	
продавали	1,2	млн	товаров	
ежедневно
• С	2016	года	входим	в	Alibaba
Group
2
Инфраструктура
3
Как	все	начиналось
• Первый	ТехХаб во	Вьетнаме	открыт	в	
2013году
• 10	PHP	программистов	и	3	QA
• Стандартный	LAMP	стэк
• Сложные	релизы	проходили	только	по	
ночам
• Типичный	стартап....
*на	фото	один	из	наших	ночных	релизов
4
Команда	Lazada	сейчас
• 4	ТехХаба:	Вьетнам,	Сингапур,	Бангкок,	
Москва
• Около	600	инженеров
• 90%	платформы	разрабатывается	в	
Москве
• Разработка	платформы	только	на	Golang
• Более	130	Golang программистов,	100	из	
которых	находятся	в	Москве
5
Микросервисы в	Lazada
Product	
Service
Customer	
Service
Order	
Service
Monolithic	Core
6
Развитие	микросервисов в	Lazada
7
Микросервисы в	Lazada
8
• Наши	микросервисы написаны	только	на	Go
• Один	микросервис =	один	репозиторий
• У	каждого	микросервиса есть	только	одна	команда	которая	за	
него	отвечает
Обычно	в	этом	месте	начинается	рассказ	про	то	
как	мы	строили	архитектуру	микросервисов,	я	
же хочу	рассказать	о	ней	с	точки	зрения	
эксплуатации.
9
Что	я	понимаю	под	эксплуатацией?
То	сколько	усилий	и	времени	занимают	
инфраструктурные	изменения	и	поддержание	
работоспособности	системы
10
Так	может	выглядеть	ваше	приложение
11
Одна	из	основных	проблем	микросервисов –
большая	фрагментация	инфраструктурных	
решений.	Тяжело	тестировать	и	поддерживать	
систему	где	много	разных	команд	пишут	на	
любимых	языках	программирования	с	похожими,	
но	разными	решениями,	релизными процессами	и	
собственными	приоритетами.
12
Что	же	делать?
13
Решение	1.	Общий	инфраструктурный	фреймворк
“+”
1. Исправляем	в	одном	месте,	просим	всех	обновится.	Это	
достаточно	удобно.
“-”
1. Фреймворк	постоянно	развивается,	теряется	обратная	
совместимость.	Обновления	для	команд	превращаются	в	боль.
2. Фрагментация	версий.	Чем	больше	приложений,	тем	больше	
разных	версий	одновременно	используется.
3. В	каждой	команде	найдется	кто-то,	кому	не	понравится	
архитектура	общего	фреймворка.
14
Тем	не	менее	у	нас	есть	такой	инфраструктурный	
фреймворк под	названием	Brick
15
Решение	2.	Стандарты	и	соглашения
16
Какие	вещи	стоит	стандартизировать?
17
1.	Сборка	и	релиз	приложений
18
Каждая	команда	сама	отвечает	за	сборку	своего	
приложения
19
Сборка	приложений
deploy/builder/Dockerfile
deploy/Dockerfile
20
Makefile
• make	deps
• make	build
• make	ci-deps
• make	ci-lint
• make	ci-benchmark
• make	ci-test-unit
• make	ci-test-integration
• make	ci-test-all
Унифицированный	CI	&	CD	процесс
coding
CI
•Unit	Tests
•Code	Style	
checks
•and	Other	
checks
code	
review
build	
Docker	
image
QA	on	
showroom
QA	on	
staging
live
21
Создание	базовой	версии	сервиса	по	одной	кнопке
22
2.	Инфраструктурные	хендлеры
23
/health_check/
24
/health_check/
25
Admin	port
26
:admin_port/swagger.json
27
А	кроме	того
• Автоматическая	генерация	клиентских	
библиотек	для	Go	&	PHP
• Расчет	покрытия	приемочными	тестами
28
3.	Соглашения по service	discovery
29
Service	Discovery
30
Service	Discovery
MySQL
Service	Discovery
31
MySQL
Service	Discovery
Service	Discovery
32
MySQL
Service	Discovery
• Распределенное	key-value	хранилище
• Написано	на	Go
• Надежное	и	отказоустойчивое
• Использует	алгоритм	консенсунса Raft
33
Соглашения	по	ключам	в	etcd
/admin/<service_type>/<service_name>/<rollout_type>/<service_owner>/<
cluster_type>/<instance_name>
/metrics/<service_type>/<service_name>/<rollout_type>/<service_owner>/
<cluster_type>/<instance_name>
/discovery/<service_type>/<service_name>/<rollout_type>/<service_owner
>/<cluster_type>/<instance_name>
34
Мониторинг	того	что	приложение	запущено
35
4.	Соглашения	по	мониторингу
36
Сбор	метрик
37
Стандартные	метрики
http_response_time_milliseconds – histogram
tags:	handler,	code,	client_name
http_requests_total
tags:	handler,	client_name
mysql_query_duration_milliseconds – histogram
tags:	host,	db,	is_error,	query	(optional)
38
Стандартные	базовые	дашборды
39
Стандартные	алерты
40
5.	Соглашения	по	трассировке	и	формату	логов
41
Трассировка
42
Соглашения	по	формату	логов
43
{YYYY-mm-ddTHH:mm:ss.microseconds±hh:mm}	|	{TraceId}	|	{ParentSpanId}	
|	{SpanId}	|	{rollout_type}	|	{service_name}	|	{level}	|	{component_name}	|	
{file_name_and_line}	|	{message}	|	{additional_data}	|	{is_truncated}
6.	Соглашения	об	эластичной	архитектуре
44
Соглашения	об	эластичной	архитектуре
Приложение	должно	запустится	даже	если	
нужные	ему	ресурсы	недоступны	и	продолжить	
работать	если	ресурс	стал	недоступен	в	процессе	
работы
45
Главный	недостаток	соглашений
Главный	недостаток	соглашений,	то	что	нужно	
следить	за	их	исполнением
46
Что	же	делать?
47
Conventions	checker
Конвейер	с	модульной	структурой,	
благодаря	которой	любой	человек	
в	компании	может	написать	свое	
расширение	на	любом	языке	
программирования
48
Интересные	модули
1. Модуль	проверки	версий	
библиотек
49
Интересные	модули
1. Модуль	проверки	версий	
библиотек
2. Модуль	проверки	эластичности	
сервиса
50
51
Дальнейшее	развитие
coding CI code	review
build	Docker	
image
Conventions	
validation
QA	on	
showroom
QA	on	
staging
live
52
Соблюдая	соглашения	команда	получает
• Создание	Go	сервиса	одной	кнопкой	и	готовый	релизный
процесс
• Административный	интерфейс	с	кучей	полезных	функций
• Возможность	динамически	обновлять	списки	внешних	
зависимостей
• Стандартные	дашборды с	метриками	и	алерты
• Готовую	инфраструктуру	для	сбора	логов
• И	много	другое	о	чем	не	хватило	времени	рассказать
53
54
Анатолий Панов
anatoly@i-panov.com
Спасибо за внимание!
Вопросы?

More Related Content

Эксплуатация микросервисной архитектуры в Lazada (Стачка 2017, Ульяновск)