目前我们处在微服务+容器的转型探索时期,在微服务框架架构方面,想咨询一下,银行互联网这块的业务,未来框架发展趋势是dubbo还是spring cloud或者是services mesh?针对银行业务,那个技术更适合?
第一、微服务+容器在探索期,我认为两个应该分阶段拆分做,第一阶段,高微服务,第二阶段再搞容器。
第二、spring cloud 和Dubbo 是实现微服务的两种手段,未来发展前景个人看好spring。针对银行业务场景我没具体实施过,所以不好评价
银行的网络和应用场景的特殊性,所以不推荐用services mesh,虽然services mesh目前也很火。框架发展趋势是dubbo还是spring cloud,这个各有利弊,spring cloud个全家桶啥都全,但是真正能用好的并不多,无非是组件的堆叠。dubbo也从阿里自己运营转向apache国际化方向,目前互联网大部分公司都是使用dubbo框架,遇到问题也能通过社区快速解决,响应效率比较快。
收起如果对性能有强要求,建议使用dubbo,如果没有强要求并且对生态要求比较高,建议使用spring cloud。services mesh是负责解决微服务中底层基础设施的功能,和业务无关。
收起先容器化,再考虑微服务,CNCF的Cloud Native Trail Map也是这么推荐的。
至于微服务的选型,目前ServiceMesh还达不到大规模生产环境使用的条件,主要是性能损耗,你能否接受Enovy 30%的请求转发损耗?
至于SDK模式的微服务框架,如dubbo与spring cloud,前面已经有同事推荐了,spring cloud生态最好,但是比较厚重。最近华为开源了一个框架ServiceComb,比较轻量,也可以关注一下。
收起纯粹微服务开发,不考虑服务线上运维的要求;spring cloud是首选,组件多,生态好。
基于通信延迟要求较小的情况下,采用rpc协议比http协议通信要好一些,dubbo占优势
service mesh是解决服务通信的基础设施,本身与微服务无关。
如果考虑容器化的方式部署,spring boot+kubernetes+spring cloud部分组件会更好一些,可以有效的减少组件依赖以及链路调用关系