谷歌云平台——这种微服务架构是否复杂/过度设计？

抱歉提了这么长的问题。

在我的公司，我们接受微服务，但使用GCP（应用引擎+云功能）的无服务器托管方法。我在微服务/无服务器领域只有1年的经验，我以前的工作经验是使用monoliths或macroservices。

故事：该公司有一个整体，决定分成几个功能，每个功能都分配给一个特定的团队。

在我的团队中，我们必须涵盖工作流的一个特定部分，因此我对为其选择的架构有技术上的疑问（其中一些是在我加入之前创建的）

该应用程序的当前架构是什么？

• 1个云函数（CF）（或aws的lambda），用于侦听来自另一团队微服务的发布/订阅请求，并将数据保存在firestore（nosql）中
• 1个应用程序引擎，每小时由云调度程序（cron）触发，在firestore中搜索需要使用某些db过滤器更新的所有订单，并为每个订单向另一个应用程序（消息队列）创建一个云任务。
• 1个应用程序引擎，接收以前的任务，调用外部系统，将结果保存在bucket（文件）中，并更新几个firestore字段（如updated\u at、task\u id等）
• 1个CF，侦听bucket事件，并使用文件数据调用另一个CF。
• 1 HTTP CF，接收订单id和外部状态（文件内容），并使用外部信息更新订单。为了更新，它使用翻译服务（见下文）。翻译后，它将结果保存在firestore上，并在pubsub中发布一个事件。
• 1个应用程序引擎（翻译服务），提供外部状态并将其转换为我们公司的状态。

未来的目标是添加另一个CF，用于侦听firestore事件并将数据保存在SQL中，然后添加另一个应用程序引擎用于报告。

因此，我们最终在8个不同的存储库中部署了8个可部署组件，其中5个使用相同的数据库，测试所有这些本地组合的服务，并且数据库上的每一个更改都需要更新到所有其他存储库。监视和查看发生的事情的轨迹也很复杂，甚至不要说一些基础设施更改或更新是在没有地形的情况下手动完成的，因此更改的可见性也会受到影响。

所以我有一个想法，为什么我们不把所有这些功能结合在一个单一的微服务（应用引擎/云运行）中，负责：

• 订单的1个端点，并将其保存在SQL中
• 1个用于批处理的端点，将任务生成到另一个端点。
• 1个端点负责从外部服务中查找新状态、翻译（在翻译应用程序的帮助下）、更新和发布。
• 1个报告端点

幸运的是，我能想象出一千行代码。所以，我只有2个可部署的，易于设置、测试和监控。

然而，我的团队说了几句话。

• 这要回到独石，我们必须保持小规模，使用事件。
•  
• 只有2个可部署功能是不可扩展的，我们应该更喜欢具有更抽象且可以单独扩展的小功能。

我不明白为什么人们会放弃在单个应用程序中包含业务需求的简单性和可测试性，而相信更小的技术部署部分可以提供更好的可扩展性。

我的问题：

你认为当前架构还有改进的空间吗？你认为我统一服务的想法如何？

谢谢