Week4 总结

因为互联网系统面临一系列的挑战，需要面对高并发、大流量、高可用、安全性、扩展性；在面对更高的并发时原有的系统架构已不能满足性能需求；这就促进了互联网系统架构演进，而且是逐步向前发展和演进的。有如下几个阶段：

【架构演化第零阶段】：这是最原始的应用程序开发架构，结构很简单：一台服务器，部署单例应用和一个数据库；在尝试阶段或者验证阶段只要少数几个人使用时基本能够使用；如何有更多的人来访问这个系统时，数据多了，请求多了需要的计算资源也多了，网络带宽也多了。首先可以垂直伸缩，提高硬件资源。就进入到第下一个阶段【应用数据分离】，应用程序和数据库部署在不同服务器，硬件资源、网络带宽、CPU资源多了，处理能力变强之后理论上可以支撑的更多的用户数、请求数和并发数；在用户数进一步提高，不断增加时，需要的资源更多，服务器的压力越来越大，此时需要提供更多的服务器计算资源。此时进入【架构演化第二阶段】增加缓存服务器，对于大多数应用，请求主要是读操作。读操作都经过数据库读取，数据库服务器的负载会非常大，而且效率是非常低。把读取的资源存放在缓存里，下次在请求同样数据时从缓存里获取，这样就可以大大提高系统响应速度，减轻数据库服务器压力。【第三阶段】用户请求进一步提高，达到几十万。而一个应用服务器线程数是有限的，可以同时处理的请求数也是有限的，更多的用户请求过来；一台应用服务器根本处理不过来，增加应用服务器进行水平扩展；跟负载均衡服务器构成集群；共同对外提供服务器。负载均衡调度器会把请求分发给不同的服务器进行处理，提高集群的并发数。用户量变得更多【数据库读写分离阶段】缓存会过滤掉一部分请求，在缓存数据过期和失效时，而且用户请求数量多，此时还是会有很多请求会到达数据库；数据库请求相比于缓存，它的响应速度是比较慢的，此时数据库的压力和负载就会非常大，数据库性能急剧下降，到时整个系统的响应变慢，甚至会卡住。此时需要采用数据库读写分离，具体方案有主从复制、主主复制、一主多从；增加数据库服务器资源，将读取操作分摊至不同服务器上；减轻每台数据库服务器负载，由于数据有多个备份也可以提高系统的可用性。进一步跟多用户访问【架构演化第五阶段】使用反向代理和CDN加速网站响应，使用CDN可以就近访问网络运营商数据中心部署的静态资源服务器中已有资源，可加速网站响应；在CDN没有访问到资源，请求继续下发到反向代理服务器，在反向代理 服务器中存在这些资源的话，则立即打包资源返回给CDN服务器，整体上这两种服务器加速了网站的响应，过滤掉很多请求；真正进入到服务供应商数据中心的请求将大大减少，对应用服务器集群等后面的所有基础设施的资源消耗，负载就小很多了。【架构演化第六阶段】使用分布式文件系统和分布式数据库。数据库的主从复制方案，无法解决数据库写的问题；在任何时候只有一台，所有的写操作都集中在这台主服务器上，这样主数据库服务器负载很大，写请求很多的时候数据库就撑不住了。早期的时候可以垂直伸缩增加CPU、内存、和带宽等资源，可以快速解决当前的问题。用普通服务器可以水平伸缩使用分布式数据库来解决。单台服务器的资源和处理能力是有限的，通过数据库表分片，将数据分摊到每台服务器上，这样每台服务器的负载就很小了；包括分布式文件系统也是一样；把大问题分解为小问题来解决，解决小问题是比较容易的，所有的小问题解决了，大问题也有解决了。【架构演化第七阶段】使用NoSQL和搜索引擎；在搜索数据时，数据库的查询效率是比较低、数据库资源紧张；搜索引擎使用数据库里的数据构建可以快速查找。没有事务性要求的数据，同时量比较大可以使用NoSQL数据库，通过Key-value查找，提高搜索性能。【架构演化第八阶段】业务拆分；之前应用程序包含很多业务功能，有一个单体应用承载，随着功能的增加，这个单体应用越来越大。很多开发人员来维护统一个单体应用系统变得越来越难，这时就需要进行业务拆分，不同的团队或小组负责不同的业务系统。拆分的系统都是一个集群，不同系统之间通过消息队列或者HTTP相互调用访问数据。【架构演化第九阶段】微服务和中台化；上一个阶段业务拆分了，但是有些共用服务，不同系统依赖这些组件，会存在组件版本及功能不一致的问题；后期问题会比较麻烦。这是从组件JAR包依赖的方式变成服务依赖；单独升级，每个系统访问的都是最新的内容。所有的这些服务构成一个中台。当有新的业务需求，开发新功能相同功能模块已有的可以直接复用，加快的系统开发，所有系统内容统一，整个系统变得更强大。【大数据与智能化】围绕应用系统产生的数据构建系统。