Микросервисы / распределенные системы
4.21K subscribers
107 photos
1 video
21 files
318 links
Мысли, новости и ссылки по распределенным система и распределенной разработке.

Рекламу не размещаю.
Download Telegram
​​Не так давно выкладывал ссылку на работу о сагах (https://tttttt.me/microservices_arch/82), пришло время работы о модульности. Еще в 71-м году Девид Парнас описал подход к модульности через сокрытие информации как более предпочтительный, чем подход, в котором модули являются шагами процесса. Физическое воплощение модульности через сокрытие информации мы и видим в том числе в микросервисах, когда скрываем детали реализации сервиса, включая его данные («difficult design decisions or design decisions which are likely to change»), за API.

…it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since,in most cases,design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules.

Читать статью полностью: https://prl.ccs.neu.edu/img/p-tr-1971.pdf
​​Иначе мы можем сказать, что при корректно определенных границах микросервисов критически важна изоляция состояния. Это дает возможность внутреннего эволюционного развития микросервиса без негативного влияния на его внешнее окружение. Под негативным влиянием можно понимать, например, необходимость координации с другими командами/сервисами при внесении изменений или, более простым языком — наличие жестких зависимостей. На картинке — если два сервиса начинают использовать одну базу, то им придется договариваться о внесении изменений в эту базу. Зависимость detected.
Хорошая статья о тестировании микросервисов «Microservices test architecture. Can you sleep well without end-to-end tests?»
с примерами кода.

https://threedots.tech/post/microservices-test-architecture/
Завтра в clubhouse в 19:30 мск поговорим о проблемах микросервисной архитектуры.

https://www.joinclubhouse.com/event/xpA28noL

w/ Anna Pimkina, Sergey Baranov, Pavel Scherbinin, and Evgeniy Peshkov
Подборка ссылок про архитектуру Netflix, одну из самых часто цитируемых микросервисных архитектур:

Netflix: What Happens When You Press Play?
Dec 11, 2017
http://highscalability.com/blog/2017/12/11/netflix-what-happens-when-you-press-play.html

High Quality Video Encoding at Scale
Dec 9, 2015
https://netflixtechblog.com/high-quality-video-encoding-at-scale-d159db052746

Building and Scaling Data Lineage at Netflix to Improve Data Infrastructure Reliability, and Efficiency
Mar 25, 2019
https://netflixtechblog.com/building-and-scaling-data-lineage-at-netflix-to-improve-data-infrastructure-reliability-and-1a52526a7977

Ten years on: How Netflix completed a historic cloud migration with AWS
Sep 10, 2018
https://www.channelasia.tech/article/646530/ten-years-how-netflix-completed-historic-cloud-migration-aws/

The Netflix Simian Army
Jul 19, 2011
https://netflixtechblog.com/the-netflix-simian-army-16e57fbab116

Globally Cloud Distributed Applications at Netflix
Oct 2012
https://www.slideshare.net/adrianco/netflix-global-cloud

Open Connect Overview
https://openconnect.netflix.com/Open-Connect-Overview.pdf

Open Connect Deployment Guide
http://openconnect.netflix.com/deploymentguide.pdf

Netflix and Fill
Aug 11, 2016
https://netflixtechblog.com/netflix-and-fill-c43a32b490c0

Automating Operations of a Global CDN
Sep 14, 2019
https://www.youtube.com/watch?v=Lwh6Yd_kfsQ

Mastering Chaos — A Netflix Guide to Microservices
Dec 07, 2016
https://www.infoq.com/presentations/netflix-chaos-microservices/

Netflix Revenue and Usage Statistics
March 6, 2020
https://www.businessofapps.com/data/netflix-statistics/

Netflix Play API — Why we build an Evolutionary Architecture
Dec 12, 2018
https://www.infoq.com/presentations/netflix-play-api/

Keystone Real-time Stream Processing Platform
Sep 10, 2018
https://netflixtechblog.com/keystone-real-time-stream-processing-platform-a3ee651812a

Netflix Releases Open Source Message Security Layer
Nov 24th, 2014
https://www.infoq.com/news/2014/11/netflix-msl/

Netflix Open Source
https://netflix.github.io/

Titus, the Netflix container management platform, is now open source
Apr 18, 2018
https://netflixtechblog.com/titus-the-netflix-container-management-platform-is-now-open-source-f868c9fb5436

Engineering Trade-Offs and The Netflix API Re-Architecture
Aug 23, 2016
https://netflixtechblog.com/engineering-trade-offs-and-the-netflix-api-re-architecture-64f122b277dd

Kafka Inside Keystone Pipeline
April 27, 2016
https://netflixtechblog.com/kafka-inside-keystone-pipeline-dd5aeabaf6bb

Open Sourcing Zuul 2
May 21, 2018
https://netflixtechblog.com/open-sourcing-zuul-2-82ea476cb2b3
История становления AWS из первых уст (Dan Rose).

Небольшая цитата из рассказа по ссылке, относящаяся к теме канала: «Around this same time, Jeff was also interested in decoupling internal dependencies so teams could build without being gated by other teams. The architectural changes required to enable this loosely coupled model became the API primitives for AWS.»

https://twitter.com/danrose999/status/1347677573900242944?s=27
Четыре виде кеширования, используемые в микросервисной архитектуре Wix

1. Locally Persisted (or S3 backed) Configuration Data Cache
2. Kafka topic based 0-latency Cache
3. (Dynamo)DB+CDC based Cache
4. HTTP Reverse Proxy Caching (Varnish cache)

Для каждого вида дано описание с небольшими техническими деталями, возможный размер кеша, в каких случаях следует использовать, а в каких – не подойдет.
В конце статьи — диаграмма принятия решений по выбору типа кеша.

https://medium.com/wix-engineering/4-microservices-caching-patterns-at-wix-b4dfee1ae22f
Фейсбук сегодня напомнил, что в этот день в 2016-м году я написал такой текст о качестве:

Правильное и уместное использование инженерных процессов и практик в купе с отлаженным и осознанным применением процессных подходов позволяют получить на выходе качественный код и первоклассные системы.

Очень часто в понятие «качественный» вкладывают смысл «корректный с точки зрения функциональности». В действительности же «качественный» можно обозначить, как открытый к изменениям. И вот в игру вступают такие термины, как: «простота», «понятность», «гранулярность», «инкрементальность».

Суть в том, что если посмотреть на «качество» с этой точки зрения, то мы можем попытаться его измерить. Общей мерой качества становится то, как быстро и насколько безопасно мы можем вносить изменения в систему.

———

Микросервисная архитектура оказывает весьма положительное влияние как на скорость, так и на безопасность внесения изменений, особенно при необходимости масштабировании (at scale).
Обращали внимание, что почти никто и никогда не пишет в книгах и статьях о микросервисах о возможности повторного использования? Конечно, это не означает, что микросервисы нельзя повторно использовать, другое дело, что это уже будет другой микросервис в другом контексте с другими границами на уровне модели предметной области.

Стоит уточнить, что под повторным использованием (reusability) мы понимаем именно использование того же самого в другом контексте. Например, библиотека логирования. В любом контексте она остается библиотекой логирования, пусть мы ее используем в разных проектах, продуктах. Для микросервисов же важен контекст, они буквально создаются в рамках контекста и перенос микросервиса в другой контекст приводит к появлению нового микросервиса. Как только мы попытаемся сделать микросервис универсальным под два контекста — мы получили зависимость и попали в лапы затрат на координацию при внесении изменений, потеряли автономность в развитии.

Немного подробнее и в цифрах. Здесь X - знак умножения.

Ценность повторного использования мы можем выразить как:
(количество повторных использований) X
(стоимость разработки фичи) X
(фактор ценности при использовании повторно используемого компонента)
(фактор стоимость разработки самого повторно используемого компонента) X
(стоимость разработки фичи)

Несколько пояснений:
фактор ценности при использовании повторно используемого компонента — процентная величина, 75% означает, что при использовании повторно используемого компонента требуется на 75% меньше усилий в сравнении с разработкой с нуля

фактор стоимость разработки самого повторно используемого компонента — процентная величина, повтрно используемый компонент реализовать — дороже, в зависимости от сложности может быть 150%, 300% и даже 500%.

Вынесем стоимость разработки фичи за скобки, получим:

Ценность повторного использования =
(стоимость разработки фичи) X (
(количество повторных использований) X (фактор ценности при использовании повторно используемого компонента)
(фактор стоимости разработки самого повторно используемого компонента)
)

Как повысить ценность? Повышать количесство повторных использований, либо повышать фактор ценности при повторном использовании, либо снижать фактор стоимости разработки повторно используемого компонента. Все логично.
И более, чем логично, если это библиотека, которая не зависит от контекста использования.

Микросервисы не задумывались повторно используемыми. Они задумывались как сервисы в рамках границ контекста в модели бизнеса. Но если мы все же хотим повторно используемый микросервис?

1. Кол-во повторных использований будет равно единице. Иначе мы создаем зависимости и чем чаще используем повторно, чем выше координационная нагрузка, а значит тем выше (фактор стоимости разработки самого повторно используемого компонента)
2. Сама начальная стоимость повторно используемого микросервиса не определена, потому как мы на перед не знаем, в каких контекстах сможем его использовать повторно. Соответственно, либо всё, что можно будет обложено конфигурационными настройками (очень дорого), либо см. пункт 1.
Технические сервисы (не микросервисы, типа сервиса отправки писем, как sendmail с rest api - это не то же самое, что микросервис в его определении, такие сервисы можно использовать повторно, конечно, что мы и делаем - это generic или supporting домены).

Итого, делаем вывод, что для микросервисов в их первоначальном определении повторное использование не применимо из прагматичных соображений. Каждый микросервис создается под свои границы в конкретной модели предметной области бизнеса. Повторное использование микросервиса приводит к появлению нового микросервиса в новом контексте, развивающегося автономно от изначального микросервиса.

Готов подискутировать в комментариях.
В подлодке планируется неделя распределенных систем. До понедельника - early birds. podlodka.io/becrew
“Don't build elaborate APIs that mimic the back-end system's design. Instead, build consumer-driven APIs that provide the service in a format that the front-ends prefer.” (с) Gregor Hohpe, Cloud Strategy

При проектировании API учитывайте контекст, в котором сущность используется.

Вместо всеобъемлющего
GET /product/123

Используйте хотя бы контексты
GET /catalog/product/123
GET /checkout/product/123
GET /someothercontext/product/123

С теми атрибутами, которые нужны в заданном контексте. Эту рекомендацию можно использовать и в монолите, в микросервисах же она жизненно-необходима.

Если пойти дальше, в DDD (например через event storming), то API изменятся еще сильнее и станут отражать поведение, а не сущности:
/GetAvailableProducts
/GetProductDeliveryOptions
/GetProductsAtSale

Такие API удобно развивать, они обеспечивать минимальную связанность и максимальное сцепление.

Проверим от противного
Три Use Cases:
- Отобразить доступные на складе продукты
- Отобразить варианты доставки продукта
- Получить список продуктов, участвующих в распродажах

В случае реализации трех сценариев с использованием метода /product/123 мы получаем зависимость всех трёх от одного API. Потребность в изменениях для одного приведет к необходимости координации изменений со всеми остальными. В случае API, определяемых от поведения таких зависимостей нет.
Рейтинг баз данных по популярности. Может пригодиться как одно из измерений в выборе БД под потребности конкретного сервиса.
https://db-engines.com/en/ranking
Security-Chaos-Engineering-Verica-.pdf
2.4 MB
Достаточно свежая, очень классная книга по теме Security Chaos Engineering.
На фото происходит ровно то, что написано, без двусмысленных толкований 🙂
Фейсбук напомнил о написанном 5 лет назад :) Легаси Стрит :)

Когда мы говорим о том, какими микросервисы должны быть с концептуальной точки зрения, мы всегда держим в уме и повторяем как мантру: «слабая связанность» и «сильное сцепление». Всегда.
И маршируя по Legacy Street за переход к более гибкой архитектуре, на наших транспарантах будут именно словосочетания «слабая связанность» и «сильное сцепление» :)
Что главное? Возможность внесения изменений и развертывание сервиса без необходимости внесения изменений в любую другую часть системы. Оно же — Low Coupling.
Сильное сцепление (High Cohesion) — я, как кем бы я ни был, хочу, чтобы связанное поведение находилось в одном месте, внутри некой границы, которая имела бы как можно более слабую связь с другими границами.
Вот тут появляется ограниченный контекст (Bounded Context) или иначе — конкретная ответственность, обеспечиваемая четко обозначенными границами.
И если мы хотим перейти от монолита к микро, то мы сначала очень аккуратно выделяем контексты, определяем модель (внутреннюю для контекста), повышаем модульность системы. Уверены? Выносим модуль в сервис.
И думаем о сервисах в терминах бизнес-возможностей. Сначала «Чем контекст (модуль, сервис) занимается и какие услуги предоставляет?», затем «Что (какие данные, внутренние или из других контекстов) ему нужны?»
Есть идеальный код, а есть просто хорошо структурированный

Так вот, идеальный код — практически невозможно писать (но можно стремиться). При пересмотре через месяц — всегда придумаешь как его можно было бы улучшить, или решить проблему более гибко/элегантно.

Структурированный, чистый, читаемый код — это код, который может быть «тупым», но легко понимаемым и читаемым. Возможно он не даст гибкости, но он позволит быстро найти ошибку в логике программы. И исходя из этого посыла НЕ СУЩЕСТВУЕТ причин, не писать хорошо структурированный код.

Статья от нетфликс о hexagonal architecture: https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749

Рассуждения Саймона Брауна на тему организации кода: https://www.codingthearchitecture.com/2016/04/25/layers_hexagons_features_and_components.html

Кому интересна история - первая статья о hexagonal architecture (Alistair Cockburn): https://archive.is/5j2NI
Для любителей видео: https://www.youtube.com/playlist?list=PLGl1Jc8ErU1w27y8-7Gdcloy1tHO7NriL