从一台服务器到几百台服务器的架构变迁

最近经常被问到或者看到一些关于网站高并发量的问题，恰好看到微信里面的这篇文章（一家创业公司的5年架构变迁史），今天就里面一些我还不理解的知识点进行整理，持续学习。

文中所提到的该公司服务器从单体架构到几百台分布式部署架构的情况，记录的是一个公司的成长变化。就像我现在所在公司一样，现在还是一家名不见经传的小公司，每天用户的请求量架构已经足够了。但是如果慢慢扩大呢（虽然我觉得不可能），所以从0到n是一个什么样的变化过程，需要什么样的技术支持呢？

一、第一阶段

创业初期的状况文章解释的非常清楚和准确了。刚创业的公司并不需要太多复杂的业务逻辑，在开发过程中，追求快速迭代。能够满足基本但是不简陋的要求即可，选择过于复杂的技术架构，会加大学习成本，增加开发难度，拖慢项目进度，对公司的发展而言，并不是一件好事。

二、第二阶段

架构简单，时间越长暴露的问题越多，文中描述的情况相信很多人都在经历，例如我现在所在的公司，所有的接口都放在一个文件夹里面，接口越来越多，文件越来越难找。有些相关的业务接口分布混乱。数据库表字段的定义也含混不清，有不少冗余字段。维护较难，bug较多，这时候就到了需要重构的时候。下面是他们第二版的架构图

可以看到，系统级别根据业务要求进行了拆分，第三方服务也分别封装。数据库也做到了物理拆分和主从数据库分离，并且引进了MQ消息队列（消息队列的基本概念）和SLB实现负载均衡（就是流量分发，不让大部分流量涌进同一台服务器，造成服务器压力以及浪费）和带宽流量入口（网站带宽与网站流量的关系）。

三、第三阶段

微服务的定义（微服务的定义）：微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务都可以独立部署，各个微服务之间都是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

第三阶段采用现在时新的微服务，将业务逻辑拆分为独立的微服务组件，每个微服务都围绕着具体业务进行构建，由专人研发和维护，并由专人做性能优化和架构优化，各个微服务组件的研发与上线互不影响。

个人认为这篇文章对我们这种小白来说很有价值，后面还有很多我就不一一列举，因为没有实践过，不好妄下定论。大家可以自己研究一下这篇文章，相信也有不少收获。