微服务架构的思考

　　要实现微服务架构，服务必须能够被透明的替代，也就服务支持复制式扩展。多个相同服务是完全相同的，他们都处于活动状态，当一个宕掉后，系统仍然是可用的。这是微服务架构显著的特点。

　　服务执行的任务分两类：被动调用、自发任务。

　　对于被动调用，请求容易分配到某个服务，服务执行时会依赖一些数据，也会产生一些副作用，如果这些信息和服务是捆绑在一起的，那么这个请求也会和这个服务捆绑在一起，那么服务自然无法透明的替代，这里关键是需要将副作用的数据与服务本身分离开。通过分布式缓存技术可以解决这个问题，例如Apache Ignite。

　　对于自发任务，多个服务都处于活动状态，如果大家做的事情都一样就会产生冲突，他们必须进行合理分工。通常的做法有两种，一种是有一个主服务进行分配，然后大家各司其职，当有服务宕掉或加入时，主重新分配。一种是引入一个协调者，所有服务共同协商出一个共同结果，当出现服务宕掉或加入时，重新协商。显然后者的可靠性更高，也更加灵活。所有服务可以做到真正的对等。解决分布式一致性问题，ZooKeeper首当其冲。