暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

聊聊单体服务VS微服务系统

IT分享 2020-03-20
904

简介:单体服务和微服务系统的优缺点

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分发等重要场景。

文章转载自IT分享,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论