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

2021年7月2日，阿里云用户组（AUG）第一次线下活动在济南召开。阿里云云原生资深专家李国强结合自身微服务领域经验，现场跟数十家山东企业分享了云原生的代表技术之一“微服务”的演进和应用实践。本文根据作者的现场演讲整理而成。
​

背景

在企业内部分为运维或开发，但最终所有做的事情都是为了解决业务的问题。如果你做一件事情，只有技术目标而没有业务目标，失败是很常见的。

什么样的业务诉求会驱动一个企业去考虑微服务呢？

随着架构的演进，当你的业务越来越复杂，组件越来越多，对于每个业务组件的独立性要求或者技术栈的异构成本越来越高的时候，就会需要去考虑微服务。换言之，如果这个业务是一个比较平稳、没有什么大的挑战，其实不需要去做微服务的改造。

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

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

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

​

微服务的应用架构

​

​

1、应用架构的演进历程

微服务最早的时候其实还是单品为主。现在的微服务对主流的一些技术框架，像 Java 体系的四分之二的 Double 类，其他语言都没有放置。但实际上其他语言都有非常多的微服务框架可以选择，像 PDP 等都会有一些。

之前云栖大会做过一次统计，账号体系在整个后端开发中的地位，50%的投票是 Java 后端开发。但现在企业越来越多元化，之前 Java 占统治的地位已经发生了变化。规模略大的公司基本上都是多元体系，里面有很多种，不同业务线的诉求不一样，可能有的业务线是 Java；有些业务偏前端框架，会用 PAP、PYTHON；还有就是企业的并购，也会带来很多元的体系。

多元数据的解法就是用一个多种的维度方案或是用新的技术形式，再往后就是容器化，微服务带来的很多问题是通过容器来解决的。包括微服务器，有些人可能直接放弃不用