问题描述
当前正在开发一个无服务器应用程序，该应用程序使用serverless-domain-manager来将我们的API维护在https://api.business.com下，整个项目是由serverless-stack.com中建议的带有微服务的monorepo构成的。这样做的主要原因是服务之间的代码共享，存在一个包含80％的实际代码（业务逻辑）的lib目录，并且各个服务都映射到这些lib帮助器上，想一想用户和管理API可以做更多的事情精细权限。
目前有40项服务，每个服务在API上都有自己的基本路径，例如，其中3项服务是：
- 服务
user是api.business.com/user / - 服务
users是api.business.com/users / - 服务
product是api.business.com/product /
问题在于某些服务变得越来越繁琐，其中包含25多个单独的功能。根据我的理解，您应该尽可能减少这些微服务。如果您想到上面提到的user服务，那么我们有以下
- 获取/ user / profile
- 输入/用户/个人资料
- 获取/ user / settings
- 放置/ user / settings
- 获取/ user / notifications
- 输入/用户/通知
- 获取/ user / store
- 获取/ user / store / STORE_ID /产品
您明白了……它已经大大简化了！
对于这种用户服务，感觉就像用户商店是单独的微服务user-stores甚至是user-profile和user-settings等的理想选择。问题是serverless-domain-manager仅支持单个“单词”作为basePath。因此，API端点将从/user/store/STORE_ID/products变为/user-store/STORE_ID/products。
虽然完全有可能，但感觉就像我失去了使用完善的工具/清晰地构造API的能力。
在相似的情况下，其他人又如何构造他们的大型应用程序？
解决方法
这不是直接答案，但是您是否研究过lambda层？您也许可以将所有库分离到一个层中，这将简化整个项目并保持精简。
有什么方法可以避免使用域管理器插件？
,这也是我面临的问题。我使用的系统有 20 个服务，每个 API 端点有 1 个 lambda 函数，总共有 200 多个 lambda 函数。
lambda 部署的总规模巨大，部署需要很长时间。
我在 serverless architecture pattern 上看到了一个帖子，将多个相关端点分组到单个 lambda 函数的服务模式似乎是一个可行的选择。 这有助于减少 lambda 部署的大小，但作为回报，将请求路由到适当的处理程序时会产生额外的代码和复杂性。
Lambda 层也可能很有用，尽管我对它的了解不多。 有一个示例项目演示了 AWS lambda layers