서버를 사용하지 않는 알리 미들웨어는이 문제를 해결하는 방법도 전체 상황을 타개하지 마십시오?

알리 자매 검토 : 서버를 사용하지 않는 주제는 매우 광범위한는 거의 응용 프로그램 수명주기의 모든 측면과 관련된 코드 관리, 테스트, 릴리스, 운영 및 유지 보수 및 용량 확장을 포함 다룹니다. 코드가 서버를 사용하지 않는 아키텍처로 마이그레이션 할 수있는 방법을 온라인 응용 프로그램을 변경하지 마십시오? 오늘, 온라인 애플리케이션의 알리바바 수천의 우리 비밀 서버를 사용하지 않는 진화.

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가 : 서버를 사용하지 않는 기술 한 후, (10 2 사이의 변동) 역 2, 마케팅 부, 11에서 기계의 수를 줄여 서비스 트래픽 피크 순간의 수만 수천 급증, CSE 순간 탄성 확장 > 5 개 세트 - -> 10, 아래 2 개 단위 용적 축소 후의 피크 흐름에서 2.

전력 서비스 제공 업체 B : 2-4에서 기계의 수의 서버를 사용 (10 ~ 2 사이의 변동).

전기 공급 사업 C : - 1 스테이션 인스턴스간에 변동 서버를 사용 완료 후 4 고정 기계 전에이 기계는 국번 (변동 사이의 1 ~ 4), 사전에 0이 달성된다.

저자 :
왕 Xiaorui : 별명 선서 케리, 알리바바 수석 기술 전문가, 아파치 RocketMQ 설립자 및 의자, 알리바바 진화 서버를 사용하지 않는 아키텍처와 클라우드 컴퓨팅 방향 메시징 미들웨어 제품 라인에 온라인 트래픽을 유도하기위한 최근 책임, 알리바바 중간 조각 혁신 연구소 및 메시징 미들웨어 프로젝트 팀 리더.

원래 릴리스 시간 : 2019년 6월 4일가
저자 : 케리 선서
Yunqi 커뮤니티 파트너의 기사, " 알리 기술은 "정보를 우려 할 수있다 " 알리 기술을 ."