Понимание микросервисов, использующих Express.js и Докер


Я новичок в узле.js и docker, а также архитектура микросервисов. Я пытаюсь понять, что такое архитектура микросервисов на самом деле, и теоретически я понимаю, что такое арка микросервисов.Пожалуйста, смотрите следующую реализацию Это индекс .js файл:

var express = require("express"); 
var app = express();
var service1 = require("./service1");
var service2 = require("./service2");
app.use("/serviceonerequest",service1);
app.use("/servicetwo",service2);
app.listen(3000,function(){
    console.log("listening on port 3000");
});

Файл service1:

    var express = require("express");
    var router = express.Router();
    router.use(express.json());
    router.get("/",(req,res)=>{
        //perform some service here
        res.send("in the get method of service 1");
        res.end();
        });

        router.post("/letsPost",(req,res)=>{
            res.send(req.body);
            res.end("in post method here");
        })
module.exports = router;

Файл service2:

var express = require("express");
var router = express.Router();

router.use(express.json());
router.get("/",(req,res)=>{
    //perform some service here
    res.end("in the GET method for service 2");
});

router.post("/postservice2",(req,res)=>{
    res.send(req.body);
});

module.exports = router;
  1. относится ли вышеизложенное к "архитектуре микрослужб"?Так как есть две услуги и к ним можно получить доступ через индекс "api-gateway".js?
  2. я прочитал основной учебник по Docker.Is возможно ли разместить вышеупомянутые три "модуля" в отдельных контейнерах?
  3. Если вышеизложенное не относится к микросервисам, что следует сделать, чтобы преобразовать вышеупомянутый образец в микросервисы?
2 4

2 ответа:

Это не может не квалифицироваться как архитектура конструирование.

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

Согласно этому определению;

"микросервисы-это небольшие, автономные службы, которые работают вместе"
построение микросервисов

Оба service1 и service2, чтобы считаться микросервисом, должны быть автономными, чего не происходит, когда вы размещаете их вместе в одном приложении express. Например, вы не можете перезапустить один, не влияя на другой. Вы не можете обновить версию service1 без необходимости развертывания service2. Они не распределены в том смысле, что их можно оставить в отдельных машинах.

На самом деле я думаю, что вы упускаете концепцию архитектуры микросервиса. Ваши службы должны быть независимыми, и если им необходимо взаимодействовать друг с другом, они должны использовать механизм обнаружения служб, который возвращает исправный экземпляр этой службы. Другой шаблон архитектуры микросервисов состоит в том, что каждая отдельная служба должна иметь конечную точку (/health), которая возвращает состояние работоспособности службы, имея это, ваше обнаружение службы может проверить, является ли этот экземпляр работоспособным и вернуть это как здоровый экземпляр..

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

Если вы хотите понять концепции, я действительно рекомендую эту книгу: http://shop.oreilly.com/product/0636920033158.do