11 篇博文 含有标签「架构设计」

旧链接说明：本文保留历史访问路径，主题内容以当前主文版本为准，这里主要用于兼容旧链接和归档检索。

很多团队把“聚合”这个词说得很泛，结果就是网关想做一点、BFF 想做一点、下游服务也顺手拼一点，最后谁都说不清真正的入口在哪里。

前面聊 BFF 的时候，更多是在讲为什么它存在。到了真正落地时，团队最容易争论的是另一件事: 这层东西到底该做多厚，做哪些事才算合理？

BFF 最容易让团队上手的价值，是它能把前端要的多个接口结果拼成一个更顺手的响应。但编排一旦做顺了，也特别容易越界。

2021 年很多团队开始把 BFF 当成前后端之间的稳定缓冲层，但一旦请求量上来，BFF 很快就会遇到一个现实问题: 要不要在这一层加缓存。

Feathers.js 用久了以后，params 会变成一个既好用又危险的对象。好用在于请求上下文、当前用户、provider、query 都能顺手带进 service；危险在于它太方便了，方便到什么都想往里放。

真正把 Feathers.js 用起来之后，很快会遇到一个问题: service 到底该写多厚，hook 到底该放多少逻辑？这个边界如果不早点想清楚，项目照样会越写越乱。

2020 年前后，微服务这个词在很多团队里都很热。系统一旦变大，大家很自然就会想：是不是该拆服务了？这个方向当然有它的价值，但我后来越来越警惕一种冲动，就是把“拆”本身看成答案，却没有先补上对应的观测和降级能力。