集群版基于SpringCloud搭建，给服务端提供了分布式系统的架构基础。那这种分布式微服务结构，能给我们带来什么不一样的收益呢？
- 假如集群版需要8G内存的机器部署，那我只有两台4G的机器怎么部署呢？
- 假如用户量访问很大，controller顶不住了，怎么解决？
- 如果task分布式部署，定时任务会不会重复触发啊？
- 分布式部署时，怎么确认负载均衡？有微服务挂了，集群版服务是怎么容灾的呢？
带着这几个问题，我来给大家简单介绍下微服务架构，有错误欢迎指出。
微服务其实是将一个单一的程序，按照功能模块进行拆分成多个服务。例如一个完整的网上商城，用户量最大应该是浏览商城页面的模块，也许订单模块，发票模块用的人比较少，那么如果用传统的加机器，例如五台linux机器同时部署五个商城，通过nginx负载均衡，那是没问题的。但是会造成很多资源浪费。
但是如果我们将这个商城拆开多个系统，例如订单系统、仓库系统、支付中心等等，然后按照一定的比例进行部署，这样就能节省服务器的成本。
当然这只是简单举个例子，一般搭配mq还能做到流量削峰、上下游系统互不干扰等等好处。
那么Sonic也是如此，最简单的crud由controller去承担，跟agent交涉就由transport去做，task负责定时任务，folder负责文件储存中心，eureka就是微服务注册中心等等。各个服务有自己的任务。那回归我们的主题。
1、假如集群版需要8G内存的机器部署，那我只有两台4G的机器怎么部署呢？
答案是可以用docker swarm或者k8s部署sonic集群，可以让一半服务在a机器，一半服务在b机器，然后进行overlay网络互相通信，通过eureka进行负载均衡与注册。
2、假如用户量访问很大，controller顶不住了，怎么解决？
eureka是可以一个微服务注册多个，例如我用docker swarm启动了两个controller，当我们访问服务端接口的时候，gateway网关会自动负载均衡，例如第一次接口会访问a的controller，第二次会访问b的controller，第三次又回到a。这样我们可以观察哪个微服务的处理能力到瓶颈之后，我们可以自定义增加某个节点的微服务数量
3、如果task分布式部署，定时任务会不会重复触发啊？
定时任务框架用的是quartz，是支持分布式部署的，所以多个task节点的时候，同一个定时任务永远只会触发一个，不会造成多次触发的问题
4、分布式部署时，怎么确认负载均衡？有微服务挂了，集群版服务是怎么容灾的呢？
首先gateway十分强大，自动会将接口根据节点数量负载均衡。其次微服务内部调用接口我用了feign也是负载均衡的，所以整个Sonic集群就是去中心化分布式。至于容灾，如果部署时候是多节点部署，那么容灾可以及时有备用节点，并且如果节点不可用，feign会有熔断、降级的作用
以上是SpringCloud在Sonic里的一些作用，实际上微服务集群的形式带来的好处还有非常多，大家也可以多多探索。文中有错误也欢迎指正
