简介：原来的微服务用户须要自建十分多的组件，包含 PaaS 微服务一些技术框架，运维 IaaS、K8s，还包含可观测组件等。SAE 针对这些方面都做了整体的解决方案，使用户只须要关注本人的业务零碎，这极大地升高了用户应用微服务技术的门槛。
作者 | 陈涛
微服务架构的长处和痛点
1、微服务架构的诞生背景
回到互联网晚期时代，也就是web1.0时代，过后次要是一些门户网站，单体利用是过后的支流利用，研发团队绝对较小，这时候的挑战在于技术的复杂度，以及技术人员的匮乏。
到了新世纪互联网时代，呈现了较大规模的一些利用，比方社交、电商等，流量和业务的复杂度也大幅减少，呈现了几百甚至上千人的研发团队，研发团队扩充之后，合作问题成为困扰。SOA 解决方案是互联网的产物，其外围在于分布式、拆分等。然而因为 ESB 这样一些单点的组件，所以没有失去很好的推广。阿里巴巴在过后推出的 HSF、开源的Dubbo 等技术，其实是相似于分布式的一个解决方案，过后就曾经有了微服务架构的理念。
微服务架构正式名称的诞生是在挪动互联网时代，这时的生存曾经实现全面互联网化，各种各样的生存类 APP 涌现，网民以及流量复杂度绝对于新世纪互联网时代显著加强。另外，较大规模的研发团队也已成为支流。这时候，大家广泛都对效率有了更高的谋求，而不只是原来只有几个巨头须要有这方面的技术。微服务架构以及微服务技术的推出，如 Spring Cloud、Dubbo 等框架的遍及，极大地推广了微服务技术。
当初咱们曾经进入全面的数字化时代，社会全面互联网化，各种各样的单位（包含政企、绝对传统的单位）都须要较强的研发能力。流量的挑战、业务复杂度的挑战、研发团队的扩充等，使得大家对效率有了更高的要求。这时候微服务架构失去了进一步的推广和遍及。
微服务架构通过这么多年的倒退，是经久不衰的一项技术，为什么它可能有这样继续的倒退？
2、微服务架构的长处
咱们来回顾一下微服务架构和单体架构的区别，以及微服务架构的外围劣势。
单体架构外围的问题在于抵触域太大，包含共享代码库。在研发过程中特地容易抵触；边界和模块的规模不清，使得团队效率也会升高。
而在微服务架构下，外围就在于拆分，包含解耦的研发态，解耦的部署态，极大地开释了团队的研发效率。大道至简，这也是微服务架构为什么可能继续倒退的一个起因。
3、微服务时代痛点
依据复杂性守恒定律，咱们解决了一个问题，问题会以另一种模式呈现，咱们又须要去解决。能够看到，微服务时代下会引入十分多的一些痛点，外围就是稳定性。因为从原来的一些本地调用改成近程调用当前，可能会产生稳定性的点激增，包含调度放大，即可能因为底层的一些近程调用问题，造成下层的一些不稳固，以及期间须要做的限流降级、调用链等。
在微服务时代定位一个问题的复杂度，也会成指数级的一个增长，这外面可能还须要服务治理。另外如果没有较好的设计和事后的一些构想，可能会呈现微服务利用的爆炸，包含研发人员和测试人员之间的合作也都会成问题。
微服务技术通过这么多年的倒退，业界其实曾经有了一些解决方案。
如上图显示，如果要比拟好地玩转微服务技术，除了开发本人的业务零碎以外，可能还要配套地搭建多个零碎，包含CI/CD、公布零碎、研发流程、微服务组件相干的一些工具，以及可观测性相干的实时监控、告警零碎、服务治理、调用链等等，还须要运维根底的 IaaS 资源。在这个时代，为了更好地运维 IaaS 资源，可能还须要本人保护一个K8s 集群。
所以说，在这样的背景下，很多企业会抉择搭建一个运维团队，或者中间件团队，或者说由一些后端研发同学兼职。然而试想，有多少企业对本人外部搭建的这套零碎是称心的？零碎的迭代效率是多少，有没有踩到过一些开源的坑，这些坑当初有没有解决？这些应该是在企业的CTO、架构师心中一个继续的痛点。
Serverless时代下的解决方案
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、弱小的利用监控 & 诊断
在微服务的场景下，因为微服务的急剧发散、调用链路的极度增长，在有问题的场景上面定位问题是非常复杂的。而 SAE 集成了阿里云各种各样的可观测产品，包含Prometheus、IaaS、SLS、根底监控等，在 Tracing Logging Metrics 等方面都提供了丰盛的解决方案，包含申请链路的查问，罕用的诊断场景的指标剖析，根底监控、实时日志、事件告诉等等，这些都能极大地升高企业在微服务台运行场景下的一些日常定位问题。
SAE的技术原理和极致弹性建设
后面曾经针对三局部，也就是零门槛PaaS、企业级微服务套件、可观测进行了一个解说。那么当初要介绍 Serverless 的一个外围模块，也就是 IaaS 层面上免运维以及弹性能力的建设。
1、SAE 业务架构
通过这张 SAE 的业务架构图，大家就能够绝对比拟清晰地看出，在SAE外面 IaaS 资源包含存储、网络等是不须要用户关怀的。另外 SAE 也托管了 K8s 这个 PaaS 层的一个组件，相当于用户也不须要本人去运维 K8s 。在 K8s 层之上，SAE 提供了微服务治理、利用生命周期治理等加强的能力。另外在弹性方面，SAE 的弹性能力达到了15秒，置信在很多企业级的场景下，这曾经能帮忙开发者较好地应答一些突发流量的状况。另外通过多套环境以及一些最佳实际，能够达到一个降本增效的成果。
2、SAE 技术架构
那么 SAE 是怎么建设免运维，对用户来说，相当于不须要托管的一个 IaaS 资源以及 K8s 资源呢？
上图中能够看到，SAE 底层其实是采纳了一种平安容器的技术，相比于Docker，平安容器相当于提供了虚拟机级别的一个平安解决方案。在 RunC 场景下，因为共享内核其实在私有云产品上，a用户有可能穿透到 b 用户的一个容器内，造成一些平安危险。采纳平安容器的技术，也就是虚拟机相干的平安技术，达到了一个生产级别的平安隔离，包含平安容器也进入了 K8s 以及容器的生态。这样平安容器+容器生态的联合，就实现了较好的平安+效率的一个均衡。
另外在存储和网络的隔离方面，SAE 不仅仅须要思考传统的 K8s 上的网络隔离，也须要思考在私有云产品下，大部分用户曾经在私有云上有十分多的一些存储资源、网络资源，这些也须要进行一个买通。
SAE 采纳了云产品的 ENI网卡技术，将 ENI网卡直通到了平安沙箱内，这样相当于用户不仅仅实现了一个计算层的隔离，也实现了网络层的买通。
能够看到当初支流的平安容器技术有 Kata、Firecracker、gVisor 等等，在 SAE 外面是采纳了最早也是最成熟的 Kata 技术来实现一个计算成平安的隔离。另外平安容器不仅实现了一个平安的隔离，也实现了一个性能隔离和故障隔离。
举一个比拟好了解的例子，在 RunC 大家共享内核的场景下，一个用户的 Container 造成了一些内核的故障，是间接可能影响到物理机的。在 SAE 应用平安容器根底上就没有这方面的危险，最多只会影响到那一个平安容器。
3、极致弹性 极致老本
下图中能够看到，如果弹性效率达到了一个极致，用户的老本也能够达到一个极致。通过左右两边的图的比照，大家能够了解弹性对用户老本能够达到的一个成果。
1、SAE 极致弹性建设：部署 & 重启
SAE 在弹性方面做了哪些事件呢？能够看到传统的 K8s 的一个 Pod 的创立过程须要通过调度、init container的创立、拉取用户镜像、创立用户容器、启动用户容器、利用运行等等阶段，它尽管合乎 K8s 的设计理念和标准，然而在生产环境下，对一些须要绝对比拟要求效率的场景，其实就不太满足企业级的要求。而 SAE 借助于阿里巴巴开源外面的 CloneSet 组件的原地降级策略，相当于不须要重建整个 Pod，而只须要重建外面的 container 省去了调度以及 innt containr 创立的一个过程，部署效率达到了 42% 的晋升。
2、SAE 极致弹性建设：弹性扩容
在镜像预热场景 SAE 也实现了一个并行的调度。能够看到，在规范的场景下，调度到用户拉取镜像是一个串行的过程。那么在此做了一个优化，就是在辨认到 pod 行将调入到单个物理机的时候，它就会并行地开始拉取用户的镜像，这样也能够达到一个弹性效率 30% 的晋升。
3、SAE 极致弹性建设：Java启动减速
那么在利用启动这个阶段，咱们也做了一些弹性效率能力晋升的事件。比如说 Java 的利用，在 Serverless 场景下其实始终有启动慢的痛点，外围在于 Java 须要一个个加载。而在一些企业级的利用外面，针对成千上万的 class 的加载，这必定是一个绝对较迟缓的过程。
SAE 联合阿里巴巴开源的 Dragonwell 实现了 App CDS 的技术，它会在利用第一次启动的时候，将 class 加载打到一个压缩包中，后续的利用加载，只须要加载压缩包即可，免去了大量 class 的一个串行化的加载，实现了部署效率 45% 的一个晋升。
4、SAE极致弹性建设
最初在利用运行态，咱们也做了一些弹性方面的加强。微服务的利用通常会须要配置十分多的一些线程，这些线程通常和 Linux 的底层线程是一一对应的。在高并发场景下，这外面就会有较大的线程切换的开销。SAE 联合阿里巴巴开源的 Dragonwell，WISP 线程的技术，将下层的几百个线程对应到了底层的十几个线程，极大的升高了线程切换的一个开销。
上图中是咱们一个压测的数据。红线就是应用了 Dragonwell、WISP 的技术，能够看到运行效率有 20% 左右的晋升。
以上就是 SAE 在 Serverless、IaaS 托管以及 K8s 托管方面，还有在弹性效率方面建设的一些技术原理和成果。
总结和瞻望
原来的微服务用户须要自建十分多的组件，包含 PaaS 微服务一些技术框架，运维 IaaS、K8s，还包含可观测组件等。SAE 针对这些方面都做了整体的解决方案，使用户只须要关注本人的业务零碎，这极大地升高了用户应用微服务技术的门槛。
后续 SAE 针对每个模块也会继续地的做能力的建设。包含：
• 在零门槛 PaaS 方面，微服务会继续做一些云产品的集成，包含 CICD 工具链。另外也会做企业级的能力加强，比方审批流等。
• 在 Serverless 免运维、极致弹性方面，咱们也会提供越来越多的弹性能力、弹性指标、弹性效率，这些也都会继续地建设。另外也会提供相似 AI 预测这样的弹性解决方案，升高用户设置弹性指标的时候的心智累赘。
• 在微服务生态方面，咱们也会和微服务的企业套件做更多的集成，进一步升高大家应用微服务技术的门槛，比如说混沌工程、近程调试能力加强等。
最初在可观测方面，SAE 相当于运维了用户的利用。那么可观测对于 SAE 自身或者说对平台自身也是一个十分重要的能力，在这方面咱们会继续地做相应的一些监控告警，包含预案和灰度建设等等。对用户来说，也须要在SAE上托管它的利用，这就要求产品可能升高用户在应用这方面的门槛，后续会建设利用大盘、事件核心等等。
原文链接
本文为阿里云原创内容，未经容许不得转载。