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

внешний интерфейс

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

Сегодня я хотел бы поделиться с вами некоторыми вещами об архитектуре и Чжунтае.

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

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

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

Происхождение Чжунтай

Во-первых, давайте посмотрим на происхождение Чжунтай.

Основной источник Китая и Тайваня - Али.Они посетили игровую компанию в Финляндии в 2015 году, то есть SuperCell.

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

Такие как Clash of Clans, Boom Beach и т.д.

Я тоже играл в их игру, но не думаю, что это интересно.

Размер этой компании составляет менее 200 человек, а модель развития компании обычно разрабатывается небольшой командой из 2-7 человек, которая внутри компании называется ячейкой, откуда и происходит название их компании.

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

После того, как продукт выйдет из строя, их не только не накажут, но и устроят вечеринку, чтобы отпраздновать и отпраздновать, что они узнали что-то новое.

Но я думаю, что это очень странно: если все они будут следовать своей модели, первые компании Tencent и Ali должны быть мертвы.

Все мы знаем, что в первые дни существования Tencent никто не хотел продавать его за 1 млн. У мистера Ма не было другого выбора, кроме как стиснуть зубы и продолжать это делать.

Однако это такая маленькая компания с чистой прибылью в 1,5 миллиарда долларов США в 2015 году, которая была приобретена Tencent за 8,6 миллиарда долларов США в 2016 году.

Дело не в этом, мы сегодня поговорим об их модели разработки, почему новая игра может быть разработана быстро?

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

Основное внимание уделяется их «средней стадии», которую они накопили за эти годы.

Они сделали много осадков на общих игровых материалах, алгоритмах и т. д. за последние много лет.

Это средняя стадия, в которой активно участвовал Джек Ма после того, как вернулся к Али.

болтать об архитектуре

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

Эпоха монолитной архитектуры

Когда я только начинал работать, лет в 11 или 12, в основном все проекты, с которыми я соприкасался, были такими.

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

Общая монолитная архитектураодин процессДа, это также относится к нашим текущим микросервисам. Просто загрузите пакет jar или war-пакет и все готово. Все модули находятся в одном процессе. Если вы хотите обновить или перезапустить, необходимо перезапустить всю службу приложения.

Конечно, все еще существуют простые уровни модуля разделения проекта, такие как шаблон MVC, который мы использовали в то время.

Просто очень просто, но те же недостатки также очевидны.

Первый момент заключается в том, что стоимость совместной работы в команде высока. Если в небольшой компании мало людей, это нормально. Когда бизнес развивается быстро, объем кода впечатляет. Когда я только начинал работать, на моем компьютере часто работал только один проект, но, кажется, другого проекта нет.

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

Второй момент, проект слишком сложный, все в сборе, все в нем.

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

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

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

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

В это время нет другого выбора, кроме как расстаться.

Отсюда возраст нашего второго архитектурного шаблона, SOA.

SOA(Service-Oriented Architecture)

Когда я работал над Ele.me, в нем было много названий SOA, и так было всегда.

Что означает SOA, полное название этоService-Oriented Architecture, что означает сервис-ориентированную архитектуру, которая в основном такая же, как наши текущие микросервисы.

Ядром SOA является:Слабая связь и повторное использование услуг,Когда в монолитной архитектуре возникает узкое место, первое, что приходит на ум, это демонтаж.В эпоху SOA уже есть такие понятия, как обнаружение регистрации сервисов и управление сервисом.Можно сказать, что когнитивного отличия от микросервисов нет .

На самом деле SOA имеет два режима: один централизованный, а другой децентрализованный.На следующем рисунке показан метод централизованного вызова службы.

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

Это ясно показывает проблему.

Во-первых, это запрос.То же количество запросов вдвое больше, чем при обычной децентрализации.Первоначально А звонил Б, но теперь он должен пройти через ESB.

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

Тем не менее, эта модель была очень популярна в начале, главная причина?

этоАрхитектура дымоходавозникающие проблемы.

Что такое конструкция дымохода?

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

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

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

Явление дымоходов очень распространено.Каждый играет по-своему.Начнем сначала дело,но дефектов много.

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

Во-вторых, стоимость взаимодействия и сотрудничества между системами резко возросла.По мере развития бизнеса можно проводить определенные маркетинговые мероприятия, создавать портреты пользователей и анализировать данные.Это нормально.

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

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

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

Нет ли общих абстрактных возможностей, которые могут быть разделены между этими системами?

Это также направление развития Zhongtai, абстракция, осаждение и обмен.

Микросервисная архитектура

Наконец, пришло время поговорить о нашей эре микросервисов, с которой все знакомы и о которой не нужно много говорить.

Что касается low-code бессерверных и облачных нативных, то я не буду здесь распространяться об этом, и я расскажу об этом позже, когда у меня будет возможность.

Вернемся к теме микросервисов, в чем разница между микросервисами и SOA.

Лично я думаю, что это на самом деле очень близко.Микросервисы являются более бесплатными и мелкозернистыми SOA.

У микросервисов не так много рамочных ограничений, мы можем использовать все, что захотим, хотя это может быть реализовано в SOA, например, мы можем использовать Dubbo для связи, Feign, Thrift, GRPC, что угодно.

Например, используя Spring Cloud, eureka может помочь нам с регистрацией и обнаружением службы, а вы можете подключиться к Eureka в качестве клиента, вызвав @enableEurekaClient.

zuul используется непосредственно для маршрутизации, hystrix — для ограничения тока и фьюзинга, лента — для балансировки нагрузки, а feign — для удаленных вызовов.

Это очень удобно.Конечно, вы также можете использовать Spring Cloud Alibaba.Я думаю, что это может стать тенденцией в будущем, и обновление и обслуживание очень усердны.

Набор Dubbo Nacos Sentinel явно больше соответствует привычкам домашнего использования.

совместное использование услуг

После разговора о развитии архитектуры мы можем вернуться к нашей предыдущей теме Китая и Тайваня.

На самом деле роль Китая и Тайваня самоочевидна, то есть разделяющая.

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

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

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

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

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

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

Сервисы самого низкого уровня — это возможности нашей инфраструктуры и промежуточного программного обеспечения, такие как базы данных, службы сообщений Kafka, Rabbitmq, хранилища данных и файловые системы.

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

разделение обслуживания

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

В целом, наше основное разделение теперь основано на бизнес-перспективах.

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

Высокая сплоченность говорит, например, о мидл-офисе транзакций, который разделен только на связанные с транзакциями и сильно зависимые.

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

Например, вначале в бизнесе мало людей, и информация об адресе пользователя размещается в сервисе пользователя, что вроде бы не проблема.

С развитием бизнеса эта адресная информация все больше и больше связана со службой логистики, можно ли ее разобрать на службу логистики?

Поэтому это следует рассматривать с точки зрения развития, а не под одну гребенку всех.

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

целостность данных

На самом деле, это похоже.Данные, связанные с бизнесом, должны быть полными.Например, если вы делаете разделение, а имя пользователя после разделения разделяется на другую систему, это неразумно.

Итерировать непрерывно

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

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

центр транзакций

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

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

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

Процесс транзакции в настоящее время обычно делится надоговорипредставлениеВо-вторых, это в основном правило всех торговых платформ.

Когда такой-то что-то делает, это контракт.

Например, покупатель предлагает продавцуценные вещи, такие как деньги, продавец должен предоставить покупателюСлужить.

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

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

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

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

Цепочка поставок должна купить, затем продавец доставит товар, и, наконец, вы подписываете его.Это также процесс заключения и выполнения контракта.

То же самое касается заказа еды на вынос.

Все эти сценарии можно свести к общему процессу, который представляет собой упомянутый выше общий процесс транзакции.

Абстрактное понятие закончено, и его нужно описать более ярко.

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

Это изображение является страницей подтверждения заказа Meituan, также известной как страница коносамента. Картинка слишком длинная, для описания я разбил ее на 3 маленькие картинки.

Можем ли мы проанализировать, из каких сервисов должна состоять эта страница, и кто должен агрегировать интерфейсы такого количества сервисов?

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

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

Подробная информация о товарах в средней части должна быть предоставлена ​​товарами и услугами.

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

Нижняя часть называется связыванием. Вы можете приобрести участников одновременно с размещением заказа. Фактически это эквивалентно размещению двух заказов, один из которых является заказом на вынос, а другой — связанным заказом, заказом на покупку. участник, а последние два Заказ объединяется и оплачивается, а окончательная согласованность сохраняется Заказ успешно размещен, и участник успешно совершает покупки.

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

В этом месте есть еще два интересных момента.

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

Как правило, все предприятия вычитают запасы после размещения заказа, но возникает проблема.

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

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

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

С этим купоном тоже есть проблема.Не знаю,нашли ли вы его.Если купите купон на членство,то можете сразу им воспользоваться.Он тоже помечен ниже.Этот заказ доступен.

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

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

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

В сочетании с панорамой это будет четче, а схема архитектуры будет четче.

<,>

Финансовый средний

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

Платеж — это ядро ​​всего финансового центра, а единая касса, к которой он переходит, — это ядро ​​платежа.

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

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

Финансовый центр это поймет сам.

децентрализация

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

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

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

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

Хорошо, на этом пока все, всем 88, я Ай Сяосянь, увидимся в следующем выпуске, в последнее время я буду периодически обновлять ритм еженедельных обновлений, это немного трудно читать, всем, пожалуйста, помогите поставить лайк и вперед некоторые, благодарный.

Справочником по содержанию статьи является Phoenix Architecture, написанная г-ном Цзоу.Студенты, не купившие физическую книгу, могут прочитать электронную версию:ледяной делится на IX. Способность/введение IO…

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