首先明確一下兩者的目標：braft是解決復制狀態機問題，brpc是解決模塊間RPC通信問題。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庫實現的話，依然需要不斷的改進和優化。
