简介：单体服务和微服务系统的优缺点
1、为什么从单体服务到微服务转移
①、最核心的原因是单体服务出现性能瓶颈，如日访问量只有几十万的服务在单体服务可以支持。
②、服务故障隔离：当只有单个应用对外提供服务的时候，这个时候如果 服务挂的话，这时整个应用就提供不了服务了。而在互联网中是要保证高可用(99.99%的时间理念能够对外提供功能)
2、微服务的缺点：
①、增加了整个方案的复杂度：如果系统的日访问量没有达到几十万的话是不需要用微服务的
将系统的整合点推移到了服务之间的接口，因此这些服务的接口需要进行良好的定义，在系统中也要对服务级别达成一致，并且还需要定义其他的非功能需求。
②、数据一致性问题：分布式事务难题
原本采用一体性应用程序架构的系统被分解为多个小型服务时，在原本的一体性架构中集中保存在某处的数据，在新的微服务应用中经常会改为保存在多个地方，这种改变可能会带来维护数据一致性的挑战。
③、网络延迟-服务之间互调存在一定的延迟 ，因为服务会部署在不同的机器上
④、增加开发复杂度
接口调用增加够通成本，要求软实力的要求比传统项目的要高一些(WIKI文档)
重复劳动
3、基于微服务的技术选型
①、微服务下的全家桶选择
②、微服务框架主体springBoot与springMVC
SpringMVC提供了一种轻度耦合的方式来开发web应用，而spring只是一种分层的应用框架,IOC和AOP的一个应用层的框架，主要做了切面和bean的依赖管理。
SpringBoot实现了自动配置，降低了项目搭建的复杂度
独立运行的Spring项目
提供starter简化maven配置
免XML复杂而冗余的设计思想
③、RPC调用Dubbo与SpringCloud
网络协议支持
SpringCloud 使用Http协议的REST API，HTTP还要建立连接所以比较麻烦。
Dubbo支持各种通信协议(部分采用epoll的通信协议性能更高）：对应的性能可能会高点
④、组件运行流程
SpringCloud,统一通过API网关Zuul,注册中心(Eureka),Ribbon进行负载均衡，微服务之间通过fegin进行通信处理业务
提供Gateway网关，Gateway通过Dubbo提供的负载均衡 机制自动完成，服务注册在ZK上面，配置中心可以用阿里的diamond。
⑤、持久层选择Mysql和Redis
⑥、本地持久化选择LoadingCache
⑦、消息中间件 选择阿里系RocketMQ
RocketMQ的消息写入内存后即返回ACK,由单独的线程专门做刷盘的操作，所有的消息均是顺序写文件。
在阿里集团被广泛应用于交易，充值，流计算，消息推送 ，日志流式处理，binglog分发等重要场景。
