首先明确一下两者的目标：braft是解决复制状态机问题，brpc是解决?？榧銻PC通信问题。braft中Raft协议的互通直接使用brpc实现，runtime使用了bthread，因此braft编译需要依赖brpc，从这点来看braft和brpc有一定的绑定关系。
但是从另一个角度来看，braft中核心的是协议状态机比如log、snapshot、configuration这些东西的抽象和实现，协议RPC只是其中一环，做一层transport抽象也可以比较容易的替换为其他的coroutine based protobuf RPC框架，对于非coroutinebased protobuf RPC来讲，braft只能用类似logcabin中pthread同步RPC，这样就丧失了多复制组支持的特性，RPC的回调改造成本就比较高了。
如何看待raft的前景？
当下，Raft已经成为分布式一致性算法的主流，业界的TiDB、CockroachDB、etcd、consul等一系列流行的组件和服务都在使用，但是业界还有一些其他的paxos变种比如epaxos，未来可能会有一种新的Paxos变种成为主流。
对于Raft来讲基于日志的连续提交的设定，相比multi-paxos的乱序提交在写入性能上会有些差距。对于Raft协议来讲没有太多改进空间了，但是braft要做一个理想的Raft库实现的话，依然需要不断的改进和优化。
