Serverless 时代下大规模微服务应用运维的最佳实践

作者 | 陈涛

微服务架构的优点和痛点

1、微服务架构的诞生背景

回到互联网早期时代，也就是web1.0时代，当时主要是一些门户网站，单体应用是当时的主流应用，研发团队相对较小，这时候的挑战在于技术的复杂度，以及技术人员的匮乏。

到了新世纪互联网时代，出现了较大规模的一些应用，比如社交、电商等，流量和业务的复杂度也大幅增加，出现了几百甚至上千人的研发团队，研发团队扩大之后，协作问题成为困扰。SOA 解决方案是互联网的产物，其核心在于分布式、拆分等。但是因为 ESB 这样一些单点的组件，所以没有得到很好的推广。阿里巴巴在当时推出的 HSF、开源的Dubbo 等技术，其实是类似于分布式的一个解决方案，当时就已经有了微服务架构的理念。

微服务架构正式名称的诞生是在移动互联网时代，这时的生活已经实现全面互联网化，各种各样的生活类 APP 涌现，网民以及流量复杂度相对于新世纪互联网时代显著增强。另外，较大规模的研发团队也已成为主流。这时候，大家普遍都对效率有了更高的追求，而不只是原来只有几个巨头需要有这方面的技术。微服务架构以及微服务技术的推出，如 Spring  Cloud、Dubbo 等框架的普及，极大地推广了微服务技术。

现在我们已经进入全面的数字化时代，社会全面互联网化，各种各样的单位（包括政企、相对传统的单位）都需要较强的研发能力。流量的挑战、业务复杂度的挑战、研发团队的扩大等，使得大家对效率有了更高的要求。这时候微服务架构得到了进一步的推广和普及。

微服务架构经过这么多年的发展，是经久不衰的一项技术，为什么它能够有这样持续的发展？

2、微服务架构的优点

我们来回顾一下微服务架构和单体架构的区别，以及微服务架构的核心优势。

单体架构核心的问题在于冲突域太大，包括共享代码库。在研发过程中特别容易冲突；边界和模块的规模不清，使得团队效率也会降低。

而在微服务架构下，核心就在于拆分，包括解耦的研发态，解耦的部署态，极大地释放了团队的研发效率。大道至简，这也是微服务架构为什么能够持续发展的一个原因。

3、微服务时代痛点

根据复杂性守恒定律，我们解决了一个问题，问题会以另一种形式出现，我们又需要去解决。可以看到，微服务时代下会引入非常多的一些痛点，核心就是稳定性。因为从原来的一些本地调用改成远程调用以后，可能会发生稳定性的点激增，包括调度放大，即可能因为底层的一些远程调用问题，造成上层的一些不稳定，以及期间需要做的限流降级、调用链等。

在微服务时代定位一个问题的复杂度，也会成指数级的一个增长，这里面可能还需要服务治理。另外如果没有较好的设计和预先的一些设想，可能会出现微服务应用的爆炸，包括研发人员和测试人员之间的协作也都会成问题。