课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
我们在上文中给大家简单分析了关于微服务技术在软件重构上的一些优势,而今天我们就再来聊聊微服务在实施过程中会遇到的问题都有哪些。
Q1:请问在实际使用时,前端网关有什么来源框架,还有分布式跟踪系统,有推荐吗?
A1:前端网关,开源的有WSO2,基于Java语言的,GO语言的有Tyk。
Q2:能展开讲一下优先级调度么
A1:分布式跟踪系统打印埋点日志比较简单,但是复杂的是后端的大数据分析。采集可以基于FLume等,后端的分析可以基于HBaseSpark
Q3:请教一下,对应用层扩容很容易,很多时候一个服务慢了,根本原因是依赖的存储数据库外部接口的原因,这个时候对应用层扩容解决不了问题,paas的扩容还有什么意义呢?数据库扩容涉及数据迁移,应用层连接池更新等等paas不能简单扩容
A3:PaaS层的扩容通常会有几种策略:
1、基于资源使用率的扩容;
2、基于服务性能指标的扩容;
3、混合模式;
4、业务自定义扩容策略,这种场景通常是级联扩容,也就是应用依赖的服务也需要同时做扩容,例如缓存、MQ等。但是,不是所有的PaaS都支持策略4。
Q4:怎样从传统的系统转化到云服务上,在系统设计及技术架构有什么需要注意点。
A4:不知道你讲的传统系统是不是指的非云系统。非云应用转到云化服务有几点设计考虑:1、服务化;2、利用云的动态性,例如弹性伸缩等;3、统一配置,使用云化的统一配置服务。
Q5:那mq缓存数据库的client都要改造支持后端自动发现了,好多中间价的client都是配置死的,有可分享的开源实现么
A5:包括前端的URL地址,MQ服务端的URL等,云化之后,MQ等服务也是一种云化服务,例如AWS的S3服务。在我们的实践中,原来的本地配置都统一放到了配置服务上,它是基于ZK的云化统一配置服务,地址都是从注册中心读取的,而不是本地配置。这样,就可以支持动态发现。
Q6:应用服务化后,涉及服务与服务之间的远程rpc,请问数据传输过程中一般采用哪种系列化方式,之间的优缺点都有哪些?还有场景
A6:几种场景考量:1、如果服务看中的是标准化、开放性,对性能要求不是特别苛刻。则建议采用RestfulJSON的方式;2、如果是内部各模块之间的服务化调用,对性能、时延要求非常高,则建议采用二进制私有协议的方式,例如可以参考或者选择ProtocolBuf、Thrift等。通常而言,服务跟协议是解耦的,也就是说某个服务,可以同时发布成多种协议。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!