边缘服务的一致性、耦合和复杂性( 三 )

SoC的标准由软件架构师来设定。以下是不同层的分类以及每个层应该关注什么。
通常来说，在现代商业软件中，最主要的层是前端和后端。
前端软件的直接交互对象是用户，通常运行在移动设备或笔记本电脑上。前端包括移动应用和Web应用，主要是关于渲染、绑定、交互和用户体验。其内部结构类似模型视图控制器（MVC）的变种。后端软件的交互对象是前端软件。在生产环境中，后端软件通常运行在数据中心（如公有云）的服务器上。后端又被进一步分为数据、边缘和集成服务。
数据服务为数据库提供保护、执行业务规则、维护一致性，并专注于可伸缩性、性能和潜在的弹性问题。其内部结构包括资源控制器、服务、模型和数据访问对象（DAO）。边缘服务负责处理推送通知、跨端点聚合和安全问题。集成服务应该作为第三方应用的反应式抗腐蚀层，如电商网站（后端集成）和电子表格（前端集成）。还有其他一些类型的服务这里没有提及。
一个功能全面的服务网格可用于处理弹性、发现、内部认证、加密和可观察性问题。要实现可观察性，需要与其他类型的服务发生交互，获得监控、告警、日志聚合，甚至是分布式追踪能力。
在架构师看来，当开发人员决定模糊这些SoC（通常是图一时的方便），就是系统开始陷入麻烦的开始。例如，因为DevOps的不完善，你决定让数据服务来处理边缘服务或集成服务应该处理的问题，或者让前端应用做一些本该由后端完成的事情。
现代技术栈
大约在六年前，我发现了一种所谓的BFF边缘服务。客户端应用程序不会直接调用数据服务，而是通过中间服务来调用，中间服务专门用来满足客户端应用程序的需求。如果设计得当，这种方式可以将数据服务与不断变化需求的GUI解耦开来。虽然数据服务仍然与数据库紧密耦合，但数据库schema变化速度相对较慢。至少对于相对成熟的项目来说是这样的。
那么BFF涉及哪些有用的技术？它们作为GraphQL暴露出来，需要基于RESTful数据服务提供一个聚合编排层，需要提供WebSocket或利用GQL的订阅能力，应该由前端团队负责开发维护，并采用前端开发人员比较熟悉的技术栈。
你可能倾向于认为BFF会增加延迟，因为多了额外的服务器跳转，但事实却相反。加重延迟的不是服务器跳转，而是数据包的传输距离。为了方便演示，请想象一下以下这种情况。假设一个网页调用了一个API ，这个API平均每次返回10个数据项，而每个数据项需要调用另外三个API ，这样才能获得渲染页面所需的数据。一位旧金山的用户从亚马逊us-east-1区域的服务器加载页面，每个请求来回需要传输5600公里。因为总共有31个请求，所以数据需要传输173600公里，这个距离可以绕地球7圈。如果你把这31个请求放在一个BFF里，并且这个BFF与服务器位于同一个数据中心里，那么你总共需要32个调用，但数据只需要传输5600公里，是不使用BFF传输距离的3% 。 Web浏览器可以通过并行的方式调用API ，但相比后端服务，在连接方面具有更强的约束。
另一种边缘服务叫作API网关，用于认证、授权、速率限定、单点登录和访问权限管理。如果有必要，它也可以将查询请求路由给GQLBFF ，或者直接将请求路由给RESTful服务。对于不同类型的客户端应用程序，需要使用不同的BFF ，但你只需要一个API网关就可以满足各种类型的客户端。 API网关有时候也作为第三方的调用代理，让它们可以访问防火墙背后的数据服务。 API网关是一种通用服务，可以由后端开发人员负责开发（OpenResty就是一种比较流行的方案），也可以是第三方提供的产品（比如Kong），或者是由公有云供应商提供的PaaS服务。