技术选项
前两篇文章主要分析了微服务是什么,并且简单总结了前人使用微服务思想开发时所遇到的、提出的一些共性的问题,以及解决方案。
大公司总是有自己的实践,虽说微服务思想是一致的,但是由于各自业务场景的不同(很大程度是因为不同的人开发的),各自都提出了自己的微服务解决方案。开源方案中主要是两类:
1、spring cloud Netfix (国外奈飞开源的)
2、spring cloud Alibaba(国内阿里开源的)
比较起来,其实两个框架都是各自公司的工程实践,也没有什么优劣之分,阿里的方案中,有用dubbo做内部的服务调用(dubbo也支持rest风格远程调用),从这一点上来说,微服务内部的调用性能要高很多。
为什么说dubbo性能高?
1、dubbo使用netty和mina做网络通信层,而netfix中采用rest调用,可以简单认为dubbo使用TCP协议,而netfix使用HTTP协议。从网络分层来看HTTP处于应用层,而TCP处于传输层,显然传输层更快。
dubbo是什么?
1、dubbo核心是一个面向接口带来的高性能的RPC远程调用,虽然它自身还有服务注册发现,负载均衡等能力,但我们可以不必讨论它的这些能力
但是实际上,多数的应用达不到阿里的业务量,使用dubbo RPC会耦合业务系统,且在异构系统中无法调用。而rest HTTP方式则更符合面向服务的思想,服务间解耦,且简化开发。
总之,选哪种都可以。符合自己的业务或者团队的就OK,甚至你可以自己开发一套微服务架构,这并不难,只是你可能需要考虑到成本问题。
下面,我们使用spring cloud Netfix这一套框架来实践一下。
github地址:
https://github.com/YRM2/springcloud-rm
再写吧,明天要早起
说好的早起没实现,早上一睁眼已经7点了(手动狗头)
代码在github,具体来讲一下:
注册中心使用Eureka
配置中心使用spring cloud config
网关使用zuul
服务间负载均衡使用ribbon
本来想写一个完整一些的项目,但是一时想不到具体的业务,所以目前只有不涉及业务的实现