一听到BFF你是不是会有一连串的疑问? 比如是前端团队实现BFF呢? 还是后端团队实现BFF呢?那前端团队实现BFF是使用node.js吗? 那后端团队实现BFF是用serverless云函数之类的还是直接堆服务器? 另外要用到传说中的GraphQL‌?那到底要几个BFF呀?下面我就说一下我们当年具体是如何落地BFF的。在开始之前我想说一句任何技术架构一定要根据自己的团队的实际情况和公司业务情况来切记。不要说看到网络上某些文章头脑一热就开始要兴致勃勃的去实践了。还美其名曰按照标准来。当时我们具体是这么干的BFF统一都是用后端开发团队来实现的有3个BFFBFF没有采用serverless也没有采用GraphQL为什么当时BFF由后端来搞原因是我们认为BFF是聚合编排层具有强业务属性另外还有自己的缓存和存储这块不可能交个前端团队的。至于为啥是通过堆机器来搞而不是采用serverless那是因为我们当时的技术团队没有人熟悉serverless也没有人有这块实实在在的实战经验就更不用谈什么对应的基础实施的健全性了。那为啥有3个BFF呢?这个当然是我定的因为我当时管的电商技术部门组织架构我是这么分的选购线用户下单前的选购线路比如购物车商品菜单等等中后台线下单支付履约等用户营销线用户会员营销且我也认为电商线大的就是如我上面那样划分的。然后每条线都有自己的前后端开发测试和产品经理。每次大需求一来横跨三条线的。那么各条线的人都内部跟自己线内的同事对接就可以了。这是为了效率因此搞了选购线BFF服务中后台线BFF服务用户营销线BFF服务那这么干的话前端是不是还得自己聚合一下对的超复杂页面的确如此。但是我们认为这是可以接受的。其实也就那么几个复杂页面会出现这种情况。剩下的基本上都是对接自己的BFF层就可以了。再者超复杂页面你去调用一个超级大的BFF的一个接口我们认为也是不可行的太危险了。因为粒度实在太粗了适当的时候让前端多调用几次反而是更好的。好。那么这么整后整个的架构是如何的呢? 如下图那么这里可能有人会问我们公司体量小是不是只搞一个BFF就可以了。当然没问题。我上面那样做是根据我们的实际情况来的。其实很多小公司一个BFF就可以了。当然还会有人问可不可以独立出一个中间层团队来这波人专门去做这个BFF层的开发呢? 当然可以。像我当时待过的一家大厂就是这么干的。光是中间层研发团队就超过70号人了。当有这样的独立的中间层研发团队后其他的职能技术团队可就幸福了。因为他们只需要很专注很纯粹的写RPC接口就行了。剩下的不用管了。中间层团队会过来对接的。不得不说效率实在太高了。当然公司也得有钱哈能养得起这么大的中间层技术团队。小结BFF怎么落地没有标准答案只有适配答案。后端做还是前端做取决于BFF里业务逻辑的比重堆机器还是上serverless取决于团队对技术的掌控程度拆几个BFF取决于业务线的规模和团队的组织方式。这三件事的判断依据都不是技术上的优劣而是人和组织的现实约束。很多团队讨论BFF容易陷入技术选型的争论GraphQL还是RESTserverless还是传统部署Node.js还是Java。但这些争的是手段不是问题本身。BFF要解决的问题是确定的——微服务拆细之后谁来组装数据。手段根据团队实际情况来选就行选什么不重要选完能跑稳才重要。最近在知乎出了「应付6000万会员的秒杀系统专栏」「几亿用户,百万并发的C端商品系统实战」「技术团队DDD领域驱动设计三年落地实战」「应付亿级用户规模的支付系统代码实战」「应付亿级用户的会员体系代码实战」专栏感兴趣的可以订阅一下。至于知识星球的可以搜老码头的技术浮生录它是一个能实际帮你解决难题的星球。有问题的找知心的Sam哥支持无限次语音一对一解决你遇到的难题。「另外后续我新写的所有对外的付费专栏在星球内都是免费的且可以拿到所有源代码。」当前星球里免费看的专栏是「应付6000万会员的秒杀系统专栏」「几亿用户,百万并发的C端商品系统实战」「技术团队DDD领域驱动设计三年落地实战」「应付亿级用户规模的支付系统代码实战」「应付亿级用户的会员体系代码实战」知识星球内后续将推出20个付费专栏覆盖电商全链路选购线用户会员营销线中后台购物车服务营销系统订单系统商品服务用户系统支付系统菜单服务结算服务从前台选购到中后台结算星球成员全部免费后续新增也不额外收费。我的知乎账号:SamDeepThinking