免费领取阿里云大礼包3150元+新客享0.26折起优惠

gydtep2002

Serverless计算具有四个特点：首先，不需要维护云计算基础设施，应用构建的抽象层次上升，变得更加高效；其次，能够实现实时的弹性伸缩，这样能够通过未来的数据驱动的负载感知算法能够实现既满足很低的延时，也能够实现很高的资源利用率；再次，计量模式提供了非常细粒度的按需的模式，可以实现按秒级计量，能够实现完全按需的付费模式，对于用户而言，资源利用率是100%；最后，能够实现高可用，将这种能力内置在平台层。

gydtep2002

阿里云Serverless产品体系
这里做一个说明，Serverless 计算只是阿里云 Serverless 产品中的一部分，除此之外还包括存储、API、分析、中间件等。因此，从这个角度来看，Serverless 也不是一个非常新的概念，最早的 OSS 对象存储就是一个 Serverless 产品，可以看出云产品体系正在 Serverless 化，只不过最近几年出现了函数计算这样通用的 Serverless 计算平台，进而能够将 Serverless 体系产品连接起来，构建一个 Serverless 应用。

gydtep2002

在人工代码评审（Code Review，CR）中，对于纯文本形式的代码浏览不可避免地将耗费大量的时间，影响CR的效率。那么有没有更智能的方法？阿里云云效代码智能语法服务基于云端备份的快速代码导航服务，无须本地克隆即可在页面体验熟悉的定义引用快速查看跳转功能，可大幅提升代码评审的效率和质量。本文分享相关的技术原理与实现方法。

gydtep2002

那么什么是代码智能语法服务呢？语法服务提供了基于云端备份的快速代码导航服务，无须本地克隆即可在页面体验熟悉的定义引用快速查看跳转功能，大幅提升代码评审的效率和质量。

gydtep2002

然而代码分析往往需要耗费大量的时间和资源，当用户请求某个语法服务（如查看定义），后端需要克隆代码，下载依赖包，解析语法，构建索引（类比一下IntelliJ Idea初始化工程的场景），编辑器场景用户已经习惯于这样的方式，等待几分钟或许问题不大。但CR场景或者轻量级的代码浏览场景，这种方式就显得时效性比较低了，几分钟后或许用户已经完成了代码浏览，而且缺少持久化的存储会导致资源过度消耗。

gydtep2002

我们的构建工作流调度主要基于阿里巴巴开源的分布式调度框架tbschedule，该系统会通过zookeeper维护一个任务集群，通过zookeeper做节点管理和任务分发，不重复不遗漏地快速处理调度任务。

针对不同语言，我们只需要实现一次从源代码到LSIF格式的转换，就能将其应用在多种场景。多种代码语言代码语言都会被解析成统一的LSIF格式文件。

gydtep2002

索引构建的另外一个难点是增量计算。如上文所述，语法服务索引构建对资源的要求非常高，而现实中代码库不可避免地会存在频繁提交的现象。如此引申出了两个优化点：

利用增量的方式减少存储内容的变更，加快索引构建速度。
利用分布式时序锁减少频繁请求带来的压力。

gydtep2002

每次分支索引构建成功，我们都会在数据库中记录分支对应的版本号，当该分支有了一次新的提交后，在生成lsif.json后，系统会比较两个分支的Diff，获取到变更文件和变更类型，通过变更文件来进一步提取索引受到影响的文件（引用或定义的坐标信息变更），分析出所有受影响的文件和对应的ES增删操作后，完成增量索引上传。这个增量的过程平均能减少45%的分支构建时间。

gydtep2002

第一点就是顶层设计。国家每5年有五年计划，这其实就是在国家整个层面的一个非常清晰的顶层架构设计，这里面对国民经济重大建设项目和生产力进行宏观的架构设计，它也是一种架构设计。在这里面，要做什么事要定义的非常清楚，要达到什么样的结果也要定义的非常清楚。

gydtep2002

阿里目前单元化架构达到一个什么目标呢？通过部署异地单元将生产流量完整运行在千里之外的独立机房，连续性的运行业务。这几句话里面包含了非常多的关键点，一个是异地，第二个是千里之外，第三个是独立，第四个是连续性。

单元化架构的总设计师是老毕，因为我们这块业务跟单元化的架构是非常相关的，所以要对它完成的掌握和吃透才能往下走。