一起学习微服务和容器2-微服务的框架

简述 前情回顾 在前面的小节中,我们大致了解了微服务体系结构的一些基本概念和理念,额外再啰嗦句,还请大家留意最重要的两点:DDD设计模型以及微服务的12原则。接下来的这篇文章将就常见的微服务的框架给大家简单介绍一下,让大家对微服务的体系结构有进一步的理解。
微服务技术栈的发展 有了前面章节的描述,相信大家也都了解,微服务很大程度来说是从SOA的体系结构演进而来的新的分布式体系结构。那SOA的相关的技术栈,在微服务的世界里面也会被继承以及迭代发展。
【一起学习微服务和容器2-微服务的框架】现下的社会是信息爆炸性发展的时代,在现下的现实社会中,特别是2000年以后这一二十年中,无论是国内还是国际上,社会的各个行业得以飞速发展,其中以金融,电信以及互联网和智能制造为代表。
行业的发展,对信息化的支撑提出了一层又一层新的要求;而信息化的发展反过来又促进了各个行业的大发展。
提到软件的体系结构,不得不说目前最最炙手可热的互联网行业,如果说过去的软件体系结构的发展和迭代以对信息化依存较高的金融和电信行业为主导,步入互联网时代之后,互联网行业的发展也慢慢的从金融和电信行业接过接力棒,引领软件体系结构的下一个大发展。
截止到目前为止,微服务的体系结构的思想最先提出并沉淀的是从互联网行业,业界常见的微服务体系结构的落地实践也是来源于互联网行业。当然这并不是说传统的行业对技术敏感度不高,从某种程度上来说,也是业务要求以及相应的技能要求侧重点不一样罢了。这个话题扯开来比较长,在此就不多累述,同学们如果感兴趣,我们可以在群里面进行探讨,估计得说个三天三夜。
微服务框架 闲话少叙,目前业界最常见的微服务体系结构大概有以下这几种。
Spring Cloud 1.0 Spring Cloud1.0 源于NetFlix(美国最大的在线视频服务网站,从最初租碟卖碟起家,现在硬生生的发展为相当NB的视频服务提供商也是技术服务商,发展路线感觉跟亚马逊有点点像,亚马逊刚开始的主业是网上卖东西,现在...,现在好NB的科技公司。)开源的微服务框架,后来贡献给Spring基金会(NetFlix还在维护自己的开源版本)。Spring基于NetFlix对其进行了封装,这是Spring Cloud1.0。
参考下图,可以看出Spring Cloud的各个组件是如何协同工作的。

一起学习微服务和容器2-微服务的框架
文章图片
image.png 其中以下几大组件来源于Netflix:

  • Spring Cloud Eureka。
  • Spring Cloud Zuul。
  • Spring Cloud FeignClient(Ribbon)。
  • Spring Hystrix
  • Spring Hystrix Dashboard。
Dubbo 相信国内的小伙伴们对Dubbo应该都不陌生。因为它是阿里巴巴开源出来的。从它开源出来的那一刻就被赋予了极大的光环,阿里的业务以及并发量可以说在国内是首屈一指,它不NB谁NB,也因此国内其它的互联网公司无论大小都开始像阿里看齐,将自己的体系结构开始重构调整。值得一提的是,Dubbo已被Apache基金会收录,并处于孵化中,期待剥茧成蝶的那一天吧。
参考Dubbo官网所提供的Dubbo的架构图如下:

一起学习微服务和容器2-微服务的框架
文章图片
image.png 对于这个图,对于大家理解它的工作原理有点虚,自己结合demo又整理了一个图,还请大家参考下。

一起学习微服务和容器2-微服务的框架
文章图片
image.png Spring Cloud2.0 为什么我把Spring Cloud2.0和Spring Cloud1.0区别开来,是因为,在Spring Cloud2.0中,Spring基金会对微服务体系结构进行很大规模的重构。
  • 其中最大的一点,在于Spring Cloud2.0中Spring Cloud抽象出了微服务的方法论,也可以称之为思想,换句业界的人话来说,就是类似于Java世界里面的interface概念。
  • 除了概念外,Spring Cloud也提供了自己的部分实现(比如说Spring Cloud OpenGateway,Spring Cloud FeignClient),除此之外,NetFlix的各个组件,从Spring Cloud1.0中担大梁,降格为Spring Cloud思想的其中一种实现,以Spring Cloud-Netflix存在。
  • Spring Cloud2 是基于Spring Boot2的实现,开始引入WebFlux等Reactor模型,支持非阻塞的网络通信,并发性能比Spring Cloud1.0提升不少。
  • 除此之外,我们的阿里巴巴也开始融入Spring Cloud的世界,遵守Spring Cloud的思想,开源出了自己的Spring Cloud-Alibaba。意外不意外?

    一起学习微服务和容器2-微服务的框架
    文章图片
    image.png
ServiceComb 类似于Dubbo,该框架来源于国内的另一个巨头-华为。从某种意义来说,华为由于是传统的电信服务提供商,随着微服务体系结构的普及兴盛,特别是基础设施云化、容器化,国内的电信服务商以及金融行业,按照工信部以及相关监管部门的要求,国内的电信和银行企业也开始推进体系结构的转型,微服务化和容器化。华为主要是为企业提供相应的解决方案,配合华为的IAAS+PAAS+MicroService战略,进行企业信息化的转型支撑。
ServiceComb也是一种RPC的框架,只是在国内的号召力比阿里的稍逊,加上开源的比较晚,互联网企业普及度寥寥,不过对于和华为有合作的电信或者金融行业应该还好。
该RPC框架也被Apache基金会收录,也处在孵化中,也期待会有出壳的一天吧。
由于本人对ServiceComb没有太深的了解,网上也没找到比较容易理解的清晰的技术架构图,暂时不提供其工作原理架构图了,如有感兴趣的同学,可以百度Google一下。
Tars 随着近几年国内的大企业也越来越认识到,技术的开源不仅仅可以提高公司的逼格,更可以从某些方面带来很多软实力的提升,各个有点体量的公司,开始拥抱开源。作为国内互联网行业的扛把子-腾讯,怎么能甘于人后,2017年开源出了自己的微服务框架Tars。
Tars也是一种RPC框架,使用Tars协议(腾讯自己的协议,类似于Dubbo的Dubbo协议,不过实现机制不同),同时配套一体化的服务治理平台,帮助个人或者企业快速的以微服务的方式构建自己稳定可靠的分布式应用。
Tars最大的优点在于提供了一体化的服务治理平台,这点跟Spring Cloud有一拼。只不过由于Tars最早发源于C++相关的技术栈,后来对异构的支持也逐渐丰富,采用类似于Corba的IDL语言定义RPC接口定义,同学们有兴趣可以自己尝试下,也是一个不错的框架平台,只不过文档的丰富度有待进一步提高,排查框架级别的问题最好要了解C++/Go等语言。
从Tars的官网拷贝过来的技术架构图,还请大家参考下吧。【声明:如有版权问题,还请留言,会删掉】

一起学习微服务和容器2-微服务的框架
文章图片
image.png 腾讯的这个图也不错,也拷贝过来吧,供大家理解。

一起学习微服务和容器2-微服务的框架
文章图片
image.png ServiceMesh 根据William Morgan(Linkerd CEO)定义,Service Mesh是用于处理服务间通信的基础设施层,用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。说白了ServiceMesh就类似于在微服务之上增加了一个通用壳,这个壳来替代微服务实现服务的注册发现,心跳的传递,以及接口的访问,再简单点,这个壳就类似于一个代理,把服务治理层面的任务做了,顺便屏蔽了服务之间的差异化,异构化。
在实践中,Service Mesh通常是一组与应用一起部署,但对应用透明的轻量级网络代理。与传统基础设施层不同之处在于,它形成了一个分布式的互连代理网络,以SideCar形式部署在服务两侧,服务对于代理无感知,且服务间所有通信都由代理进行路由。
下图可以很好的说明Service Mesh的工作原理,在图中是单个Service部署在各自的宿主机上,实际上,单个宿主机可以分端口不说多个,或者引入容器部署。

一起学习微服务和容器2-微服务的框架
文章图片
image.png 基于这种理念,衍生出来的ServiceMesh技术有:
- SOFAMesh。这个框架是蚂蚁金服开源出来的ServiceMesh框架,在这里,不得不佩服阿里的能耐,该框架也是阿里的手笔,据说阿里内部还有一套自己在用的HSF。
  • HuaWei Mesher。华为开源出来的自研的Mesh。由Golang实现。
  • Motan Mesh。新浪微博使用的技术。也是Golang实现。
  • Linkerd。Linkerd 是一个实现了服务网格设计的开源项目。其核心是一个透明代理,可以用它来实现一个专用的基础设施层以提供服务间的通信,进而为软件应用提供服务发现、路由、错误处理以及服务可见性等功能,而无需侵入应用内部本身的实现。
    它作为独立代理运行,无需特定的语言和库支持。应用程序通常会在已知位置运行 Linkerd 实例,然后通过这些实例代理服务调用,服务连接到它们对应的 Linkerd 实例,并将它们视为目标服务,由Twitter公司贡献。
  • Istio。Istio提供一种简单的方式来建立已部署服务网络,具备负载均衡、服务间认证、监控等功能,而不需要改动任何服务代码。
    想要为服务增加对Istio的支持,您只需要在环境中部署一个sidecar,使用Istio控制面板功能配置和管理代理,拦截微服务之间的所有网络通信。貌似目前只支持Kubernetes容器化的部署,由 Google、IBM 等公司贡献。
截止到此,我们初步了解了下现下比较流行的几种微服务的框架,接下面的章节里面,我们将就Spring Cloud,Dubbo, Service Mesh(Istio)进行详细展开。其它的框架,同学们有兴趣,可以自行去研究下,思想大致都差不多。
我们下一节将进入Spring Cloud的世界,Are you ready?
【声明:本文中,有引用网上的架构图,如果有版本问题,还请留言。如果同学们要引用本文,或者本文中的图片,还请注明出处!】
欢迎各位同学加入QQ群145979969,进行讨论。

    推荐阅读