一文看懂微服务，阿里云原生资深专家李国强独家分享
凌云时刻
编者按：2021年7月2日，阿里云用户组（AUG）第一次线下活动在济南召开。阿里云原生资深专家李国强结合自身微服务领域经验，现场跟数十家山东企业分享了云原生的代表技术之一“微服务”的演进和应用实践。本文根据作者的现场演讲整理而成。
补充说明：原文在「凌云时刻」首发于9月26日，现基于原作者建议进行补充修改后重新发布，力求信息传递准确。
微服务与业务复杂度高相关
企业为什么需要微服务架构？一定是从业务需求角度考虑和回答的。
在企业内部，技术团队往往分为运维和开发，最终所做的所有事情都是为了解决业务的问题。如果你做一件事情，只有技术目标而没有业务目标，失败是很常见的。
那什么样的业务诉求会驱动一个企业去考虑微服务呢？随着架构的演进，当你的业务越来越复杂，组件越来越多，对于每个业务组件的独立性要求或者技术栈的异构成本越来越高的时候，就需要考虑微服务。换言之，如果这个业务是一个比较平稳、没有什么大的变化和挑战，其实不需要去做微服务的改造。
各企业需要结合自己的业务去分析是否真的需要微服务。有些企业可能为了技术领先性或者架构师、CTO的个人诉求去做微服务，最终往往会惨淡收场。微服务的价值一定是从业务驱动的这个角度考虑的，需要考虑的是业务的复杂程度。
比较一下单体和微服务之间的区别，什么情况下需要微服务，和复杂程度是非常相关的。如果业务复杂程度比较低，处于单体时代的时候，前端后端数据库都是一体的，需要进行变更时，一个应用包发布，所有的业务都上去了。所以，当你的业务足够简单的时候，单体效率一定是最高的。
随着业务不断往前演进，复杂度越来越高的时候，单体的发布可能会影响到别人。比如我有一个应用，里边包含一个模块，在这个模块上线的时候，需要去考虑别的模块怎么上线。业务流量进行扩缩容的时候，需要对相关的业务进行沟通，而不是对单个模块进行扩缩，会发现资源浪费会很高。这个时候就会到一些拐点，不管是你的发版或者是你的资源利用率都会出现一些问题，生产效率开始降低。单体应用架构的效率的拐点就是客户考虑是否需要微服务架构的一个时间点。
微服务的应用架构
微服务最早的时候其实还是Java为主。微服务最主流的技术框架，像Java体系的spring cloud alibaba，Dubbo微服务体系都比较完整。其他语言没有出现特别占统治地位的微服务框架，比较分散。之前云栖大会做过一次统计，在整个后端开发中，50%的开发者还是在使用Java语言。
但随着现在企业越来越多元化，之前Java占统治的地位已经发生了变化。规模略大的公司基本上都是多语言体系，不同业务线的诉求不一样，可能有的业务线是Java；有些业务偏前端框架，会用PHP、Python；还有就是企业的并购，也会带来很多元的技术体系。
微服务解决了横向扩展问题，提高了研发的敏捷性，但同时也引入了运维复杂等问题。再往后的演进历程就是容器化，微服务带来的很多问题都可以通过容器化来解决。比如微服务体系，一些新的业务负责人可能会考虑不再采用dubbo，spring cloud alibaba这样的语言相关的微服务体系。再者，可以直接用K8S Service作为微服务暴露的单元。这个方案的好处是和语言无关，任何一种技术体系的业务模块都可以暴露为一个K8S Service。同时k8s也解决了很多微服务的运维问题，比如可用性，可观测性，k8s以及相关的生态都很好地进行了解决。
但在微服务治理上K8S本身是不足的，为了进一步解决这个问题，新的网格技术开始出现。去年开始越来越多的企业开始尝试服务网格，这里面就包括用Service Mesh这个技术来解决跨语言的调用和服务治理。还有一个更新的叫做Dapr的技术可以解决中间件依赖多样性的问题。
可以发现，应用架构的演进是一个业务提出新的挑战，然后新技术框架出现，新的框架又可能会引入新的问题，不断推动着技术发展的演进过程。
整个阿里巴巴内部是完全走过一遍上述流程的，因为业务的快速增长，对技术团队也在不断地进行挑战。淘宝商城最开始用的是PHP，但后来随着业务发展，淘宝的体量越来越大，PHP本身的扩展能力也撑不住了。
2009年，阿里先做了分布式改造。阿里正式从单体变成了分布式架构，那时候体量已经比较大，当时还没有双十一，但已经促成了阿里内部去自研了分布式框架。除了分布式的服务框架，还有分布式的数据库和分布式的消息队列，在内部称为三架马车，这也是从单体变成分布式框架时，必须要解决的三大核心技术问题。
到2011年时，阿里开始探索容器化。先做了T4项目，是对于容器化的技术实现，后来演进成一个叫Pouch的容器的实现，它也是符合容器标准的实现。这体现出针对微服务化后带来的运维挑战，容器是一个非常好的解决方案。
再往后到2013年，整个Oracle包括小型机在阿里下线，全部变成自己的自研+开源的技术栈。2015年开始，阿里全面拥抱云原生技术，同年，我们也开始了把内部技术输出到阿里云上的历程。2016年到2019年间，阿里做了内部业务云原生上云，包含已经全面拥抱的K8S体系，以及微服务的改造、治理等，并且全部运行都了阿里云上。
Dubbo3.0在上周已经发布了最新版，这其实是一个很坎坷的项目。2008年的时候Dubbo在内部正式发布，2011年正式开源。
以前，Dubbo和HSF在阿里内部是并存，但随着业务互相调用原来越多，我们希望技术上是统一的，不希望有两套技术，两边不互通。这两个技术栈进行了一次PK， HSF胜出，所以阿里内部目前全是HSF。而Dubbo就开源了，但没想到无心插柳柳成荫。现在Dubbo成了国内最火的微服务框架之一。中间有段时间，阿里对Dubbo开源投入比较少。到2017年时，我们中间件团队再次重启了Dubbo开源项目的投入，一直到近期的Dubbo3.0的发布。
这个开源项目目前是非常活跃的，现在的贡献和使用率都非常高。Dubbo3.0里其实做了很多事去拥抱最新的一些理念，比如对Service Mesh的支持，它的协议也和grpc做了更好的兼容，做了一系列全新的服务发现模式。现在国内用得比较多的还是2.6、2.7的版本，3.0发布之后，很多企业也开始试用。当时还没发布时，社区里就有一个用户在拿3.0开始测试了。
另一个重要的微服务体系是Spring Cloud体系，它和Dubbo是当前Java的微服务体系中最流行的两个框架。Spring Cloud体系的优点是组件非常丰富。Dubbo这两年也在从RPC框架往完备的微服务框架去演进，而Spring Cloud诞生之初就是要构建完整的微服务体系。
阿里巴巴在Spring Cloud 体系下推出了Spring Cloud Alibaba，将阿里开源一系列的中间件，包括Nacos注册中心、配置中心、限流降级sentinel以及事务Seata等多个开源项目融合到一个体系下，去帮助用户解决刚才讲到的微服体系中各种各样的问题。
微服务是一个完整的体系，而不仅仅是简单的调用框架。微服务在使用落地过程中碰到的问题，阿里也同样碰到了，而且有不错的实践落地。于是我们把其中的一些重要的点进行了开源，同时整合阿里云的一些重要SDK，把这两部分结合在了一起。主要目的之一是帮助用户去参考阿里的最佳实践和稳定的组件使用Spring Cloud体系，另一个目的是帮助用户在阿里云上去更好地运行Spring Cloud，与云产品做比较好地整合。
大部分用户知道的Nacos, Sentinel, Seata等中间件，一方面在云上都有对应的云产品。同时在开源社区我们也和其他公司的同学一起不断贡献，推动开源项目的演进。在阿里，我们会认为开源和商业化是同样重要的，一个团队既需要承担开源项目，也需要承担云产品的研发。
微服务不是免费的午餐
微服务不是免费的。它会带来很大的复杂度提升，包括服务框架的选型、注册中心的稳定性等。比如，当一个客户业务不断变大的时候，他会面临的一个问题就是注册中心的稳定性可能会成为一个业务的瓶颈。包括应用的监控、统一的配置管理、任务调度等一系列的东西都会成为微服务落地过程中需要考虑的问题。
在这个过程中，对整个企业的技术挑战还是比较大的，不是每个企业都有能力去把整个微服务的相关组件全部自己运维起来。这一大堆组件如果全部靠自己运维起来，要求还是比较高的。大多数企业还是希望能更关注业务。而一些相对偏运维的事情，可以借助云厂商提供的成熟云产品进行解决。当然有些企业在技术上的投入足够大，也可以去通过开源自建的方式去解决。
刚才讲到Spring Cloud、 Dubbo挺好用，但实际上也存在问题，即SDK的升级会变得非常困难，因为这个升级对业务没有任何价值，业务方不愿意去配合。比如运维团队发现dubbo 2.6有bug，需要升级到2.7版本。这个时候就需要推动业务方去做包替换，以及业务重启，因为他把SDK引用进去了，之后如果有bug或者做一个增强，都需要在SDK里做，这时业务方往往是不愿意的。在阿里内部这个问题也同样存在。
实际上这涉及到一个比较大的话题，即业务开发人员和基础设施运维人员的边界在哪，SDK这件事情到底属于业务人员还是属于基础设施。业务开发人员认为SDK是运维负责的，因为我只要调用接口，剩下治理相关的能力和业务开发没关系。但很多时候运维人员又不得不让研发人员去配合SDK的升级，这是模糊的边界，必然会发生冲突。
所以从云的角度或从计算的角度出发，我们在探讨软件架构的演进和基础设施能力丰富度的问题时，能不能把业务不相关的所有能力都下降到基础设施由运维团队负责，这是一个不断演进的问题。在实际中已经经历过几代：
第一代是云计算。它把基础设施从业务侧剥离下来，业务人员就不需要再去关心基础资源。
第二个是容器和k8s的普及。运维这件事情变得更简单后，开发人员就不会关心这一层了，但是SDK侵入这件事对于业务开发员来说还是一种侵入。
SDK剥离的问题是在Service Mesh这个技术上来完成的。它把所有运行态的治理能力、流量管理能力全部从用户侧、开发测的SDK剥离出来。这也就意味着用了Service Mesh之后，用户不需要做语言绑定，也就解决了刚才说的那个模糊地带很难解决的问题。Service Mesh可能会成为替代掉现在任何一个单语言微服务框架的一个方向。
再往后讲其实还有一种依赖。比如当你需要一个中间件时，你一定要去做选型，这需要业务开发人员的配合。比如选择rocketmq还是rabbitmq，对于业务人员是有感知的。下一个理念就是是否能把中间件下沉到基础设施。到这时所有的业务开发人员真的只需要关心业务代码，所有的基础设施就全部下沉了。运维团队的任务就是不断的让基础设施能力更加丰富，来满足上层业务。真正的实现边界清晰，完全解耦。
Service Mesh是一个服务和流量治理框架。在之前的SDK模式里，它属于业务的一部分，上面是业务代码，下面是这些能力。Service Mesh能做的最重要的一件事，就是把这些能力剥离到Istio里来，业务代码就变成了纯业务功能，边界很清晰，服务治理、流量治理框架由运维团队来负责。
Darp能够进一步地分离上层的语言和下层所有的基础设施，通过一层统一的接口进行抽象。不管用RocketMQ还是RabbitMQ，对上层业务是无感的，它会给上层业务一个统一抽象的API ，而且是HTTP或者gRPC这样的一个通用的API 。开发人员不再关心底下的中间件到底是什么，进一步让开发人员和下面进行解耦。
目标理想架构
最后真正理想的框架是什么样的呢？开发人员和业务人员边界到底在哪呢？我们画了一个理想的框架。
对上层来讲的话，我们会期望不同的业务单元可以选择不同的语言和框架。比如说有的是单体，有的是Spring Cloud或者Dubbo，从调用层面来讲，完全是互通的，可以接入Service Mesh的技术，或者现有的这个框架 对于中间的容器服务，会让业务不再感知具体的中间件。
再往下是容器服务，要作为整个体系的一个系统支撑。
右边是它的支撑体系，如微服务会带来一些复杂性，需要通过可观测性，Devops的流程支持CICD，以及安全性支撑。
这时候企业就可以真正让业务开发人员用他喜欢的语言去开发他想的业务，而不再关心这些所有的基础设施团队需要去解决的问题，这其实也是从应用框架或微服务上来讲的最终目标。
微服务化实践案例
我们去做微服务时会碰到一些问题，有一种解决方式是进行开源自建，这对于一些企业来说工作量比较大。阿里云会把其中一些共性的东西变成产品来提供。比如说你去搭建一个微服务，你需要配置功能、网关、治理能力，阿里云会用一个产品的形态直接给到你，不用自己建了。比如注册中心，有些用户会基于nacos自建。但当规模比较大的时候，nacos的稳定性，或者升级的问题还是有一些挑战的。另外一个选择就是通过MSE这个云产品来提供，那么所有的稳定性，升级，安全等问题都由云产品来解决，用户只需要关注nacos最终提供的注册中心地址就可以了。
分享一个客户案例，畅捷通是用友的一个全资子公司，这个客户专门做小微企业的财务系统。它全面上到阿里云，把自己的财务系统全部变成SaaS化的模式交付。大家都知道传统的财务系统ERP等都是偏单体的架构，畅捷通的整个财务系统也经历了从虚机到K8S的转变。一开始，是在虚机上跑微服务，后来从虚机转到了K8S。整体来看，在云上的规模非常大，也服务了非常多的客户。
从容器化到微服务这样一个过程，它也是通过阿里云的产品解决了微服务治理能力和监控能力。在新业务快速上线、频繁的版本迭代中确保系统的稳定健壮。微服务框架方面一开始用了阿里云的HSF，后来逐步变成Spring Cloud，现在是两个框架在一起使用。
服务网格这个技术在去年发布1.0，推荐用户用于生产，但实际上真正在生产上落地的企业还在不断地去尝试中。阿里云也一样希望通过云产品解决掉一些复杂的运维问题，加速service mesh的落地。Mesh对于很多企业来讲只是个技术概念，企业要的是一种多语言微服务的能力，而ASM服务网格能够从方案级帮助用户落地多语言微服务的方案，但不需要过多的关注服务网格这个技术本身，降低门槛。
上海的商品科技是做各种物联网设备的，它碰到的问题是内部技术框架和语言体系比较复杂，各种各样的语言和服务治理起来非常复杂。它希望对这些业务能够进行统一的流量管理，包括发布时的流量管理，所以它最终选择用Service Mesh这个技术来提供多语言微服务的能力。选择了阿里云的ASM产品，从这些业务价值的数据可以看出，使用ASM提供的能力之后，比如更新迭代、异常排查、控制面资源成本都有了较大的优化。
↓↓↓
你可能还想看