问通信微服务/微前端架构

EN

微额的好处：

在teams/domains

• Ability之间独立部署UI代码的
• 能力，以便在每个团队
• 硬边界上使用不同的技术/为该域
• 封装UI代码提供更小的代码库

以加快构建、测试和部署时间

​

最佳的微前端架构：

假设单个用户面向for应用程序:从用户的角度来看，frontend)

• Frontend A“平台”微前端服务于“骨架”页面

• ，它是一个具有一个域名(避免CORS问题)的单一站点(

• )--“骨架”页面根据命名空间路由向团队特定的前端发出呼叫，通常这种基于路径的路由是通过入口或反向代理来处理的(例如，/namespace/accounting到计费for服务(微前端)对表示问题负有严格责任，并且经常调用对各种data.

• Frontend服务拥有所有权的其他后端服务，这些服务包含用于服务静态资产/组件和处理ajax请求/组合UI特定数据的逻辑。

​

摘要：

您的前端服务通常需要调用后端服务来为表示目的组合数据。例如，如果需要显示用户数据，则可能需要调用一些UserService或AccountService来获取有关该用户的其他详细信息。我不建议尝试使用特定于前端服务的复制数据来构建单独的数据存储。

前端服务通常不应该包含业务逻辑；但是，有一个论点是，对于较小的应用程序/更早的应用程序来说，拥有一个同时处理同一个域的UI和业务逻辑的服务是有意义的。通常情况下，服务范围太广而不是范围太窄是不太坏的。

但是，在微服务体系结构中，将服务之间的必要依赖保持在最低程度仍然很重要。一个常见的问题是陷入“依赖”地狱，在那里您调用服务A，它需要调用服务B等等，这使得体系结构变得缓慢和脆弱。前端服务通常会调用“一层深度”的服务，然后将这些响应组合到单个显示数据/有效负载中。

最后，明智地选择前端服务/域的边界非常重要。不应该有很多前端服务都需要频繁地调用相同的后端服务。最好从一个单一的、广泛的前台服务开始，并随着你对边界的更有信心而进一步分解它。