前言
假设当前手上有一个单体应用，现在准备将其转换为BFF架构。
自然需要一个前端 、一个BFF层 以及多个微服务（今天的重点）。
本文主要讲述如何拆分这多个微服务
正文
假设当前应用有
- 访客模块
- 博客模块
- 在线人数模块
- ...
问题1：各个服务之间的数据库要共用还是各个服务有各个的数据库？
回答：
推荐每一个服务 有独立的数据库。
其实主要是为了【提高项目的可扩展性&&避免各个服务之间的耦合】。
当我们需要新增某一些功能的时候------比如我要在现有的基础上新增一个【打赏功能】。
我只要做功能的新增，而不用对之前的各个服务进行任何的调整。
还有一个好处就是，我可以根据不同的业务，选择最适合的数据库。
上口诀：事务用MySQL，灵活用Mongo，快选用Redis
问题2：如何设计各个服务之间的协议
回答：
协议的使用是与当前的业务的特性息息相关的。
我会用场景来对应协议，而不是光说理论：
【场景1】我要做在线人数的统计服务
这个东西是高频的、低延迟的。
我推荐：
WebSocket（前端到BFF） + gRPC（BFF到微服务）
【场景2】支付功能
这个东西安全第一，关于【安全】的可以优先考虑：
HTTPS（对外） + gRPC（内部）
【场景3】日志收集
我们假设这个日志是特别多的那种，看了头皮发麻的那种巨量日志。
你应该脑海里有一个词在不断横跳才对------"削峰填谷"
没错，选Kafka/RabbitMQ这样的消息队列方案直接秒：首先将消息全塞到消息队列，再安排一个服务慢慢消费即可。
【场景4】稀松平常的获取博客
这种就属于比较平常的业务了。
选择HTTP/gRPC即可。
【小贴士：gRPC性能>HTTP】
最后
贪多嚼不烂
暂时只举这些场景
后续如需要会再补充。