I. Introduction
The evolution of the Internet architecture is divided into three periods: the era of stand-alone, distributed and clustered age era. Three era history is not in accordance with the chronological order, more time is determined by the team or product is located.
Second, the process
-
Stand-alone era
Internet early, like Hang research team when the start-up of a product, limited resources, lack of manpower, in order to quickly develop a product, or a web site on-line, stand-alone often is a good choice, at this time will be an application, file serving, database services and other resources are concentrated on a single Server. Where the application is usually a whole package and deploy the specific format depends on the language and framework applications, such as Java WAR file, Rails catalog file, this architecture often referred to as single architecture.
Monomers architecture
FIG system architecture often longer like this:
Figure-1: Single Age -ALL IN ONE
advantages: As described above, simple and rapid, easy to develop, easy to test, easy to deploy
disadvantages: very significant only for early projects, large after difficult to maintain, and there is a single point, the upgrade needs to stop takingLayered architecture
An observant people soon discovered that at this time of the application architecture appear disorganized, which may exist in the early Web development, such as the use of JSP + JDBC, ASP + ADO, but this is clearly not a friendly standard architecture, so stratified architecture emerged, layered architecture as shown, is generally divided into the presentation layer (Presentation), the business layer (business), persistence (persistence) and a database (database). Actually, this is the most common of the MVC architecture.
Figure-2: Stand-alone era - Software Architecture - layered architecture
system architecture diagram after transformation as follows:
Figure-3: Stand-alone era - layered architecture
advantages: simple structure, clear division of labor, hierarchical test, if you do not know what software when architecture is recommended to use it
Cons: poor scalability, low efficiency of iterative development, sometimes leading to excessive levels of process complexityData separation
添加了分层架构，应用上好看点了，团队的开发效率有了一定的提升。此时业务量进一步增大，并且有了一定的用户规模，逐渐发现一台主机上应用和数据资源争夺的非常厉害。因为每种服对硬件资源的要求是不同的，应用服务器需要更快的CPU，文件服务器需要更大的硬盘，数据库服务器需要更大的内存和硬盘，于是决定把应用和数据服务分离，形成了如下架构：
图-4: 单机时代-数据分离
优点：资源分散，提高不同服务对硬件的利用率，方便维护
缺点：增加了资源消耗和网络开销，同时还存在单点缓存登场
产品有了一定的口碑，用户量持续增长，访问开始频繁，想提升访问速度，缓存必不可少，闪亮登场。
图-5: 单机时代-缓存登场
服务端缓存又可以分为本地缓存和远程缓存，各有优劣，本地缓存访问速度快，但数据量有限，而且后续集群化不方便共享；远程缓存可以共享，可以集群，容量不受限制，但要注意缓存更新的问题。
优点：简单有效，减少对 DB 的查询
缺点：增加逻辑判断，不适合存储大对象，此架构同样有单点读写分离
市场反响不错，业务也在持续增长，但性能又有所下降，分析整个架构，发现数据库读写非常频繁，甚至有些业务，读大于写，单台数据库服务器又成了瓶颈，此时就可以尝试做读写分离和主从复制了。
图-6: 单机时代-读写分离
优点：降低数据库单台压力，从机的数量可以灵活变更
缺点：架构开始变得复杂，维护难度加大
自此，单机时代的架构已然成型，“麻雀虽小五脏俱全”，初期已经能很好的支撑业务的运转。但随着业务的增长，各个模块还是可能出现瓶颈。而单机时代最大的问题，就是整个架构都存在单点，这个问题将在集群时代一一解决。 -
集群时代
单机时代，做了不少措施来缓解数据库层的压力，包括服务器分离、引入缓存、数据分离等，但随着访问量的猛增，对高可用的要求越来越高，减轻应用层压力、解决单点问题是当务之急，这就是集群时代需要做的事情。
负载均衡
代码是架构的基础，但前期改造代码的工作量较大，如果人员变动频繁，那风险就更高了，所以提高服务器性能，常用的手段还是先将应用集群化，做负载均衡。
图-7: 集群时代-负载均衡
优点：去除应用层单点，可用性得到保证，性能有所提高
缺点：这时要注意应用之间的一致性问题，比如对缓存的访问，对Session的存储冗余集群
以上一个中型网站架构基本成型。当中型网站继续向大型网站演进，最终的目标是要保证“三高”：高并发、高性能、高可用。以上架构基本可以满足性能需求，接下来更多的是关注“高可用”，确保“无单点”。
此时，就要对关键的服务，做冗余集群负载。
理想情况下，我们将以下服务/应用都集群化：
数据库服务集群
文件服务集群
缓存服务集群
应用服务集群
负载均衡调度器集群
静态内容服务集群
CDN服务器集群
图-10: 集群时代-冗余集群
优点：去单点，高可用
缺点：数据有状态问题、数据一致性问题，资源成本、人力维护成本都上去了
到此为止，一个大型网站的架构也基本成型了，能“加机器”的地方都加完了，是不是就终结？当然不是！伴随着 DT/分布式 时代的到来，大流量和大数据的场景的出现，对应用提出了更高的要求，接下来就需要对应用程序开刀了。 -
分布式时代
应用拆分
在前面，我们只是把应用程序做了分层架构，在创业初期或产品前期还是一个不错的选择。虽然应用也做了集群和负载均衡，但应用架构层面还是“集中式”的。随着业务越来越复杂，网站的功能越来越多，应用拆分势在必行了。
优点：应用解耦，分拆团队负责，分而治之
缺点：架构变复杂
应用拆分之后，还伴随着一个相互依赖、公共模块的问题，特别是依赖于相同的逻辑或功能代码。这时就可以考虑将这些共用的服务提取出来，独立部署，统一治理，提高重用度，这就是面向服务的架构（service-oriented architecture，缩写 SOA）了。消息队列
应用拆分、服务独立部署之后，还是会出现一些通信或依赖问题，这时就可以引入消息队列，提高吞吐量。
优点：异步、解耦，提高吞吐量
缺点：消息消费延迟等问题
数据分库
应用拆分之后，DB分库理所当然，否则多个应用连接在单个数据库上，连接数、QPS、TPS、I/O处理能力都非常有限。
优点：DB分压，降低耦合
缺点：数据访问模块冗余、复杂
提到分库，不少人会想到分表，这一块我并未实践过，不好下笔。但想来会引入更复杂的数据架构和数据一致性问题，而且市面身上成熟开源的分库分表方案并没有，保不准又是一个深坑。拆或不拆，也是一个值得思考的问题。微服务架构
微服务架构（microservices architecture）一度成为热点，在文章、博客、大会演讲上经常被提及。微服务并不是凭空出现，有人说，它是面向服务的架构（SOA）的升级，在此之前，还有诸如集中式架构、分布式的架构等。这里借用一副抽象的图来描述下常见的几种架构：
图-11: 分布式时代-微服务架构-抽象对比
微服务架构由多个微小服务构成，每个服务就是一个独立的可部署单元或组件，它们是分布式的，相互解耦的，通过轻量级远程通信协议（比如REST）来交互，每个服务可以使用不同的数据库，而且是语言无关性的。它的特征是彼此独立、微小、轻量、松耦合，又能方便的组合和重构，犹如《超能陆战队》中的微型机器人，个体简单，但组合起来威力强大。
图-12: 分布式时代-微服务架构
优点：扩展性好，服务之间耦合性低，服务间相互独立，容易部署，易于开发，方便测试每一个服务
缺点：容易过度关注服务的大小，可能拆分的很细，导致系统依赖于大量的微服务，而服务之间的相互通信也会变得复杂，系统集成复杂度增加，很难实现原子性操作。
微服务之所以这么火，另一个原因是因为 Docker 的出现，它让微服务有一个非常完美的运行环境，Docker 的独立性和细粒度非常匹配微服务的理念，Docker的优秀性能和丰富的管理工具，让大家对微服务有了一定的信息，概括来说 Docker 有如下四点适合微服务：
独立性：一个容器就是一个完整的执行环境，不依赖外部任何的东西。
细粒度：一台物理机器可以同时运行成百上千个容器。其计算粒度足够的小。
快速创建和销毁：容器可以在秒级进行创建和销毁，非常适合服务的快速构建和重组。
Perfect management tool: a large number of containers schedule management tool that can quickly realize the combination and scheduling services.
Of course, good architecture and technology, to be applied in practice, allowing users to recognize the job, which requires rich scene application on top of the micro-service architecture and Docker technology. NetEase is also actively exploring the scene of cellular micro-service architecture and service platform cloud container, please take a practice landing.
So far, three era architecture changes introduced complete. Overall architecture is not static, stop time, more than progress, so people, architecture remains.