Azure 设计模式之为特殊前端创建后端服务

为特殊前端创建后端服务

创建单独的后端服务以供特定的前端应用程序或接口使用。当您想避免多个接口共享单个后端时，此模式很有用。

问题背景

应用程序最初可能定位于桌面WebUI。通常会并行开发后端服务，以提供该UI所需的功能。随着应用程序用户群体的增长，就要开发与相同后端进行进行交互的移动应用。后端服务同时满足桌面和移动界面的要求。

但是，在屏幕尺寸，性能和显示限制等方面，移动设备的功能与桌面浏览器的区别很大。因此，移动应用程序后端的要求与桌面，Web UI有些部分会不同。

这些差异导致后台的需求竞争。后端需要定期进行大更新才能为桌面，网页用户和移动应用提供服务。通常，每个接口小组完成各自的前端工作，导致后端成为开发过程的瓶颈。解决更新需求的冲突的同时为所有前端保持服务，为单一部署造成了很大的人力成本。

由于开发活动侧重于后端服务，因此可能会创建一个单独的团队来管理和维护后端。最终，这将导致接口与后端开发团队之间产生隔阂，后端团队为了平衡不同UI团队的需求竞争而承担额外的负担。当一个接口组提出需要后端进行更改时，这些更改必须与其他接口组进行验证，然后才能提交需求到后端。

解决方案

为每个用户接口分别创建一个后端。对单个后端的行为和性能进行优化，以最好地满足前端环境的需求，而不用担心影响其他前端。

因为每个后端都是特定于服务一个接口，所以可以针对该接口进行优化。因此，它将比通用后端更小，更简单。可能比通用后端开发起来更快。每个接口团队都有自主权来控制自己的后端，而不再依赖于共同的后端开发团队。这使前端团队在语言选择，发布节奏，工作负载优先级和后台功能集成方面具有更多的灵活性。

问题和思考

需要部署多少后端。

如果不同的接口（如移动客户端）会提出相同的请求，请考虑是否需要为每个接口实现后端，还是单个后端就足够。

实施此模式时，很可能导致跨服务的代码重复。

面向前端的后端服务应仅包含客户端特定的逻辑和行为。通用的业务逻辑和其他全局功能其他地方进行管理。

想想这种模式可能如何落实在开发团队的职责中。

考虑实施这种模式需要多长时间。建立新的后端团队的努力是否会产生技术债务，而与此同时，要继续维护现有的通用后端。

何时使用这种模式

若维护通用的后端服务，会带来显著的开发成本。

希望针对特定客户端接口的要求来优化后端服务。

需要一个容纳多个接口的后端。

这种模式可能不适用于：

当多个接口对后台的请求类似或相同。

当只有一个接口与后台进行交互时。