duboo服务使用thrift协议 + MQ

写一篇博客来记录从 Python 转型到 Java 的学习成果。
整体架构:
rpc: dubbo + thrift
idl: thrift
registeration: zookeeper
MQ: kafka
sql: mysql
noSql: redis
过程中遇到的问题:

1. 数据库唯一标示ID
沿用了 sonwflake 的设计方案, 单个服务每毫秒最大吞吐量为 4096 个ID
2. 日志部分
目标: 每次请求只有一条info日志, 并且其他日志格式保持统一。(如 warn error)
日志格式: logID {method request response} {runTime}
runTime: 可在函数内部自定义计算代码段的运行时间
解决思路:
1. 考虑到一条请求只有一条日志，因此需要重写log库
2. info 这种日志每次调用还要手动打印出来太费劲了，所以考虑到了用 dubbo SPI filter 扩展
3. 重写log库
1. 单利: 由于dubbo处理每次请求使用的都是不同的线程来处理，所以保证每条请求保证只有一个info日志并且还能把代码段运行时间保证存储在一条日志中这里考虑了单例，不能每次调用接口时都 new 一个新的log对象 1. 不符合个人编码风格，重复的代码太多了。 2. 接口调用内部方法时要记录方法内部的代码段运行时间不容易。 但单利就能很好的解决这个问题。
2. 保证日志数据为线程级别: 又回到了刚才的问题，dubbo每次请求都是用一个线程来处理当前请求的，所以使用的单利这时候就会出现数据记录错误的问题，这时候考虑到了创建一个容器，用来存储需要打印的数据，用线程号来区分是哪个线程级别的数据。
3. runTime: 这里跟日志问题2一样，都需要保证线程级别参数不能出现问题。
3. 消息队列设计:
场景:
1. 关注用户行为(follow服务)
2. 更新关注feeds(focus服务)
3. 更新消息 + 推送(message)
设计思路:
常用的设计思路就是 product -> MQ -> consumer
比如上面的这个案例 那么我们第一想法就是 谁需要消费则谁是消费端
follow -> MQ -> (focus, message)
这时 follow服务作为kafka的 producer
focus, message服务作为kafka的 consumer
优点: 配合 consumerGroup 效率最高
缺点: 维护成本高, 优化是需要改动多个服务

更新方案: followProducer -> MQ -> kafkaConsumer -> (focus, message)
followProducer: dubbo服务提供者 + kafka生产者
kafkaConsumer: kafka消费者 + dubbo服务消费者
(focus, message): dubbo服务提供者
这样的设计就是所有服务都可以是kafka的生产值, 但只有一个kafka的消费者消费者接收到来自kafka的消息后进行对其他服务的消费
优点: 维护成本低，扩展性强，优化时只需要改动一个项目
缺点: 承载了一部分业务，运行时间慢（优化: 使用多线程处理）
3. 关注feeds设计:
需求: 关注用户行为时，更新用户的关注列表
设计思路: 数据存储在redis中, 使用 sorted set(有序集合)结构存储关注feeds
其实有推拉模式，消息订阅的意思。
关注一个用户行为可以理解成 关注一个用户动态的行为
如果想要在获取时更轻松，那么就要在关注时受点累将要展示的数据整理好
4. dubbo(坑贼多):
由于微服务使用的是 dubbo + thrift 而上层api又是 php 所以在调用时出现了不少毛病，最后扩展了dubbo的原生协议解决了这个问题。
上面这个问题解决了，但是又出现了一个令人发指的问题！！！就是java服务相互调用时只要出现并发必定报错！！！解决这个问题使用到了多协议，nthrift + thrift原生协议。