在Segment早期，我们的基础设施是拼装的，我们通过AWS的用户界面提供实例，有一个由从未使用的AMI组成的组件，以及通过三种不同方式实现的配置。

随着公司业务开始腾飞，我们的工程师团队开始扩充，架构也开始日益复杂，但是生产环境的相关工作仍然局限于我们少数这些知道神秘陷阱的人。我们一直在逐步改善过程，但我们需要给我们的基础设施更深层次的改革以保持快速发展。

因此，几个月前，我们坐下来问自己：“如果我们今天设计，那么基础设施设置会是什么样子?”

在10周的过程后，我们完全重新设计了基础设施，我们撤下了几乎每一个实例和旧的配置，将我们的服务移到Docker容器中运行，并且切换为使用全新的AWS账号。

我们花了很多时间考虑如何使生产环境设置变得可审计、简单并且易用，同时仍然不失可扩展的弹性。

下面就是我们的解决方案。

独立的AWS账户

我们切换到了完全独立的AWS账户，而不是使用Region或者Tag来分离不同的预生产环境和生产环境实例，我们需要确保提供的脚本不会影响当前运行的服务，并且使用全新的账户意味着我们将从一张白纸开始。

运维账户提供了跳转和集中登录服务，团队中的每个人都有一个AWS IAM账户。

其它环境拥有一系列IAM角色来进行切换，这意味着只能有一个登录点来管理账户，也只有一个地方限制访问。

举个例子来说，Alice也许可以访问上图中的所有三个环境，Bob只能访问开发环境(哪怕他删除了生产环境中的负载均衡器)，但是他们都是通过同一个运维账户登录的。

作为对于复杂的IAM设置限制访问的替代，我们只是简单地通过环境来锁定用户并且通过角色来分组，从界面上使用每一个账户就像切换当前的活跃角色一样方便。

我们可以免费获得真正意义上的隔离，无需额外配置，而不是担心预生产环境沙盒会不安全或者会改动生产环境数据库。

分享配置代码带来的额外好处就是我们的预生产环境事实上将会成为生产环境的一个镜像，配置中仅有的区别只有实例大小和日期数目。

最后，我们也可以跨账户合并账单。我们使用相同的发票来支付月付账单，可以看到一个按照环境来分割的详细分解后的费用。

Docker和ECS

一旦我们设置好了账户，接下来就是轮到如何设计服务真正运行了，为此，我们转向了Docker和EC2容器服务(ECS)。

截止今天为止，我们大部分的服务都运行在Docker容器里，包括我们的API和数据流管道。容器每秒钟都会接收数千次请求，每月处理500亿条事件。

Docker的最大好处就是可以一定程度上授权团队从无到有构建服务，我们不再有一组复杂的配置脚本或AMIs——我们只需交给生产集群一个镜像然后运行即可。不会再有有状态的实例了，我们可以保证预生产环境和生产环境运行的是一模一样的代码。

配置完我们的服务如何运行在容器里后，我们选择了ECS作为调度器。

在一个较高的水平，ECS负责在生产环境中实际运行我们的容器。ECS关注服务的调度，即将服务放置在单独的主机上运行，并且在当连接到ELB时确保零宕机重载服务。ECS甚至可以通过AZs调度提供更好的可用性，如果某个容器挂了，ECS会确保在集群中重新调度一个新的实例。

切换到ECS极大地简化了运行服务的工作，从而不需要担心Upstart工作或者配置实例。添加Dockerfile、设置任务定义以及将其和集群关联都是非常容易的。

在我们的设置中，Docker镜像通过CI(持续集成)来构建，然后再推送到Docker Hub。当一个服务启动时，会从Dokcer Hub上拉取镜像，接着ECS就可以跨机器调度了。

我们将服务集群按照它们的关注领域和负载profile(比如针对API、CDN、APP等的不同的集群)分组，拥有分离的集群意味着更好的可见性以及针对每一个集群都可以决定如何使用不同的实例类型(因为ECS没有实例关联的概念)。

每一个服务都有一个特定的任务定义，指出了运行在哪一个版本的容器里、运行多少实例以及选择哪一个集群。

在运行过程中，服务通过ELB注册它自身，使用健康检查来确认容器是否准备好运行。我们在ELB中指向一个本地的Route53条目，这样服务借助于DNS可以互相通信和简单地引用。

设置非常的棒，因为我们不需要任何服务发现，本地的DNS就完成了所有的记账工作。

ECS可以运行所有的服务，我们从ELB获得了免费的CloudWatch监控指标，这比起在启动阶段就不得不通过一个中央认证授权中心注册服务要简单多了，并且最大的好处还是在于我们不需要亲自处理服务状态冲突了。