codenvy 端口_Codenvy的体系结构，第1部分-CSDN博客

Codenvy是一个云IDE，提供多种产品，如Codenvy.com、Codenvy Enterprise和Codenvy ISV。它有别于桌面IDE，云IDE在云中托管并提供构建和运行时环境。 Codenvy平台SDK采用插件式架构，支持创建和扩展不同的云IDE，具有云客户端API和服务器服务。 Codenvy.com为用户提供专用和共享资源的配置选项。用户管理和认证服务基于Java认证和授权服务，支持匿名和命名用户，以及公共和私人项目。系统通过ACL控制访问权限，并支持多租户，实现灵活的资源管理和协作模式。

摘要由CSDN通过智能技术生成

codenvy 端口

1.0概述

Codenvy是一个云IDE，有将近100,000个开发人员使用它来编码，构建和测试应用程序。

本文介绍了Codenvy的各种技术和站点的体系结构。

（点击图片放大）

我们的架构由我们打算推出的各种产品驱动：

Codenvy.com-具有支持，SLA和硬件的托管云IDE。
Codenvy Enterprise-使组织能够在自己的服务器上编码，构建，测试和部署应用程序。
Codenvy ISV-使用提升的工厂，可货币化的插件和IDElet来驱动和衡量已发布的SDK和API的技术参与度。工厂是一种使用策略启动临时代码，构建，测试，调试工作区的方法。 IDElet是可嵌入代码，构建，测试，调试工作流，可以插入到另一个产品中。
Codenvy平台-一种云IDE引擎，为开发人员提供了一种开发，测试和运行工具插件和应用程序的方式。

Codenvy平台用作提供Codenvy.com，Codenvy Enterprise和Codenvy ISV的引擎。它也可以用于创建其他IDE，并带有实现者所需的任何品牌。该SDK的结构与Eclipse平台相似，但专为云环境而设计。它还为开发用于构建，运行，测试和调试工作流的插件提供支持，这些插件通常在IDE本身之外运行。

架构讨论分为两部分：1）驱动Codenvy Platform的SDK，以及2）扩展SDK来创建Codenvy.com的组件。

2.0云IDE和桌面IDE之间的差异

两种类型的IDE之间的主要技术差异是-通常-使用桌面IDE，IDE供应商期望打包，构建，测试和运行时环境是在工具本身之外安装和管理的。并非总是如此，因为某些真正高级的IDE会负责将这些附加组件安装到主机上，但通常并非如此。

在云IDE环境中，IDE完全存在于云中。但是，通常，云IDE供应商除了执行IDE外，还必须在托管位置提供构建和运行时环境。

这种区别既带来了希望，也带来了挑战。云IDES的承诺是，云IDE供应商可以完全部署在云中，可以提供更多组件，更快地完成操作，并有可能降低配置的故障率。挑战包括管理工作区的额外开销，该工作区现在除了项目，代码，构建器和运行器外还包括一个IDE。

2.1云IDE工作空间管理的方法

在云中管理工作区通常采用两种方法：

授予用户专用的VM，他们可以在其中获得特权，包括安装文件和其他可以编辑，构建或执行的软件。
用户共享同质结构的池化资源，用于IDE功能（即，重构），构建功能和运行功能的命令分布在针对每个功能优化的不同群集中。开发环境越均匀，操作员的系统操作就越密集。不利的一面是，这些系统灵活性较差，不太适合项目开发人员。

Codenvy.com为用户提供两种配置。

对于高级计划的用户，我们将使用第一个配置，为他们提供带有SSH选项的专用VM。（该计划将于2013年第四季度提供。）可以在VM上安装不同的构建和运行时软件。然后，可以重新配置在Codenvy系统中运行的IDE，以指向生成，运行和调试命令以执行驻留在专用VM中的进程。

对于免费计划的用户，我们运营着一组集中式服务器，这些服务器分为三个集群：一个集群用于IDE，一个集群用于构建器，一个集群用于运行器。每个群集之间都有一个队列系统，每个群集之间来回限制活动。每个群集可以独立于其他群集扩展，并允许整个群集中更高的密度。 IDE群集可扩展其I / O和内存的瓶颈，在计算上构建群集，并在内存上运行群集。

3.0 CODENVY PLATFORM SDK体系结构

由于开发人员提出了各种不同的开发工作流程，因此我们需要设计一种引擎，以允许创建不同的云IDE，这些IDE可以改变系统的行为及其感觉。多年来，Eclipse和JetBrains生成了一些定义良好的结构化插件结构，这些接口可以扩展到多租户云环境。

该SDK包括：

一个云客户端运行时，用于发现，注册，加载和管理插件。运行时还负责管理与参与工具工作流程的系统的一组多租户入站和出站外部连接。
一个云客户端SDK，可用于开发多租户云客户端插件。 SDK提供了用于处理资源，事件和用户界面的通用模型。插件可以以可扩展的，定义明确的格式彼此集成或分层。
一组标准插件，可以从运行时中排除（如果需要），以提供与核心开发工具有关的功能。当前的插件集包括：git，Java，CSS，Python，HTML，Ruby，XML，PHP，JavaScript，Browser Shell和maven。
默认的IDE包含用于组织代码存储库，项目，文件，构建集成，运行时/调试器集成以及部署/发布工作流的结构化工作台。该IDE是一组集成插件的软件包，可提供一组默认工具。可通过代表每种工具功能的浏览器或一组RESTful Web服务访问此IDE。

3.1插入式架构

构建IDE的基础是创建，打包，部署和更新插件的能力。插件本身是可扩展的，并且可以分层，以便一个插件可以调用和扩展另一个插件。

SDK设计为具有Web应用程序和服务器端应用程序服务的两层应用程序。这两个层次都是可扩展的，可以由第三方进行修改。

插件使用Java，GWT和CDI编写。整个接口系统都使用注入和面向方面的编程作为扩展插件，将插件连接在一起以及将插件链接到IDE本身的技术。 CDI的注入和接口系统使在插件前面创建一个非常干净，简单的接口成为可能。使用GWT是因为它具有许多优化功能，可以生成可在许多浏览器上运行的标准和高性能JavaScript代码。

这是一个空白插件，它将菜单项添加到IDE，该菜单项在被选中时会更改状态。该插件可以在其自己的工作流程中进行编译，测试和验证。注入用于扩展Java类的构造函数，并且这些注入可用于添加传递到扩展本身的其他参数。

package com.codenvy.ide.extension.demo;

import com.codenvy.ide.api.editor.EditorAgent;
import com.codenvy.ide.api.extension.Extension;
import com.codenvy.ide.api.ui.action.ActionManager;
import com.codenvy.ide.api.ui.workspace.WorkspaceAgent;
import com.google.inject.Inject;
import com.google.inject.Singleton;

/**
 * Extension used to demonstrate the IDE 2.0 SDK fetures
 *
 * @author <a href="mailto:nzamosenchuk@exoplatform.com">Nikolay Zamosenchuk</a>
 */
@Singleton
@Extension(title = "Demo extension", version = "3.0.0")
public class DemoExtension {

    @Inject
    public DemoExtension(final WorkspaceAgent workspace,
                         ActionManager actionManager,
                         EditorAgent editorAgent) {

       menu.addMenuItem("Project/Some Project Operation", new ExtendedCommand() {
           @Override
           public Expression inContext() {
               return projectOpenedExpression;
           }

           @Override
           public ImageResource getIcon() {
               return null;
           }

           @Override
           public void execute() {
               Window.alert("This is test item. The item changes enable/disable state when something happend.");
           }

           @Override
           public Expression canExecute() {
               return null;
           }

           @Override
           public String getToolTip() {
               return null;
           }
       });
    }
}

3.2插件服务和API

插件具有各种可以使用的服务和API。提供了三类服务。

3.2.1 IDE客户端API

这些是开发人员期望在平台中使用的典型API，以帮助他们为IDE本身的客户端部分创建可视扩展。这包括用于首选项，菜单，视图，助手，向导，工具栏，选择，编辑器，热键等的软件包。还有一组公用库，其中包含UI组件和其他实用程序功能。

默认IDE附带提供了一组顶级的标准化视图。这些视图包含各种透视图和面板，并且可以由插件本身直接访问。控制台，编辑器，项目资源管理器，菜单，表单，外壳和向导都有视图。

3.2.2 IDE服务器服务

为了使插件能够访问在云环境中运行的工作空间，提供了一组标准的RESTful API，可用于允许插件与云开发环境进行交互。云管理构建集群，运行集群，所有文件都保留在其中的虚拟文件系统，Codenvy与外部/第三方服务之间的连接池，用于管理用户凭据的身份管理服务器，用于计费/订阅的接口以及其他高级功能。计算功能，这些功能最好在云中卸载，而不是在浏览器中处理。

Codenvy的平台不同于大多数云IDE。开发人员的工作空间跨用于服务不同IDE功能的不同物理资源进行了虚拟化。依赖管理，构建，运行器和代码助手可以在物理节点的不同群集上执行。为了正确虚拟化对所有这些资源的访问，我们需要实现一个VFS，该VFS支持服务和物理资源，但也具有对IDE行为的原生了解。

卸载服务的一个示例是重构。由于重构命令可能需要更改许多文件中的内容，包括重命名某些文件和删除其他文件，因此将重构作为云服务而不是在浏览器中进行处理更为有效。此功能作为一组RESTful服务公开，可以由插件本身直接访问。

3.3插入生命周期

插件本身是指示服务器端和客户端以某种方式运行的代码的组合。由于客户端是GWT，并且核心IDE本身也是用GWT编写的，因此必须将与其他IDE一起编译加载到系统中的插件，以每次生成新的IDE。核心IDE GWT代码和插件提供者编写的GWT扩展的组合创建了一个编译的二进制代码集，该代码集生成了一个集成的，优化JavaScript集，即UI本身。插件本身打包为单个JAR文件，在创建阶段与IDE WAR结合在一起。

可以使用一组已加载的插件来运行SDK运行时，然后激活或停用通过配置文件主动向用户显示哪些插件。引导时插件的可配置性允许对整个IDE的内存和CPU标记进行一些微调的控制。

ISV和其他第三方开发人员需要构建和测试他们编写的插件的方法。插件部署有三种模式：

独立。插件在专用计算机上创作，编译，然后使用自定义的Codenvy运行时（即WAR文件）启动。通常，这是在台式机上完成的，但也可以作为托管服务来完成。有一个标准化的插件项目模板，带有一组相关的maven构建命令，以在Codenvy SDK的可下载版本中启用此打包。
托管的SDK。位于codenvy-sdk.com上，这是运行Codenvy平台的影子站点。它提供了一个基本的IDE，可以在其中创建，编译和执行插件。执行的插件将加载到实例化的IDE中。所有这些都是在浏览器中进行的，实例化的IDE正在以不同的进程（即Tomcat服务器）运行。本质上，开发人员正在使用影子Codenvy创建更多Codenvy实例，并加载了一个插件来测试行为和功能。插件类型的每个“运行”都会导致另一个JVM使用不同的IDE负载配置启动。
Codenvy.com。我们将经过批准的插件合并到Codenvy.com的生产版本中，构建一组Selenium测试以使接口测试自动化，然后激活以供社区使用。

当前，所有已加载的插件均已激活。我们最终将创建一种机制，该机制允许Codenvy.com上的命名用户识别哪些插件在其命名工作空间中处于活动状态。

4.0 CODENVY.COM体系结构

我们使用为平台提供动力的引擎来创建Codenvy.com，这是一个具有弹性，托管和受支持的环境。我们将Codenvy.com设想为一个持续存在的实体，可以通过各种不同的角色进行访问。因此，Codenvy.com主要是一个具有不同接口的系统。开发人员使用浏览器来利用系统。 Devops和ISV具有用于访问工作流和按需创建IDE的程序化界面，内部受众具有用于查看分析数据，管理用户/工作区以及指示系统在无人值守时应如何操作的配置界面。

（点击图片放大）

4.1客户服务器通信

浏览器通过WebSocket和HTTP REST连接与Codenvy进行交互。启动工作空间会话时，将建立连接。浏览器和服务器之间的通信受到限制，并且仅限于需要服务器访问的功能。服务器访问功能与访问新文件，定期自动保存，构建服务，事件日志记录和运行程序服务有关。没有心跳，并且已对协议进行了优化以最大程度地减少网络流量。

当需要进行持续的协作讨论时，我们将使用WebSocket通信。对于多用户编辑和聊天窗口，在协作会话中最经常发生这种情况。由于WebSocket会消耗服务器上的大量资源，因此我们将HTTP REST连接用于单向或即发即弃的任何命令，例如用户发起构建请求，重构，提交PAAS部署，或提交日志事件。

4.2临时VS. 命名的工作空间

Codenvy具有临时工作区的概念。临时工作区是具有项目，代码存储库以及一些代码，构建，测试，调试服务的工作区，但结构化为隔离区，因此无法长期保存工作。此外，如果长时间闲置或关闭浏览器，临时工作空间将被破坏。在临时工作空间中，对于某些操作，必须重复某些行为，例如，对外部提供者进行身份验证，因为系统不会保留任何这些凭据。永久工作空间绑定到用户或组织，并且其中的项目得以保留。此外，系统将保留帐户信息，外部服务的凭据（例如GitHub的SSH密钥），并允许公共/私有项目功能。

临时工作空间对于未经身份验证的用户和经过身份验证的用户都具有相似的行为。对于只希望在临时空间中工作的开发人员，所有分解项目都在临时工作区中开始。对于拥有注册帐户的用户，他们可以将项目复制到其永久工作区中。对于没有帐户的用户，他们可以执行身份验证过程，并且在确认身份验证后将复制项目。

临时工作空间和命名工作空间之间的体系结构差异是，是否使用持久性存储（LDAP）来存储相关的帐户信息。临时工作空间具有完整的用户配置文件；但是，由于该信息完全保留在内存中，因此租户本身的任何破坏都将抹去整个项目空间。我们还将所有临时租户放入虚拟文件系统的隔离部分，以便能够针对这些文件运行批处理清理和报告算法。

4.3用户管理和认证服务

可以通过基于表单的登录名或OAuth对用户进行身份验证。我们使用Java身份验证和授权服务作为处理身份验证的核心技术。每当用户尝试访问受URL引用的受保护资源时，都会进行身份验证。某些URL引用不受保护（公共），而另一些则受保护（私有）。进行身份验证后，系统会尝试确定用户应访问的工作空间和项目。如果所引用的URL没有明确的工作空间引用，则将用户重新路由到其他工作空间和租户选择算法。

（点击图片放大）

4.4匿名与命名用户

命名用户是具有关联帐户并被授予访问受保护资源的可配置权限的用户。匿名用户是他们访问系统的地方，并且无法将可识别的凭据与该帐户关联。匿名用户可以存在以下两种情况之一：

没有cookie的用户将启动Factory操作，并将其放置在临时工作区中。
用户可以访问公共项目URL，并以只读模式通过该URL输入产品。

对于匿名用户和命名用户，系统的行为是不同的。对于匿名用户，管理员可以通过可通过配置文件访问的一组配置参数来配置产品的哪些功能。匿名用户必须创建一个帐户或进行身份验证（在产品外部或产品内部），以便重新激活这些功能。匿名用户还必须将所有流量都路由到IDE群集，该IDE群集与处理命名用户流量的其他IDE群集隔离。这种路由和隔离是使用我们编写的HAProxy和云管理IP进行的。

在体系结构上，匿名用户具有自动生成的用户名，该用户名不会保留在LDAP中。它们仅在内存中。匿名用户和命名用户都具有一组相关联的权限，并且都是组的成员。匿名用户的关联组和权限是预先确定的，不能更改。

4.5公共VS. 私人项目

Codenvy支持公共和私人项目的概念。公共项目是指有权访问URL的任何人都可以访问项目空间或其任何文件的项目。我们最终将通过网站上的导航目录公开所有这些公共项目，但是今天，它需要明确了解URL才能获得访问权限。

我们使用ACL来控制工作区，项目和文件的行为。在工作区，每个项目以及子目录中关联的文件集的虚拟文件系统上设置ACL。我们可以通过根的任何子目录传播ACL属性。对于指定为完全公共的工作空间（例如，在我们的社区计划中），我们在虚拟文件系统的根目录下设置了一组标准的ACL，并使其无法更改。对于私有项目，然后使这些ACL可以修改。无论是组还是个人，都可以设置和修改ACL。

4.6邀请与厂

当邀请一个用户进入另一个用户的工作区时，他们必须具有适当的密钥才能获得访问权限。对于被邀请到工作区的现有Codenvy用户，我们会自动将来自被邀请用户的邀请密钥关联到邀请者的工作区中。对于与Codenvy帐户无关的电子邮件地址的邀请，我们将生成一个临时密钥，并将其与他们的电子邮件一起存储在LDAP存储库中，然后通过链接和密钥向用户发送电子邮件。当用户单击链接时，我们将应用临时密钥，然后授予该用户访问邀请他们的帐户的权限。

对于访问公共工作区的用户，不需要密钥。我们创建一个自动访问密钥，该密钥授予匿名或命名用户对工作区本身某些访问权限。这些通常是读取文件的权限，以及数量有限的项目，构建和运行功能。

对于单击“工厂”的用户，我们将创建一个单独的临时工作区。不邀请用户使用工厂。任何有权访问Factory URL的用户都可以使用该Factory。如果访问工厂的用户已经过身份验证，那么我们可以识别出该身份，并允许他们将内容复制到其现有工作空间中。如果用户未通过身份验证，我们将在临时工作区会话期间创建一个匿名用户帐户。

4.7合作模式

打开文件时，可以使用标准编辑器或协作编辑器来完成。

（点击图片放大）

标准编辑器仅在单个JVM中运行，而对其他JVM中发生的情况一无所知。这意味着该编辑器仅对显式打开它的用户可用，并且不适用于真正的协作模式。可以为网络上的连接较弱或ping时间较长而影响WebSocket性能的环境启动标准编辑器。使用标准的编辑器，可以控制消耗的内存空间，并且用户可以保证完全手动保存。

协作编辑器是Codenvy平台中的默认编辑器类型。我们扩展了Google的collide开源项目，以允许多个用户同时编辑文件。协作编辑器控制虚拟文件系统中的文件锁，然后实时协调每个用户对文件所做的更改。碰撞编辑器能够定期将更改异步保存到文件中，并将保存事件传播回最终用户屏幕，以使他们知道持久性更改。此外，协作编辑器可同时同步同一编辑器/文件组合中的各个用户之间的事件。

4.8多租户

IDE群集，构建器和运行器有不同的租赁模型。

IDE群集。在此群集中，我们为每个节点运行一个JVM，该JVM消耗了该节点上所有可用的内存和计算。在JVM内，我们使用一些内部IP在JVM本身内启用多租户。每个工作区都分配有自己的线程，内存和虚拟文件空间。当在单个JVM中用其自己的IDE实例化工作区时，我们将路由器配置为将HTTP请求和WebSocket连接映射到正确的IDE。并且IDE本身被映射到其中的适当目录。通常，在HAProxy必须启动另一个IDE服务器之前，我们能够在AWS的中等实例上运行的单个JVM中操作大约300个IDE租户。
构建集群。在构建集群中，有一组队列在集群的前端。在队列前面有一个BuildManager服务，可通过RESTful Web服务访问该服务。 BuildManager处理消息的收集，排序和处理。构建消息根据传入的客户端上下文（例如付费/免费帐户）路由到队列。有一个管理控制台，用于指定为队列分配多少个节点。我们为社区层（免费）运行一个处理队列，然后每个高级订阅（付费）都有一个专用队列。然后，使用该模型，我们可以将多个硬件节点分配到一个工作空间，队列管理器可以在不同的构建节点之间平衡工作空间请求。客户端IDE会定期轮询分配给其进程的构建器，以收集输出和日志文件，以便在浏览器本身中显示。
跑步者集群。与构建集群类似，在构建集群和运行集群之间也有一个队列系统。构建集群可以向运行器集群下达命令，或者命令可以直接来自IDE。运行器群集上的每个节点都运行CloudFoundry的多租户部署。 CloudFoundry盒式磁带用于确定引导的服务器的环境配置。

在 本文的 第2部分中 ，我们将介绍以下Codenvy主题：使用的虚拟文件系统，如何实现日志记录和分析，托管的API，集群管理，总体情况，发布模型和用于开发的SCRUM流程。