А с прошлого года в школу берут только по официальному месту проживания
О. я похоже многое пропустил. Это получается- хотят получить что то похожее как в америках. Чтобы цена дома зависела о качества школы к которой он приписан?
ЗЫ. Алексей- привет!
На самом деле- минусов у vert.x тоже хватает.
Я с этим vert.x — собаку съел. Но нужно понимать- что все описанные проблемы- это то что всплывает при реально очень больших нагрузках- порядка 1K rps.
Из того что сразу могу назвать:
1. Утечки памяти. Берем асинхронный клиент Redis идущий в поставке с vert.x. Шикарная вешь- отлично работает в асинхронном режиме с обычной кофигурацией Redis типа — vert.x клиент- редис. Но в случае- когда редис скофигурирован работать в Sentinel конфигурации, да и еще и под высокой нагрузкой — начинаются утечки памяти. Покопавшись в дебрях стектрейсов — понял что vertx redis client не сразу закрывает соединения- даже после того как код вышел за область исполнения redis related кода при возникновении таймаутов в запросах к редису. В свое время пришлось брать Jedis- так как он работает надежнее при любых нагрузках.
2. Rx обертки для vert.x тоже текут- или я совсем не умею их готовить
3. Писать код на колбеках — сложно. Еще сложнее потом это чинить и поддерживать/оптимизировать.
4. Hazelcast — что используется для distributed event bus- отлично ведет себя на тестовых примерах- но в на больших нагрузках- создаёт проблемы:
4.1. Надежность. Потерять сообщение? Легко.
4.2. Несвоевременно освобождение сокетов? Обязательно.
4.3. Конфигурация сокет пула- это отдельное приключение. Особенно — когда надо убедить Operations team- открыть порядка 1000 портов для общения между кластером vert.x- - та еще забава А это надо делать для каждой ноды в кластере.
5. Непонятки с рандомными ошибками «port in use» — я так и не понял куда копать. То ли проблема в Hazelcast, или OS закрывает сокеты недостаточно быстро, а приложение уже закрыло и думает- что сокет освобожден и можно переиспользовать. Вообщем- хз.
6. ЧАВО — нечаво. просто оставлю этот тут stackoverflow.com/questions/tagged/vert.x Создатель vert.x неподелил что то с stackoverflow и в итоге искать ответы на проблемы приходится в документации/исходниках и гугл группах но не на stackoverflow .
7 Идея distributed vertices в эпоху k8s & docker — слишком переусложнена. Горизонтально смаштабировать приложение намного легче средствами k8s, чем встраивать в само приложение.
8. Vert.x асихронные колбэки сложно/невозможно мониторить многими популярными системами мониторинга. Например я был к команде тех — кто потребовал от appdynamics реализовать поддержку Vert.x в их продукте года 3 назад, до этого- appdynamics java client ничего почти не видел в vert.x кластере.
9. C10k problem — всплывает если пишешь highload на vert.x без предварительной подготовки.
10. Vert.x поддерживат множество языков программирования. Например JavaScript. Но писать Vert.x приложение на EcmaScript 5 (на тот момент nashorn engine -поддерживал только 5 версию)- это очень малоприятное занятие- не говоря уже о том что документации и примеров- примерно «0» (не спрашивайте зачем мне это понадобилось- было такое требование)
Но хватит о проблемах. Vert.x действительно отличный фреймворк. Я большой фанат этой штуки и уже сделал множество решений на Vert.x.
Если надо сделать быстрое, малотребовательное, достаточно низкоуровневое (если это слово можно применить к java) — приложение— Vert.x это ваш выбор.
А чем конкретно занимаются сервисы оркестрации?
Это набор сервисов — которые знают свою зону ответственности и могут направлять данные на обработку сервисам о которых они знают. (serviceorientation.com/...soaglossary/orchestration) Допустим есть входное сообщение, self describing json- сервис оркестрации читает сообщение и если понял какую либо инструкцию- перенаправляет сообщение соответствующим сервисам на исполнение в паралель (топология- звезда), собирает результаты выполнения и отправляет обратно клиенту. В случае если сообщение не понято/частично не понято- сервисом оркестрации — перенаправляется следующему в цепочке сервису оркестрации( en.wikipedia.org/wiki/Pipeline_(software ) . Таким способом- я строю легко расширяемую систему- без необходимости править существующие микросервисы- при добавлении новой фичи. Получается сеть из сервисов оркестрации о зонами ответственности (сервисы исполнения).
Kubernetes это оно?
Кубернетес — это слой оркестрации инфраструктуры. Я же говорю о сервисах оркестрации приложения работающего поверх кубернетес.
разделение на сервисы бизнес логики и сервисы доступа к данным, в чем фишка?
Это фишка отлита кровью и и нервами моего опыта- когда закачик приходит говорит- ко мне вчера приходили сейлзы оракла и сказали что сделают хорошую скидку на оракл экзадата- при условии подписания контракта на 5 лет с оплатой upfront. и заказчик соглашается на это. И это при наличии MS SQL, MySQL, Kafka, Influxdb, Informix etc.
В итоге надо работать с целым зоопарком источников данных- и поэтому vendor specific CRUD operations реализованы в виде отдельных сервисов.- ну и обращаться к ним могут множество других сервисов при необходимости.
Если сервис реализует бизнес логику, разве у него не должно быть доступа
Доступ к данным остаётся- только обращаться к данным сервис будет путем вызова соответствующего CRUD микросервиса — так проще поддержку осуществлять. Ну и секьюирити никто не отменял- незачем сервису бизнеслогики ходить в consul vault за строкой подключения с базе данных.
Вся прелесть распределенных систем состоит в том- что при их разработке- изначально закладывается опредленных уровень прочности, т.к. Распределенная система будет фейлить- и это должно быть учтено дизайном. Trust no one.
Каждый сервис желательно включить поддержку Retry,Circuit Breakers, heartbeat etc
И сколько версий одновременно поддерживаете?
На данный момент- самай глубина истории — 4- так как есть внешние клиенты- ну с ооооочень медленным циклом разработки- новую версию выкатывают раз в 3 месяца и большой болью. Для них на проде держу 1 версия сервиса интеграции с их подделкой- тогда как как на остальных environment-ах уже поддерживаю их новую спецификацию т.к. я использую URI versioning — то мне не проблема деплоить один и тот же код на все environment-ы. Каждая версия работает независимо.
Есть процесс отказа от устаревших версий API
Как только сторонний вендор выдохнет- и откажется от старого api- так сразу и я заброшу- но в коде оно еще будет жить около полу года- т.к. вендоры бывают косячат и просят откатиться на пред пред предыдущую версию.
Тесты пишете на конкретный кусок функциональности(сервис) или есть тесты покрывающие всю систему целиком?
Пишу три вида тестов
1. Юнит тесты — каждого публичного метода в каждом классе.
2. Функциональные тесты — тестится связка одно или нескольких сервисов одновременно — тест фич другими словами
3. Бэк тесты — т.к. я пишу AI систему- то после добавления каждой новой фичи — необходимо проверить как это отразилось на рассчетах проведенных в прошлом (обратная совместимость на уровне данных)
Пока что вот эти три типа тестов- позволяют держать можную защиту от криворукости, и изменчевых пожеланий вендоров и заказчиков.
Допустим у меня есть сервис с товарами, есть сервис с клиентами и сервис с заказами.
Я не знаю всей подноготной, но думаю здесь тоже можно применить принцип декомпозиции.
Думаю моожно сделать примерно так:
1. Разбиваешь задачи на независимые сущности
2. Создаешь сервисы оркестрации взаимодействия между всеми сущностями
3. Создаешь сервисы доступа к данным
4. Создаешь сервисы безопасности
5. Создаешь сервисы взаимодествия с third party systems (if any)
5. Создаешь сервисы фасады для общения с клиентами (web, sockets, udp/ tcp, etc)
Цепочка взаимодействия может выглядеть примерно так
клиент ->(your prefered protocol) -> Load Balancer -> сервисы фасада ->(raw message)-> сервисы безопасности -> сервисы оркестрации -> (выбор что надо делать в паралель/последовательно) сервисы бизнес логики -> сервисы доступа к данным/сервисы взаимодествия с third party systems
Есть ли практика задублировать какие нибудь данные из клиентов в заказы, чтобы избавиться от лишнего сетевого взаимодействия при запросе с клиента?
Внутри кластера (виртуализации) — сетевой обмен это небольшая проблема- т.к. организовано все это внутри кластера (3 и больше хостов организуют кластер, которые обычно соединены между собой high speed fiber channel)
После того, как сообщения прошло проверку безопасности- оно дублируется всем сервисам в исходном виде — на выходе сервисы оркестрации собируют результаты со всех сервисов что уложились в SLA- и формируют ответ клиенту ( с заглушками если кто то опоздашка)
Надо разделять рабочие отношения и нерабочие.
На работе здороваюсь только если есть eye contact. Но в большинстве случаев это только экспаты.
Ну кухне все держатся обособленными группами.
Доходит до того- что если сменил проект и команду- то с предыдущей командой больше не общаешься- работа.
Как пишут во всяких книгах по развитию личности0 никогда не ешь в одиночестве. Обычно приглашаю кого- либо из коллег на ланч/кофе. Это лучший способ узнать внутренную кукню компании.
Ну и еще важны внерабочие ивенты.
Комментарии. Улучшить работу с комментами. Например популярная тема с 500+ коментов очень сильно нагружает систему. К примеру постраничный вывод сделать. rsdn- отлично решили эту проблему. Вообщем постраничный вывод + ajax подгрузка должны улучшить ситуацию
Да, есть стандартный подход.
1. Создается дизайн приложение (картинки, оформление и тд)
2. Создается каркас приложения — желательно резиновый.
3. Собирается сборка только для телефонов и отдельно сборка для HD экранов. Это делается для того чтобы уменьшить общий вес apk. Иногда делают больше форков под разные типы устройств.
4. В случае с играми часто делают форки под разные железки. Например на Tegra устройствах свой конвеер обработки граф. примитивов и доступны уникальные для tegra шейдеры. Сейчас еще и Intel выпускают свой граф. процессор для андроид устройств.
В этом и состоит основные трудности разработки под андроид. Для больших проектов, чтобы сделать качественное приложение приходится держать в || много форков.
Это мне напоминает детские болезни становления платформы как PC в
Ничего, это временно- скоро устаканится.
Андроид отличная платформа для разработки, уж поверьте.
К тому же Nasa рассматривает эту платформу как основу для своих мобильных устройств, как полностью открытую. Что в свою очередь приведет к росту рынка гос заказов на платформе андроид.
Меня сложно назвать Андроид разработчиком, пару лет назад писал игрушку под андроид. Что могу сказать:
1. На джаве писать очень легко ( у меня C#/С основные)
2. Отлаживаться лучше на девайсе — эмулятор ужасно медленно работает.
3. Проблема фрагментации замечена не была. Если пользоваться резиновой версткой для UI и писать качественный код- то все будет -Ок, почти везде. Я проверял свое приложение на 4 разных девайсах- везде все работало отлично, и на разных версиях андроида.
4. Разрабатывать под Андроид можно и нужно- еще не так много приложений сделано как под яблофон.
5. Делал для себя- pet project, поэтому пресовал меня только лишь я, сам.
6. Дизайн, кодинг, делал сам- тестировать помогали жена, друзья.
7. Фриланс под андроид на "дядю"- не знаю, из того что я видел мало прибыльно. Но это то что видел я на одесках.
8. Продавать по честному приложения с Украины низззя. Так что прийдется делать либо бесплатное с рекламой/внутренними покупками, либо искать обходные пути.
9. Пользователи у андроида- откровенно говоря- хрюнделя- очень часто сливают рейтинг приложению т.к. не разобрались в нем.
10. Ну и сама платформа мне очень нравится.
Вот ссылка на раннюю версию моей игрушки
Агрономы, Баролгины, Эферолганы и их брат меньший- Иммодиум
5. Коробачка для сбора и хранения жуков.
Да, всё перечисленное вполне реально, можно кстати для начала сделать заказ в Boston Dynamics, они то уже собаку съели на этих роботах.
На днях хотел создать топик-вопрос на форуме но оказалось не все так просто- т.к. оказыватся «нэможно» — подтверди аккаунт- отправь смс на короткий новомер. Вообщем еще раз- отлична новость
Вcе вокруг п***сы- один я Д’артаньян.
13. В качестве оправдания всего этого обычно приводят еще худшие по данным пунктам страны. Но равнятся то надо на лучших.
Ну что товарищЪ- достаточно?
Случайности не случайны.
& android 4.hz on galaxy tab 2
Цена со скидкой $99
---З.Ы.TrollFace
Мы в частные ходим уже пару лет как.
И да и нет.