Я планирую написать несколько статей, подытоживающих мои три года работы техническим директором Nuggets, в которых я расскажу о своем мышлении и достижениях с точки зрения технологий, продуктов и управления.

Эта статья — первая из них.Когда я впервые пришел в Nuggets в конце 2016 года, я опишу в хронологическом порядке техническое планирование и техническое планирование рефакторинга и миграции всего сайта на Nuggets, техническое сообщество, работающее на ServerLess, Nuggets , в общедоступное облако. Процесс внедрения. И некоторые размышления.

начало истории

Когда я впервые пришел в Nuggets, там было 2 инженера по Android, 2 инженера по iOS и 3 фронтенд-инженера. Не больше. Это весь штат разработчиков. Этот штат поддерживает первых 200 000 зарегистрированных пользователей Nuggets. Служить.

Nuggets построены на платформе ServerLess. Наша реализация на стороне сервера — это все node.js. Затем мы предоставляем интерфейсы для всех клиентских вызовов. Платформа завершила базовый драйвер базы данных, хранилище модели данных и базовый механизм ACL, лежащие в основе таких абстракций, как как хранилище контента, функции, связанные с пользователем (полный набор решений для пользовательского центра) и т. д. Используя его SDK, вы можете создать небольшое приложение.Так быстро родились Nuggets.

Но вскоре мы столкнулись с некоторыми проблемами.

故障.Да, и это системный сбой.Из-за высокой интеграции платформы ServerLess мы даже не можем открыть панель управления в случае системного сбоя.Если это система построенная нами, то по крайней мере может быть но полностью Если мы полагаемся на всю систему, у нас нет другого выбора, кроме как ждать, пока платформа исправит ее перед лицом системных сбоев.

性价比问题Мы все знаем, что тарификация по объему очень рентабельна, когда объем запроса небольшой, а модель тарификации с фиксированным объемом будет более экономичной, если объем запроса превышает определенный уровень.Это то же самое, что и мобильный пакет данных. объем нашего бизнеса уже пересек экономический диапазон, основанный на объемах, затраты начали значительно расти.

平台架构完全的黑盒.За исключением SDK, который мы используем, мы ничего не знаем об архитектуре и инфраструктуре платформы.Внешней рабочей границей является наше собственное доменное имя, а внутренней рабочей границей является наш собственный код бизнес-логики.Кроме того, это полностью Черный ящик ServerLess.Хотя преимущество ServerLess в том, что разработчикам вообще не нужно обращать на это внимание, в реальной производственной практике ServerLess не всемогущ.

架构腐败, Сложность кода разрослась до ситуации, с которой невозможно справиться существующей рабочей силой.Идея ServerLess заключается в том, чтобы быть как можно более легким, но связанность существующей архитектуры довольно высока, и это часто необходимо чтобы запланировать отдельное время для рефакторинга кода.Это кажется тяжелым Создано, чтобы сделать организацию кода более гладкой, но на самом деле это более глубокая проблема.

Необходимость частого рефакторинга кода напрямую иллюстрирует следующие проблемы:

Существующий архитектурный проект сильно противоречит новым требованиям, и каждая модификация несовместима с исходной архитектурой.
Существующие архитектуры сложны для разработки и требуют довольно глубокого понимания текущего макета и шаблонов, которые необходимо изменить, иначе архитектура будет повреждена.
Существующая архитектура расширяет горизонтальную сложность (увеличивается объем кода), что приведет к резкому увеличению вертикальной сложности (кода, который организует код), а бизнес-развитие стартапов идет очень быстро, что приводит к очень быстрому росту. в том количестве кода, которое будет вынуждено провести Безумный рефакторинг.Вот почему крупномасштабным проектам нужны шаблоны проектирования.Всем нужен единый способ управления ростом горизонтальной сложности бизнеса, а само управление будет увеличивать вертикальную сложность Вообще говоря, объем кода слишком велик Для организации кода необходимы соответствующие шаблоны проектирования, и чем больше кода, тем сложнее шаблоны проектирования и требуемый организационный код, т. е. возрастает вертикальная сложность. быть решена человеческими руками, а вертикальная сложность требует富有经验的,熟悉当前架构的,并对接下来业务衍化有一定预知能力的инженеры для решения.

Три необходимых условия, которые я даю, чтобы хорошо справляться с вертикальной сложностью, — это выводы, сделанные на основе опыта и размышлений:

富有经验的Представитель может понять текущую структуру
熟悉当前架构的Представители могут быстро вносить изменения в текущую архитектуру
并对接下来业务衍化有一定预知能力的Это означает, что текущую архитектуру можно изменить в правильном направлении.

Основываясь на этих причинах и размышлениях, я намерен полностью изменить старую архитектуру и разработать архитектуру Nuggets для обслуживания 1 миллиона зарегистрированных пользователей.

Когда я впервые подумал об этом, я также был очень осторожен. Я полагаю, что вы сталкивались с проектами рефакторинга в своей карьере. Риск рефакторинга так же велик, как и он.

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

Но единственная уверенность в том, что если Nuggets не сможет вырасти до 1 миллиона зарегистрированных пользователей за короткий промежуток времени, то дальнейшее развитие бессмысленно, только при быстром росте появится шанс на выживание в будущем. единственный способ - внести изменения.

Что ж, теперь, когда я решил это сделать, я должен реализовать это как можно скорее, но в это время я столкнулся с новой проблемой: не хватает персонала.

Да, количество инженеров не пополняется.Хотя я изо всех сил старался снизить требования к найму инженеров, может не найтись даже одного человека, который сможет легко внедрить связанный список на собеседовании., инженеры с богатым опытом. Если начинающая компания неизвестна, она сама по себе не очень привлекательна.Если вы хотите нанять инженеров с крупного завода, это не проблема, которую можно решить, платя зарплату с крупного завода. .А у нас такого бюджета нет.Вообщем по моему опыту он как правило в головной компании,и идеального кандидата можно набрать за 2 недели на позицию джуниор.Но перед Наггетс это не обязательно удовлетворительный кандидат на 3 недели.

Это приводит меня к предположению, столкнутся ли «Наггетс» с такой ситуацией, когда общий уровень инженеров не может быть улучшен в течение длительного времени?

На момент написания этой статьи прошло 4 года с тех пор, как я выдвинул эту гипотезу.Оказывается, эта гипотеза верна.初创公司如果不花大价钱, 那就无法稳定获得和维持优秀的工程师Это урок пролитой крови.

Итак, еще в то время, когда уровень инженеров был невысок, а рабочей силы не хватало, как построить能支撑100W用户,能迅速推进新业务,成本又不是特别高системы?Прежде чем продолжить, нам нужны некоторые теоретические основы.Эти теории и размышления могут быть все еще на очень поверхностном уровне, но из практического опыта они оказались успешными и привели к моему ответу.Так что поделюсь с вами,надеюсь Бросать кирпичи для привлечения нефрит.

скучная концепция

Концепция размера порции

Размер сервиса - интересная тема. Почему бы нам не организовать весь код в один сервис? Как нам спроектировать размер сервиса?

давайте сначала посмотрим服务大小的区分, Размер службы не относится к размеру кода службы, а относится к организации служб, составляющих бизнес.Мы можем попытаться классифицировать размер службы в зависимости от организации.

Давайте сначала предположим бизнес фиксированного размера, такой как Wordpress, который является полноценным бизнесом типа CMS.

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

Далее мы разделим Wordpress бесконечно и разделим его на каждую функцию, чтобы сформировать службу (потому что подразделять бессмысленно, а разделение функции соответствующего размера и функции только снизит производительность и усложнит). с функцией наименьшей единицы обслуживания является наименьшим видом в обслуживании.

Для простоты обсуждения мы прямо называем минимальную модель обслуживанияPicoservice, Максимальная ставка режимаPolyservice. PolyserviceWordpress, о котором мы только что сказали, является хорошим примером, на самом делеPolyserviceЕсть много традиционных компаний, которые могут организовать код таким образом, и я думаю, что все видели это. Но бизнес, в котором каждая функция разделена на службы, встречается редко. Я примерно насчитал около 10 000 функций в Wordpress. Да Представьте себе разделение Wordpress наPicoserviceКакой ужас, наконец, превратиться в бизнес.На самом деле, только бизнес, работающий на платформе FAAS, может быть составлен и работать в виде одной функции.

Согласно определению размера сервиса, мы можем отсортировать существующие типы сервисов по размеру:

Picoservice <= FAAS(or ServerLess) < Microservice < Monoservice <= Polyservice

Уведомление服务大小и服务部署规模тоже не важноPicoserviceвсе ещеPolyservice, если он правильно разработан, его можно развернуть на нескольких компьютерах для повышения производительности.

И почему FAAS выглядит как модель, близкая к разделению каждой функции на услуги?降低每次编写成本, Если программа достаточно мала и цель достаточно едина, то стоимость каждой записи или модификации будет достаточно низкой.Эта идея аналогична unix, написать программу с одной целью и функцией и использовать конвейер для организации программа для выполнения более сложной работы.Другой момент заключается в том, что текущая аппаратная производительность достаточно мощная, чтобы разориться таким образом, жертвуя некоторой производительностью в обмен на удобство.

Микросервисы — это архитектурная модель бизнес-единицы такого рода мышления, поэтому я думаю, что микросервисы также можно назвать BAAS (бизнес как услуга, бизнес как услуга).

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

Концепция шаблона зависимости службы

Введя понятие размера службы, мы можем начать обсуждение шаблонов зависимости между службами.

Сначала мы знаем, этоPolyserviceЭто не имеет необходимой связи с тем, удовлетворяются ли низкая связанность и высокая когезия.PicoserviceА как насчет ситуации? Конечно, у нас не будет интерфейса для каждой функции, но если мы предположим, что наш сервис будет разделен, как мы должны его разделить? Очевидно, нам нужно, чтобы его было как можно проще отключить Места, которые легко отключить, — это естественная логика бизнеса, подфункции бизнеса, внешние зависимости, границы ресурсоемкой логики, такой как память ЦП, и логика многократного повторного использования.

Начнем также с идеальной модели.Здесь речь идет о чистом数据耦合(Data Coupling).

Серийный шаблон ABC

который:

A->B->C

Если такой бизнес разделен, пока А и С не объединены, это не ошибка, потому что функции А и С не имеют значения, и они становятся偶然内聚性(Coincidental Cohesion)Ни о какой сплоченности не может быть и речи.

Взаимная модель AB

A <-> B

Если есть два узла, вы можете решить, разделяться или нет, если нет других условий, вам не нужно слишком много думать.

Шаблон дерева ABC

то есть такой шаблон:

ABC-Tree-Pattern:

 A
↓ ↓
B C

или

ABC-Turn-Tree-Pattern:

B C
↓ ↓
 A

Для обоих режимов также гарантируется, что пока偶然内聚性(Coincidental Cohesion)Совмещение B и C не является ошибкой.

Петля ABCD

который:

A -> B
↑    ↓
D <- C

Этот шаблон обычно используется в функциях обратного вызова и обычно подходит для использования с прямым порядком байтов для повышения производительности.

Эти 4 минимальных шаблона являются наиболее распространенными шаблонами, которые составляют деловые вызовы.Далее, давайте посмотрим на шаблоны вызовов реальных программ:

Мы можем видеть граф вызовов программы (Call Graph), который в основном является комбинацией этих режимов, для крупного бизнеса это фактически древовидный режим вызовов (как показано на рисунке, граф вызовов Kiali микросервисов ).

Затем, в соответствии с приведенным выше базовым шаблоном, мы знаем, на какое состояние не подходит расщепление, но мы не имеем ни малейшего представления о том, на какое состояние его можно расщепить.

Наименьшая единица естественного бизнеса

Все мы знаем, что спрос порождает бизнес, а если спроса нет, то и писать код не нужно.Так что же такое наименьшая единица бизнеса?

Мы определяем, что набор операций, который содержит только одну функцию, является минимальной бизнес-единицей, например, бизнес статей (включая создание статей, чтение статей, обновление статей, удаление статей и т. д.), а операции — это наименьшая операционная единица. (Минимальная операционная единица).

Вообще говоря, в соответствии с минимальным пределом разделения бизнеса, он делится в соответствии с минимальной бизнес-единицей.Если это для повышения производительности, его можно частично обновить, чтобы разделить в соответствии с минимальной операционной единицей.Даже для максимальной производительности операционная единица необходимо разделить внутри. Например, при производстве потока данных Weibo модели большого V и обычных пользователей различаются.

Мой практический опыт показывает, что если часть логики программы имеет одно или несколько из следующих поведений, ее можно рассматривать для разделения:

Вызывается только другими частями, т.е. логикой в нижней части графа вызовов (обычно это может быть утилита или класс хранилища)
называется многими другими частями
называет многие другие части
Части, в которых бизнес-требования меняются очень часто
различные части пользователя
Запросы, которые занимают много времени
Объем кода значительно больше, чем другие части

Разделение с минимальным шаблоном бизнес-единицы

Благодаря концепции размера службы мы узнали, что чем меньше служба, тем проще в нее вносить изменения и, конечно, ниже производительность. сервисные зависимости проще.

Выше мы говорили о появлении концепции Zhongtai, которая извлекает общие части между микросервисами для повышения производительности.Тогда мы можем естественно подумать о том, существует ли противоположная Zhongtai концепция?Например, разбросанная платформа (здесь будет Zhongtai's Zhongtai is понимается как концентрированный Чжун, а не посередине?

Хорошо, давайте поговорим о паттерне между FAAS и микросервисами в размере услуги. Я называю его паттерном минимальной бизнес-единицы. То есть бизнес-подразделение является базовой единицей паттерна, и его особенность на практике Преимущество в том, что это поощряется повторно использовать одну и ту же логику способом репликации, чтобы уменьшить степень повторного использования одной и той же логики разными службами.Таким образом, влияние бизнес-изменений на службы сводится к минимуму.

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

Это анти-паттерн, хоть и является разновидностью повторного использования, но прямо нарушает принцип DRY (Don't Repeat Yourself), недостатки напрямую ведут к расширению объема кода, увеличению затрат на сопровождение и т.д. сложность обслуживания.Но на этот раз мы посмотрим, что он будет делать:

Прежде всего, его самым большим преимуществом является то, что он может снизить вероятность внесения ошибок в модификацию кода.旧代码不变就不会引入新问题.
Во-вторых, увеличение вертикальной сложности кода (логика управления, созданная для организации кода, лучшим примером является шаблон проектирования) может быть заменено увеличением горизонтальной сложности (раздуванием объема кода).
Опять же, его стоимость очень низкая.Модификация на основе исходного кода требует не только знакомства с исходным бизнесом, изменения его в подходящую организационную модель, но также необходимо протестировать исходный бизнес после модификации (потому что нет гарантии, что первоначальный бизнес будет в порядке после модификации), это все затраты. А новому бизнесу нужно только скопировать требуемую логику и добавить логику.
В конце концов, это не приведет к централизации дефектов, что согласуется с принципом генетической изменчивости в биологии.Изменения в ДНК (которые можно рассматривать как логические) в процессе репликации могут быть вызваны масштабными вспышками вирусов (которые можно расценивать как ошибки).Уменьшить зону заражения.После одновременного копирования отказ копируемой части одной программы не повлияет на другие копии кода, использующие этот код, и программы, разделяющие эту часть кода в бизнесе, как только эта часть кода зависнет, весь бизнес, использующий эту часть кода, выйдет из строя. Лучший пример — центр конфигурации, обычное дело в крупных компаниях. потерпит неудачу Включение конфигурации в код не является хорошей идеей, потренируйтесь, но не сталкивайтесь с этой проблемой.

Однако обязательно выясните, когда применяется этот анти-шаблон разделения:

Бизнес, который реализует анти-шаблон, должен быть разделен на достаточно мелкие части Это предпосылка создания анти-шаблона, и следующие несколько будут опираться на это правило.
Этот антипаттерн подходит для частых вспышек экспериментальных новых сервисов.产品经理在实验他的新想法, В настоящее время вместо того, чтобы модифицировать первоначальный бизнес, а затем обнаружить, что ни одному пользователю не нравится эта новая функция, окончательное добавление логики в бизнес будет только бомбой замедленного действия (будь то ошибка или угроза безопасности). чтобы напрямую Написать новый бизнес, скопировать необходимые части и повторить их. Таким образом, вы можете выйти в автономный режим напрямую, когда он вам не нужен. Это не повлияет на исходный бизнес. Стоимость изменений намного ниже, чем разработка на исходный код.
После реализации этого режима ситуация ремодификации не подходит для рефакторинга, а больше подходит для рерайта.Пока бизнес достаточно мал, стоимость рерайта будет бесконечно мала.Вероятность рерайта внесения новых багов соответственно тоже уменьшится.
Этот режим подходит для частой смены обслуживающего персонала.Например, если в компании недостаточно персонала или персонал часто меняется, то изменение исходного кода требует понимания режима организации исходного кода, и можно добавить новый напрямую. .
Еще одна цель внедрения антишаблона — исключить вызовы между сервисами.Если антишаблон все еще вызывает исходный бизнес после завершения внедрения, это означает, что внедрение не завершено.

он начал

руки вверх

Хорошо, это все для абстрактных понятий. Давайте посмотрим, что было сказано выше:

Начнем с характеристик сервисов разного масштаба
Затем мы говорили о том, как разделить сервис, если мы хотим сделать его меньше, и при каких обстоятельствах он подходит для разделения?
Наконец, мы говорили о модели минимальной бизнес-единицы, которая разбита на очень маленькие единицы с очень низкой стоимостью модификации.

Хорошо, мы придумали шаблон с низкой стоимостью записи, незначительным воздействием на периферийные устройства и, конечно же, низкой производительностью благодаря анализу шаблонов размера службы и взаимозависимости между службами — шаблон наименьшей бизнес-единицы.

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

Итак, как решить проблему производительности?Что касается проблемы общей производительности, то здесь есть неотъемлемое преимущество WEB-бизнеса.Пока развернута реплика, общая производительность будет линейно улучшаться в зависимости от количества реплик.Для производительности один запрос, мы знаем, что есть два способа улучшить производительность,做减法, то есть естественная производительность улучшается за счет уменьшения логики.集中化, то есть, как и в промежуточной платформе, части, чувствительные к производительности, централизованы для повышения производительности.

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

Ахиллес держит черепаху

Рефакторинг никогда не делается в одночасье.Было бы самоубийственно остановить бизнес за один раз, написать новую систему, а затем переключить трафик за один раз.Порядочно, старайтесь не влиять на существующий трафик для переключения, вероятность успеха будет увеличиваться. Таким образом, процесс переключения прямо противоположен написанию крупномасштабного бизнеса с нуля. Рекомендуется сначала переключать пограничный бизнес верхнего уровня, затем постепенно двигаться внутрь и, наконец, переключать ядро.

Всем известна история про Ахиллеса и черепаху, и процесс рефакторинга бизнеса похож на это чувство.В процессе рефакторинга, как сделать так, чтобы старый бизнес-код не продолжал расширяться, является одним из ключей к успеху рефакторинга, иначе старый бизнес-код не будет продолжать расширяться, код раздут, и у новых бизнесов никогда не будет шанса выйти в онлайн.

Эта ситуация очень проста, просто измените исходный бизнес-код на доступный только для чтения.Я сделал правило с бизнес-командой, начиная с определенного момента времени, на старую платформу больше не будет добавляться код.Новый бизнес всегда будет начинаться с поцарапать Написать новый сервис.

Реконструкция бизнеса похожа на замену аквариума на рыбу.Для участия во всем процессе необходимы четыре вещи: аквариум (исходная система), рыба (пользовательский трафик), рыболовная сеть (мост), новый аквариум (новая система). Поскольку это не может продолжаться в исходной системе, продолжайте добавлять код, так как же разрешить новой системе доступ к функциям и данным, оставшимся в старой системе в процессе рефакторинга?

Выбрать мост между старой платформой и новой платформой очень сложно, необходимо пробросить трафик по правилам в конечной точке (шлюзовой части) всего трафика доступа, чтобы добиться минимальных изменений и охватить все сервисы . Исходная платформа ServerLess SDK является хорошим мостом. Всем клиентам нужен SDK для связи с сервером. Мы немного модифицировали его. Бизнес, разделенный новой платформой в соответствии с моделью наименьшей бизнес-единицы, не только читает свою собственную базу данных, а также считывать исходные данные, оставшиеся на платформе ServerLess, через преобразованный SDK.Точно так же бизнес на исходной ServerLess должен получить доступ к бизнесу на новой платформе, и преобразованный SDK также перенаправляет эту часть трафика на новую платформу. Таким образом, каждый раз, когда бизнес мигрирует, пока вы вносите изменения в SDK, вы можете направить трафик на новую платформу.После того, как все переходы завершены, вы можете найти время, чтобы удалить SDK и заменить его на собственный вызов URI.

На самом деле это одно из ограничений в дизайне платформы ServerLess. Доменное имя для платформы ServerLess в прошлом было CNAME, а URI вообще нельзя контролировать. На платформе, созданной вами, есть веб-шлюз, и миграция должна быть изменена только на веб-шлюзе.Однако бизнес совершенно не знает.Платформа ServerLess не может управлять веб-шлюзом, поэтому она может делать только такой взлом.Я должен сказать, что SDK с открытым исходным кодом и дает нам возможность мигрировать.Если это закрытый исходный код, мы можем только рискнутьОчень высокая однократная миграция или адаптировать слой вашего собственного веб-шлюза поверх для достижения того же эффекта.

Очевидно, что доступ SDK к двум платформам станет узким местом в производительности, поэтому я напрямую реализовал api-proxy централизованного прокси-шлюза трафика на новой платформе, реализовал переадресацию трафика с помощью openresty и внедрил реализацию с lua-resty-lrucache. Этот прокси-шлюз может достигать производительности, близкой к 80KQPS (среднее время запроса 20 мс, в случае попадания в кэш) при конфигурации машины 8core16G, о которой мы говорили выше Да, используйте традиционный централизованный режим в основной части, где производительности недостаточно для повышения производительности.

Ghost Dubbing

Переключение базы данных более сложное.Для статей и комментариев мы можем напрямую копировать трафик переключения базы данных, когда пользователи находятся онлайн меньше времени.Но мы столкнулись с проблемами при копировании пользовательских данных. Пароли пользователей зашифрованы, и мы не знаем как (внутренняя функция платформы ServerLess, конкретная реализация неизвестна).

Как переключить эту часть данных Мы сделали этот дизайн.

Для незарегистрированных пользователей это очень просто, просто вызовите новый интерфейс пользовательского центра после миграции, чтобы зарегистрироваться.

Для зарегистрированных пользователей: когда пользователь входит в систему, вызовите API-прокси для имитации входа пользователя. После того, как пользователь успешно войдет в систему на старой платформе, он докажет, что имя пользователя и пароль действительны, и напрямую введет пароль, введенный пользователем. в логику обновления пароля пользователя новой платформы, завершите Обновление пароля локальной базы данных. Как только будет обнаружено, что у локального пользователя есть пароль, он не будет вызывать API-прокси, а напрямую войдет в новый пользовательский центр, чтобы завершить процесс входа пользователя. Таким образом, мы завершаем процесс повторного шифрования пароля пользователя и сохранения результата в новой базе данных, не зная исходного метода шифрования.

Для неактивных пользователей постоянный вызов api-proxy для проверки входа пользователя не завершит миграцию, ведь мы, наконец, будем оффлайн api-proxy. Итак, мы устанавливаем переходный период в 2 недели, через 2 недели мы напрямую отключаем API-прокси. Неактивные пользователи будут непосредственно входить в процесс сброса пароля и завершать обновление пароля, отправляя ссылку для сброса на зарегистрированный адрес электронной почты пользователя.

Шаблоны развертывания и локальная оптимизация

Наконец-то мы разобрались с некоторыми неудобными для серого переключения частями, и подготовили конкретное время для общего переключения.Онлайн-процесс очень простой, мы заранее оформили анонс, а затем убрали SDK и апи-прокси на Платформа ServerLess.Логика форвардинга напрямую переключается на новую среду.Поскольку тест проведен полностью,ошибок адаптации в принципе нет.Но есть проблемы с производительностью.

После переключения общая задержка значительно увеличилась, а главную станцию даже в часы пик не открыть.Это проблема производительности, вызванная мелким разделением.Однако решение уже готово.Развертывание нашего сервиса.Режим развернута как единая машина целиком, то есть каждая машина на линии имеет все сервисы всей станции.Поэтому для повышения производительности сразу открываем новую машину в публичном облаке, разворачиваем на ней все сервисы, и наконец добавить новые в машине обратного прокси WEB будет делать.

Прежде чем не будет контейнерной платформы, если вы хотите быстро и легко расширяться, рекомендуется развертывать одну машину целиком.Архитектура достаточно проста.Каждая машина является идемпотентной.Не будет проблем находится в автономном режиме и некоторые сервисы недоступны.Но недостатки также существенны.Потому что производительность одной машины ограничена.Поэтому при наличии многих предприятий производительности одной машины будет недостаточно.Хотя увеличение количества машин может Чтобы облегчить, если есть бизнес с интенсивным использованием ЦП, то этот вид режима развертывания должен делить основную частоту с другими предприятиями, что приводит к увеличению задержки.Согласно нашей практике, у Nuggets есть более 100 репозиториев микросервисов. скажем, эти репозитории расположены на каждом микросервере компьютера.Наш лимит тестовых данных около 8 репо на ядро.То есть 16-ядерная машина, вероятно, выдержит 128 репо при нашей дробной гранулярности.

Чтобы уменьшить задержку интерфейса, мы также сделали некоторые оптимизации на API-прокси, поскольку сервис является наименьшей моделью бизнес-единицы, поэтому, когда есть больше данных, связанных с бизнесом, обычно требуется больше базовых интерфейсов хранилища, которые необходимо называется. Это будет серьезно влияет на производительность. Особенно, когда данные зависят от контекста. Примером может служить уведомление пользователя. Например, если пользователь получает уведомление о том, что кому-то нравится его статья, то информация об уведомлении должна отображать краткое содержание статьи ( читать статью system) и отображать лайки Users (читать информацию о пользователе), отображать количество лайков (like system), для этого требуется вызов трех интерфейсов. Для этой цели API-proxy разработал глобальный кеш. эти данные вместе с построителем заранее, данные требуются Система напрямую считывает кэш, и отфильтровывает ненужные поля, и сохраняет только те поля, которые необходимы Это типичная идея обмена пространством На время.

конец

Рефакторинг и переключение Nuggets длились почти 6 месяцев, с 2016-12 по 2017-05.В начале рефакторинга были я и 2 инженера фронтенда, 2 инженера бэкенда, 2 инженера iOS, 2 инженера Android инженер.Из них месяцы с 2016-12 по 2017-02 проводились параллельно, то есть одновременно проводились разработка нового бизнеса и рефакторинг.В марте 2017 потеря инженеров была очень серьезной, а на фронтенде и бэкенде были только я и еще один.Фронтенд-инженеры и iOS-инженеры все ушли, а андроид-инженеры остались.Так что большая часть этого месяца идет на набор новых инженеров, а набрано 3 бэк-энд-инженера в конце марта.На самом деле, каждый год после вручения наград в конце года Это самый серьезный момент текучести инженеров, но мы слишком много потеряли из-за некоторых других проблем.Кстати, мы многого достигли в подготовке инженеров.Все эти инженеры после увольнения пошли на заводы первого эшелона.Должен сказать,что маленькие компании Слишком тяжело во всех отношениях.Вот почему мне пришлось отпустить свою гордость и сохранить архитектуру как можно более простой .

С 2017-04 по 2017-05 разработка нового бизнеса была остановлена, и все время шел рефакторинг и миграция.На финальном этапе миграции можно сказать, что нагрузка на все команды очень высока.Команда продукта находится в «нет новых» функциях, не может привлечь пользователей для добавления забавных и неловких ситуаций», а команда разработчиков находится в самом конце кривой Парето, и чем ближе она подходит к завершению, тем больше кусочков вы найдете ждет восстановления и совершенствования.Этот момент - момент, чтобы сыграть роль лидера.В конце концов, я прямо отсек некоторые старые дела, сначала выполнил переход, а затем нашел время, чтобы завершить эту часть оставшихся проблем На самом деле, когда я уходил из Наггетс, эта часть бизнеса не была разрушена, требует повторной реализации.

Я слышал бесчисленное количество историй типа «Если бы я знал, что это так сложно, я бы никогда этого не сделал». Я надеюсь, что переход можно будет завершить как можно быстрее.Но после того, как переход завершен, оценка результатов работы стала сложной проблемой.Поскольку я не столкнусь с узкими местами в производительности за короткий промежуток времени, у меня нет времени писать такая длинная статья, чтобы объяснить из принципа, почему важно структурировать, как реконструировать, процесс реконструкции и преимущества реконструкции.Возможно, только в тот момент, когда старая структура рушится, ее можно мгновенно восстановить с помощью магии. Но волшебства не существует, и стартапы тоже не имеют времени выражать свои эмоции.

Сильная архитектура не так хороша, как деньги, а деньги - это еще не все.Поэтому сильная архитектура - это еще не все (вручную смешно). Нет разницы между хорошей и плохой архитектурой, только подходит ли она для команды и бизнеса Тщательно проведите рефакторинг и сначала оцените.

Увидимся в следующий раз.