Если не получается отличить гугловского копипастера от «какого-то там идеальный разработчик» за собеседование и сколько там месяцев работы, если разработчики резко достигают плато только при первых трудностях, то плато далеко не у них, а у автора. И это плато не соответствует требованиям должности в отличии от гугловиков которые справлялись со своими задачами.
Во всех архитектурах микросервисов и подобных решений не хватает дополнительных метрик связанными с жизненными циклами бизнес логики. Нужно понимать, что сформировавшийся логике легче может жить в вакууме, чем новым идеям, которые могут переписываться хоть каждую неделю.
В своей практике делаю два условных слоя: Сервисы и Бизнес логика. Также есть их этапы эволюции:
1. Монолит. Сервисы отвечают за свою предметную область и вначале предоставляют просто CRUD, Бизнес Логика же использует эти сервисы под свои потребности. Если бизнес логика повторяется в нескольких местах, то я оставляю дубликат кода, так как логика может поменять в одном из мест достаточно быстро.
2. Монолит. При формировании уже устойчивой бизнес логики можно анализировать дубликаты кода для определённой предметной области и выносит в соответствующий Сервис. Тем самым мы уменьшаем код в Бизнес Логики и начинаем наращивать сервисы устойчивой логикой уменьшая вариативность их использования.
3. Микросервисы. После формирования Сервисов с решением своей задачи в предметной области(а не CRUD), можно выносит такие Сервисы в отдельные узлы со своими техническими особенностями при необходимости. При этом у нас остаётся оркестрация в виде Бизнес Логики.
Описанный выше подход не использует триггеры и эвенты, Сервисы не общаются между собой никак, вся логика вызовов строится внутри Бизнес Логики, на то это и оркестрация. Если посередине Процесса-1 одного сервиса нужно вызвать Процесс-2 другого сервиса, то Процесс-1 просто разбивается на два отдельных Процесса и Бизнес логика вызывает их по порядку передавая данные между ними.
Также это очень хорошо ложится под паттерн Saga и вопрос с распределёнными транзакциями.
P.S.
В 2012 году наткнулся на блог Александра, даже задавал вопросы по архитектуре, состоял в .net рассылке. Спасибо большое, Вы внесли большой вклад в моё развитие. Рад, что спустя такое количество времени нахожу общие идеи и могу понимать все эти решения.
var async = require('asyncawait/async');
var await = require('asyncawait/await');
var Promise = require('bluebird');
var fs = Promise.promisifyAll(require('fs')); // adds Async() versions that return promises
var path = require('path');
var _ = require('lodash');
/** Returns the number of files in the given directory. */
var countFiles = async (function (dir) {
var files = await (fs.readdirAsync(dir));
var paths = _.map(files, function (file) { return path.join(dir, file); });
var stats = await (_.map(paths, function (path) { return fs.statAsync(path); })); // parallel!
return _.filter(stats, function (stat) { return stat.isFile(); }).length;
});
Есть и ещё одна функция, слои. Слой — это как commit в git.
Т.е. пишите вы свой Dockerfile
FROM nginx
COPY nginx.conf /etc/nginx/nginx.conf
И при каждом изменении nginx.conf будет создаваться новый коммит.
Хранить эту историю изменений можно публично hub.docker.com/, либо приватно github.com/docker/docker-registry.
Удобно, если новая версия перестала работать, можно откатить до работающей.
И скоро они сделают своё средство для оркестрации, и тогда можно будет без проблем работать с зоопарком контейнеров.
Бывают задачи, когда нужно рендрить шаблон и на клиенте и на сервере (привет SEO). github.com/firehist/angular-twig-pack — вот такие штуки позволяют делать это безболезнено.
Когда-нибудь это включат в документацию
�
В своей практике делаю два условных слоя: Сервисы и Бизнес логика. Также есть их этапы эволюции:
1. Монолит. Сервисы отвечают за свою предметную область и вначале предоставляют просто CRUD, Бизнес Логика же использует эти сервисы под свои потребности. Если бизнес логика повторяется в нескольких местах, то я оставляю дубликат кода, так как логика может поменять в одном из мест достаточно быстро.
2. Монолит. При формировании уже устойчивой бизнес логики можно анализировать дубликаты кода для определённой предметной области и выносит в соответствующий Сервис. Тем самым мы уменьшаем код в Бизнес Логики и начинаем наращивать сервисы устойчивой логикой уменьшая вариативность их использования.
3. Микросервисы. После формирования Сервисов с решением своей задачи в предметной области(а не CRUD), можно выносит такие Сервисы в отдельные узлы со своими техническими особенностями при необходимости. При этом у нас остаётся оркестрация в виде Бизнес Логики.
Описанный выше подход не использует триггеры и эвенты, Сервисы не общаются между собой никак, вся логика вызовов строится внутри Бизнес Логики, на то это и оркестрация. Если посередине Процесса-1 одного сервиса нужно вызвать Процесс-2 другого сервиса, то Процесс-1 просто разбивается на два отдельных Процесса и Бизнес логика вызывает их по порядку передавая данные между ними.
Также это очень хорошо ложится под паттерн Saga и вопрос с распределёнными транзакциями.
P.S.
В 2012 году наткнулся на блог Александра, даже задавал вопросы по архитектуре, состоял в .net рассылке. Спасибо большое, Вы внесли большой вклад в моё развитие. Рад, что спустя такое количество времени нахожу общие идеи и могу понимать все эти решения.
там p12 в pem
«Convert P12 file for Push Notification to PEM format»
А по делу, есть Roadmap? В сети не нашёл, может упустил что-то.
Даже не знаю, что дороже.
Хотя и с промисами хорошо идёт.
Даже в прощальном письме что-то рекламируют.
Какой подход, такой и результат.
Basic Example
var async = require('asyncawait/async');
var await = require('asyncawait/await');
var Promise = require('bluebird');
var fs = Promise.promisifyAll(require('fs')); // adds Async() versions that return promises
var path = require('path');
var _ = require('lodash');
/** Returns the number of files in the given directory. */
var countFiles = async (function (dir) {
var files = await (fs.readdirAsync(dir));
var paths = _.map(files, function (file) { return path.join(dir, file); });
var stats = await (_.map(paths, function (path) { return fs.statAsync(path); })); // parallel!
return _.filter(stats, function (stat) { return stat.isFile(); }).length;
});
Есть и ещё одна функция, слои. Слой — это как commit в git.
Т.е. пишите вы свой Dockerfile
FROM nginx
COPY nginx.conf /etc/nginx/nginx.conf
И при каждом изменении nginx.conf будет создаваться новый коммит.
Хранить эту историю изменений можно публично hub.docker.com/, либо приватно github.com/docker/docker-registry.
Удобно, если новая версия перестала работать, можно откатить до работающей.
И скоро они сделают своё средство для оркестрации, и тогда можно будет без проблем работать с зоопарком контейнеров.
Вроде, всё
blog.docker.com/2014/12/docker-announces-orchestration-for-multi-container-distributed-apps/
Краткий перевод: www.nixp.ru/news/13000.html
При запуске (docker run) вставить вот такой флаг: -v /путь/на/хосте:/путь/в/контейнере
Так же можно делать и в fig
github.com/firehist/angular-twig-pack — вот такие штуки позволяют делать это безболезнено.
Мне кажется, ваш опыт будет очень интересен и полезен.