全托管：MSE+SAE 微服务应用全托管解决方案
——毕衫
阿里云 SAE 研发负责人
一、微服务架构的优点和痛点
微服务架构的诞生背景经历了几个阶段：
互联网早期主要是门户时代，大部分应用都是单体应用，主要的挑战在于单纯的技术挑战，研发团队相对较小。
进入新世纪互联网时代后，以腾讯和阿里为代表的社交电商巨头开始面临流量和复杂度大增的挑战。此时的研发团队相较于之前已经明显扩大，并开始实践 SOA /微服务架构，比如阿里的 HSF。
进入移动互联网时代后，人们的生活全面互联网化，不仅是巨头企业，越来越多的互联网公司也开始面对流量和复杂度爆发，而且研发团队进一步扩大。此时除了研发效率的要求，微服务架构也成为了比较普适性的需求，许多新的词汇被提出，比如微服务架构，比如开源的解决方案Spring Cloud、Spring Cloud Alibaba等。
今天，我们已经进入了全面数字化阶段。面对社会全面数字化的转型，流量和复杂度的挑战愈发普遍，团队规模大，效率要求高，使得微服务架构再一次发挥了它的优势。
微服务架构到底有什么样的优点和缺点？
单体架构的缺点比较明显，共享代码库比较容易冲突，边界不清、模块耦合，团队效率低。
而微服务架构正好解决了以上问题，它的核心手段就是拆分：解耦研发态，解耦部署态，最终达到释放团队效率的效果。
微服务解决了单体架构的很多问题，除此之外，它还能解决哪些问题？
上图中蓝色部分是业务系统（业务应用），灰色部分是引入了微服务技术架构以后，研发团队需要解决的各种技术复杂度问题，包括网关 CI/CD 、微服务的框架、配置中心、注册中心、限流降级、压测工具、监控系统、告警系统、服务治理等，甚至还需要处理 K8s 、IaaS 本身的运维复杂度。
微服务虽然解决了研发效率问题，但随着团队的扩大以及技术复杂度的增高，它也带来很多额外开销。因此很多公司会设立 10 人以下的团队专门解决这类开销问题，包括 v5 框架、运维基础设施等。然而，这类团队的工作成果是否能得到公司的认可依然存疑。
阿里云 MSE+SAE 微服应用全托管解决方案能够完美解决以上问题。从网关到微服务套件到资源和 K8s 的托管以及监控、CI/CD ，都可以全套交给云原生解决方案。
SAE 其实是 serverless 的新形态， All on Serverless 覆盖的场景从微服务到 web 应用到前端全栈等场景。它底下的基础设施是 serverless 化的，用户无须关心；在应用层，它提供了应用管理、微服务治理和运维配套。
基于此，低门槛的微服务架构转型有了最佳实践。
上图左侧灰色部分是原先采用微服务架构开发模式下需要处理的一些复杂度，右侧代表采用 MSE+SAE 的微服务全托管解决方案以后需要处理的复杂度。可以看到用户几乎只须专注于业务的开发，无须再关心其他问题。
MSE+SAE 的微服务全托管解决方案具有以下几个特性：
1.微服务治理增强。
在 MSE+SAE 的前提下， SAE 平台直接提供了 agent 注入到用户的应用中，用户无需去感知 agent 存在，jar 包可以直接部署到 ACE 平台，实现 0 升级成本。借助 agent 还能够实现以下能力，包括无损发布、离群摘除、服务测试、限流降级、故障注入等。
2.前后端全链路灰度
在微服务场景下，全链路灰度是比较典型的诉求，流量从浏览器打到用户的微服务网关，再打到消费者，最后打到提供者。在提供了 agent 的背景下， SAE 可以基于用户 ID 或其他cookie 来达到指定灰度路由的效果。
3.CloudToolkit 端云调用
在微服务场景下，开发者可能有 10-20 个应用，如果需要在本地开发，将这些应用全量启动，是难以实现的工程。而 MSE+SAE 借助于阿里云 CloudToolkit 的能力，达到了本地和云上环境微服务联调的效果，本地只需启动统一的 consumer 或 provider ，即可直接和云上环境进行互通，流量直接转到本地，达到了最大化简化微服务开发的效果。
4.强大的应用监控&诊断
包括 Metrics 、Tracing 和 Logging 。
那么，从原先的平台迁移到MSE+SAE 平台，是否需要修改整体架构？
MSE+SAE作为弹性资源池降本，流量从外部的负载均衡或用户的 Nginx 进入。用户如果原先采用了 ECS， 则在常态化的流量下依旧可以继续打到 ECS ，弹性流量可以打到 SAE。 适用于弹性时间极短或峰值流量和常态流量差异较小、或想从 ECS 迁移到 SAE 过渡方案的用户。
