前端服务 Front-End Service
发布网友
发布时间：2024-10-24 01:18
共1个回答
热心网友
时间：2024-10-26 21:14
用户在使用平台系统进行部署、管理或执行复杂事务时，通常会经历一系列既定的流程和操作。这些流程有时简单，有时则较为繁琐。因此，如何简化操作、提高效率成为了UI交互设计与页面展现的主要研究目标。
然而，UI的设计与实现实际上依赖于后台数据服务。换句话说，UI（用户界面）与数据服务共同完成了用户交互设计的完整流程。
随着需求的不断增长，系统变得越来越庞大。为了满足快速演变的需求和更广泛的系统适应场景，我们采用了微服务（Microservice）架构模式来构建具有扩展性和可持续开发能力的系统架构。对于微服务，每个人都有自己的理解，但大体上仍有一些共同的标准。
1. 由分布式服务组成的系统。
2. 按照业务而非技术来划分组织。
3. 制作有生命周期的产品而非项目。
4. 自动化运维（DevOps）。
5. 容错。
6. 快速演化。
在按照功能拆分服务后，客户端如何访问这些服务成为一个关键问题。
服务的与依赖实际上是业务责任的前移和UI调度的实现。
从服务的角度来看，微服务的拆分实际上是将原来平台中用于业务调度等工作从具体的服务中剥离出来，以达到解耦的目的。每个服务更专注于自身被赋予的使命，并能以某种形式对外提供服务，将责任之外的事情剥离出去。架构设计明确了服务的责任，遵循单一责任原则，为满足变化的需求提供了可能。
从业务的角度来看，拆分实际上是将一个完整的业务流程或步骤打散，抽象出组成业务的服务或更细粒度的服务因子。从而可以合理地为服务分配各种资源，或扩展现有服务以适应新的业务变化。重组业务成为可能。
从终端（前端）的角度来看，整合拆分后的服务因子，调度业务流程上的各个服务，为用户提供完整且有意义的功能实现。这缩短了产品和服务的上市时间，降低了开发和改变流程的成本。
前端服务（终端服务）是重要的上层服务。
用户通过各种形式的终端来真正使用功能。而后端的各种服务对用户来说则是不可见的，甚至是无意义的。换句话说，单一服务不能解决用户问题，也不能真正满足用户实际需求。因为，用户需要的是一辆完整的汽车，而不仅仅是堆砌在一起的汽车零件。终端服务的好坏决定了功能的好坏。
前端是终端的一种形式，前端服务的好坏对产品的优劣有非常重要的影响。
前端服务的责任与使命：
前端在访问按功能拆分的服务时，需要整合多个服务的API和部署位置。如果服务发生下线、更新或升级，前端需要重新适配这些变化。这明显不符合拆分服务的理念，特别是在业务节奏变化快的情况下。
另外，拆分成多个服务后，虽然不会也不允许影响用户UI交互层的流程逻辑。但是，在前端与服务配合完成的具体业务逻辑时的API实现成为一个缺口。通常，一个单一业务视图的数据请求可能来自于被拆分后的多个微服务。也就是说：一个完整的End-Point形式的UI交互逻辑是由多个原子化的REST形式的API拼合而成。这会导致多次客户端服务器往返的HTTP请求。
Multiple Round-Trips API-Gateway
一般微服务在系统内通常是无状态的。当需求设计需要对跟踪用户状态或权限管理等进行会话跟踪时，就需要一个统一的管理服务来维护。
因此，这些拆分后的服务后台与UI之间需要有API-Gateway代理服务，整合End-Point与事务形式的业务请求。
实时监控与状态统一问题：监控系统对数据的及时性要求较高，也是持续消耗网络的主要业务。实时性业务要求服务后台在保证数据准确性的同时，也要稳定持续。然而，网络延迟的不确定性因素很大，通常很难通过基本的http-loop请求轮询保证数据实时有效。
另外，有些对操作状态有要求，但非实时性的交互操作也不能通过简单的http-loop保证数据的有效性。
构建从服务端到前端的高性能数据通道，减少外部网络环境对业务服务的影响，提升数据传输效率，同时将数据负载可控。
Data Tunnel
在用户完成某项操作后（这个操作本身可能复杂或简单），系统去完成这项任务或多或少都会耗费一些时间，因为可能要参与的具体服务不止一个。如果客户端直接调度一系列步骤对应的服务即耗费时间，也无法保证操作的完整性。
相比服务端，前端是不可靠、不稳定的。微服务拆分后，业务的完整性并不是的服务应该承担的责任，服务本身不可能承担这样的请求。业务前移后，前端只向Front-End Service提交事务型业务的描述，由Service去完成实际的工作，既保证了事务，又提高了效率。
