共识机制
Basic Paxos在全部节点可信任的时候，主要还是效率问题。所以zk、etcd都要用改进的算法。
Basic Paxos在部分节点不可信任的时候，是不适用的。所以公共区块链项目需要用其他的共识机制。
公共区块链中，常用的共识方法有PoW、PoS、DPoS等，这些方法，一方面是要达成共识进行记账，另一方面是要防止网络被恶意攻击；
联盟链中，一般采用PBFT、PoET等方法，由于不需要面向整个互联网，所以共识机制效率比公共链高不少；同理RAFT、ZAB，默认所有节点是可信任的，效率也是比较高的。
其实大家在日常生活中，默认会通过中心化的方式来达成共识，比如转账成功与否，大家一般会通过银行或支付宝的记录来判断，而不是线下协商。而这种方式，反而是交易效率最高的。
还是那句话，根据业务场景，选择足够用的架构和算法就好了。适合团队，能高效低成本解决问题的方案，就是最好的方案，哪怕这个技术方十分十分的朴素。
为何有了 DNS，还会出现 Eureka、Consul 这些专有的服务发现框架？
感觉其实要解决的问题并不一样：
1、基于DNS，其实要解决的问题是流量的流向，可以做到流量监控，但无法管理到具体业务，功能简单，效率更高；正好符合K8S的需要；
2、服务发现框架，其实是深入到业务层面，在应用框架集成、业务监听支持、健康检查、服务保护等功能。而且基于业务需求，进一步提供配置管理、环境管理等、多数据中心管理、业务紧密结合的功能；
有点像前面说的四层负载和七层负载的意思。
一个功能简单，效率高花头少；一个功能复杂，效率低可发挥空间更大；
那么除了 BFF 之外，你还用网关来做什么？
在API网关之前，会把移动APP的后端服务单独独立出来，APP访问APP后端服务，APP后端服务访问Web后端服务，相当于做了一个完全定制化的API网关。
当时也尝试过直接用Nginx来完成，但当时也不知道OpenResty这类扩展，复杂些的功能没能实现，没能实际应用。
后面从Zuul开始就不造轮子了。
客户端的负载均衡
客户端的负载均衡，在传统的CS解决方案中也有涉及，比如：
1、直连数据库时，统计类SQL直连只读库就好了
2、而且有些其实也变相做了优化，比如大家都熟悉的游戏开新服，登陆时就把流量分了
客户端负载均衡方案，其实和nginx的均衡策略基本一致的。但还遇到过一种中间情况，就是多了一个调度器，客户端定期获取服务IP列表，也可以从调度器获知每个IP的繁忙程度，然后决定要访问那个IP。
此外，云厂商对于移动、联通、电信的网络，有时也会用不同的链路，并会交一定的“保护费”啦。
负载均衡的设计，最佳人选，应该是懂业务的架构师（默认架构懂开发、懂运维）。
但同时，开发、运维团队要参与及评审：
1、比如开发要与架构沟通，团队熟悉哪些技术栈，哪些服务有状态哪些服务无状态等，中间件如何取舍
2、比如运维要与架构沟通，跨机房数据同步要如何做，容灾备份要如何处理，动态扩展是靠脚本还是靠云平台机制等