Микросервисы

Хранилище данных медленное и не справится с большим потоком запросов. В таких случаях можно использовать https://www.elastic.co/elasticsearch/ — он отлично справляется с большими нагрузками и умеет шардироваться и реплицироваться из коробки. Положим в него данные отдельным скриптом для последующего поиска по ним.

Архитектура

https://habrahabr.ru/company/mailru/blog/342526/ - Сервис-ориентированная архитектура (SOA)
https://habrahabr.ru/company/mailru/blog/320962/ - Архитектура микросервисов
https://habrahabr.ru/company/flant/blog/347518/ - Смерть микросервисного безумия в 2018 году

Документация

• Файл Readme плюс можно применить https://swagger.io/

Мониторинг в микросервисной архитектуре

https://www.youtube.com/watch?v=5rdIbu4hNfQ&index=37&list=PLH-XmS0lSi_ypiqUoKq1eTsh4JvMV_URG

Микросервисы: опыт использования в нагруженном пр

https://www.youtube.com/watch?v=MBZtcNgDXzU&feature=youtu.be

Доставка

Про сборку буду рассказывать в терминах Bamboo (так как мы его у себя используем).

https://www.atlassian.com/software/bamboo

Архитектура микросервисов перевод

https://habr.com/en/company/mailru/blog/320962/

http://basho.com/posts/technical/microservices-please-dont/

http://devopsru.com/news/2016-05-10-microservice-trade-offs.html

Статья на хабре

https://habr.com/en/post/249183/

Статья с описанием плюсов и минусов микросервисной архитектуры

http://devopsru.com/news/2016-05-10-microservice-trade-offs.html

https://habrahabr.ru/post/311208

Разработка web API 

https://habr.com/en/post/181988/

RESTful API: мы всё делаем неправильно

https://habr.com/en/post/331064/

Разные команды

Над микросервисами (в Экосистеме) совместно работают несколько команд (Рублевка/Выписка, АБМ, Клик). Мы понимаем, что это разные команды с различными целями и приоритетами.

Общие сервисы

Каждая команда разрабатывает сервисы под свои собственные проекты.

Однако, мы выделяем некий "корневой" набор сервисов, оперирующий базовыми доменами предметной области. Критериями таких сервисов является:

• использование более, чем в одном проекте;
• ориентация на работу с базовыми доменами предметной области;
• отсутствие функциональности, специфично для какого-либо конкретного проекта;
• покрытие тестами не менее, чем на 146%;

Примером такого сервиса может служить сервис работы со счетами или организациями.

Pull-request'ы

Разработка "корневых" сервисов ведется по принципам open-source сообщества. Другими словами, за сервисы не отвечает некая выделенная команда. Вместо этого из каждой команды выделяется набор специально обученных людей (maintainer'ов). Когда одной из команд требуется внести изменения в сервис, она создает pull-request и лоббирует его рассмотрение группой maintainer'ов. Такой подход позволяет:

• каждой их команд принимать участие в разработке;
• вносить изменения так быстро, как это нужно команде (при определенном навыки мотивации review'еров); 

Кроме того, совместное ревью кода должно более-менее выровнять стиль и техники разработки между командами. С другой стороны, подход потребует некой культуры общения и воли reporter'а для того, что бы его pull-request не "завис".

Репозиторий

Stash является единственным и основным интерфейсом к системе контроля версий (Git). Использование альтернатив (GitLab) увеличивает внутреннюю энтропию Организации и не является целесообразным.

Структура и Naming

Каждый проект (Рублевка, Выписка, АБМ) имеет свой отдельный namespace ("Project")  в системе контроля версий (Stash). Проекты группируются по принадлежности к тому или иному бизнесу / направлению: розница, корпораты, мобильные приложения. Каждая группа имеет свой собственный префикс для имени/ключа проекта в Stash (для удобства группировки и выделении в общей массе других проектов). Например:

• Corporate RublePayments / CORP-RPAY
• Retail Transactions / RTL-TRANS

Внутри себя проект содержит все, что необходимо для его функционирования:

• мидл-слой: corp-rpay-xxx-api
• front-слой: corp-rpay-xxx-ui (если фронт на проекте один, можно использовать шаблон corp-rpay-ui)
• скрипты развертки: corp-rpay-scripts

Для сервисов, используемых более, чем в одном проекте создается отдельный репозитарий: CORP-CORE, RTL-CORE. Формат наименования в данном случае изменяется на corp-core-xxx-api.

Индивидуальные инстансы

Каждый проект разворачивает свой собственный инстанс "корневого" сервиса (если таковой требуется). При этом имя экземпляра сервиса становиться отличным: core заменяется на код проекта (e.g., rpay).

Так же при развертке каждого сервиса "тагируется" (с помощью api Consul'а) кодом проекта, в котором он используется (так, что бы проект мог различать "свои" сервисы не только по имен, но и по тагу).

Как только "индивидуальный" сервис начинает использоваться более, чем в одном проекте, и разработчик/архитектор видят потенциал его использования в других проектах, он должен быть перенесён в "корневые". При этом из его имени убирается суффикс проекта, а сам он переезжает в репозитарий "корневых" сервисов.  

RESTful API для сервера – делаем правильно (Часть 1) перевод

https://habr.com/en/post/144011/

RESTFul Api контроллеры в .NET MVC 4 tutorial

https://habr.com/en/post/164945/

Create a REST API with Attribute Routing in ASP.NET Web API 2

https://docs.microsoft.com/en-us/aspnet/web-api/overview/web-api-routing-and-actions/create-a-rest-api-with-attribute-routing

Микросервисы: Azure Functions — скажи серверу нет

https://habr.com/en/company/microsoft/blog/323808/