Node js、微服务和分享app.listen？

Question

我的公司从一个使用微服务的相对较小的项目开始。可以想象，代码共享的热门话题出现了，什么可以共享，什么不可以共享。一个争论点是在一个库中共享实际的快速服务器 listen() 代码并在多个服务中使用。我觉得这是错误的，因为我相信这通过共享初始化代码将这两个服务紧密结合在一起。我同事天说我们已经在加上快递了。这种共享方法是正确的做法吗？此外，他没有将路由和控制器分离到它们的结构中，是的，代码很小，但不确定如何快速找到路由。

以下是正在分享的内容。我对有更多经验的人对这种方法的看法很感兴趣。

let app = express();

let app_ready = false;
function check_alive(request, response, callback?:(req:any, resp:any) => void) {
    console.log("alive state requested");
    if (callback === undefined) {
        // no alive_check callback provided
        // use default
        if (app_ready) {
            response.status(200);
        } else {
            response.status(503);
        }
        response.json({ready: app_ready});
    } else {
        callback(request, response);
    }
}

function check_ready(request, response, callback:(req:any, resp:any) => void) {
    console.log("ready state requested");
    callback(request, response);
}

exports.instance = app;
exports.init = (ready_check: (req:any,resp:any) => void, alive_check?:(req:any,resp:any) => void) => {
// basic routing
    app.get("/liveness", (req, res) => {check_alive(req, res, alive_check);});
    app.post("/liveness", (req, res) => {check_alive(req, res, alive_check);});

    if (ready_check == undefined || ready_check == null) {
        app.get("/readiness", (req, res) => {check_alive(req, res);});
        app.post("/readiness", (req, res) => {check_alive(req, res);});
    } else {
        app.get("/readiness", (req, res) => {check_ready(req, res, ready_check);});
        app.post("/readiness", (req, res) => {check_ready(req, res, ready_check);});
    }
};

exports.listen = (port, callback) => {
        return app.listen(port, () => {
        app_ready = true;
        callback();
    });
}

exports.get = (url:string, callback:any) => {
    app.get(url, callback);
}

exports.post = (url:string, callback:any) => {
    app.post(url, callback);
}

编辑：因此，虽然这段代码在技术上是正确的，但应用程序初始化函数是否应该包含在共享库中？如果没有，为什么不，什么应该分享，什么不应该分享？

我在 medium、devops 和这个网站上阅读了很多文章，说只要你可以独立部署、重启等，它就是一个微服务。

提前感谢您的任何见解。

Answer 1

当单一的代码库变得太大而无法管理和团队理解时（即引入新的开发人员是一个很大的痛点），必须采取一些措施。

许多方法都是可行的，但大多数是“分而治之”类型：创建记录和版本化 APIs 的黑盒，这样程序员就不必了解所有细节。这些黑匣子可以是库、npm 包、微服务......只要它们是版本控制和记录的。

在 NodeJS Web 的情况下 API 你可以想象将你的应用程序拆分成多个正确记录的 npm 包来实现大部分逻辑，然后编写一个 API 来导入这些。

每个团队，无论是在 npm 包上工作还是在使用它们的 Web API 上工作，都不需要了解其他项目的内部工作原理。结果是一样的。

微服务（以及之前的 SOA）将其提升到了一个新的水平。他们没有使用库来分而治之，而是通过定义多个互连的 Web 服务来实现。

这有一些好处，但也有很多缺点。

你付出了 RPC 的（大）性能代价，这样代码就不会在同一个进程中结束，需要编写更多的代码，重构是一件痛苦的事情（很难将功能从一个微服务转移到另一个微服务而不是重命名和移动类...)，在重要的项目中，您需要拥抱最终一致性（不再需要外键！）。

但是，您可以使用“适合每项工作的最佳工具”（Python 中的机器学习服务、Node 中 API 等...）。比库（Swagger、GraphQL 等）更好的工具来记录和版本 Web APIs。可以更容易水平扩展（即使这在大多数项目中很少需要）。

对我来说，真正重要的是：

你的微服务是否有明确的边界（即，如果你迁移你的数据库，你是否需要迁移所有的微服务？他们不应该共享state/data否则它是一个“分布式单体”）。
他们有版本控制 API 吗？（您确定迁移其中一项服务不需要您更新所有调用它的微服务吗？）
是否对它们进行了记录（开发人员不必了解服务的内部工作原理就可以使用它们，这对您有好处吗？）

这是一个很长的答案，但我的观点是，不要对您的微服务是否共享 10 行代码感到迂腐。恕我直言，“没关系”。

免责声明：我相信微服务是一个很好的模式，只要它们解决了给定项目的实际问题，但由于炒作而被广泛过度使用，而且在我从事的大多数项目中，它们不需要，并且增加了很多复杂性和开发痛苦，但收效甚微（我是一名自由职业者）。

Node js、微服务和分享app.listen？

Nodes js, Microservices and share app.listen?

code-sharing

node.js

express

microservices