写在开始
故事的开始是这样子的，我在一家创业公司从事教育工作，也可以翻译为在一家教育公司从事创业工作。
使用比较流行的JAVA作为开发语言，从struts1到struts2再到SpringMvc，Spring boot，Spring cloud；从Mysql到MongoDB、Solr再到Redis(毕竟免费开源是创业公司的必备)；从网站单体架构到集群分布式再到现在流行的微服务架构。当然，我们还没上升到docker这种轻量级的、可移植的、自给自足的容器。
产品研发初始，我们跟其他创业型小公司一样，采用MVC架构，四五个人轻轻松松在没有产品，设计、架构，测试的情况下，把项目搞定了(当然这只是个试验品，尼玛太狗血了有木有...)。
各位看官不要急，先听个小曲。
上云前
一、项目发布的第一阶段：Tomcat+Mysql， 这时候产品基本处于内测阶段，基本就是开发点点，领导看看。
生火烧水
初始阶段用户量很小，我们的应用和数据库服务是放在一起的。随着业务的扩展，一台服务器已经不能满足用户需求，因此我们将项目应用、数据库各自部署在独立的服务器上，暂且算是第一阶段。
二、项目发布的第二阶段：Nginx+Tomcat+Mysql+FastDFS，用户量阶段性稳步增长。
随着用户的增长，虽然为TOMCAT设计出NIO的Filip HanikTomcat测试过其最高支持了16000个并发连接(我比较心虚，虽然NIO.2采用异步非阻塞，多路复用的模式，但毕竟然而并且和生产环境还是差很远的)，但是单台App Server再强劲，也有其瓶颈，高速路修的再好，改堵还不是一样坐下来一起打牌。
我们秉着少花钱办实事，开源万岁的宗旨，于是前端增加了Nginx反向代理。在开始业务还不是特么大的时候，我们采用纵向集群，这样可以充分利用原有内存，尽管CPU未得到扩展。随着业务量的增长，升级为横向集群，好处是CPU，内存都扩展了，处理能力也扩展了。坏处是，又得财务拨款了并且要维护多台服务器。
维护服务器的痛
进而逐步优化，加入GIZP静态文件压缩，文件缓存，动静分离以及负载均衡(由一开始的ip hash升级为加权轮询，session有Redis统一管理)的配置，来加速用户请求响应。
此时此刻你以为就可以坐下来喝茶了吗？
由于系统架构调整，项目集群后可能就是两个甚至多个Tomcat了，对于用户来说一切操作都是透明的，他们根本不用关心后台是如何运行的。就上传图片来说，用户一点上传，可能上传到了Tomcat1中，但是下次要显示这个图片时，可能会被轮询到Tomcat2，然后可怕的404就来了。
你以为我没穿内衣吗？其实我还小！
一开始，我们为了简平快，我们把所有的文件都存放在服务器一个叫fileserver的目录文件下，以软连接的形式提供给各个项目，集群中的项目文件统一软连接到fileserver下。
然而随着文件容量的快速增长，文件的存储和读取终将是一个不可言喻的痛。终于我们购买了一台强力存储型服务器作为文件存储(哈哈哈~~这个来的稍微有点晚哈，不要问我为什么？因为这个我说了不算)，采用NFS挂载的方式为各个服务器提供文件服务。
然而你以为这样就完了吗？水还没烧开呢，继续等！单点故障是很可怕的，特别是在数据时代，任何数据的丢失都是你交不起的学费 。有人说过一个看似不恰当的例子，大脑对与人来说，就是一个单点，大脑损坏，人就完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。
一个网站，从基础的硬件层，到操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。如果要有效地消除单点故障，最重要的一点是设计的时候要尽量避免引入单点，随着架构的变化，定期审查系统潜在的单点也是有必要的。说了这么多，消除单点的最常见的做法，增加冗余。运维人员(其实就是开发人员，小公司啥都得会)催促财务赶紧采购了三台同样强力存储型服务器，最终我们采用FastDFS实现了分布式存储。
三、项目发布的第三阶段：Nginx+Tomcat+Mysql(读写分离)+mycat+FastDFS
知道这绿绿的东西是什么吗？农村烧火神器鼓风机，城市的娃请自行脑补！
虽然尽管并且楼主本身自带多线程异步处理功能，水已烧开，然而楼主一直被占用着没时间去捣鼓茶具。目前第二阶段，我们只能解决前端访问和业务逻辑层的压力，在网站的用户达到一定的规模后，数据库因为负载压力过高而成为网站的瓶颈。这时候，我们采用Mysql自带的主从热备功能+Mycat数据库中间件实现读写分离、逐步SSD优化、垂直分库，水平sharding分库等等，也许这些只有经历过才深有体会吧。
在读写分离阶段性放松以后，随着数据量的增加，数据库的压力又变的的越来越大。在大部分的网站系统中，都会利用缓存技术改善系统的性能，使用缓存主要源于热点数据的存在，大部分网站访问都遵循28原则（即80%的访问请求，最终落在20%的数据上），所以我们采用Redis分布式缓存对热点数据进行缓存，减少这些数据的直接访问，提高用户体验。
就这样，我们又赶紧采购了多台服务器做数据库主从集群和分布式缓存服务，顺便我把茶具给准备一下。
四、项目发布的第四阶段：Nginx+Tomcat+Mysql(读写分离)+mycat+redis+keepalived
上面有提到单点故障是很可怕的，任何生产环境的事故都是你交不起的学费。然而此时此刻前端代理服务器节点只有一个，如果挂掉绝壁不是404那么简单的问题了。这时候我们使用keepalived实现双机热备，当提供服务的一台出现故障的时候，另外一台会马上自动接管并且提供服务，而且切换的时间非常短。
来来来，各位看官，茶沏好了，不妨闲来品品！
五、项目发布的第五阶段：微服务架构
流行的不一定是最适合的，但一定的最先进的，就如党代表最先进的生产力一样不容置疑。这个阶段我们对各个产品进行的拆分，服务单元化，采用分布式服务框架Dubbo作为RPC远程服务调用方案。
我只是互联网的搬运工。
然后逐步增加了一系列开源组件，Logstash、Elasticsearch、Kibana作为日志采集分析存储，Solr作为全文检索，ActiveMQ作为消息队列，MongoDB实现分布式文件存储的数据库，JavaMelody 监测Java或Java EE应用程序服务器，Zookeeper做分布式同步以及集群管理，Jenkins+Git+Maven+Shell持续集成......
省略号是什么鬼？
然而你以为故事就这样结束了吗？你想静静的喝茶，你以为静静就会让你安心吗？
为什么上云
由于我们的服务器分布在各个地方，各种各样棘手问题需要来应对，服务器托管(冰冷的机房再也不想进去了)，集群配置管理、监控报警、系统升级以及开源组件的优化维护；IDC服务商的网络出现故障，黑客的侵入，还有各种流量带宽的猫腻......
选择云
为了应对种种问题，我们决定云平台化，由于XX云、XX云、XX云等厂商与阿里云整体实力悬殊，当然个人也在使用阿里云的原因，最终选择了阿里云。
2012年记得知乎上很多同学不看好阿里云服务，然而今天阿里云的种子即将播向全球，又是狠狠的一记，幸好没有打在我脸上。
云产品选购和解决方案：https://www.aliyun.com/easybuy
一、通过方案，我们可以轻松的选择所需产品，ECS、RDS 、 OSS以及CDN等
二、安装镜像环境(一键安装)，同步数据库(RDS自带神器)，部署系统相关依赖环境
三、迁移代码库到云平台
四、部署持续集成环境
五、项目架构部署以及A/B测试与灰度发布
六、迁移云完毕
上云优势
一、按需扩充计算能力和云市场全方位的服务，只需要付钱，一分钟搞定。对于中小企业来说，有时候，花钱能马上解决问题，其实是最节约的方式。
二、安全是互联网永恒的话题，阿里云有国际顶尖的安全资质认证。阿里云提供了云盾安全管家提供检测和防御功能，为客户保驾护航。DDoS防护，防御大流量DDoS、CC攻击，按天付费，单线路超过300G防御能力；Web应用防火墙，网站安全必备防护产品，防SQL注入、防篡改、防CC、防刷、防爬虫，同时也可以满足您网站的定制化防护需求。当然还有很多防御功能，你所有碰到的问题解决方案都在这里可以找到。
三、阿里云提供了强大的云监控平台，对你所购买的云产品进行监控和警报。这样我们就可以通过警报发现问题，而不是用户投诉。
四、数据备份服务
对于任何一个企业来说，数据丢失都会是一件很麻烦的事情，任何生产环境的事故都是你交不起的学费，所以需要做很多的数据备份工作。
阿里云ECS供了快照功能，它可以保留某个时间点上的系统数据状态，用于数据备份，或者制作镜像。
阿里云EDS提供了全天候，可自定义频率的数据自动备份机制，确保数据不丢失。
五、阿里云提供完善的性能监控和秒级别的配置升级，能够先于业务方发现性能瓶颈同时能够马上升级对于的配置。
ECS监控
RDS监控
如果让我把上云的好处一一道出，我觉得上云前的痛楚就是一个个好的教材。对于中小互联网企业来说，能牢牢的抓住流量暴涨的难得机会，当自己的客户量或者访问量猛增的时候，能平稳的服务好自己的客户，是云计算带来的最大价值。
我想静静
来来来，喝茶~~~
后记(献给所有程序员)
我们程序员的努力与挣扎有时非常尴尬，如果没有结果，都是徒然。2017年，愿天下所有的程序员运用灵感的代码，编辑智慧的程序，发送抽象的指令，念动网络的密语，便将梦幻的理想变成神奇的现实。
