Serverless 时代下微服务应用全托管解决方案
——捌哥
云原生应用平台
一、Serverless时代下微服务发展与挑战
在业务规模比较简单的早期，大多团队采用单体应用，彼时单体应用已经能够很好地满足团队的业务需求，并且在较小规模的业务研发团队中能够快速迭代。
随着业务规模的不断增长，系统变得越来越复杂，单体应用逐渐无法满足线上生产的问题。比如电商应用中，如果将交易、商品支付功能都集中在单体应用里，发布简单查询功能也可能会影响到交易，从而对整个电商系统产生影响，给企业造成损失。
因此，单体应用逐渐被微服务应用替代，微服务应用的优势能够在生产效率上不断迭代。比如从原来单体复杂的 spring MVC 架构，演变为微服务应用中成熟的 Dubbo 框架，让开发更轻量化。能够将商品团队应用的发布与交易团队解耦，保证商品团队在发布过程中不会影响交易。
随着业务进一步发展，系统愈加复杂，加之新技术的到来，比如云原生时代下 K8S 成了标准以及 Docker 容器镜像，再次加速了微服务化的过程。
世界上不存在完美的架构。根据复杂守恒性定律，虽然在单体应用环节解决了一部分系统的复杂性，但是随着业务规模的不断发展以及新技术的引入，新增了诸多复杂性，也会对现有的方式造成影响，主要体现在以下三个方面：
1.效率：随着应用规模的扩张，新的研发团队需要面临很多开发和测试中的复杂性问题。在团队协作上，不同应用团队之间如何更好地形成稳定的调用链路，在几十几百甚至上千个应用的场景下如何进行调用链路的快速部署亟待解决。此外，流量的处理、调用链路的跟踪和服务鉴权也非常影响效率。
2.稳定：微服务化之后，会出现调用链路上某核心环节出现问题，导致其他环节发生雪崩，且难以定位到具体问题所在环节。需要可视化、可观测性的工具来帮助快速定位分析问题。
3.成本：单体应用一般只需部署几台机器；到了微服务时代，随着应用数的剧增，出于可用性的考虑需要为每个应用保持一些冗余，比如一次大促中，一个调用链路会涉及到十几个应用，为了稳定性以及调用链路的安全，会进行整个链路应用的扩容，而实际上很多应用可能长时间没有流量，服务器空闲，导致巨大的成本浪费。
针对以上问题，我们总结了云原生 Serverless 时代下微服务发展的几个趋势解：
① 后端服务的 BaaS 化。将 DB、MQ、配置中心以及服务治理中心等后端微服务中间件相关的应用独立出来，做成一个后端服务，让研发人员将更多中心放在核心的业务逻辑。
② 客户端轻量化。将与业务无关相关的服务治理逻辑、服务注册发现逻辑沉淀到 Java agent 或 Sidecar 等第三方的应用上，对业务更透明，方便业务快速上云。同时也能让业务团队将重心集中在业务研发的逻辑上，从而提升研发效率。
③ 业务侧 Serverless 化。很多业务可以将应用完全托管在 SAE 这样的云原生 Serverless 平台上，对其进行全生命周期的管理，包括应用的启停、发布、回滚等。在一些流量高峰场景下能进行快速自动扩缩容，能够根据业务的流量或者指标满足整个链路的安全健康水位。另外，通过集成可观测组件，完善日志、 metrics 以及 tracing 等全调用链路的分析，提高整体应用的可观测性，能够帮助业务快速发现问题、定位问题。
因此，针对微服务场景，我们不仅限于提供资源的平台，更多的是希望与微服务已有架构更好地融合，并利用云上的服务与平台自身的应用进行最佳协同，从而达到降本增效的功能。
二、SAE微服务应用全托管解决方案介绍
SAE 是面向微服务应用的Serverless PaaS 平台。作为云平台，它能够为微服务进行全生命周期的赋能。它能将一些标准化的微服务应用以及 Serverless 加 K8S本身的红利集中在一起，让微服务应用快速上线。以产品化的形式快速提供给用户，开箱即用，以解决用户常见的微服务问题，提升研发效率。
SAE 提供了包含但不限于 CI/CD 流水线、微服务框架、Spring Cloud、Dubbo 、共享注册中心、K8S 容器以及诸多运维相关的功能，包含调用链、日志、告警、性能监控、流量的治理以及自动弹性等。它提供了无服务 Serverless 框架与微服务进行深度结合的最佳实践的平台。
功能一：微服务治理增强。
在Serverless 时代下，微服务的趋势是客户端越来越薄，其中与服务治理、业务逻辑无关的部分被沉淀在Java agent等组件里，通过字节码的方式集成到业务中，业务无侵入、无感知，并在过程中提供了丰富的微服务治理能力。比如流量管理相关的无损上下线、金丝雀发布、可视化数据上报等能力。
针对非 Java 场景，Java agent 也能够与不同的微服务框架进行通信。此外，与 Sidecar 之间的通信也正在不断完善建设中。
功能二：无损下线。
比如某个业务 APP 后端的服务需要升级做发布，它的服务提供者被发布重启之后，消费者无法短时间内感知服务发布的变化，导致会将流量打到错误的 IP 上，造成业务报错。
SAE 的无损上下线功能能够很好地解决上述问题，它对原有的基于注册中心的服务上下线过程进行了增强。首先在业务调研过程中，提供者主动向数字中心进行注销，同时通知消费者服务发生变化需要更新本地的服务列表信息，从而及时感知到最新上线的服务以及最新下线的服务，以选择正确的服务列表进行调用。
无损上下线能可将原先发布过程中的报错率降低 90%。
功能三：前后端全链路灰度。
在实际的业务开发过程中，可能需要通过业务请求的 cookie 或 header 甚至一些内部 IP 灰度到新发布的实例或功能上，并基于功能做一些流量验证或基本的灰度验证。
SAE 打通了此类前后端调用的 http 请求，通过网关以及微服务体系下的服务发现者和服务消费者，基于 Java agent 组件进行规则的过滤，用户通过白屏化的配置即可实现前后端的全链路灰度。
功能四：可观测。
在微服务发展过程中，服务快速定位的问题可以通过可观测功能得以解决。可观测功能包括Metrics、Tracing 和 Logging ，它们在 SAE 里进行了深度集成。SAE通过打通阿里云的ARMS 云监控、SLS 以及普罗米修斯等可观测性产品，在以上三方面都提供了非常完整的解决方案，能够很好地帮助开发者解决微服调用过程中的痛点。
针对基础监控调用链、实时日志的追踪以及具体的调用事件，能够快速定位问题，帮助用户在复杂的微服务场景下快速止损，维持正常的系统运行。
三、SAE 上微服务功能最佳实践
在微服务开发过程中，开发人员往往希望在测试环境有主干的稳定版本，能够在主干上进行快速回归。同时，在开发新功能时，也希望在本地的开发机器上能够快速运行并验证，因此希望将本地的正常流量和测试流量区分开。
而 SAE 能够轻松满足上述要求。主要应用了两个基础功能：基于端云联调的能力和针对微服务飞度的能力。分为以下四步：
步骤一：将应用部署在 SAE 测试环境。此处需要独立的注册中心。
步骤二：配置端云联调互联。需要购买 ECS 代理服务器（带公网IP），能够帮助打通本地的开发环境和 SAE 的测试环境。对中心进行打标，并且下载 agent 到本地。
步骤三：快速启动本地测试应用，进行联调验证。
步骤四：发起流量调用验证。针对正常流量以及需要测试的流量，做基于 header 的区分。
Demo演示
第一步：首先将 SAE 应用通过控制台部署到单独的测试环境，包括将应用连接到购买的注册中心上。
第二步：进行端云联调的设置。购买代理器，并在 IDE 环境下进行配置。选择购买的注册中心、带有公网 IP 的地址，并在本地环境做 local 打标。完成以上准备工作以后，即可在本地启动应用。
第三步，验证环节。正常流量会通过网关打到 A 路径上，返回路径上对应的测试环主干链路的应用 IP ，可以看到 A 应用是170，B 应用是161，C 应用是 162 。只需要将对应的测试流量标加上“--head ”以及将mse-tag 设置为此前在 IDE 里做好的标志“local”即可调用。
返回的是127.0.0.1接口，说明流量已经在 A 应用和 B 应用上都已打到本地的 A’和 C’两个实例上， C应用依然走主干，实现了开发和测试环境流量隔离的效果。
四、客户案例
广州小迈步是以数字化领先为优势的互联网科技公司。它在 SAE 上部署了十几款流量巨大的游戏 App ，后端应用也在 SAE 上进行了微服务化部署，充分利用了 SAE 上的微服务能力。
针对游戏场景的客户的个性化需求，比如系统的稳定性以及针对平台进行快速扩缩容、灰度发布以及无损上下线， SAE 提供的微服务能力能够很好地提供解决方案，为用户简化运维、降低成本并提升效率，帮助用户在短时间内快速上线新游戏，带来很好的客户价值。
未来，SAE 在微服务场景下也会持续保持能力增强。希望能够提供端到端的终极解决方案，帮助用户降低微服务开发过程中的门槛，提供新的、高阶的微服务功能，比如故障注入、全链路压测等。我们也会在运维好微服务应用的同时，不断持续投入，打造核心能力。
