国外酷炫网站有哪些,无代码网站建设,惠州网站建设方案外包,海淀青岛网站建设简介#xff1a; 2021年7月2日#xff0c;阿里云用户组#xff08;AUG#xff09;第一次线下活动在济南召开。阿里云云原生资深专家李国强结合自身微服务领域经验#xff0c;现场跟数十家山东企业分享了云原生的代表技术之一“微服务”的演进和应用实践。本文根据作者的现…简介 2021年7月2日阿里云用户组AUG第一次线下活动在济南召开。阿里云云原生资深专家李国强结合自身微服务领域经验现场跟数十家山东企业分享了云原生的代表技术之一“微服务”的演进和应用实践。本文根据作者的现场演讲整理而成。
2021年7月2日阿里云用户组AUG第一次线下活动在济南召开。阿里云云原生资深专家李国强结合自身微服务领域经验现场跟数十家山东企业分享了云原生的代表技术之一“微服务”的演进和应用实践。本文根据作者的现场演讲整理而成。 背景
在企业内部分为运维或开发但最终所有做的事情都是为了解决业务的问题。如果你做一件事情只有技术目标而没有业务目标失败是很常见的。
什么样的业务诉求会驱动一个企业去考虑微服务呢
随着架构的演进当你的业务越来越复杂组件越来越多对于每个业务组件的独立性要求或者技术栈的异构成本越来越高的时候就会需要去考虑微服务。换言之如果这个业务是一个比较平稳、没有什么大的挑战其实不需要去做微服务的改造。 各企业需要结合自己的业务去进行分析是否真的需求微服务。很多企业可能为了沟通或者架构师、CTO有自己的诉求想要这个技术领先去做微服务最终惨淡收场其实这种案例是非常多的。微服务的适用性一定是从一个业务驱动的这个角度考虑的需要考虑的是业务的复杂程度。 比较单体和微服务之间的一个区别什么情况下需要它和复杂程度是非常相关的。当你的一个业务的复杂程度比较低处于单体时代的时候前端后端数据库都是一体的需要进行变更时一个数据包上去所有的这个业务都上去了。并且当你的业务足够简单的时候单体效率一定是最高的。
业务不断往前演进复杂度越来越高的时候单方面的发布可能会影响到别人。比如我有一个数据包里边对应一个模块在这个模块上线的时候需要去考虑别的模块怎么上线。业务流量进行扩缩容的时候需要对整个业务进行沟通而不是对单个模块进行沟通你会发现资源浪费会很高。这个时候就会到一些拐点不管是你的发版或者是你的资源利用率都会出现一些问题生产效率开始降低。单体应用架构的效率出现的拐点就是客户考虑是否需要微服务架构的一个时间点。 微服务的应用架构
1、应用架构的演进历程
微服务最早的时候其实还是单品为主。现在的微服务对主流的一些技术框架像 Java 体系的四分之二的 Double 类其他语言都没有放置。但实际上其他语言都有非常多的微服务框架可以选择像 PDP 等都会有一些。
之前云栖大会做过一次统计账号体系在整个后端开发中的地位50%的投票是 Java 后端开发。但现在企业越来越多元化之前 Java 占统治的地位已经发生了变化。规模略大的公司基本上都是多元体系里面有很多种不同业务线的诉求不一样可能有的业务线是 Java有些业务偏前端框架会用 PAP、PYTHON还有就是企业的并购也会带来很多元的体系。
多元数据的解法就是用一个多种的维度方案或是用新的技术形式再往后就是容器化微服务带来的很多问题是通过容器来解决的。包括微服务器有些人可能直接放弃不用了。负责人看到 Double 这个体系直接用 K8sS Service 去做它的这个运行的暴露单元好处是和语言无关什么样的体系里面都可以是一个 K8s Service。但在用了微服务后暴露出来的问题会比较多我们需要对这么多的业务组件进行治理。
K8s 本身是不强的就是为了要进一步解决这个问题引入了更多的网格技术。去年开始越来越多的企业开始做网格网络这里面就包括用 Service Mesh 这个服务网解决跨语言的调研和服务治理。还有一个更新的叫做 Dapr 的技术解决供应链依赖问题。
可以发现应用架构的演进是一个业务不断地提出问题然后产出新框架新的框架又可能会引入新的问题不断推动着技术的运行过程。 阿里应用架构演进
整个阿里巴巴内部是完全走过一遍上述流程的因为业务的快速增长对技术团队也在不断地进行挑战。PHP 是世界上最好最早的语言淘宝商城其实就是用的 PHP。但是后来业务发展淘宝的体量越来越快后不但不能够支撑这个业务PHP 本身的扩展能力也撑不住了。
2009 年阿里先做了分布式业务。阿里正式地从单体变成了分布式业务那时候体量已经比较大还没有双十一但已经促成了阿里内部去做自己的分布式框架。除了会有分布式的服务框架还有一些分布式的数据库和分布式的相应规定在内部称为三辆马车这也是从单体变成分布式框架时必须要解决的三件事。
到 2011 年时阿里开始探索容器化先做了 T4 项目是对于容器化的技术实现最后变成 Pouch 的容器化的实现它也是符合容器标准的容器化的实现。这体现出针对微服务后带来的运维挑战容器是一个非常好的解决方案。
再往后到 2013 年整个 Oracle 包括小型机在阿里下线全部变成自己的开源的技术栈。2015 年开始阿里全面拥抱云原生技术包括容器技术的对外开放等业务整个体系逐步深化。2016 年到 2019 年间阿里做了云原生上云包含已经全面拥抱的 K8s 体系以及微服务的改造、治理等。
到现在这段时间我们做的事情是图上画的最后一个阶段基于网格进一步对服务点的支持多语言越来越常见。阿里有很多业务是从外部合并进来的阿里原来的整套技术战略全部都是 Java对外部合并进来的用户非常不友好因为他们不可能全部配好重启不得不去适配 Java。所以近来我们在做的事情就是基于网格的新一代微服务架构做演进会有一些技术让微服务的框架本身对于多元的支持变得更好包括治理也可以去解耦这也是成本较高的一个原因。 2、Apache Dubbo 3.0
Dubbo 3.0 在 6 月底已经发布了最新版这其实是一个很坎坷的项目。2008 年的时候Dubbo 在内部正式发布2011 年正式开源。以前Dubbo 和 HMPK 在阿里内部都有但阿里希望技术上是统一的不希望有两套技术两边不互通。这是两个技术栈所以进行了一次 PKApache Dubbo 胜出所以阿里内部目前全是 Apache Dubbo。现在这也是国内最火的 Apache 框架。中间有段时间阿里内部投入比较少。到 2017 年时我们中间件团队再次去做商业化重启整个 Dubbo 开源才让 Apache 从完整的一个项目到前几天时完成了发布。
这个项目是非常活跃的现在的贡献和使用率都非常高。Dubbo 3.0 里其实做了很多事去拥抱最新的一些理念比如对 Service Mesh 的支持它的协议也和 GRP 做了更好的兼容做了一系列全新的服务发现模式。现在国内用得比较多的还是 2.7、2.6 的版本3.0 发布之后很多企业一旦用起来都比较喜欢。当时还没发布时社区里就有一个用户在拿 3.0 开始测试了。 3、Spring Cloud Alibaba
另一个不得不夸奖的是 Cloud 体系它和 Java 的微服务这两个体系目前还是最流行的。Spring Cloud 体系的优点是组件非常丰富。Dubbo 这两年在从 IPC 框架往主流服务器去引擎而 Spring Cloud 诞生之初就是要把微服务数据相关部门支持起来。
随后阿里巴巴做了 Spring Cloud Alibaba阿里开源一系列的中间件包括 Double 注册中心、配置中心、限流交易规律以及事务去帮助用户解决刚才讲到的微服体系中各种各样的问题。
微服务是一整个体系而不仅仅是简单的调用框架。微服务在大家使用的落地过程中碰到的问题阿里非常重视。它把其中一些重要的点进行开源同时通过与阿里云结合做 SDK 的分装把这两部分合在一起。主要目的之一是帮助用户去使用 Spring Cloud 体系另一个目的是帮助用户在阿里云上更好地运行 Spring Cloud。所以这是阿里巴巴的 Cloud。
大部分的用户知道的 Nacos、Sentinel 等中间件实际上和云的一些产品间有非常好的基础。我们也会和其他公司去联合开发不断地演进项目。因为在阿里我们会认为开源和商业化是同样重要的一个团队既需要承担开源项目也需要承担商业化的服务。 微服务不是免费的午餐
1、微服务会带来复杂度的提升
微服务不是免费的它会带来很大的复杂度提升包括服务框架的选型、注册中心的稳定性等。当一个客户足够大的时候他会面临一个很大的问题就是注册中心的稳定性可能会成为一个业务的瓶颈包括应用的监控、统一的配置管理、任务调度等一系列的东西都会成微服务落地过程中需要考虑的问题。
在这个过程中对整个企业挑战还是比较大的不是每个企业都有能力去把整个微服务的开发组件全部自己运维起来。这一大堆组件如果全部靠自己运维起来要求还是比较高的。所以在里面更多地是希望企业更关注业务的一些相对偏运维的事情云厂商才可能通过用其他方式进行解决或者是如果企业足够强大也可以去通过开源自建的方式去解决。 2、软件架构诉求与基础设施能力间存在“步调差 ”
刚才讲到 Spring Cloud、 Dubbo 挺好用但实际上也存在问题即 SDK 的升级会变得非常困难因为这个升级对业务没有任何价值业务方不愿意去配合。很多时候都是系统来说 2.6 有 bug需要升一下 2.7 版本。这个时候就需要推动业务方去做因为他把 SDK 引用进去了引了之后如果有 bug 或者做一个增强都需要在 SDK 做这时业务方往往是不愿意的。在阿里内部这个问题也同样存在。
实际上这涉及到一个比较大的话题即业务开发人员和基础设施的运维人员的边界在哪。SDK 这件事情到底属于业务人员还是属于基础知识这个问题问起来很抽象是大家的一个责任边界的问题。业务开发人员认为 SDK 是运维测试的因为我只要接口剩下更新、治理、工程上和业务开发没关系。运维人员又不得不让研发人员去配合业务研发这是模糊的边界必然会发生冲突。
所以从云的角度或从计算的角度出发我们在探讨所谓的软件架构速度和基础设施能力丰富度的问题时能不能把业务和完成业务没有那么相关的所有能力都下降到基础设施的运维团队这是一直在思考的一个问题。在演练中经历过几代
第一代是云计算。它把基础设施的这个东西从业务侧翻下来业务人员就不需要再去关心基础资源。第二个是容器和推广安全。运维这件事情变得更简单后开发人员就不会关心这一层了但是 SDK 侵入这件事对于业务开发员来讲就是一个侵略。剥离的问题也是在 Service Mesh 这个技术上来做的。它把所有运行态的治理能力、流量管理能力全部从用户侧、开发测的 SDK 过滤出来而不再需要去做 SDK 的生产。这个也就意味着用了 Service Mesh 之后用户是不需要做语言绑定也就解决了刚才说的那个模糊地带很难解决的问题。这个可能对于现在在用 Spring Cloud 的企业都可以考虑这个东西会不会成为替代掉现在任何一个单语言的微服务框架技术。再往后讲其实还有一种依赖。比如当你需要一个中间件时你一定要去做选型这需要业务开发人员的配合。单独的一个理念就是我能让你把这个中间件下沉到基础设施。到这时所有的业务开发人员真的只需要关心业务代码所有的这些基础设施就全部下载下来是不断地去让基础设施能力更加丰富来满足上层业务这样一个自主发展趋势。3、Service Mesh的剥离了服务和流量治理能力
Service Mesh 就是服务治理、流量治理框架。在原有的设计里它属于业务的一部分上面是业务代码下面是这些能力。Service Mesh 能做的最重要的一件事就是把这些能力剥离到 Istio 里来业务带中就是纯业务功能边界很清晰服务治理、流量治理框架由运维团队来服务。 上层所有的语言和下层所有的基础设施通过一层层统一的接口进行抽象。不管用 Rock MQ 还是 Rabbit MQ对上层业务是无感的它会给上层业务一个统一抽象的 API 而且是 HTTP 或者 gRPC 这样的一个企业的 API 。开发人员不再关心底下到底是什么进一步地让开发人员和下面进行解耦。 目标理想架构
最后真正理想的框架是什么样的呢开发人员和业务人员边界到底在哪呢我们画了一个理想的框架。
对上层来讲的话我们会期望不同的业务单元可以选择不同的语言和框架。比如说有的是单体有的是 Spring Cloud 或者 Dubbo从调用层面来讲完全是互通的可以接入 Service Mesh 的技术或者现有的这个框架对于中间的容器服务会让业务不再感知具体的中间件。再往下是容器服务作为整个位置的一个支撑。右边是它的支撑体系如微服务会带来一些复杂性需要通过可观测性监控你的 Devops 的流程 CICD 或者安全性支撑。
这时候就可以让你的业务开发人员用他喜欢的语言去开发他想的业务而不再关心这些所有的基础设施团队需要去解决的问题这其实也是从应用框架或微服务上来讲的最终目标。 微服务化实践案例
1、微服务引擎MSE
我们去做微服务时会碰到一些问题有一种解决方式是进行全国自建这对于一些企业来说工作量比较大。阿里云会把其中一些共性的东西变成产品来提供。比如说你去搭建一个微服务你需要配置功能、网关、治理能力阿里云会用一个产品的形态直接给到你不用自己建了。就好像我原来是自建的现在是影响他启动的数据不一样那对于你原来是自建的 Nacos现在就是一个云产品的提供。 2、畅捷通
另外有一个案例畅捷通是用友的一个全资子公司这个客户专门做小微企业的财务系统。它全面上到阿里云把自己的财务系统全部变成 SaaS 化的模式交付。大家都知道传统的财务系统 ERP 等都是偏单体的架构畅捷通的整个财务系统也经历了从虚机到 K8s 的转变。一开始是从虚机跑了微服务后来从虚机转到了 K8s。整体来看在云上的规模非常大也服务了非常多的客户。
从容器化到微服务这样一个过程它基本上也是这个难题希望提升系统微服务治理能力和监控能力在新业务快速上线、频繁的版本迭代中确保系统的稳定健壮。它一开始用了阿里云的一些项目后来想把它变成 Spring Cloud现在是两个结合在一起使用。 3、阿里云服务网格ASM
服务网格这个产品技术大概是在去年发布用于生产但实际上真正在生产上落地的企业还在不断地去尝试。阿里云也一样通过一个产品去降低用户使用 Service Mesh因为 Mesh 这件事情对于很多企业来讲只是个技术概念企业要的是一种多元微服务的能力而 ASM 服务网的产品会帮助用户去做服务网的一个落地。 4、商米科技通过 Service Mesh 完成微服务化
上海的商品科技是做各种物联网设备的它碰到的问题是内部技术框架和语言体系比较复杂各种各样的语言和服务都遇到了困难。它希望对这些业务能够进行一个统一的流量管理包括发布时的流量管理所以它最终选择用 Service Mesh 这个技术去解决多元微服务。从这些业务价值的数据可以看出比如更新迭代、异常排查、控制面资源成本都有了较大的优化。 以上就是关于微服务的演进和实践分享希望有带给大家一些微服务的体系的梳理。
原文链接
本文为阿里云原创内容未经允许不得转载。
