история начинается
Прошло почти два года с тех пор, как я впервые столкнулся с RPC. В то время я думал, что это просто потрясающе. Написание демо уже было потрясающим. Я ничего не знал о внутренней структуре или принципе, и я не У меня нет желания исследовать Я просто чувствую, что могу бегать.
Постепенно я вступал в контакт со все большим и большим количеством и знаю такие термины, как регистрация службы, обнаружение службы, центр регистрации и процесс выполнения чего-либо.
Позже я чувствую, что очень хорошо использовал распределенную структуру компании.Apache Tuscanyреконструированный. Это была просто иллюзия в то время, потому что я не сталкивался со многими проблемами, это была не более чем небольшая проблема с конфигурацией, что сервис не мог быть найден. Просто резюме пропало.
Резюме классное и быстрое, но это ощущение непрофессионала беспокоит меня каждую минуту.
Я начал покупать похожие книги, чтобы читать, «Я действительно больше не могу читать», основы, которые я не могу вспомнить.
Если этот путь не сработает, я воспользуюсь самым примитивным и самым эффективным, а для демок буду использовать все услышанные и названные RPC-фреймворки.
duang, duang, duang.... От dubbo, springcloud до Thrift, grpc. Это чувство чужака до сих пор не ушло.
сюжетный поворот
На данный момент я, кажется, применил все приемы, которые я могу использовать, но это не работает.
Но я также знаю последний, последний, последний трюкпосмотреть исходный код, этот трюк является проверкой основных навыков, в том числеУмение читать на английском языке, владение родной библиотекой, эти факторы будут влиять на скорость понимания прочитанного фреймворками с открытым исходным кодом.
Когда я вошел в яму, я подумал, что основные пути этих фреймворков должны быть похожи, поэтому я просто нашел чужой блог, чтобы сначала проанализировать исходный код.
душа, я нашел серию статей по интерпретации исходного кода grpc. Но я застрял на первой статье из этой серии из 6 статей.Основное введение, я делал заметки, рисовал, делал заметки, рисовал... Я не дочитал первую статью, но не думаю, что сложно сделать простую RPC-инфраструктуру. Многократно делая заметки и рисуя картинки, я узнал, что мне нужно и как добиться того, что мне нужно.
Выкопайте яму, скопируйте колеса.
Поговорим о том, что есть в фреймворке RPC.
1. Вероятно, наиболее часто встречающийся фреймворк RPC в объявлениях о вакансиях.dubbo
С картинки
- 1.Провайдер (сервер)
- 2.Registry (регистрационный центр)
- 3.Потребитель (клиент)
- 4.Монитор
2. Еще один более лаконичный с картинкиgrpc
- 1. Сервер gRPC (сервер)
- 2. Заглушка gRPC (клиент)
Самым большим преимуществом этих карт является то, что они очень мощные и обобщают основные компоненты.
Но знать что-то далеко не достаточно, сколько бы у вас ни было теоретических знаний, и сколько бы вы ни читали, писать в первый раз будет сложно.
Другой заключается в том, что, например, учась готовить, вы можете увидеть весь процесс от нарезки овощей и обжига до приготовления пищи, а затем проследить процесс, чтобы попрактиковаться самостоятельно. Есть также бизнес-проекты, которые мы делаем ежедневно, как построить фреймворк и как написать бизнес, мы можем видеть практику наших предшественников. Это легко сделать самому.
Я использовал программное обеспечение для статистики кода, чтобы прочитать около 10 строк dubbo и более 330 000 строк версии grpc java. /черный вопросительный знак/🐶/👐🏻
Я должен найти структурумне легче понять, инфраструктура RPC с относительно небольшим объемом кода, особенно понимать общую структуру инфраструктуры RPC и то, как она реализована. К счастью, я нашел Baidu без особых усилий.brpc, объем кода не большой, а структура мне очень понятна.
Все готово, это совсем не сложно (мне тогда было мало 🐶)
конец истории
Поскольку мощный клиентский сервер Netty передает и принимает данные очень удобно, я также использую эти красивые высокопроизводительные кадры для создания мусорного колеса.
процесс вызова frpc
Код ядра составляет менее 700 строк, используется сторонний фреймворк.
- nettyКлиент сервера отправляет и получает сообщения
- lombokУменьшите количество кода
- curatorклиент зоопарка
- fastjsonСериализация
- cglibДинамический прокси
- slf4jжурнал
- commons-pool2Пул соединений клиентского канала
github frost
Техническое резюме
Реализованные функции: простой (чоулоу) клиент, сервер, клиентский пул соединений (изначально идет с netty, и заменяется, если не используется), регистрация службы, обнаружение службы.
Сложность: Когда я только начал это делать, я не учел, что будет задержка отправки и получения запросов, и будет задержка появления нулевого указателя, что приведет к прямому нулевому указателю в тесте, но я сразу подумал о причине.Во-первых, проверка, каждый раз, когда я получал ответ от клиента, Оба Спят на 1 секунду. Проверка завершена, нулевой указатель исчез. Затем начните долгий поиск и научитесь решать проблему асинхронно, изучив AbstractQueuedSynchronizer, ReentrantLock и CountDownLatch.
строить планы:
- 1. Самый простой способ — сначала сжать данные.
- 2. Трансформировать сервис регистрации в сервис Discovery, (сейчас я могу зарегистрировать только один сервис, discovery должен получить этот 🐶) Цель имитировать dubbo или brpc.
- 3. Преобразуйте пул соединений. (пока нет направления)
Все же надеюсь, что в случае с полными функциями, чем меньше количество кода, тем лучше, и чем четче структура проекта, тем лучше.