假设接下来我们公司要把财税的项目改造成微服务架构,接入注册中心,熔断器什么的,整成微服务架构!用java里的spring cloud那些组件来做,有没有问题?
这时就有一个大大的问题!财税系统中有的应用零几年用pb开发的,还有不少是.net写的!怎么接入那些java的注册中心、熔断器啊…
接下来自然就是了解一下边车(SideCar)。
Sidecar这个词中文翻译为边车,或者车斗,也有一个乡土气息浓重的翻译叫做边三轮。通俗来讲:就是如果只是单独一辆自行车只能坐一个人,可以给自行车加一个边车(SideCar),扩展一下现有的功能。像下边这样:
Sidecar这个东西出现的时间挺长的,它在原有的客户端和服务端之间加多了一个代理。其实这个模式在微服务中也可以用的!我们给财税应用做一个代理,然后呢,服务注册、鉴权、限流啊…这些功能都做在代理里,然后呢我们不要直接调动财税应用,调的是财税应用的代理,这里代理就是所谓的边车(SideCar),大概部署图是下面这样的!
要将一个应用改成微服务架构,基本有两种方式:
- 以改FrameWork的方式,直接在原来的项目代码里头进行修改!
- 以边车(SideCar)模式的方式,通过边车(SideCar)进行转发请求!
边车(SideCar)模式这种方式,不仅对原来的应用代码零侵入,而且不限制原来应用的语言,特别适合我们公司这种好几种语言异构微服务的场景!另外,以后你的边车(SideCar)要升级了,是可以独立升级的,不用重新打包原来的应用!还能解决下面这些我们不得不面对的诸多现实。
像表中的这些现实,首先,我们的业务开发团队的强项是什么?最强的会是技术吗?不,通常来说我们的业务开发团队最强的是对业务的理解,是对整个业务体系的熟悉程度。 第二个事情,业务应用的核心价值是什么?我们辛辛苦苦写了这么多的微服务,难道是为了实现微服务吗?微服务只是我们的手段,我们最终需要实现的是业务,这是我们真正的目标。 第三个事情是,就微服务这个手段而言,有比学习微服务框架更艰巨的挑战。在做微服务的真正落地时,会有更深刻的理解。比如微服务的拆分,比如要设计一个良好的API,要保持稳定并且易于扩展,还有如果涉及到跨多个服务的数据一致性,大部分团队都会头疼。最后是康威定律,但凡做服务的同学最终都会遇到这个终极问题,而大多数情况下是欲哭无泪。
但是这些还没完,比你写一个新的微服务系统更痛苦的事情,是你要对旧有的系统进行微服务改造。所有这些加在一起,还不够,还要再加一条,这条更要命:业务开发团队往往业务压力非常大,时间人力永远不足。说下月上线就是下月上线,老板是不会管你有没有时间学习spring cloud的,也不会管你的业务团队能否搞得定微服务的方方面面。业务永远看的是结果。
利用SideCar模式,可以把财税软件改成微服务架构,听起来是不是很完美。具体怎么实现可,Spring Cloud Netflix Sidecar框架提供了Sidecar模式的现成解决方案。
Spring Cloud Netflix Sidecar 包含一个简单的http api来获取给定服务的所有实例(即主机和端口)。然后可以通过从Eureka获取其路由条目的嵌入式Zuul代理来代理服务调用。可以通过主机查找或通过Zuul代理访问Spring Cloud Config服务器。但是第三方程序必须执行健康检查(服务心跳检测),以便Sidecar可以根据应用程序启动或关闭时,向eureka报告。
使用步骤:
1.需要一个第三方的程序,可以是python,nodejs,php,.net等一系列非java语言编写的程序,也就是非微服务架构的老系统。
2.第三方程序(老系统)提供health接口,接口返回json格式的字符串
3.创建sidecar项目
<1>引入坐标依赖
<2>配置文件
<3>编写启动类,添加@EnableSidecar注解
经过上面的几步sidecar的操作,服务已经可以正常启动,并且可以代理第三方有效服务,注册到注册中心,进行不同语言服务间的相互调用;
思考一个拓展的问题:能不能给所有的微服务都搭一个边车(SideCar),然后用一个平台将边车(SideCar)管理起来,像下面这样:
答案当然是可以的,这就是云原生里火热的服务网格(ServiceMesh)模式。
先从概念上看下服务网格,下面是 Willian Morgan 对 Service Mesh 的解释:
如果用一句话来解释什么是 Service Mesh,可以将它比作是应用程序或者说微服务间的 TCP/IP,负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层(比如通过 HTTP 协议的 RESTful 应用),同样使用 Service Mesh 也就无须关心服务之间的那些原本通过服务框架实现的事情,比如 Spring Cloud、Netflix OSS 和其他中间件,现在只要交给 Service Mesh 就可以了
Service Mesh 的架构如下图所示:
Service Mesh 有如下几个特点:
- 应用程序间通信的中间层
- 轻量级网络代理
- 应用程序无感知
- 解耦应用程序的重试/超时、监控、追踪和服务发现
可以说Service Mesh 并没有给我们带来新功能,它是用于解决其他工具已经解决过的问题,只不过这次是在以 Kubernetes 为基础的云原生生态环境下的实现的。
带来的好处也是巨大的
第一,Service Mesh为业务开发团队带来的变革:降低入门门槛,提供稳定基座,帮助团队实现技术转型。最终达到的目的是,让业务开发团队从微服务实现的具体技术细节中解放出来,回归业务。
第二,是对运维管理团队的强化,这里如果有做运维的同学,你们可以认真思考一下:如果有了Service Mesh,你们对系统的管理和控制力会有多大的?注意很多功能的实现已经不再和应用有关,都在移到Service Mesh中,而Service Mesh通常是在运维的掌控中。
边车模式(Sidecar)对应用加了一个代理,扩展现有的功能。实现了应用与底层平台之间的松耦合;
在云原生架构下,技术栈可以是多种多样的。无论是如何能够将公司的传统服务架构改成微服务架构,以及如何将这些异构的服务组件串联起来,管理好。Sidecar模式都有很好的使用,产生了像方便旧系统进行微服务架构改造的Spring Cloud Netflix Sidecar中间件,提供有如负载平衡、服务发现、流量管理、熔断、遥测、故障注入等许多功能的Istio服务网格。
Sidecar设计模式已经越来越受欢迎,并在社区内得到更广泛的采用。