[НЕТ_ЗВУКА] В этой лекции мы поговорим про микросервисы. Микросервисы это популярный в последнее время паттерн организации программы для упрощения и борьбы со сложностью. Потому что программ становится все больше, больше и больше, сложность их растет, и как-то в этом надо разбираться. Но для начала давайте вообще разберемся, что такое монолит, и чем он отличается от микросервиса. Допустим, у вас есть программа — одна! — которая ходит во все базы данных и делает все, то есть у вас есть кластер серверов, на который катится только одна программа. Все. Это называется монолит. Монолит, потому что он один — и все! А в нем, как правило, намешано довольно много. В нем много разных частей, много кусков. Если же... да! и делает он все. Если же эта программа не большая, и делает она ограниченное количество вещей, но все-таки более-менее разных, это можно назвать просто сервис. А микросервис — это очень маленькая программа, то есть в пределах, ну конечно, в зависимости от языка, от нескольких сотен до нескольких тысяч строк, и делает она только одну вещь. То есть принцип единой ответственности. Это такой идеальный микросервис. Для того чтобы понять, почему вообще стоит разбивать, нужно разобрать проблемы монолита. Первая проблема монолита — это сложность. Когда ваша кодовая база переваливает за несколько миллионов строк, разобраться там бывает довольно тяжело, и когда приходишь так, смотришь — ого! — и бросает в дрожь. Потому что оно между собой вот так вот перекручено, интегрировано, связано — это тяжело. Если вам нужно подправить в одном месте, довольно часто бывает, что в монолите может стрельнуть где-то в другом месте, которое вроде бы никак не должно затрагиваться. Но и опять-таки вам приходится выкатывать это все вместе, и чем больше у вас изменений, тем больше вероятность, что вам придется откатить какие-то другие ваши изменения из-за того, что где-то что-то в одном месте сломалось, но оно критичное для работы вашего сервиса. Еще одной проблемой монолита является то, что все-таки рано или поздно появляется другой сервис. Например, старый был написан на php, новый вы пишете на Go. И вам надо дублировать код, вам надо дублировать вашу бизнес-логику, хотя хорошо бы этого не делать. Либо же еще худший случай — вам нужно копипэйстить один и тот же код в разные места. Если вдруг вам нужно где-то что-то поменять, вам нужно будет обновлять везде все. Поэтому стараются разделять, то есть следовать принципу «разделяй и властвуй», для того чтобы разделить монолит на несколько сервисов. Как обычно это происходит? Вначале у нас есть какая-то просто гора кода, которую мы периодически копаем лопатой, для того чтобы что-то получилось. И если мы хотим оттуда выделить микросервис, для начала мы должны как-то организовать нашу программу. В случае, если у нас правильная архитектура, это хорошо. У нас и так уже все изолировано, и общих пересечений совсем нету. Итак, мы изолируем наш отдельный сервис. То есть у нас, по сути, монолит, но такой, микросервисный, монолит, то есть когда есть несколько отдельных, изолированных кусков кода, которые выступают как отдельные сервисы. Но просто внутри вот одной общей кучи. Соответственно, когда мы выделили такой микросервис, такой сервис внутри вашего монолита, мы можем просто выделить его в отдельную программу. В монолите же, ну или в том, что осталось от этого монолита, потому что он, конечно же, должен уменьшиться в размерах, мы можем оставить только интерфейс похода в наш микросервис. В идеале это будет выглядеть примерно вот так: у нас есть некоторое количество умеренно больших сервисов, где сосредоточена наша основная бизнес-логика. Есть такое же небольшое количество микросервисов, которые следуют принципу единой ответственности и делают одну небольшую вещь, но для всех клиентов к этому микросервису. Однако тут надо не переусердствовать и не получить кучу-малу уже не внутри одной программы, а разнесенную на несколько программ. Это будет довольно печально и жизнь вам не упростит. То есть микросервисы не нужно ставить во главу угла, не надо начинать разработку программы с микросервисов оттого, что вы будете их создавать 20-30 штук. Потому что почему... микросервис — это не всегда хорошо. Ну, во-первых, у микросервисов есть накладные расходы на коммуникацию. Когда у вас ваш, давайте будем оставлять это — монолит, микросервис и база данных. Раньше монолит ходил сразу в базу, и все было хорошо. А потом монолит начал ходить в микросервис, то есть у вас получилось один шаг накладных расходов. В случае, если у вас нестабильная сеть, либо запросов много — это может стать проблемой. Также, если раньше вы катили одну программу, один бинарник, или набор кода, то теперь вам придется катить много программ. То есть ваша сложность может перекочевать просто из одного места в другое. Вы не решите так своих проблем. Ну и надо, наконец, понимать, что микросервис — это не панацея. Они не решат всех ваших проблем. Если ваши проблемы не в том, что у вас монолит, где что-то много стреляет, где бывают ошибки из-за того, что стрельнуло в одном месте, а какие-то организационные проблемы, либо проблема именно с написанием кода: там много ошибок, нет тестирования, то микросервисы, не факт, что решат эти проблемы. Поэтому об этом не надо забывать. Далее мы рассмотрим, каким образом уже в коде можно выделить сервис и как-то заизолировать его, а потом вынести в отдельный микросервис. Мы рассморим всю цепочку и рассмотрим, какие инструменты Go предоставляет для этого. Рассмотрим встроенный пакет для RPC — вызов удаленных процедур, для JSON RPC, и рассмотрим большую библиотеку для организации микросервисов под названием gRPC.
