互联网公司的架构演进过程

单体应用架构

从单体应用架构发展到SOA架构，再到微服务架构，应用架构经历了多年的不断演进。

初生

​
在Web应用程序发展的早期，大部分的Web工程是将所有的功能模块打包到一起部署和运行。

在单体应用中，所有这些模块都集成在一起，这样的系统架构就叫做单体应用架构。

单体应用是最早的应用形态，开发和部署都很简单。

典型的技术是LAMP，即Linux、Apache、Mysql、PHP，但是PHP的性能并不是很好，随着网站业务的发展，越来越多的用户访问，这种架构的性能越来越差，越来越多的数据导致储存空间不足。这时候该怎么办呢？将应用服务与数据服务分离。

应用服务与数据服务分离

在扩展的过程中，应用服务器需要更快更强大的CPU（处理大量的业务逻辑），数据库服务器需要更快的硬盘和更大的内存（快速磁盘检索和数据缓存），文件服务器需要更大的硬盘（存储大量用户上传的文件）。

不同的服务器承担不同的服务角色，提高了并发处理能力，扩大了数据存储空间，整个系统的性能会有较大提升。

可是随着用户增多，网站再次面临挑战。数据库压力太大导致访问延迟，进而影响整个网站的性能，用户体验感极差！这时候该怎么办呢？使用缓存提高性能。

使用缓存改善性能

使用本地缓存速度会极快，但是空间有限，使用远程分布式缓存速度稍慢（相对本地缓存来说稍慢，但也很快了），但是可以按需扩展。常用的缓存组件是Redis、Memcache。

随着用户逐渐增多，单一应用服务器面临新的问题。能够处理的请求连接有限，在网站访问的高峰期，应用服务器成为整个网站的瓶颈。这时候该怎么办呢？使用应用服务器集群提高性能。

应用服务器集群

使用应用服务器集群，可以有效改善网站的并发处理能力。

负载均衡服务器需要满足高性能、高并发处理能力。

使用缓存之后，虽然大大减轻了数据库的读压力，但是面临新的问题。有一部分读操作（缓存访问不命中、缓存过期）和全部的写操作要访问数据库，当用户达到一定规模后，数据库因为负载压力过高而成为整个系统的瓶颈。

这时候该怎么办呢？将数据的“读”和“写”分离，以此来提高性能。

数据库读写分离

这里有一个数据访问模块，数据访问模块主要由以下三种来构建：①在MyBaits中开发插件；②Mycat；③Sharding-JDBC。

随着用户规模越来越大，分布地域越来越广，地域网络环境差别很大，如何保证用户的访问体验，不至于因访问慢而流失用户呢？可以使用反向代理和CDN加速。

反向代理和CDN加速

反向代理和CDN加速（比如代理商）可以把静态资源缓存起来。

能够加快用户访问响应速度，减轻后端服务器的负载压力。

但是，随着用户量的增加，数据的积累，单文件服务器、单数据库服务器难以存下日益增长的数据。这时候该怎么办呢？我们可以使用分布式文件系统和分布式数据库系统。

分布式文件系统和分布式数据库系统

随着业务的发展，数据的存储需求和检索需求越来越复杂，这时候面临的问题是：存储的字段差异过大，出现骷髅表（这里空一块，那里空一块）；文本检索需要越来越复杂。

这时候该怎么办呢？可以使用NOSQL和搜索殷引擎。

使用NOSQL、搜索引擎

搜索引擎用什么？Lucene、Solr、ElasticSearch.

NOSQL用什么？MongoDB、ElasticSearch

网站越做越好，业务不断扩大，越来越复杂，这时候应用程序将变得无比庞大，迭代周期越来越快，牵一发而动全身，怎么应对快速的业务发展需要？需要将业务进行拆分。

业务拆分

如大型电商网站会将首页、商铺、订单、买家等拆分成不同的产品线，分归不同的团队负责，分成不同的应用，独立部署。通过链接、MQ、数据存储系统建立联系。

随着业务规模不断增大，应用拆分越来越小，越来越多，这时候应用间的关系越来越复杂，应用中存在大量相同的业务操作。同时后端的数据库要被成千上万台应用服务器连接，数据库连接的资源不足了。

分布式架构：SOA架构和微服务架构

这时候需要采用分布式（服务化）的架构方法。

服务化的两种架构方式：SOA和微服务。

开发方面。在两种体系结构中，可以使用 不同的编程语言和工具开发服务，从而将技术多样性带入开发团队。开发可以在多个团队中组织，但是在SOA中，每个团队都需要了解常见的通信机制。另一方面，使用微服务，服务可以独立于其他服务运行和部署。因此，频繁部署新版本的微服务或独立扩展服务会更容易。

“上下文边界”。SOA鼓励组件的共享，而微服务尝试通过“上下文边界”来最小化共享。上下文边界是指以最小的依赖关系将组件及其数据耦合为单个单元。由于SOA依靠多个服务来完成业务请求，构建在SOA上的系统可能比微服务要慢。

通信。在SOA中，ESB可能成为影响整个系统的单一故障点。由于每个服务都通过ESB进行通信，如果其中一个服务变慢，可能会阻塞ESB并请求该服务。另一方面，微服务在容错方面要好得多。例如，如果一个微服务存在内存错误，那么只有该微服务会受到影响。所有其他微服务将继续定期处理请求。

互操作性。SOA通过消息中间件组件促进了多种异构协议的使用。微服务试图通过减少集成选择的数量来简化架构模式。因此，如果您想要在异构环境中使用不同协议来集成多个系统，则需要考虑SOA。如果您的所有服务都可以通过相同的远程访问协议访问，那么微服务对您来说是一个更好的选择。

大小Size。SOA和微服务的主要区别在于规模和范围。微服务架构中的前缀“微”是指内部组件的粒度，意味着它们必须比SOA架构的服务往往小得多。微服务中的服务组件通常有一个单一的目的，他们做得很好，另一方面，在SOA服务中通常包含更多的业务功能，并且通常将它们实现为完整的子系统。

我们不能简单地说一种架构比另一种架构更好。这主要取决于你正在构建的应用程序的目的。SOA更适合需要与许多其他应用程序集成的大型复杂企业应用程序环境。这就是说，小型应用程序不适合SOA架构，因为它们不需要消息中间件组件。而微服务架构，在另一方面，是更适合于较小和良好的分割，基于Web的系统。另外，如果你正在开发移动或Web应用程序，那么微服务作为开发人员可以为您提供更大的控制权。最后，我们可以得出结论，因为它们服务于不同的目的，微服务和SOA确实是不同类型的体系结构。

大数据技术、监控、日志分析系统

再往后，需要什么了？
数据挖掘、分析、推荐等业务需求，庞大系统的监控。问题分析等需求。

资源获取

关注公众号“fairboylil”，后台回复“001”，获取高清图片及互联网架构演进PPT讲义。