В этой статье мы в основном хотим поделиться с вами тем, как за последние три года Song Xiaocai превратилась из одноточечной системы валунов в сервисно-ориентированный дизайн, ориентированный на предметную область. Эта эволюция продолжается до сих пор, мы столкнулись со многими ямами в процессе практики, а также приобрели опыт и мышление.
Я был первым программистом, который присоединился к Songxiaocai на подготовительном этапе и был свидетелем всего процесса системы Songxiaocai от 0 до 1. В то время, техническая группа состояла только из одного менеджера продукта, один программист (это был я), и пять аутсорсинга одноклассников. Я до сих пор очень хорошо помню первый день работы в песенном Xiaocai, который был 18 января, 2015. я очень хорошо помню нашу первую задачу, чтобы произвести торговую платформу до марта. Что необходимо для торговли, пользователи, счета, товарно-сырьевые, фонды, заказов ... Эти модули представляют собой раннюю торговую систему Songxiaocai в. В то время, слишком много вещей, которые были принесены в жертву скорости, такие как отсутствие общего архитектурного дизайна, отсутствие достаточного понимания бизнеса, отсутствие функциональной абстракции, а также отсутствие анализа производительности. Такое поведение теперь, кажется невероятным и неприемлемым. Я часто думаю о вопросе, если мы используем наш текущий опыт и понимание, чтобы поехать назад в три года назад, чтобы разработать самую раннюю систему Songxiaocai, что вид сцены бы это было? Смогу ли я планировать несколько крупных центров, такие как пользовательский центр и товарный центр с самого начала? Будет ли дизайн апатридов системы и горизонтальную масштабируемость с самого начала? Будет ли развивать платформу шлюза с самого начала конденсироваться и стандартизировать все вызовы API? Ответ не должно быть, и результат часто не обязательно лучше, чем это было в первую очередь. Ранние системы не нужны ядерного оружия, как архитектура и ППО. То, что они на самом деле нужно это способность обеспечить борьбу с бизнесом компании как можно быстрее.
В то время существовало две основные системы, а именно внутренняя ERP-система и система обслуживания API для клиентских обращений, эти две системы завершали замкнутый цикл наших транзакций. В течение следующих двух лет бешеное нагромождение бизнес-кода и неконтролируемое дублирование кода сделали систему все более громоздкой. Структура системы в то время была очень простой, а общедоступные модули извлекались в виде jar-пакетов.Зависимости ERP-системы можно увидеть на следующем рисунке:
这时候的系统改造就变得非常痛苦，每次发布都会变得异常紧张，生怕有哪个模块的jar包改动了没有更新，就导致系统无法顺利启动。曾经有那么一段时间，我会很惧怕系统的发布，如果顺利发布，我也会长舒一口气。
在系统的各个地方散落了一些异常刺眼的注释，比如“这段代码太牛逼了，我不敢改，所以就复制了一份”、“这部分的逻辑是xxx写的，不要轻易改动”等等。以下六点是我们系统存在的主要问题：
- Управление пакетами jar хаотично, что часто приводит к сбою сборки системы;
- Неуклюжая, жесткая связь, запутанные точки воздействия релиза и изменения в базовом банке, из-за которых необходимо выпускать каждую прикладную систему;
- Сложность сотрудничества во время разработки;
- Новичкам трудно учиться и понимать;
- Управлять непросто, много нечистого кода;
- Все больше и больше технического долга; Когда компания еще невелика, сложность бизнеса и системная сложность все еще находятся на относительно приемлемой стадии, и система валунов часто является более эффективным архитектурным решением. Однако с непрерывным расширением бизнеса сложность и количество посещений будут увеличиваться, и если какая-то критическая точка будет нарушена, обновление архитектуры системы и разделение услуг станут чем-то, что необходимо сделать.
Когда было принято решение о разделении услуг, численность технической группы была не особенно велика, и ни у кого из студентов не было большого опыта в разделении услуг. Оглядываясь назад, это было небрежное начало. Мы не стали слишком много планировать и сразу перешли к части «сделай это». Можно себе представить, насколько грязным будет сервис. Будет "центр цен" и "центр авторитета" какое-то время. Что полегче, тот и снесет первым, а какой новый бизнес запустит, тот и сервис запустит первым. Впоследствии были выявлены такие проблемы, как нехватка серверных ресурсов, сложность в эксплуатации и обслуживании, а также путаница между службами. Когда все осознали эту проблему, это не было неизлечимой болезнью. Мы сразу же выполнили дизайн и разделили общую сервировочную тарелку Song Xiaocai и разделили сервировку на верхний и нижний уровни. Верхний уровень — это бизнес-уровень, а нижний уровень — это уровень возможностей.Попытайтесь сделать вызовы между службами в виде дерева, а не кольца.
Разделить сервисы очень просто, и ключ заключается в контроле детализации. В то время существовало почти параноидальное понимание микросервисов, думая, что пока функциональный модуль независим, он должен стать сервис-независимым, а для обеспечения доступности необходимо установить два узла. По этой теории мы провели практику, и действительно было много экстремальных операций. Постепенно мы поняли, что с этой идеей есть некоторые проблемы, и для решения этой проблемы мы должны достичь консенсуса по концепции разделения услуг. Мы пытаемся использовать DDD (Domain Driven Design) для планирования услуг.Основываясь на методе проектирования DDD, начиная с текущего бизнеса, абстрактный бизнес находит основные возможности бизнеса Songxiaocai и разделяет его как услугу. Но DDD — это методология, а не догма или золотое правило, не заходите слишком далеко в процессе ее использования. После использования DDD для анализа мы обнаружили более неприятную проблему, то есть предыдущие сервисы были дизассемблированы слишком мелко, а многие сервисы, которые не должны дизассемблироваться, были дизассемблированы на два и более. Итак, после этого мы начали внутренний «Проект Ковчег».Основные цели проекта заключаются в следующем:
- Создайте в команде общее понимание того, как разделить услуги и продвигать использование DDD;
- Определите микросервисную конструкцию и технические характеристики;
- Объединить ранее мелкозернистые услуги; Благодаря этой поездке мы также понимаем, что расщепление услуг является очень осторожным.
2.3.1 Опыт
Первым вопросом, который следует учитывать, может быть наличие у команды разработчиков достаточного опыта для освоения технологического стека микросервисов. Это не требование, что команда должна иметь полный опыт, чтобы инициировать разделение услуг, безусловно, лучше, если в команде есть эксперт в этой области. В противном случае может потребоваться достаточная техническая демонстрация и репетиция заранее, по крайней мере, чтобы не вести неподготовленный бой. Как было сказано выше, наш стартап был немного неряшливым, и в команде не было особо профессиональных студентов, поэтому мы наступили на ямы в некоторых распространенных распределенных проблемах, таких как повтор вызова, механизм тайм-аута, распределенные транзакции и т. д. Как только появляются эти проблемы, многие неопытные студенты будут очень злыми и даже не смогут начать.
2.3.2 Стабильный тест
Неизбежная проблема разделения услуг заключается в усложнении самооценки развития учащихся. В предыдущей системе, независимо от того, была ли она запущена локально или выпущена в тестовой среде, все вызовы были детерминированными. Но как только часть услуги разделена, она может столкнуться со многими проблемами:
- Локальные вызовы к удаленным сервисам могут быть запрещены, поэтому для их решения нужно использовать mock'ы.При тестировании локальных блоков основной проверкой является бизнес-логика и процессы, а удаленные вызовы не могут быть идеально измерены, возвращающие данные.
- Вызывающая тестовая среда может быть нестабильной, и когда вы захотите позвонить, служба может давно зависнуть.
- Когда несколько проектных групп разрабатывают новые функции, они вызывают одну и ту же службу.В это время может возникнуть конкуренция за ресурсы из-за ограниченных ресурсов сервера. В разных компаниях разные ситуации, и тестовые среды, созданные для разработчиков, тоже разные. Но одно можно сказать наверняка: если тест будет сложным, это вызовет большое давление на учащихся, занимающихся развитием. Очевидно, что это очень простая функция, ее изменение может занять всего 5 минут, но ему потребовался 1 час, чтобы завершить полный тест. Если ее не удастся решить после разделения сервиса, это приведет к все большему количеству случайностей и лени среди разработчиков, и код будет представлен или выпущен без тестирования.
2.3.3 Журналы
Разделение сервисов неизбежно приведет к разрозненным логам, будь то локализация проблемы и просмотр лога, или какие-то события нужно реализовать на основе лога, станет намного сложнее, чем раньше. Вначале мы не осознавали эту проблему, поэтому многие разработчики не знали, как найти их после того, как у них были ошибки или сбои. Потому что вызов метода может быть усилен в несколько раз или даже в десяток раз из-за сервис-ориентированного вызова, где возникает конечная ошибка и как ее найти — это проблема.
3. Заключение
О том, как построить эффективную свежую B2B-платформу, потому что она содержит много контента и очень сложна, невозможно объяснить это в рамках одной статьи. Эта статья просто для того, чтобы почерпнуть некоторые идеи. Последующая будет разделена на несколько статей. описывается текущая ситуация в отрасли, бизнес-статус, обзор продуктов, построение технической команды, создание серверной технологической платформы, разработка интерфейса и другие аспекты.Мы раскроем основные продукты и технологические платформы, которые накопились в B2B поле уже более трех лет и надеюсь, что больше людей в отрасли смогут углубиться в понимание, избежать некоторых обходных путей, я надеюсь помочь всем, эта серия статей распространяется следующим образом (будет обновляться):
1,«Как создать эффективную свежую платформу B2B (часть 1 обмена технологиями B2B)»
2,«Как Song Xiaocai вышла на свежий рынок B2B (часть 2 обмена технологиями B2B)»
3.«Как итерировать продуктовую систему платформы Fresh B2B (часть 3 обмена технологиями B2B)»
4.Как создать эффективную техническую команду для Fresh B2B (часть 4 обмена технологиями B2B)
5.«Как построить свежую технологическую систему B2B от 0 до 1 (часть 5 обмена технологиями B2B)»
8,«Дизайн Сун Сяокай и размышления о« возможностях »(часть 8 обмена технологиями B2B)»
9,«Проектирование и обдумывание разделения услуг (часть 9 совместного использования технологий B2B)»