微服务引擎 MSE:打造通用的企业级微服务架构

本文涉及的产品
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
密钥管理服务KMS,1000个密钥,100个凭据,1个月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 微服务引擎MSE致力于打造通用的企业级微服务架构,涵盖四大核心内容:微服务技术趋势与挑战、MSE应对方案、拥抱开源及最佳实践。MSE通过流量入口、内部流量管理、服务治理等模块,提供高可用、跨语言支持和性能优化。此外,MSE坚持开放,推动云原生与AI融合,助力企业实现无缝迁移和高效运维。

微服务引擎 MSE:打造通用的企业级微服务架构

 

内容介绍:

一、微服务技术趋势以及挑战

二、MSE微服务引擎打造通用企业级微服务架构

三、MSE拥抱开源,坚持开放

四、MSE最佳实践演示视频

 

MSE微服务架构分四部分进行讲述,第一部分,分享整个微服务的技术趋势以及这些趋势衍生的挑战;第二部分,在MSE上面应对这些挑战做了哪些的场景和思考;第三部分,应对开源的思考和沉淀。最后是我们整个场景上面的最佳实践。

 

一、微服务技术趋势以及挑战

1、微服务的发展趋势

微服务全景图现在比较流行,是微服务架构的一个最佳实践。面向微服务的发展趋势,整体上面有三个方向。第1个方向是标准化,标准化主要体现在两个方面,一方面在于整个架构上面的分层,这个分层是逐步在标准化,我们有整个的数据层、治理层、控制面、运维面,是这一层的标准化。

第二方面在于整体选型,在技术选型上,基本上大家趋于一致,这里面会考虑到软件的维护以及整个架构整合的联通性,考虑到这些整体的软件选型的成熟度。第2个方向是多元化,在生活过程、工作过程很多场景上面都融入了AI,产生了语言体系是不是要整体换掉或者把自己的语言体系加入进来的问题,这里面涉及到多语言架构的趋势。

第3个是高可用的趋势,高可用一直都很重要,很多高可用的事件包括一些场景、火灾等,在这些场景怎么能保证业务的高可用,是现在考虑的一个重中之重的选择。

2、微服务挑战

应对于这三个趋势,有三种类型的挑战。第1个挑战就是本身维护成本高,在整个开源维护的过程当中,开源维护的场景选择了标准化,但是开源的软件它根据企业本身的诉求,这里面包含比如运维的场景、使用的性能是不是匹配。

第2个挑战是跨语言复杂度高,比如原本是Java的体系栈用的很好,现在要拥抱AI,Java也可以用,但还有一些场景要考虑用Python,这里面可能一个语言有一套技术栈,中间怎么把这些技术栈做互通是一个复杂度比较高的事情。

第3个挑战是高可用改造的代价高,很多软件在诞生的过程以及业务的运行过程当中,刚开始高可用的点考虑的比较少,后面去做高可用改造的时候,改造成本是比较大的,可能涉及到整个业务、整个全链路。以上三个挑战其实是一个三高的挑战。

 

二、MSE微服务引擎打造通用企业级微服务架构

1、通用的企业级微服务架构-流量入口

MSE针对于三高的问题的一些思考主要分两方面。一方面是通过流量的视角,去看各个组件怎么去应对三高的问题。另外是MSE为用户能额外带来的一些东西。第1点就是站在流量视角,流量最重要的就是入口,网关是整个流量的入口。在考虑流量的时候,很多时候可能会遇到一个场景,就是现场排查问题,应用好像有一些异常的流量,但发现网关没有问题,网关的流量都是正常的,排查许多发现就是一个定时任务在跑,这个定时任务不停的发起流量。这个其实就是一个任务调度的业务场景,阿里在任务调度的这块有一款产品SchedulerX,这个产品是阿里内部的,并且在云上也有很多的用户,云上还有一些用户他们在这个场景里面选择了XXL-Job,这个产品在云上应用的比较广。

微服务引擎MSE发布任务调度XXL-Job:使用XXL-Job可以平滑零改造的迁移到MSE上来,关于三高挑战在任务调度上面的思考有以下几点,首先第1点在于开源维护,XXL-Job有两个核心痛点。第一个痛点在于本身的性能,XXL-Job本身的性能在开源上面,要调的很好比较麻烦,我们在这个点上面做了突破,我们基于SchedulerX它本身的内核拓展了XXL-Job的协议。百分百兼容开源的协议场景下,做到了整体的性能翻倍。

XXL-Job还有一个问题是在于它整个发展链路比较长,版本也比较多,不同的版本还不兼容,在过程当中如果升级了版本,可能还需要改代码。我们整个MSE的XXL-Job是不需要改任何代码的,任何的版本的XXL-Job都可以平滑地迁移到我们MSE的XXL-Job上。

这是我们开源维护上的一个思考。第2个是跨语言的架构,我们XXL-Job整体兼容了开源的协议,对应的客户端上面有一个多语言的多sdk。第3个就是高可用上,在高可用上XXL-Job是默认的,做到了3AZ以及数据是多备份的,并且有整体的防护能力,能帮助大家把在任务调度上面的高可用提升上来。

2、通用的企业级微服务架构-内部流量

内部流量的应用流转时,最核心的是注册中心,注册中心是帮助流量进行寻址的,额外是配置中心,配置中心是辅助管理整个应用集群的,整个应用集群里面动态信息都通过配置中心管理。注册配置中心在MSE里面有Nacos、Eureka、zookeeper。这块回到我们三高挑战,在开源维护,MSE的注册配置中心是全自动化的运维,注册中心一般都是有状态的,这个状态的集群运维是比较复杂的,我们把这一层完全屏蔽掉了。

再一个是整体的安全防护,因为注册中心、配置中心里面存的信息比较机密,不能泄露,但没有一个开源软件不会有漏洞的,有漏洞就要及时去修,MSE可以提前通过最佳实践的方式避免掉这些问题,并且能做到一个整体的热更新,在大家能看到漏洞之前就已经把它修复掉了。

第二在于跨语言的架构,主要有两点,一点是在于本身的生态,Nacos的生态支持整个的全链路、能看到的主流语言。另一点是针对于注册中心的场景里面,可以把多语言的不同框架串起来,支持跨语言的服务注册。

最后最重要的一点就是高可用,注册配置中心的高可用是比较重要的,它断联了之后可能整个链路都会断掉,在我们的场景里面涉及到了多机缓存,保证了整个服务在任何的故障场景,把它的缓存做好之后,整体的链路可用。我们做了比较多的反脆弱的能力,可以帮助我们应对一些突发的场景。

3、通用的企业级微服务架构-服务治理

流量的终态场景是流量要被控制,流量在它整个运行的过程当中,很多时候可能会出现一些异常的场景,需要通过一个好的方式把流量控制起来,有一个通用的模块服务治理可以达到很好的效果。针对于这个领域,服务治理不仅仅控制流量,它本身面向的是三态,这三态又包含整个应用的开发态、变更态、运行态,整个应用的全生命周期来做治理。

MSE的服务治理可以做到整个应用的测试以及环境隔离,在变更态上可以做到整个全链路的灰度以及服务的上下线。在运行态可以做到整体的流量防护,并且能做到整个的同城多活。整体上服务治理其实面向应用就是在做高可用的,三高挑战里面的高可用就不用考虑了。另外在开源维护上面,服务治理是面向于整体的无侵入的零介入,就是用户的应用不需要做任何的网络改造,也不需要做任何的流量改造,默认集成进去服务治理的能力。

4、微服务引擎MSE发布Golang服务治理

多语言架构这块有点挑战,因为本身我们的服务治理原来只支持一个Java,我们调研了整体用户的需求,发布我们Golang语言的服务治理。MSE发布Golang语言的服务治理是拉起java的治理能力的,Golang语言的治理包括了gin、grpc以及现在主流的Golang语言的框架,都可以进行一个整体的治理。

还有一个额外的能力就是不仅能去治理Golang架构还可以把Golang和我们现在的Java的服务治理以及我们开源的Java串联起来,包含多语言上面比如sdk开源的这部分都可以集成进来串联到Golang agent治理的链路里,也能串联到存量的Java的治理上面。基于统一的服务治理的控制面下发规则让整体的流量串联起来,拉起服务治理的能力。

5、微服务引擎MSE:通用的企业级微服务架构

MSE通用的企业级微服务架构包含了刚才介绍过的这些产品:网关、服务治理、注册为中心的任务调度。这块围绕着应用给应用做加强,包含了本身的性能以及高可用还有serverless的能力,serverless的能力其实在于大家看到的有状态的组件,使用的时候直接使用服务就可以了。安全方面面向开源或者用户全面的产品领域上面能构建哪些能力呢?默认给用户做三个方面的增强。

第1个方面增强就是做到默认的高可用,第二方面是做到默认的安全零信任,最后是所有的组件做到默认的性能翻倍。默认是指应用不需要改造就部署上来或者接入上来,整体的能力做到一个增强。

(1)默认高可用-全域灰度升级

在研发态、变更态、运行态中,高可用真正有问题的时候变更态的问题是最核心的。因为统计出来80%的故障都是由变更态导致的,如何控制变更的风险最核心的一个点是在于灰度。介绍一下全链路灰度的升级版全域灰度,全域灰度的升级包含了什么呢?一方面前端的流量也能进行了一个灰度,通过流量把前端里面的流量带上灰度标,之后他去选择到灰度到的前端文件再到我们整个的应用、我们全链路的灰度。

我们可能有比如100个应用,这次变更只涉及到50个应用,那这50个应用会因为灰度的能力把它串起来验证上线有没有问题,并且还可以逐步扩展流量,它其实从0到100的过程是逐步变更的,在这个过程当中还有一次发布。

比如说一个应用上线的时候,不仅应用要变,前端、配置也要变,这次发布的应用,里面涉及到一些配置要变,这些配置在发布的过程当中我们这个能力也可以跟着应用的灰度一起上线。并且里面不仅有我们的配置,还有我们的任务,比如我们任务调度的过程当中让这部分灰度发布的应用的节点能感知到这些任务。消息在过程当中很多都是同步的,异步的链路层面也可以做到一个灰度。

整个的全域灰度,就是从前端到后端,再从同步链路到异步链路,再从配置到任务,都能做到灰度。应用开发的过程当中,面向于场景,可以把灰度逐步做起来,灰度有一个最核心的点是在于可观测,灰度的过程流量落在灰度的节点上,灰度的变更太少。它有没有问题是很核心的,全域灰度把整个可观测串联起来了。整个的灰度的流量,它的成功率、rt跟线上普通的流量、rt以及错误率内存的占比,都可以一眼看出来差异。

(2)默认高可用-零改造实现应用同城多活

运行时上面很核心的点在于容灾。运行时出现故障,整个az出问题了之后容灾怎么办?涉及到比如全整体做容灾,首先考虑缓存的异步,但站在全局的角度去看,其实容灾涉及到同城多活和异地多活。针对于业务,首先建议做同城多活,因为异地多活是一个业务架构,这里面变更很多的业务代码,要做异地多活之前一定要去做同城多活,因为这个可以很便利地把应用的能力提上来。

对于同城多活MSE的思考在于同城多活在同一个地域里面有多个可用区、多个az,az基于MSE的流量管控可以做到网关流量的秒级的切除。也就是说网关的节点出问题了,可以秒级的把这个网关的节点切除掉。网关的流量达到了应用,应用的一个节点有问题,也可以秒级的剔除掉,因为有秒级的探测。在这个过程当中,它部署在region,有多个可用区默认是互串的,服务治理可以帮助应用做到无感的同az优先,同az优先可以让它的流量直接在az内封掉了,不需要跨az去调用了。

真正出问题的时候,这种场景里面对他基本是无损的,另一方面同az优先对业务的rt也会有提升。再往下在于底层的基础设施层,基础设施层涉及到的就是注册配置中心以及任务调动。注册配置中心在MSE里面默认有三个可用区,任何的一个可用区去故障都可以容忍,nacos任何两个可用区故障了也可以容忍。三个可用区故障两个,nacos的协议也可以保证整体的服务以及注册可用。整体上面默认的高可用是在于应用只要按照我们的场景去做介入,不需要做额外的代码改造就可以具备整体同城多活的能力。

(3)默认安全零信任-企业级安全能力构建

网关能切割的外部流量和内部流量,在网关上面可以做统一的收口,网关也包含了认证鉴权以及消费者鉴权,还有buff和防护能力。再往下是mtls的零信任全链路的传输加密,这个传输加密可以基于应用层的打包能力以及注册配置中心底层的能力能达到整个传输过程当中全部都是tls的。这里面值得一提的是配置,应用的配置是很关键的,配置包含应用的数据库密码和各种各样的场景,比如ak、sk,MSE nacos提供了一个把这些重要的东西存上的方式,就是配置加密,配置加密可以做到一个无感的加密。配置存在nacos里面本身是明文的,可以单独创建一个配置,并且把配置做一层嵌套,在不改代码的情况下,把敏感信息做一层加密。

(4)默认安全零信任-无感安全能力增强

安全零信任有一个无感安全能力的增强。本身针对开源协议的兼容,做到默认的安全的最佳实践,这里面会最大程度上避免安全的问题,也就是我们本身就已经把这些问题避免掉了。如果开源软件出了问题,因为本身对于开源的领域是最先的,可以最广大面的收集到开源的漏洞,在这个场景里面的话,识别到这些问题会快速的进行修复,我们本身的修复是对用户无感的。

通过热更新的方式,把安全加固的能力放到线上去,用户在这个过程当中,他不需要重启,也不不会感知到连接的断开,用户默认把这个能力提上来了。整体上面安全的风险可以做到一个自愈。

(5)默认性能翻倍-MSE比开源性能最高提升3倍

网关也有提到,我们的能力相比于Nginx提升了一倍。基于8代机的场景下,GZIP的性能默认最高提升三倍。应用层最近开始发布了Double3.3,3.3版本的triple现在非常成熟,triple相比于原来的Rest这种场景的调用,性能默认提升了两倍。

MSE的nacos相比于开源的nacos,性能是提升了1到3倍,最核心的推送能力方面,整体优化了内核,优化了推送的引擎,在这个场景里面,性能是提升了三倍。最后是xxl-Job相比于开源优化了调度算法,以及基于SchedulerX的本身能力,整个性能提升了一倍。所以默认接入MSE,它的性能就默认翻倍了。

(6)微服务引擎MSE:打造通用的企业级微服务架构

通过网关把流量引入进来,做一个防护,并且在高可用场景上面,把服务引擎做到一个能力的赋予,应用可以默认的支持整体的高可用。再到底层的底座,注册配置中心以及分布式调度zk以及任务调度的场景做一个整体的加强。一方面兼容开源标准,另一方面是跨语言的生态能做到包括Golang、Java以及其他语言都能串通的能力。以上是现在的MSE具备的能力。

 

三、MSE拥抱开源,坚持开放

1、拥抱开源,坚持开放

代码怎么能被更多人使用,其实就是开源,开源能跟社区里面的人互相的讨论共建,做出来的东西能被更多的人接受认可,是一个非常进步的事情。MSE上整体的产品包含微服务的全景图,每年出达的开发者有上百万,这些上百万的开发者会关注、使用我们,并且一起参与进来。还包含get up的start树,刚突破了4万。刚发了一个pr宣传文章,nacos就在前两天刚突破了3万。

nacos突破了3万意味着在注册配送器这个领域它超越了Eureka、zookeeper以及众多这些领域的产品,我们在这个领域里面全球排行第一,是最受全球开发者关注的一个产品。开源共建方面有2000以上的核心贡献者跟我们一起去参与共建,所以针对于整个开源的场景,MSE或者团队的人都会持续的投入、拥抱、共建开源。spring AI alibaba是我们后面的方向,在于我们本身网关、网关的AI插件,翻译、拦截这些核心的AI能力能应用到场景,被更多的人所接受。之后是包含动态的变更,nacos的动态模板以及整个接入过程当中所有接入点的动态更新,再有同步异步消息的能力。spring AI alibaba会把全部能力都集成进来,帮助大家在AI的场景去做一个持续的增强。

2、云原生和AI原生

spring cloud alibaba和spring AI alibaba的关系,首先是在于spring cloud alibaba在整个国内以及国际上面有比较多的用户,这些用户沉淀了大量的场景,用spring cloud alibaba的时候都会选择我们的底层组件。AI里面最缺的就是场景。

我们把spring cloud alibaba的场景不停的注入到AI的场景里面去,针对于spring AI的体系,它其实就只能获得更多的场景,反过来spring AI体系面向于AI提供了智能,这个过程当中,会不停的赋于spring cloud alibaba体系一个智能化的能力。后面也会持续的去共建这两块的信息,并且帮助大家在实际的应用过程当中解决问题。

 

四、MSE最佳实践演示视频

欢迎观看全链路灰度效果演示,本次演示主要包括以下场景:场景一前端灰度,支持对前端页面灰度访问,同时与服务端灰度调用兼容。场景二多语言调用灰度,新增Go语言应用灰度,并且支持跨语言调用。场景三分布式调用灰度,分布式任务支持调度灰度节点,也与服务端调用兼容。场景四配置灰度,支持配置灰度发布与灰度订阅。

首先进行Demo说明,流量入口是云原生网关,网关一方面路由到一个前端应用,应用包含线上节点和灰度节点,一方面还路由到一个Go应用,Go应用会向后调用到Java应用。GoApp、JavaA、JavaB分别具有灰度节点,Java A具有一个分布式调度任务,该任务会调用一次Java B,Java B再调用Java C,Java A还接入了Nacos配置中心,监听并更新动态配置。

首先演示前端灰度,默认情况下,我们访问ICE Pro base基准线上站点,如果需要访问灰度站点,我们只需在请求中加入预先设置好的灰度条件,刷新页面后,我们从页面左上角看出已经访问了灰度站点。

接下来演示多语言调用灰度,我们在支持Java的基础上,新增支持了Go语言,并且支持跨语言调用,在治理中心开启全链路灰度,使用云原生网关发起服务调用。从打印的节点标签中可以看到,普通请求的每一跳都会路由到基准节点,再根据预定义的灰度规则,发起灰度请求,从调研结果可以看到,GoApp、Java A、B均路由到了灰度节点, Java c没有灰度节点,所以路由到基准节点,接下来我们关闭全链路灰度,再使用原来的灰度条件发起请求,结果是每一跳都只能路由到基准节点。

接下来演示分布式调度灰度,Java A接入了调度中心,拥有一个调度任务,我们的调度中心支持配置发往特定标签节点的任务,演示中简洁起见,我们手动运行一次灰度调度,运行成功后,前往Java A灰度节点日志中查看结果,可以看到灰度节点收到了调度,但后续链路却路由到了b的基线节点,这是因为我们还没有开启全链路灰度,开启之后我们再试一次,我们再次在控制台手动发起一次灰度调度,然后查看Java A灰度节点日志,这次我们看到灰度调用与后续的灰度调用就全部串联起来了。

最后演示nacos配置灰度,Java A监听了sc-A.properties中key为dynamicConfig的配置,当前值为default,为了方便观察配置的变化,我们在请求中把配置的值打印出来,首先路由到基线节点,我们通过结果打印看到配置的值为default,接下来我们路由到灰度节点再看一下,灰度节点中该配置的值也是default。接下来我们使用基于标签灰度发布方式,将配置的值从default修改为gray,点击发布后,我们看到灰度发布已经成功了。再次通过云原生网关将请求路由到灰度节点,我们发现配置的值已经从default变化为了gray,在路由到基线节点看一看,配置的值并没有发生变化,依然是default。

我们在将配置全量发布,发布成功后再次将请求路由到基线节点,可以看到基线节点的配置也已经更新。以上就是MSE全链路灰度演示的全部内容。

我们就是想要知道到底哪些场景我们是解决不掉的,其实它不是一个陈述句,是一个疑问句。会有很多的问题,一直在解决,一直在更新,一直在提升能力。经过了这么多年,站在现在这个角度。这句话后面应该再加一句,我们就想知道哪些场景是我们解决不掉的,解决不掉的这些场景我们会和我们的用户一起去解决。

相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
相关文章
|
3月前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
214 6
|
3月前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
85 1
|
2月前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
300 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
2月前
|
运维 监控 持续交付
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
552 36
微服务架构解析:跨越传统架构的技术革命
|
3月前
|
消息中间件 供应链 架构师
微服务如何实现低耦合高内聚?架构师都在用的技巧!
本文介绍了微服务的拆分方法,重点讲解了“高内聚”和“低耦合”两个核心设计原则。高内聚强调每个微服务应专注于单一职责,减少代码修改范围,提高系统稳定性。低耦合则通过接口和消息队列实现服务间的解耦,确保各服务独立运作,提升系统的灵活性和可维护性。通过领域建模和事件通知机制,可以有效实现微服务的高效拆分和管理。
87 7
|
3月前
|
JavaScript Java API
深入解析微服务的架构设计与实践
深入解析微服务的架构设计与实践
56 0
|
4月前
|
设计模式 测试技术 持续交付
架构视角下的NHibernate:设计模式与企业级应用考量
【10月更文挑战第13天】随着软件开发向更复杂、更大规模的应用转变,数据访问层的设计变得尤为重要。NHibernate作为一个成熟的对象关系映射(ORM)框架,为企业级.NET应用程序提供了强大的支持。本文旨在为有一定经验的开发者提供一个全面的指南,介绍如何在架构层面有效地使用NHibernate,并结合领域驱动设计(DDD)原则来构建既强大又易于维护的数据层。
58 2
|
4月前
|
存储 SQL 分布式计算
湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
【10月更文挑战第7天】湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
333 1
|
4月前
|
Java API 微服务
微服务架构:解密微服务的基本概念
微服务架构:解密微服务的基本概念
113 0
|
5月前
|
安全 应用服务中间件 API
微服务分布式系统架构之zookeeper与dubbo-2
微服务分布式系统架构之zookeeper与dubbo-2

热门文章

最新文章