如何看待微软新开源的Service Fabric？

本人曾在Service Fabric (SF)项目中做了几年，这次很兴奋能看到它的开源。短短两天已经有1300多个关注了。我看了一下开源的代码，真是满满的干货，200多万行C++代码，所有最核心的协议算法都在里面。但是，不得不承认，现在各种微服务框架已经用的非常广泛，Service Fabric出来的晚，对它的定位会十分尴尬。而且官方的文档写的大而全，看了让人更糊涂。我这里根据自己的理解解释一下。

SF定位是一个“分布式系统平台”，意思就是说，它是用来写其他的分布式系统的，比如有了SF，就可以很容易写个Zookeeper、分布式Redis或者分布式数据库。但各种应用千差万别，怎么能实现一个你自己的分布式XYZ呢？SF通过主打有状态服务(Stateful Service)来帮你实现这个目的。

先从无状态服务(Stateless Service)说起，这个是目前大多数应用采用的方式。比如这个图是一个很典型的三层结构：前端，中间层和存储层，此外通常还会加个缓存层。前端和中间层都是无状态的，就是说其中不保存数据，可以比较容易地增加或减少节点。存储层是有状态的，需要特别留意数据安全性和一致性。由于前端过来的请求可能由于网络或者硬件故障而丢失，就需要使用队列来增强可靠性。如果访问数据速度是瓶颈，还需要增加缓存层，缓存层也是有状态的，所以缓存本身以及缓存和存储层的数据一致性也需要很小心。

有状态服务(Stateful Service)采用另一种思路，把数据与处理它的程序部署在一起，如下图里面，把存储层的数据进行分片后移到中间层，每片数据对应自己的一套处理程序。每片数据有奇数个副本，由SF来保证这些副本之间的数据的可靠性和一致性。好处就是，首先数据处理程序只需要关心本地数据，逻辑大大简化；其次数据的传输变少了，性能可以得到很大改善；而且系统架构变简单了，不需要在存储层、缓存层、队列等地方分别管理可靠性和一致性，只在SF一个地方管理。

为了保证数据一致性和可靠性，SF设计了非常复杂的协议，比如数据修改操作怎么同步到多个副本，数据修改如何保证严格有序，主副本如果失效该如何选举下一个主副本，节点如何动态加入和去除，容器的负载（内存+CPU）过大如何进行均衡等等。这些协议是我们当时花最多精力的，因为要支持类似分布式数据库这样的应用，要从理论上保证它的正确性，不能有一点意外。