一文看懂微服务背后的技术演进与应用实践

各企业需要结合自己的业务去进行分析是否真的需求微服务。 很多企业可能为了沟通，或者架构师、CTO有自己的诉求，想要这个技术领先去做微服务，最终惨淡收场，其实这种案例是非常多的。微服务的适用性一定是从一个业务驱动的这个角度考虑的，需要考虑的是业务的复杂程度。

比较单体和微服务之间的一个区别，什么情况下需要它，和复杂程度是非常相关的。当你的一个业务的复杂程度比较低，处于单体时代的时候，前端后端数据库都是一体的，需要进行变更时，一个数据包上去，所有的这个业务都上去了。并且，当你的业务足够简单的时候，单体效率一定是最高的。

业务不断往前演进，复杂度越来越高的时候，单方面的发布可能会影响到别人。比如我有一个数据包，里边对应一个模块，在这个模块上线的时候，需要去考虑别的模块怎么上线。业务流量进行扩缩容的时候，需要对整个业务进行沟通，而不是对单个模块进行沟通，你会发现资源浪费会很高。这个时候就会到一些拐点，不管是你的发版或者是你的资源利用率都会出现一些问题，生产效率开始降低。单体应用架构的效率出现的拐点就是客户考虑是否需要微服务架构的一个时间点。

阿里应用架构演进

整个阿里巴巴内部是完全走过一遍上述流程的，因为业务的快速增长，对技术团队也在不断地进行挑战。PHP 是世界上最好最早的语言，淘宝商城其实就是用的 PHP。但是后来业务发展，淘宝的体量越来越快后，不但不能够支撑这个业务，PHP 本身的扩展能力也撑不住了。

2009 年，阿里先做了分布式业务。阿里正式地从单体变成了分布式业务，那时候体量已经比较大，还没有双十一，但已经促成了阿里内部去做自己的分布式框架。除了会有分布式的服务框架，还有一些分布式的数据库和分布式的相应规定，在内部称为三辆马车，这也是从单体变成分布式框架时，必须要解决的三件事。

到 2011 年时，阿里开始探索容器化，先做了 T4 项目，是对于容器化的技术实现，最后变成 Pouch 的容器化的实现，它也是符合容器标准的容器化的实现。这体现出针对微服务后带来的运维挑战，容器是一个非常好的解决方案。

再往后到 2013 年，整个 Oracle 包括小型机在阿里下线，全部变成自己的开源的技术栈。2015 年开始，阿里全面拥抱云原生技术，包括容器技术的对外开放等业务，整个体系逐步深化。2016 年到 2019 年间，阿里做了云原生上云，包含已经全面拥抱的 K8s 体系，以及微服务的改造、治理等。

到现在这段时间，我们做的事情是图上画的最后一个阶段：基于 格进一步对服务点的支持，多语言越来越常见。阿里有很多业务是从外部合并进来的，阿里原来的整套技术战略全部都是 Java，对外部合并进来的用户非常不友好，因为他们不可能全部配好重启，不得不去适配 Java。所以，近来我们在做的事情就是基于 格的新一代微服务架构做演进，会有一些技术让微服务的框架本身对于多元的支持变得更好，包括治理也可以去解耦，这也是成本较高的一个原因。

?

3、Spring Cloud Alibaba

另一个不得不夸奖的是 Cloud 体系，它和 Java 的微服务这两个体系目前还是最流行的。Spring Cloud 体系的优点是组件非常丰富。Dubbo 这两年在从 IPC 框架往主流服务器去引擎，而 Spring Cloud 诞生之初就是要把微服务数据相关部门支持起来。

随后，阿里巴巴做了 Spring Cloud Alibaba，阿里开源一系列的中间件，包括 Double 注册中心、配置中心、限流交易规律以及事务，去帮助用户解决刚才讲到的微服体系中各种各样的问题。

微服务是一整个体系，而不仅仅是简单的调用框架。微服务在大家使用的落地过程中碰到的问题，阿里非常重视。它把其中一些重要的点进行开源，同时通过与阿里云结合做 SDK 的分装，把这两部分合在一起。主要目的之一是帮助用户去使用 Spring Cloud 体系，另一个目的是帮助用户在阿里云上更好地运行 Spring Cloud。所以，这是阿里巴巴的 Cloud。

大部分的用户知道的 Nacos、Sentinel 等中间件，实际上和云的一些产品间有非常好的基础。我们也会和其他公司去联合开发，不断地演进项目。因为在阿里，我们会认为开源和商业化是同样重要的，一个团队既需要承担开源项目，也需要承担商业化的服务。

?

?

2、软件架构诉求与基础设施能力间存在“步调差 ”

刚才讲到 Spring Cloud、 Dubbo 挺好用，但实际上也存在问题，即 SDK 的升级会变得非常困难，因为这个升级对业务没有任何价值，业务方不愿意去配合。很多时候都是系统来说 2.6 有 bug，需要升一下 2.7 版本。这个时候就需要推动业务方去做，因为他把 SDK 引用进去了，引了之后如果有 bug 或者做一个增强，都需要在 SDK 做，这时业务方往往是不愿意的。在阿里内部这个问题也同样存在。

实际上这涉及到一个比较大的话题，即业务开发人员和基础设施的运维人员的边界在哪。SDK 这件事情到底属于业务人员还是属于基础知识，这个问题问起来很抽象，是大家的一个责任边界的问题。业务开发人员认为 SDK 是运维测试的，因为我只要接口，剩下更新、治理、工程上和业务开发没关系。运维人员又不得不让研发人员去配合业务研发，这是模糊的边界，必然会发生冲突。

所以从云的角度或从计算的角度出发，我们在探讨所谓的软件架构速度和基础设施能力丰富度的问题时，能不能把业务和完成业务没有那么相关的所有能力都下降到基础设施的运维团队，这是一直在思考的一个问题。在演练中经历过几代：

• 第一代是云计算。它把基础设施的这个东西从业务侧翻下来，业务人员就不需要再去关心基础资源。

• 第二个是容器和推广安全。运维这件事情变得更简单后，开发人员就不会关心这一层了，但是 SDK 侵入这件事对于业务开发员来讲，就是一个侵略。

• 剥离的问题也是在 Service Mesh 这个技术上来做的。它把所有运行态的治理能力、流量管理能力全部从用户侧、开发测的 SDK 过滤出来，而不再需要去做 SDK 的生产。这个也就意味着用了 Service Mesh 之后，用户是不需要做语言绑定，也就解决了刚才说的那个模糊地带很难解决的问题。这个可能对于现在在用 Spring Cloud 的企业都可以考虑，这个东西会不会成为替代掉现在任何一个单语言的微服务框架技术。

• 再往后讲其实还有一种依赖。比如当你需要一个中间件时，你一定要去做选型，这需要业务开发人员的配合。单独的一个理念就是我能让你把这个中间件下沉到基础设施。到这时所有的业务开发人员真的只需要关心业务代码，所有的这些基础设施就全部下载下来，是不断地去让基础设施能力更加丰富，来满足上层业务这样一个自主发展趋势。

上层所有的语言和下层所有的基础设施，通过一层层统一的接口进行抽象。不管用 Rock MQ 还是 Rabbit MQ，对上层业务是无感的，它会给上层业务一个统一抽象的 API ，而且是 HTTP 或者 gRPC 这样的一个企业的 API 。开发人员不再关心底下到底是什么，进一步地让开发人员和下面进行解耦。

?

目标理想架构

最后真正理想的框架是什么样的呢发人员和业务人员边界到底在哪呢们画了一个理想的框架。

• 对上层来讲的话，我们会期望不同的业务单元可以选择不同的语言和框架。比如说有的是单体，有的是 Spring Cloud 或者 Dubbo，从调用层面来讲，完全是互通的，可以接入 Service Mesh 的技术，或者现有的这个框架
• 对于中间的容器服务，会让业务不再感知具体的中间件。
• 再往下是容器服务，作为整个位置的一个支撑。
• 右边是它的支撑体系，如微服务会带来一些复杂性，需要通过可观测性监控你的 Devops 的流程 CICD 或者安全性支撑。

这时候就可以让你的业务开发人员用他喜欢的语言去开发他想的业务，而不再关心这些所有的基础设施团队需要去解决的问题，这其实也是从应用框架或微服务上来讲的最终目标。

2、畅捷通

**

另外有一个案例，畅捷通是用友的一个全资子公司，这个客户专门做小微企业的财务系统。它全面上到阿里云，把自己的财务系统全部变成 SaaS 化的模式交付。大家都知道传统的财务系统 ERP 等都是偏单体的架构，畅捷通的整个财务系统也经历了从虚机到 K8s 的转变。一开始，是从虚机跑了微服务，后来从虚机转到了 K8s。整体来看，在云上的规模非常大，也服务了非常多的客户。

从容器化到微服务这样一个过程，它基本上也是这个难题，希望提升系统微服务治理能力和监控能力，在新业务快速上线、频繁的版本迭代中确保系统的稳定健壮。它一开始用了阿里云的一些项目，后来想把它变成 Spring Cloud，现在是两个结合在一起使用。

?

4、商米科技通过 Service Mesh 完成微服务化

上海的商品科技是做各种物联 设备的，它碰到的问题是内部技术框架和语言体系比较复杂，各种各样的语言和服务都遇到了困难。它希望对这些业务能够进行一个统一的流量管理，包括发布时的流量管理，所以它最终选择用 Service Mesh 这个技术去解决多元微服务。从这些业务价值的数据可以看出，比如更新迭代、异常排查、控制面资源成本都有了较大的优化。

以上就是关于微服务的演进和实践分享，希望有带给大家一些微服务的体系的梳理。

?

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树使用JDBC操作数据库数据库操作91693 人正在系统学习中