Clay.io的Zoli Kahan开始了“10X”系列博文的撰写

近日,Clay.io的Zoli Kahan开始了“10X”系列博文的撰写。通过这个系列博文,Zoli将分享如何只使用一个很小的团队支撑Clay.io的大规模应用。首期分享则是对Clay.io所使用技术的盘点。

下为译文

云方面

CloudFlare

CloudFlare主要负责支撑DNS,并作为一个防护DDoS攻击的缓存代理,同时CloudFlare还负责处理SSL。

Amazon EC2 + VPC + NAT服务器

基本上Clay.io的所有服务器都是Amazon EC2类型,其中大部分是中大型实例。同时,我们还使用Amazon VPC将所有服务器托管在一个私有网络,从而这些服务器很难在外网访问。为了访问这些私有网络,我们还配置了一个NAT服务器,它同时也作为一个VPN终端,用以内部网络使用。

Amazon S3

我们使用Amazon S3作为应用的CDN后端,它托管了Clay.io的所有静态内容。为了安全和性能因素,我们为之配置一个独立的域名——cdn.wtf,一个cookie-less域名。

HAProxy

HAProxy是一个非常高性能的反向代理,我们使用它将流量路由到不同的服务。基于Clay.io的性质和平台所需支撑的内容(比如遗留代码),HAProxy意义重大。在以后文章中,我将对这点进行深入讨论。

当下,Clay.io使用的是一个配置了m3.medium的HAProxy服务器。在流量增加后,HAProxy必将迎来一次无可避免的升级。此外我们还会在前端增加一个Amazon ELB,在需要时进行横向扩展。

应用服务器——Docker

Docker用于管理Linux容器,类似于轻量级的Virtual Machines(同时还省略了隔离和安全保障)。Docker的好处是可以做代码封装,并且忽略底层服务器特性做任意的代码重用/移植,在下文我们将详细介绍。

演示应用服务器——Docker

在Clay.io,演示环境服务器和应用程序服务器相同,并且和生产环境运行相同的二进制Docker文件。对于防止不必要的生产系统破坏和宕机,这种设置环境非常重要。

数据存储

MySQL

MySQL是一个久经沙场的关系型SQL数据库,当下Clay.io的数据大部分都依赖一个主从设置的MySQL集群。在这个集群中,一个主节点和两个从节点服务器支撑了大部分的用户查询。当然,在未来我们可能需要对主节点进行分片。但是期望不要太早,因为我们正在考量其他数据库。

Logstash

Logstash是个日志聚合工具,通过Kibana进行分析。当下,它基本上负责了Clay.io所有的应用程序日志,以备系统发生错误时使用。使用Kibana,我们避免了必须SSH到一个机器进行日志检查。

MongoDB

MongoDB是个NoSQL文档存储数据库,当下MongoDB为我们的一些开发端点和A/B测试框架Flak Cannon提供服务。

Memcached

Memcached使用了键值存储类型,非常类似于Redis。Memcached在Clay.io主要负责一些遗留Web应用,用以缓存MySQL的查询结果。毫无疑问,随着系统的迭代,最终它将完全被Redis取代。

DevOps

Ansible

在我们系统中,Ansible被作为服务器管理工具的一个选择。对于大部分开发者来说,它非常易于学习和使用,Ansible可以帮助许多日常DevOps的自动化处理,由一个专门的运营团队负责。

其他服务

GitHub

GitHub——无需多言,这是个非常强大的源代码管理工具。

Uptime Robot

Uptime Robot是个免费的监测服务,我们使用它来监测健康检查和端点。如果有问题发生,它可以在5分钟内给我们发送电子邮件和文本消息。

Drone.io

Drone.io是一个连续的集成服务,我们使用它为各种项目连续不断的运行测试集。它非常类似于TravisCI,近日我们还释放了一个开源的自托管版本。

Docker Registry

当下,我们使用官方的Docker Registry来管理Docker容器,它类似于Docker专用的GitHub。

New Relic

New Relic是个服务器和应用程序监视服务,主要用于服务器监视,在磁盘和内存满载时进行提醒。

Google Analytics

Google Analytics是我们主要的网站分析跟踪工具,用于跟踪网站具体功能,我们使用了定制事件特性。

Google Apps

Google Apps为我们clay.io域名提供邮件,并为机构提供了一个共享的Google Drive设置。

Last Pass

Last Pass是一个密码管理服务,它允许我们便捷的在所有团队共享公司认证信息。

未来

虽然我们对当下的设置已经比较满意,但是我们仍然期望在数个月内对系统的某些方面进行升级。审视最初的基础设施版本,有许多地方并没有花大量的时间去设计。而就是这些地方,成了未来系统扩展时必须面对的瓶颈。

Kubernetes在大规模Docker容器管理上表现出了惊人的潜力,也是我们重点跟踪的项目之一。毫无疑问,在该项目成熟时,必将成为我们生产环境的一部分。 Amazon Glacier,用于数据库备份,是我们未来的一个实现目标。 RethinkDB,虽然当下还非常不成熟,但其潜力不容忽视。和Docker一样,我们将紧跟这个项目的发展。在未来弃用MySQL时,它将是一个不错的选择。 原文链接:How Clay.Io Built Their 10x Architecture Using AWS, Docker, HAProxy, And Lots More(编译/童阳 责编/仲浩)

免费订阅“CSDN云计算(左)和CSDN大数据(右)”微信公众号,实时掌握第一手云中消息,了解最新的大数据进展!

CSDN发布虚拟化、Docker、OpenStack、CloudStack、数据中心等相关云计算资讯,     分享Hadoop、Spark、NoSQL/NewSQL、HBase、Impala、内存计算、流计算、机器学习和智能算法等相关大数据观点,提供云计算和大数据技术、平台、实践和产业信息等服务。

时间: 2024-10-27 07:52:22

Clay.io的Zoli Kahan开始了“10X”系列博文的撰写的相关文章

Clay.io基于AWS、Docker、HAProxy等的10X架构打造

近日,Clay.io的Zoli Kahan开始了"10X"系列博文的撰写.通过这个系列博文,Zoli将分享如何只使用一个很小的团队支撑Clay.io的大规模应用.首期分享则是对Clay.io所使用技术的盘点. 下为译文 云方面 CloudFlare CloudFlare主要负责支撑DNS,并作为一个防护DDoS攻击的缓存代理,同时CloudFlare还负责处理SSL. Amazon EC2 + VPC + NAT服务器 基本上Clay.io的所有服务器都是Amazon EC2类型,其中

10x系列之Clay.io的服务发现

本文讲的是10x系列之Clay.io的服务发现,[编者的话]Clay.io的Zoli Kahan撰写了"10X"系列博文,分享如何只使用一个很小的团队支撑Clay.io的大规模应用.本文是整个系列的第四篇,介绍如何构建一个服务发现系统. 架构 面向服务的架构是构建绝大多数产品的最可迭代和可用的软件配置之一.这些系统也遇到过很多问题,其中最大的问题可能就是服务发现问题.服务发现实际定义了你的服务如何与其它服务通信.Docker里也有这个问题.如果你不知道我们如何部署Docker,请参看D

整理 25个超好的 HTML5+JavaScript 游戏引擎库

对于一个游戏开发者,寻找一个可以与 JavaScript 和 HTML5 无缝工作的游戏引擎是一个不错的解决方案.市面上有很多免费和付费的游戏引擎,让专业的游戏开发者满意的游戏引擎肯定需要包含独特的东西.游戏开发者对完美游戏引擎的追求永远不会停止. 下面我们整理出地球上使用最好的html5和javascript游戏引擎列表,每个游戏引擎有每个人想要的特性.每个游戏引擎有他自己的优缺点,这样你可以根据你自己的需求做选择,我确定这个列表中有你在寻找的游戏引擎 1) Canvas Engine Can

HTML5 game engines

  The following are few examples of game engines implemented with HTML5 and JavaScript: Construct 2: One of the first WebGL enabled HTML5 game engines. Exports purely to HTML5 and JavaScript. Uses Canvas only and is extensible with JavaScript plugins

Node.js事件驱动

  Node.Js是基于javascript语言,建构在google V8 engine以及Linux上的一个非阻塞事件驱动IO框架.这里主要不是介绍nodejs具体应用代码,而是想介绍一下事件驱动编程. Node.js事件驱动实现概览 虽然在ECMAScript的标准里并没有(也没有必要)明确规定"事件",但是在浏览器中,事件作为一个极为重要的机制,给予JavaScript响应用户操作与DOM变化的能力;在Node.js中,异步事件驱动模型则是其高并发能力的基础. 学习JavaScr

JAVA拾遗录

本系列博文主要收录Java中一些常见的但是平常又容易忘记.记错或者记混的知识点的集合.各个知识点之间没有必然的联系,可以随意跳着看,希望能够对各位同学有所帮助. 本博文持续更新.修改,转载请保留原文链接. 1. JAVA堆和栈的区别 堆和栈都是内存的一部分,有着不同的作用,而且一个程序需要在这片区域上分配内存.众所周知,所有的JAVA程序都运行在JVM上,这里所说的自然是JVM中的堆和栈. 最主要的区别就是栈内存用来存储局部变量和方法调用.而堆内存用来存储Java中的对象.无论是成员变量,局部变

前端知识图谱,你值得收藏

综合类 - [前端知识体系](http://www.cnblogs.com/sb19871023/p/3894452.html) - [前端知识结构](https://github.com/JacksonTian/fks) - [Web前端开发大系概览](https://github.com/unruledboy/WebFrontEndStack) - [Web前端开发大系概览-中文版](http://www.cnblogs.com/unruledboy/p/WebFrontEndStack.h

领域驱动设计系列(转)

曾经参与过系统维护或是在现有系统中进行迭代开发的软件工程师们,你们是否有过这样的痛苦经历:当需要修改一个Bug的时候,面对一个类中成百上千行的代码,没有注释,千奇百怪的方法和变量名字,层层嵌套的方法调用,混乱不堪的结构,不要说准确找到Bug所在的位置,就是要清晰知道一段代码究竟是做了什么也非常困难.最终,改对了一个Bug,却多冒出N个新Bug.同样的情况,当你拿到一份新的需求,需要在现有系统中添加功能的时候,面对一行行完全过程式的代码,需要使用一个功能时,不知道是应该自己编写,还是应该寻找是否已

《WCF后续之旅》博文系列总结[共17篇]

<我的WCF之旅>系列自开篇以来,得到了园子里很多朋友的厚爱,并荣登了博客园2007年度系列博文Top 10.由于工作原因,沉寂了一阵,两个月前开始WCF新的旅程.如果说<我的WCF之旅>主要是对WCF基本原理概括性介绍,而对于这个新的系列,我将和大家分享我对WCF的一些实现机制.设计原理的理解,以及我在实际的项目开发中的一些实践经验(比如在后续的一些文章中,我将介绍通过WCF Extension实现一些在真正的分布式项目开发中很有现实意义的功能). [第1篇] WCF是如何通过B