玩转云计算：教你在Akamai Linode上构建IT架构–定义项目

时至今日，选择以云计算方式来运维业务，已经成为大部分情况下的最优选。那么如果要从零开始开发一个新应用，并依托云平台来设计、开发、部害和远维，具体该从何处下手？这一系列文章将介绍如何基于Akamai Linode平台实现这个目标。

欢迎阅读这一系列文章的第二篇。本篇我们将定义“Demo”这个项目的基本场景和要求，并在Akamai Connected Cloud上进行构建。

欢迎点击这里回看本系列的第一篇，了解相关背景信息。

假设有一家名叫“Vapor”的公司，这是一家只销售游戏并提供游戏下载的线上公司。该公司原本使用了一家托管服务提供商（MSP）的服务，由于相关服务的体验非常糟糕，他们转为向Akamai寻求帮助。

除了追求更高性能外，Vapor的DevOps团队还希望能有更多实践机会，能够对“表面之下”的东西进行调优，这样整个解决方案就可以重新架构，以适应新的云提供商。

项目分为两个主要阶段：

（关键阶段）对当前平台进行平移（Lift and shift），以最小代价对其进行改进；随后引入监控和管理软件，并创建管道。当前使用的解决方案，其停机时间较长，直接导致了大量收入损失。
利用Akamai的Kubernetes托管服务（LKE）和计算能力对整个栈进行容器化和现代化。此外，Vapor还计划在不久的将来进驻亚太、欧洲、中东和非洲以及美洲，因此在设计基础架构时应考虑到这一要求。

基于PHP和MySQL开发的定制化应用程序，其中包含数千篇文章。

应用程序在负载均衡器之后的八台Web服务器上运行。使用独立主机运行MySQL数据库引擎，游戏数据则存储在200TB的对象存储中。

硬件规格：

8台Web服务器：每台16个CPU内核，64GB内存，200GB SSD存储
- CPU平均用量为70%
- 内存用量为80%
- 平均IOPS为400
数据库服务器：32个CPU内核，128GB内存，500GB SSD存储
- 数据库约300GB，每季度增大10%
- 内存用量90%
- 平均IOPS为5500，偶尔激增至10000 IOPS
负载均衡器
平均每秒1000个请求，偶尔激增至每秒2500个请求
对象存储
目前托管在另一个云提供商平台上

监控和管理由目前的MSP负责，因此在选择监控、访问、安全等技术时，有一个开放的竞争环境。

在开始编写任何代码（没错，要做的一切都将用代码完成）之前，我们需要定义项目目标、功能性和非功能性需求，并尝试预测一下未来。

首先是项目的主要目标

如图所示，我们的基础架构布局可细分为经典的DT(A)P方法，以及管理和备份账户。

管理账户将运行基础架构运转所需的所有“操作”服务，如监控、构建和部署管道、安全工具、安全访问服务等，我们将为开发/测试和生产工作负载提供专门的开发、测试和生产账户。这样做的目标是使开发、测试和生产账户在规模以外的各方面都完全相同。这将确保运行的所有基础架构和应用测试都能提供真实的结果。

最后，我们将在不同地区使用专用的Akamai Connected Cloud账户，并通过这些账户运行备份软件和灾难恢复基础架构。此外，可能需要的任何Akamai Connected Cloud服务（如虚拟机、对象存储、LKE集群等）也将部署在相应的（DTAP）账户中。

这样做的目的是尽可能将所有环境在物理和逻辑上分开。

整个基础设施将使用代码构建，第一阶段主要使用Terraform和Ansible；到第二阶段，我们将研究使用Kubernetes和应用程序管理工具及管道。具体待定。

在下一篇文章中，我们将开始定义整个项目的功能性和非功能性需求，深入到具体类别，并开始定义路线图。敬请期待！