はじめに：この記事では、サーバーレス時代のマイクロサービスの開発と、その過程で遭遇する比較的複雑な要件を紹介します。これらに直面して、Alibaba CloudのサーバーレスアプリケーションエンジンSAEは、「サーバーレス」の概念を最下位レベルから極限まで引き継いでいます。 IaaS、上位層のK8、アプリケーションPaaS、CICD、マイクロサービススイートの統合、監視可能な拡張機能などはすべて「サーバーレス」方式でホストされており、マイクロサービスシナリオ向けのSAEの完全なソリューションを実現しています。
著者：
陳新
サーバーレス時代におけるマイクロサービスの開発と課題
初期の頃、ビジネスの規模は比較的単純でした。ほとんどのチームは、チームのビジネスニーズを十分に満たし、迅速に反復できる単一のアプリケーションを開発しました。しかし、事業規模の継続的な拡大に伴い、システムはますます複雑になり、1つのアプリケーションでオンライン生産の問題に徐々に対応できなくなります。たとえば、eコマースビジネスでは、トランザクション、支払い、商品などのすべての機能が1つのアプリケーションで開発される場合、単純な商品を公開する機能がトランザクションに影響を与え、それによってeコマース全体に影響を与える可能性があります。システムと企業に損失を引き起こします。
現時点では、多くのチームがモノリシックアプリケーションアーキテクチャをマイクロサービスアーキテクチャに変更して、モノリシックアプリケーションの問題を解決します。しかし、ビジネスがさらに発展するにつれて、システムはより複雑になり、クラウドネイティブ時代の標準K8やコンテナイメージDockerなどの新しいテクノロジーの出現により、研究開発、運用、保守への投資が行われます。各サービスの通常の運用と協力は、運用と保守に大きな課題をもたらします。
1.効率：アプリケーション規模の拡大に伴い、新しいR＆Dチームは、開発とテストにおいて多くの複雑な問題に直面する必要があります。チームコラボレーションの観点から、異なるアプリケーションチーム間で安定したコールリンクをより適切に形成する方法、および数十、数百、さらには数千のアプリケーションを含む大規模なシナリオで、コールリンクにアプリケーションを迅速に展開してグレースケールする方法。さらに、非常に多くのアプリケーションのトラフィックの処理、コールチェーンの追跡、およびサービス認証も効率に大きく影響します。
2.安定性：マイクロサービス化後、呼び出し元リンクのコアアプリケーションに問題が発生し、システム全体が雪崩になり、問題をすばやく特定して分析するのに役立つ視覚的で観察可能なシステムが不足する場合があります。問題をすばやく特定することが困難になります。問題を適用すると、長期的な損失が発生します。
3.コスト：通常、単一のアプリケーションは数台のマシンをデプロイするだけで済みます。マイクロサービスの時代では、アプリケーションの数が急増しているため、可用性を考慮して、アプリケーションごとにある程度の冗長性を維持する必要があります。たとえば、大規模なプロモーションでは、1つのコールリンクに12を超えるアプリケーションが含まれます。コールリンクの安定性とセキュリティのために、リンク全体のアプリケーション容量が拡張されます。実際、多くのアプリケーションには、長期間トラフィックがない場合があります。時間、そしてサーバーがアイドル状態になる可能性があり、莫大なコストの浪費につながります。
マイクロサービスによってもたらされるこれらの問題と要件に直面して、サーバーレスアプリケーションエンジンはこの点でどのような作業を行いましたか？それはどのような変化をもたらしましたか？
SAEマイクロサービスアプリケーションのフルマネージドソリューションの紹介
SAEは、マイクロサービスアプリケーション向けのサーバーレスPaaSプラットフォームです。クラウドプラットフォームとして、マイクロサービスアプリケーションのライフサイクル全体をホストできます。サーバーレスとK8s自体のメリットを組み合わせて、マイクロサービスアプリケーションをすばやくオンラインにすることができます。すぐに使用できる製品化された形式でユーザーに迅速に提供し、ユーザーに共通のマイクロサービスの問題を解決し、研究開発の効率を向上させます。
SAEは、CI / CDパイプライン、マイクロサービスフレームワーク、Spring Cloud、Dubbo、共有レジストリ、K8sコンテナなどの機能と、コールチェーン、ログ、アラーム、パフォーマンスモニタリング、トラフィック管理、自動弾力性などの多くの運用および保守関連機能を提供します。 、など。これは、サーバーレスフレームワークとマイクロサービスを緊密に統合するためのベストプラクティスプラットフォームです。
SAEマイクロサービスの機能と実践
基盤となる機能：拡張されたマイクロサービス機能
サーバーレス時代のマイクロサービスのトレンドは、クライアントがますます薄くなり、サービスガバナンスやビジネスロジックに関係のない部分が、バイトコードを介してビジネスに注入されるJavaエージェントやビジネスなどのコンポーネントに組み込まれることです。開発これは、非侵入的かつ非知覚的であり、プロセスで豊富なマイクロサービスガバナンス機能を提供します。たとえば、ロスレスオンラインおよびオフライン、カナリアパブリッシング、ビジュアルデータレポートなどのトラフィック管理関連機能。
Java以外のシナリオの場合、Javaエージェントはさまざまなマイクロサービスフレームワークと通信することもできます。また、サイドカーとの通信も工事中です。
開発の実践：デバイスとクラウドの共同デバッグ
Alibaba CloudToolkitプラグイン+Springboardに基づくサーバーレスアプリケーションエンジン（SAE）は、次のことを実現できます。
- ローカルサービスのサブスクリプションとクラウドSAE組み込み登録センターへの登録。
- ローカルサービスは、クラウドSAEサービスを使用して相互に呼び出すことができます。
在实现的时候用户需要有一个 ECS 代理服务器，实际注册的是 ECS 代理服务器到 SAE 的注册中心，IDEA 在安装 Cloudtoolkit 插件以后，在启动进程时，会在本地拉起一个通道服务，这个通道服务会连上 ECS 代理服务器，本地所有的请求都会转到 ECS 代理服务器上，云端对服务的调用也会通过 ECS 代理转到本地，这样就可以以最新的代码在本地断点调试，这就是云端联调的实现。
发布态实践：无损下线
在版本更换的过程中，SAE 是如何保证旧版本的微服务流量可以无损地下线掉？
上图是微服务注册和发行的整个流程，图中有服务消费者和服务提供者，服务提供者分别有 B1、B2 两台实例，服务消费者分别有 A1、A2 两台实例。
B1、B2 把自己注册到注册中心，消费者从注册中心刷新服务列表，发现服务提供者 B1、B2，正常情况下，消费者开始调用 B1 或者 B2，服务提供者 B 需要发布新版本，先对其中一个节点进行操作，如 B1，首先停止 Java 进程，服务停止过程又分为主动销毁和被动销毁，主动销毁是准实时的，被动销毁的时间由不同的注册中心决定，最差的情况可能需要一分钟。如果应用是正常停止，Spring Cloud 和 Dubbo 框架的 ShutdownHook 能正常被执行，这一步的耗时基本上是可以忽略不计的。
如果应用是非正常停止，比如说直接 Kill-9 的一个停止，或者是 Docker 镜像构建的时候，Java 进程不是一号进程，且没有把 Kill 信号传递给应用的话，那么服务提供者不会主动去注销节点，它会等待注册中心去发现、被动地去感知服务下线的过程。
当微服务注册中心感知到服务下线以后，会通知服务消费者其中一个服务节点已下线，这里有两种方式：注册中心的推送和消费者的轮巡。注册中心刷新服务列表，感知到提供者已经下线一个节点，这一步对于 Dubbo 框架来说不存在，但对于 Spring Cloud 来说，它最差的刷新时间是 30 秒。等消费者的服务列表更新以后，就不再调用下线节点 B。从第 2 步到第 6 步的过程中，注册中心如果是 Eureka，最差的情况需要消耗两分钟；如果是 Nacos，最差的情况需要消耗 50 秒。
在这个时间内请求都有可能出现问题，所以发布的时候会出现各种报错。
经过上面的分析，在传统的发布流程中，客户端有一个服务端调用报错期，这是由于客户端没有及时感知到服务端下线的实例造成的，这种情况主要是因为服务提供者借助微服务，通知消费者来更新服务提供的列表造成的。
那能否绕过注册中心，服务提供者直接通知服务消费者？答案是肯定的。SAE 做了两件事情，第一，服务提供者在应用发布前，会主动向服务注册中心注销应用，并将应用标记为已下线状态，将原来停止进程阶段的注销变成了 preStop 阶段注销进程。
在接收到服务消费者的请求时，首先会正常处理本次请求，并且通知服务消费者此节点已经下线，在此之后消费者收到通知后，会立即刷新自己的服务列表，在此之后服务消费者就不会再把请求发到服务提供者 B1 的实例上。
通过上面这个方案，就使得下线感知时间大大缩短，从原来的分钟级别做到准实时的，确保你的应用在下线时能够做到业务无损。
运行态实践：可观测
运行态的实例，服务的运行过程中会出现这样或者那样的问题，怎么去排查和解决它？
排查和解决的前提是必须具有强大的应用监控能力和诊断能力，SAE 集成了云产品 ARMS，能够让跑在上面的 Java 微服务看到应用的调用关系拓扑图，可以定位到你的 MySQL 慢服务方法的调用堆栈，进而定位到代码级别的问题。
たとえば、リクエストの応答が遅く、ビジネスに問題がある場合、どのリクエスト、どのサービス、およびサービスのどのコード行に問題があるかを特定できるため、問題の解決に非常に便利です。問題。一般に、サービス運用の過程で問題をより適切に診断できるようにするために、最初に監視と警告を行う機能が必要です。
カスタマーケース
要約する
この記事では、サーバーレス時代のマイクロサービスの開発と、その過程で遭遇する比較的複雑な要件を紹介します。これらに直面して、Alibaba CloudのサーバーレスアプリケーションエンジンSAEは、「サーバーレス」の概念を、最低レベルのIaaSから上位レベルのK8、アプリケーションPaaS、CICD、マイクロサービススイートの統合、監視可能な拡張機能などはすべて「サーバーレス」モードでホストされており、マイクロサービスシナリオ向けのSAEの完全なソリューションを実現しています。
今後、SAEは、マイクロサービスシナリオでの機能を強化し、エンドツーエンドのソリューションを作成し、開発者がフォールトインジェクション、フルリンクストレステスト、多言語マイクロサービスなどのマイクロサービステクノロジーに直面するためのしきい値を下げていきます。 。サービスなど。サーバーレスのシナリオでは、複雑さは実際にはユーザーによってプラットフォームに渡されるため、非常に多くのアプリケーションを運用および保守する方法も当社のコア機能であり、今後も投資と改善を続けていきます。
元のリンク：click.aliyun.com/m/100034866…
この記事はAlibabaCloudのオリジナルコンテンツであり、許可なく複製することはできません。