简介：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 在阿里外部都有，但阿里心愿技术上是对立的，不心愿有两套技术，两边不互通。这是两个技术栈，所以进行了一次 PK，Apache 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 这个技术去解决多元微服务。从这些业务价值的数据能够看出，比方更新迭代、异样排查、管制面资源老本都有了较大的优化。
以上就是对于微服务的演进和实际分享，心愿有带给大家一些微服务的体系的梳理。
原文链接
本文为阿里云原创内容，未经容许不得转载。