サーバレスアリミドルウェアは、この問題を解決する方法のいっぱいのものを変更しないでください？

アリの姉妹REVIEW：サーバレストピックは非常に広いをカバーし、ほとんどそれはアプリケーションのライフサイクルのあらゆる側面に関連したコード管理、テスト、リリース、運用・保守および容量の拡張が含まれています。オンラインアプリケーションでは、コードがサーバレスアーキテクチャに移行することができますどのように変化しないのですか？オンラインアプリケーションのAlibabaの何千もの今日、私たちの秘密サーバレス進化。

AWSラムダは、象徴的な製品のサーバレスフィールドですが、それがコアビジネスに適用された場合は、次のような問題が発生する可能性があり:(ビューのちょうど私のポイント）

これは、ユニットの開発、新開発フレームワーク、強力な結合クラウド・ベンダー、コミュニティの主流の高い技術スタックの移行コストとして機能するように、ユーザが必要です。
関数の開始速度は十分速い、またはミリ秒第二は、この制限は、シーンに強い制約が適用されます。
機能はAPIゲートウェイ、長い応答時間を経ての間に呼び出されます。

クラウドサービスエンジンクラウドサービスエンジン（以下、CSEと呼ばれる）、AWSラムダとの様々な利点を目的とした一般的なサーバレスコンピューティング・ミドルウェア製品のためのアリクラウドミドルウェアの開発チーム、およびAWSラムダを使用する際にユーザーエクスペリエンスを解決することができます問題。

サーバレスとは何ですか？

公式サイトから取得したサーバレスの定義:( AWS）のためのAWS

AWSが提供するAWS非機能サーバプラットフォーム:(公式サイトから引用）

AWSパッケージサーバレスプログラムは非常によく、それがどのように株式サーバレスのアーキテクチャのアプリケーションの移行の問題に対処していません。唯一の新しいアプリケーションの開発のためには、サーバレスアーキテクチャをオンにするチャンスがあり、開発のFAASの方法を使用することをお勧めします。私は、大規模なプロモーションのサーバレスアーキテクチャに、ストックビジネスのためのソリューションを持っていることができなければならない、と信じています。

クラウドコンピューティングの価値のサーバレス

云计算，归根结底是一种 IT 服务提供模式，不论是公共云还是专有云（以 IT 设备的归属不同分类），其本质都是帮助 IT 的最终使用者随时随地，并且简便快速地，获取 IT 服务，目前，IaaS、PaaS 都已经做到了按需付费，PaaS 甚至做到了按请求付费，如 DB，CACHE，MQ 等，但是 IaaS 的付费粒度仍然是时间维度，最快按照小时付费，以分钟来交付。

因此，当下的云计算场景，应用的开发维护方式相比传统 IDC 时代的开发维护，差别还不是很大。但 AWS Lambda 提供了一种全新的开发维护方式，用户只需要写好业务代码，提交到云上，所有和机器容量、可用性、机器为单位的运维工作可以全部交给了云平台，这种模式极大地释放了云的弹性价值，真正做到了按需付费。

CSE 试图提供一种更规模化的解决方案，像 AWS Lambda 一样，能进一步释放云的弹性价值，并且可以平滑迁移存量应用。

存量在线业务实现 Serverless 架构的挑战

存量在线应用程序具有以下特点：

资源分配速度 = 分钟级
应用程序启动速度 = 10分钟+

基于以上客观条件，通常做法是提前预定好机器数量来应对任意时刻的流量峰值，假设上述技术参数变为毫秒级，就有机会将应用程序架构演变成下图所示方式。

上图中，Service A 在调用 Service B 时，如果 B 的容量充足，则调用成功；如果 B 的容量不足，这时候如果线程池满，则直接触发限流阀值，A 会收到一个错误码，然后直接调用资源总控系统，资源总控系统负责新分配一个 Service B 实例，这个分配的速度非常快，耗时几十毫秒，同时把 B 的服务地址直接返回给 A，A 会将之前未完成的请求发送到新创建的 Service B。

以上过程对于开发者完全透明，具备了以下价值：

价值一：无需管理服务器，即无需容量评估；容量评估这件事情对于应用负责人一直是一个极难解的问题，因为我们很难预测未来的峰值是什么。
价值二：持续扩展；之前的做法是每个应用程序独占一定数量的资源，如果变成Serverless 模式，所有应用程序可以共享资源池，每个应用程序几乎可以无限扩展。
价值三：按照请求计费；因为每个实例的启动时间甚至比 FaaS 的函数启动时间还快，就可以像 FaaS 一样来核算成本，成本只与以下因素有关：

请求数量（QPS）
每次请求CPU执行时间，例如100ms
每个实例的内存规格

综上所述：为了做到以上描述的分布式架构，关键技术点在于应用启动速度，这里的应用启动速度是指应用可以正常处理流量为止。

如何将应用启动速度提高到毫秒级？

应用在启动过程中通常会初始化多个组件，如各种中间件、数据结构，以及网络调用外部服务。在阿里内部广泛使用 SOA 和微服务的情况下，应用在启动过程中会大量加载共享业务 SDK，存在启动过程达到10分钟量级的情况，个别应用可能会更长。因此，这个启动过程必须提前完成，才有机会以“临阵磨枪”的方式去创建新实例。

方案一：应用冷启动资源压缩方案

L1 弹性能力是指在一台物理机或者大规格的 ECS 上部署同一个应用的多个实例，通过操作系统和 JVM 的优化，一个占用 4G 内存的应用，即使部署10份，仅需占用2.2G RAM。

L1 总结来看是一种高密度部署方式，由于应用已经提前启动，并且对容器进行冻结，意味着这个应用实例 CPU 占用率为0，RAM 占用相当于之前的1/20，但是具备了毫秒级弹性的能力。L1的特点是启动速度极快，但是需要消耗资源，且只能垂直弹性。

L2 是通过将应用程序启动后在 RAM 中的指令和数据结构 dump 到磁盘文件，只需要在机器之间拷贝文件即可以达到横向弹性的能力，这个时间消耗主要是数据的网络传输时间+内存拷贝时间，大约在5秒左右就可以完成。L2 的成本开销只有网络磁盘容量，开销极低，可忽略不计。

L2 的每个 SNAOSHOT 对应一个可运行的实例，例如预计一个应用需要最大启动100个实例，那么需要提前生成100个 SNAOSHOT，每个 SNAOSHOT 对应一个运行实例，需要启动时，从远程磁盘加载这个 SNAPSHOT。

此方案通过 L1 和 L2 的组合来达到加速应用启动的目的，在支持一定流量脉冲能力下，可以最大50ms内启动任意应用，平均在10ms内完成。

方案二：应用热复制启动加速方案

L1 采用通过 fork 种子进程达到快速启动的效果，操作系统团队专门为此开发了 fork2 技术，与 Linux Native fork 的关键区别在于可以指定 PID 来 fork 一个进程。

L2 的单个 SNAPSHOT 可以创建多个进程，一对多关系。

两种自研方案的对比

方案一：不存在 UUID 问题，但是每种语言的 VM 要单独定制，成本效果相比方案二略差。
方案二：会存在 UUID 问题，若开发者希望应用的每个实例启动时，都赋值一个 UUID 给一个静态变量，但通过 fork 会导致每个实例的这个静态变量都相同，这与开发者预期不符。方案二的优势是更易实现、和语言无关、成本效果更优，适合 FaaS、NBF 这类场景或者开发者自己定义的开发框架，能避免 UUID 的问题。

整体来看，方案一的适用场景更广，但是实现成本更高，方案二较适合 FaaS、NBF 这类场景。

和 AWS Lambda 相比

Lambda 为了做到快速扩缩容，要求用户的应用以 Function 为单位开发，Lambda Runtime 动态加载 Function 来快速增加实例。

CSE 则通过将一个应用的多个实例启动后，共享相同的指令数据，抽取出不同的指令数据，每次启动实例只需要加载多实例的差异部分。因此可以透明兼容社区主流技术栈，如 Spring Boot，PHP/Java/Python/Node.JS 等。

CSE 的成本优势

理论模型：

Serverless 方式应用占用的实例数随时在变化，因此可以多个应用错峰使用同一台机器。

定量分析：

サーバーレス・コストの利点は、エンドユーザに、より良い全体的なコストを与えるために、スケジュールの部分等CPUシェアを混合ラインから重なり、コスト上の利点です。

CSEのコードサンプル

HSFのデモ

package com.test.pandora.hsf;

import com.alibaba.boot.hsf.annotation.HSFProvider;

@HSFProvider(serviceInterface = HelloWorldService.class)
public class HelloWorldServiceImpl implements HelloWorldService {
    @Override
    public String sayHello(String name) {
        return "hello : " + name;
    }
}

春ブーツのデモ

package com.example.java.gettingstarted;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController
public class HelloworldApplication {
  @RequestMapping("/")
  public String home() {
    return "Hello World!";
  }

  @RequestMapping("/health")
  public String healthy() {
    // Message body required though ignored
    return "Still surviving.";
  }

  public static void main(String[] args) {
    SpringApplication.run(HelloworldApplication.class, args);
  }
}

CSEの生産慣行

電力会社のビジネスA：サーバレス技術の後、（2〜10の間で変動）11からステーション2にマシンの数を減少させる、マーケティング部、サービストラフィックのピークはCSE瞬時弾性膨張、十モーメントの数千のに数千から急増> 5セット - - > 10、ダウン2つの単位体積低減後のピークフロー2から。

パワーサービスプロバイダB：2~4からマシンの数のサーバレス（〜10 2の間で変動します）。

電力会社のビジネスC： - 1ステーションのインスタンスの間で変動4サーバレスが完了した後にマシンを固定する前に、マシンは（変動との間の1〜4）局番となるが、予め0を達成しました。

著者：
王Xiaorui：ニックネーム宣誓ケリー、アリババの上級技術専門家は、Apache RocketMQの創設者＆チェア、アリババ進化サーバレスアーキテクチャとクラウドコンピューティング方向メッセージングミドルウェア製品ラインにオンライントラフィックを駆動するため、最近担当し、Alibabaの真ん中ピース革新ラボ＆メッセージングミドルウェアプロジェクトチームのリーダー。

オリジナルリリースタイム：2019年6月4日
投稿者：ケリーの宣誓
Yunqiコミュニティパートナーからの記事、「アリ・テクノロジー」の情報については、関係があり、「アリの技術を。」