Serverless 时代下大规模微服务应用运维的最佳实践
时间：2021-10-08 17:01:11
[导读]微服务架构的优点和痛点Aliware1微服务架构的诞生背景回到互联网早期时代，也就是web1.0时代，当时主要是一些门户网站，单体应用是当时的主流应用，研发团队相对较小，这时候的挑战在于技术的复杂度，以及技术人员的匮乏。到了新世纪互联网时代，出现了较大规模的一些应用，比如社交、电...
微服务架构的优点和痛点
Aliware
1
微服务架构的诞生背景
回到互联网早期时代，也就是web1.0时代，当时主要是一些门户网站，单体应用是当时的主流应用，研发团队相对较小，这时候的挑战在于技术的复杂度，以及技术人员的匮乏。
到了新世纪互联网时代，出现了较大规模的一些应用，比如社交、电商等，流量和业务的复杂度也大幅增加，出现了几百甚至上千人的研发团队，研发团队扩大之后，协作问题成为困扰。SOA 解决方案是互联网的产物，其核心在于分布式、拆分等。但是因为 ESB 这样一些单点的组件，所以没有得到很好的推广。阿里巴巴在当时推出的 HSF、开源的Dubbo 等技术，其实是类似于分布式的一个解决方案，当时就已经有了微服务架构的理念。
微服务架构正式名称的诞生是在移动互联网时代，这时的生活已经实现全面互联网化，各种各样的生活类 APP 涌现，网民以及流量复杂度相对于新世纪互联网时代显著增强。另外，较大规模的研发团队也已成为主流。这时候，大家普遍都对效率有了更高的追求，而不只是原来只有几个巨头需要有这方面的技术。微服务架构以及微服务技术的推出，如 Spring Cloud、Dubbo 等框架的普及，极大地推广了微服务技术。
现在我们已经进入全面的数字化时代，社会全面互联网化，各种各样的单位（包括政企、相对传统的单位）都需要较强的研发能力。流量的挑战及传统业务复杂度的挑战、研发团队的扩大等，使得大家对效率有了更高的要求。这时候微服务架构得到了进一步的推广和普及。
微服务架构经过这么多年的发展，是经久不衰的一项技术，为什么它能够有这样持续的发展？
2
微服务架构的优点
我们来回顾一下微服务架构和单体架构的区别，以及微服务架构的核心优势。
单体架构核心的问题在于冲突域太大，包括共享代码库。在研发过程中特别容易冲突；边界和模块的规模不清，使得团队效率也会降低。
而在微服务架构下，核心就在于拆分，包括解耦的研发态，解耦的部署态，极大地释放了团队的研发效率。大道至简，这也是微服务架构为什么能够持续发展的一个原因。
根据复杂性守恒定律，我们解决了一个问题，问题会以另一种形式出现，我们又需要去解决。可以看到，微服务时代下会引入非常多的一些痛点，核心就是稳定性。因为从原来的一些本地调用改成远程调用以后，可能会发生稳定性的点激增，包括调度放大，即可能因为底层的一些远程调用问题，造成上层的一些不稳定，以及期间需要做的限流降级、调用链等。
在微服务时代定位一个问题的复杂度，也会成指数级的一个增长，这里面可能还需要服务治理。另外如果没有较好的设计和预先的一些设想，可能会出现微服务应用的爆炸，包括研发人员和测试人员之间的协作也都会成问题。
微服务技术经过这么多年的发展，业界其实已经有了一些解决方案。
如上图显示，如果要比较好地玩转微服务技术，除了开发自己的业务系统以外，可能还要配套地搭建多个系统，包括CI/CD、发布系统、研发流程、微服务组件相关的一些工具，以及可观测性相关的实时监控、告警系统、服务治理、调用链等等，还需要运维基础的 IaaS 资源。在这个时代，为了更好地运维 IaaS 资源，可能还需要自己维护一个K8s 集群。
所以说，在这样的背景下，很多企业会选择搭建一个运维团队，或者中间件团队，或者说由一些后端研发同学兼职。但是试想，有多少企业对自己内部搭建的这套系统是满意的？系统的迭代效率是多少，有没有踩到过一些开源的坑，这些坑现在有没有解决？这些应该是在企业的CTO、架构师心中一个持续的痛点。
Serverless时代下的解决方案
Aliware
1
Serverless时代
Serverless 从2012年第一次提出，到 2014年 推出了 Lambda 这样一个引爆性的产品后，短暂地达到了一个影响力的顶峰。但是这样一个新生事物，突然到真实的、复杂的生产环境中，其实有许多不适应，包括需要改善的地方，所以后续几年它可能要进入一个低谷。
但是，Serverless 的“将简单交给用户，复杂留给平台”的理念，其实是非常正确的一个方向。所以在开源界包括业界，其实都在持续性地进行 Serverless 方面的一些探索和发展。
阿里云在2017年推出了函数计算（Function Compute，FC），在2018年推出了Serverless应用引擎 SAE，在 2019年以及后续的这些年，阿里云持续地在 Serverless 领域进行投入，支持了包括镜像部署、预留实力、微服务场景等。
2
Serverless 市场概况
在2021年最新的 Forrester 评测中，阿里云 Serverless 产品能力是中国第一、全球领先，阿里云的 Serverless 用户占比也是中国第一。这侧面说明了阿里云 Serverless 是已经越来越多地进入到企业真实的生产环境中，越来越多的企业认可 Serverless 以及阿里云 Serverless 的能力和价值。
3
SAE解决方案
可以看到，在传统的微服务架构下面，企业要用好微服务相关的技术需要自己研发非常多的解决方案，那么在 Serverless 时代下，在 SAE 这个产品里面是怎么解决的？
我们可以看到，SAE 将 Serverless 这个理念发扬到了极致，不仅仅托管了 IaaS 资源，包括上层的 K8s，另外还集成了白屏化的 PaaS 以及企业级微服务相关的套件和可观测相关的套件。在 SAE 整体解决方案里面，针对这些都进行了很好的集成，给用户提供了一个开箱即用的微服务解决方案，让企业和开发者能够很简单地使用微服务。
1、0 门槛 PaaS
图中可以看到，SAE 在最上层给用户提供的是一个白屏化的操作系统，它的设计理念非常符合企业一般的 PaaS 系统，包括发布系统或者一些开源的 PaaS 系统，这样极大地降低了企业上手 SAE 的门槛，甚至可以说零门槛，包括它也集成了阿里巴巴最佳的一些发布，即发布三板斧——可观测、可灰度、可回滚。
另外它也提供了一些企业级能力的增强，包括命名空间环境隔离、细粒度的权限控制等等。从图中可以看到，在一个企业里面，如果有两个相互比较独立的模块，完全可以通过命名空间进程进行隔离。
2、微服务治理增强
在微服务治理增强方面，特别是在 Java 语言，SAE 采用了一个 agent，对用户来说相当于是无侵入、无感知、零升级，而且 agent 的全面兼容开源，使用户几乎在无修改的情况下，就可以使用无损下限、API 管理、限流降级、链路追踪等等能力。
3、前后端全链路灰度
这里展开两个能力，第一个能力是前后端全链路灰度。SAE 借助前面提到的 agent 技术，从 web请求到网关到 consumer 到 provide 进行了一个全链路的打通，使用户可以通过很简单的白屏化配置，就可以实现一个灰度发布场景。而这样的技术如果企业需要自建，这里面的复杂度大家应该是非常清楚的。
4、CloudToolkit 端云联调
第二个能力就是 CloudToolkit 的端云联调。大家都知道微服务的场景下面应用数量是呈现一个爆炸的趋势，如果本地需要开发，需要启动那么多的应用，如何能够安全便捷地联调云上的一个服务？现在借助 CloudToolkit，用户可以很简单地在本地就打通云上的环境，进行一个端云联调，极大地降低开发测试的门槛。
5、强大的应用监控
下载文档
