Atlassian的Stash数据中心为Git提供了高可用性及可伸缩性
Atlassian最近发布了Stash数据中心，这是一个具有高可用性以及横向扩展能力的部署选择，用于本地源代码与Git库管理解决方案Stash。这套系统能够在不产生停机时间的情况下直接添加新节点，以实现双主机方式（active/active）的集群以及即时的可伸缩性。\u0026#xD;\n\u0026#xD;\n在Stash推出数据中心之前，JIRA与Confluence的数据中心版本已经先行问
Atlassian最近发布了Stash数据中心，这是一个具有高可用性以及横向扩展能力的部署选择，用于本地源代码与Git库管理解决方案Stash。这套系统能够在不产生停机时间的情况下直接添加新节点，以实现双主机方式（active/active）的集群以及即时的可伸缩性。
\u0026#xD;\n\u0026#xD;\n在Stash推出数据中心之前，JIRA与Confluence的数据中心版本已经先行问世，数据中心版本服务是为企业级使用场景设计的，这些场景要求“高可用性，以及大规模使用情况下的良好性能”。这些服务提供了与单机版产品相同的终端用户特性，它们使用了非常类似的集群技术，以实现处理大量并发用户、实现应用程序弹性以及提高服务质量的优点。这些服务的许可方式是基于用户的数量，而不是服务器或CPU的数量，这样就使得客户能够选择自定义的、灵活的基础设施，并且也易于估算成本。
\u0026#xD;\n\u0026#xD;\nStash服务器已经在“全球超过1万3千个组织中得到使用”，它包含了许多面向企业环境的特性，例如：
\u0026#xD;\n\u0026#xD;\n- 支持代码审查，以及根据不同的Git工作流、围绕着pull request进行协作，包括自动进行分支合并，以及为保持质量需求而进行全面检查。\u0026#xD;\n\t
- 将开发工作流与JIRA和Bamboo进行整合，为开发者提供了例如根据Jira issue创建Git分支以及状态自动转换、以及通过分支检测创建构建计划的功能。\u0026#xD;\n\t
- 通过完善的REST API获得扩展能力，并从Atlassian Marketplace网站上下载各种插件\u0026#xD;\n\t
- 具有细粒度的代码访问控制，可在全局、项目、库或分支的级别设置权限，同时也提供了对允许哪些人接受并合并pull request的控制能力。\u0026#xD;\n
Stash服务器已经为企业级的应用、高可用性及可伸缩性提供了详细的指南。而通过使用Stash数据中心集群，可以实现更高的能力。
\u0026#xD;\n\u0026#xD;\n- 大规模的高性能 —— 通过添加新的节点，为更多的并发用户提供服务\u0026#xD;\n\t
- 通过故障转移实现高可用性 —— 双主机方式的集群能够容忍节点的丢失，而将对用户的影响降至最低、甚至是零。\u0026#xD;\n\t
- 即时的可伸缩性 —— 新的节点能够快速上线，而不会产生停机时间\u0026#xD;\n
InfoQ有幸采访了Atlassian开发者工具部门的总经理Eric Wittman，谈及了Atlassian最新推出的数据中心服务。
\u0026#xD;\n\u0026#xD;\nInfoQ：Stach服务器已经为一个单服务器上的数千个用户提供了横向扩展的能力，这些服务器已经用于各种小型与大型公司了。那么，在Stash数据中心中进一步提升可伸缩性的主要动力是什么呢？
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nWittman：虽然你可以为大量的用户选择纵向扩展的方式，但纵向扩展受限于物理服务器的数量，而我们想避免这一点，为用户提供横向扩展的能力。一方面，我们的目的是让客户能够将扩展能力提高到1万个用户以上，而我们通过Stash数据中心提供更高的可伸缩性的另一个主要动力，是因为在各大组织不断推进它们的持续集成实践的情况下，在高峰期间，构建服务器对他们的SCM系统会产生极大的压力，新的数据中心将能够应对这种压力。
\u0026#xD;\n
InfoQ：在Stash数据中心的文档中表示，它能够以近乎线性的方式横向扩展到至少4个以上的节点，而由于服务价格是按照用户数量进行计算的，因此你鼓励客户“想要几个节点就加几个节点”。那么对于支持的用户数量是否存在上限呢？
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nWittman：我们对于Stash数据中心所支持的用户数量并没有设定上限。我们在测试中最多使用了4个节点，通过对它的可伸缩性进行衡量，我们就能得出一个集群能够处理的整体吞吐量。能够支持的用户数量不仅取决于节点的数量，也取决于来自于其它自动化系统的压力，例如持续集成。
\u0026#xD;\n
InfoQ：对Git进行大规模化是一种很严峻的技术挑战。你是否能简单地提一下你们是如何实现这一点的，比例你们是否对Git的默认行为进行了一些改变？
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nWittman：我们在多台机器上进行了横向扩展、添加了更多的CPU和内存，并且使用了本地磁盘缓存，这些都有助于缓解资源的占用，尤其是Git托管操作。此外，我们在集群节点上使用了额外的快速本地磁盘，这也为我们的SCM缓存带来了好处。除此这外，我们对Git本身并没有进行任何改变。
\u0026#xD;\n
- 在Atlassian Summit 2014大会上，Atlassian Stash架构师Stefan Saasen进行了一场名为“大规模化Git”的演讲，对底层的Git概念、所面对的挑战和迁移进行了深入的探讨。\u0026#xD;\n
InfoQ：Stash通常会与Atlassian的其它工具共同使用，例如JIRA和Bamboo，这样可以更好地集成工作流。你们的客户当中是否有人仅仅单独使用Stash呢？
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nWittman：我们确实有些客户仅仅使用Stash工具，并且从Stash的细粒度权限控制中受益良多，但多数Stash的客户不仅使用了Stash中细粒度的代码访问控制能力，同时也与JIRA和Bamboo的工作流集成使用。
\u0026#xD;\n
InfoQ：你的同事Tim Pettersen近期详细地说明了由Stash与Bitbucket所带来的“更好的pull request模型”，但要实现这个更复杂的算法，也需要额外的资源。你能否为我们总结一下为什么你们倾向于这种途径吗？
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nWittman：Stash和Bitbucket中的pull request算法比起其它Git解决方案中的算法，具有两点主要的优势：
\u0026#xD;\n\u0026#xD;\n
- 可以在pull request中显示出合并冲突，如果开发者的代码产生冲突，他们就可以共同讨论如何解决这个冲突。\u0026#xD;\n\t
- 审查者能够看到某个特性分支上的变更对master分支会产生怎样的影响，这样就能够对最终在产品中发布的代码有一个更好的认识，从而减少了最终会发布到客户手上的产品的缺陷数量。\u0026#xD;\n
InfoQ：Atlassian已经在Docker上发布了Stash，目前还只用于评估的目的。这一系统是否也支持集群化的部署方式，你是否认为这一系统今后能够成为你们的产品部署选项中的一种？
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nWittman：Docker部署方式目前还不支持集群化的部署，因为主要的目的是让开发者进行评估。我们将对使用Docker映像作为今后产品的一种部署选项进行评估，而这取决于Docker作为一个平台的成熟度，以及客户在这方面的需求。
\u0026#xD;\n
Stash 3.8最近刚刚发布，进一步改善了一些操作的功能，引入了完全无头的（headless）上线过程，并且使用了JMX性能计数器，可用于衡量“项目与库的数量、Git的push与pull操作的数量，以及各种线程池方面的指标”。
\u0026#xD;\n\u0026#xD;\nStash数据中心的文档提供了更多的细节，包括与故障转移、性能、可伸缩性有关的章节以及一篇FAQ。Stash用户文档同样加入了更多细节内容，而开发者文档中则涵盖了通过插件或远程REST API对Stash进行扩展的途径。在Atlassian支持门户中提供了常规的Stash支持资源，同样也提供了专门的企业服务与支持项目。
\u0026#xD;\n\u0026#xD;\n查看英文原文：Atlassian’s Stash Data Center Offers High Availability and Scalability for Git
开放原子开发者工作坊旨在鼓励更多人参与开源活动，与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动，如meetup、训练营等，主打技术交流，干货满满，真诚地邀请各位开发者共同参与！
更多推荐
0
0- 0
已为社区贡献46条内容
所有评论(0)